Most zero-day exploits in web applications are usually easier to find, study, and attack than actual services like a webserver due to the fact that a hacker does not need to create shellcode, debug the service over and over or even know about the memory layout of the target machine. Furthermore, there are no opcodes to worry about, but there are usually some other sort of security mechanisms in place instead.

Case Study: Seo Panel

Whenever we have found a product that we would like to fuzz and/or audit (review the source code), the first step is to install a local copy of the application on your own test server. Don’t fire against external targets or for that matter, even a demo site of the application, since it may have been altered (as in limited) and the configuration of the webserver could also disable certain types of attacks as well.

Keeping this in mind, we continue to the actual installation which is relatively simple in this case.

First, we check that the following prerequisites are installed:

• Apache
• PHP
• MySQL
• PHPMyAdmin (optional)

This is, of course, only going to work if we are attacking an application that depends on PHP and MySQL, and in this case we are.

Creating a new database with phpMyAdmin is relatively simple as shown below.

When the basic requirements are fulfilled such as:

• Files are stored in the right “document_root” directory
• A new database and a user for this application is created

Then we are ready to browse to the directory in our browse which in this case redirects us to the installation directory.

Following the steps is relatively simple and in case you use XAMPP, find (the right) php.ini and uncomment “curl” under extensions.

When that is done then, it is always good to take a look at how the site works in order to get an idea of how function calls are made, and perhaps test a few of them with a “locator string”. I tend to use something like “testing’/\>< which can break almost any unsanitized function accepting user-input.

After browsing for a while, the sitemap function was discovered, which looked quite interesting.

The reason why this appears to be interesting is because a filename is in one of the GET-parameters of the URL, and as you can see, the file is stored locally so that means we’re loading a file from our file system.

So of course the first thing to do is to check whether it is possible to load a local file and then see if an error was returned or if we were successful. In this case, “COPYING” was tried, which is 1 directory below the “tmp” directory where sitemaps are stored, so logically the following string should make us able to load that file: ../COPYING

You are not allowed to access this file!

When such a message appears, it is time to investigate why so we can determine whether the security feature is really working (as in implemented correctly) or not.

Since it’s the download.php file we’re requesting the file from, opening that to get a clue is the best choice for starters.

So it appears that a reference to a custom function is there and after looking at the includes we figure it may be download.ctrl.php which contains this custom function.

While taking a quick look, it may not be easy to notice but there is another custom function which checks whether the file is valid or not.

Basically, the input is first decoded according to the urldecode() builtin PHP function, and then all “../” are replaced with nothing, and finally the end of the file must match: .xml, .html or .txt

A long time ago, this may have seen impossible but it is really not. The regular expression has a basic flaw allowing us to add a 00-byte to our string so if we wanted to load a file named: hax0r.php in the current directory, then we would simply write: hax0r.php%00.txt just as an example.

Bypassing the other feature which should disable directory traversal completely is a bit more tricky, but after taking a deeper look it is actually not that hard to bypass.

This may seem obscure, but notice that ../ and not .. is replaced with nothing. This makes us able to supply a somewhat obscure string: ….//

I didn’t say it would make sense, but take a look at ….// and then “deduct” ../ from it. Remember that the function only searches for references to ../ and then removes them once. (It does not loop through the string several times.)

After finding out this relatively simple bypass, we try the following string: ….//COPYING%00.xml and notice we are greeted with either a direct download of the file or a direct text version of it.

File Disclosure for Fun and Profit

In this case study, files containing passwords and similar are the most optimal to read since we can’t really execute any code on our target with this vulnerability alone. But after studying this particular application we discover that the configuration file sp-config.php is located within the “config” directory.

By supplying the following string: ….//config/sp-config.php%00.xml we are able to download the configuration file and read the credentials for the database.

If the database server accepts remote connections from external networks, we can log into this database server and perhaps inject a browser exploit to target a potential target user via an iframe, during a deeper penetration test against a target company.

Even file disclosure vulnerabilities can become critical, though it really depends how the target is configured.

~ MaXe

References:
[1] Seo Panel Critical File Disclosure
[2] http://www.youtube.com/watch?v=ni3inoHkOPc

Discuss this post in our Forums

Note: This post is from Exploit-DB by MaXe, just for the sake of knowledge sharing! and Download PDF File