AcuSensor and the pink blog

While testing our AcuSensor technology, I downloaded a small PHP blog application from the internet. The installation went smoothly. This particular application was not using a database but it was storing everything in text files. I added a sample blog post and I was ready to start the scan. The application looked like this before scan:

I was very surprised when the scan finished as the application now looked like this:

Quite funny 🙂 There are a number of differences between these two images. First, the top color was changed somehow during the scan (from blue to pink). Second, the blog post disappeared and third, error messages were displayed everywhere.

At first, I didn’t know how to figure out what’s going on, so I restored the application and scanned it again. After a few seconds since I started the scan, the application stopped working displaying some more error messages. A few minutes later, two more error messages appeared and in the end it looked like the second image again.

Then it clicked my mind that this application doesn’t use a database, but text files. Therefore, I should easily be able to understand what’s going on by comparing all the files from the application directory before and after the scan. So, I started Beyond Compare (great software BTW) and compared the two directories. Below are the comparison results.

I’ve configured Beyond Compare to display only mismatches, and a few files were reported. As you can see one of these files is settings.php. This is the configuration file for the application.

It seems that Acunetix WVS managed to somehow modify the settings.php file while scanning the application, which is pretty bad. The differences are shown below.

One can notice a lot of changes; almost all settings are blank now except $skin which somehow managed to get the value “pink” 🙂 I also noticed that a few settings are also missing, such as $rss_title, $blog_offline and so on. So finally we figured out why the application stopped working. The settings.php file got corrupted during scanning.

Now let’s investigate the source code to better understand what’s going on.

But how would you know where in the code you should start looking to fix problem? It could be a very complicated task and it depends on how the code is written. At this point I got the idea that it would be cool to modify AcuSensor to report these kind of problems, i.e. when user input gets written to a file.

So, we modified AcuSensor and came up with an alert named File Tampering. The scanner detects when user input is written to a file on disk. This alert requires user confirmation. There may be a false positives in some cases (for example, when the application is creating a log/text file). It depends on the file that gets written and how/if the user input is sanitized before being written to the file.

We ran the scan again and AcuSensor reported 17 File Tampering alerts. The nice thing about these alerts is that you know exactly where the problem is in the code . Let’s have a look at one of these alerts.

The problem is in cp_settings.php file, at line 85. Let’s take a look at this piece of code to see what’s going on in there.

As you can see, input from the user is directly written to the settings.php file without any kind of sanitization. Apart from that, this file requires no authentication. Therefore anybody can call this file directly and adjust the configuration parameters as he likes.

This can be exploited very easily by issuing a HTTP request like the one in the screen shot below:

The above request closes the quotes and inserts our custom PHP code in settings.php. We use the __halt_compiler() PHP  function to make things easier. This code gets written to settings.php and you can call it directly by accessing http://bld02/lb/settings.php.

Another interesting vulnerability found by AcuSensor in this application is Arbitrary File Deletion. Basically, the user input is used in an unlink() call and an attacker can delete arbitrary files from the server. Check the screen shot below:

The file cp_memberedit.php, around line 25, contains the following lines of code:

Again, this php script requires no authentication, therefore anybody can delete files by providing a malicious $_GET parameter. For example, http://bld02:80/lb/cp_memberedit.php?delete=../readme.txt%00 will delete the file readme.txt from the application directory.  The scanner found more vulnerabilities in this application but I think it’s enough for today.