Introduction

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 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.

The top issues in PHP-based websites are:

SQL Injections

SQL databases are the heart of 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

index.php?option=com_****&Itemid=name&cmd=section&section=-
      000/**/union+select/**/000,111,222,
      concat(username,0x3a,password),0,
      concat(username,0x3a,password)/**/from/**/jos_users/*

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.htm

SQL Injection 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 essence, it means trusting the users to put in the RIGHT stuff, and not put in queries meant to harm the system. User input is rarely to be trusted for this reason. It should always be checked for proper format, length, and range.

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 ('[email protected]','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_vulext 
        INSERT INTO jos_mydb_users
        ('email','password','login_id','full_name')
        VALUES ('[email protected]','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.