GSR-IconBannerAd_v1d

Security Advisories

Trustwave Press Releases

« TWSL2011-004: Cross-Site Scripting Vulnerability in ZyXEL ZyWALL 70 Firewall | Main | Patch the Vuln - Feathers - SQLi »

13 June 2011

Comments

thanks for your answer Dan, i'll dig it a little more ^^

@Lopj Yes, it's what I meant by "if the conditions are right". As I said in a previous comment, this method has gained me code execution in more than one pen test. Trust me, it works.

To clarify:
The application must allow uploading of .php files to the Web root as executable in a predictable place (or any of the equivalent extensions such as .php3, .php4, .phtml, .phtm...)
OR
There must be a file inclusion flaw
OR
If it's on Apache you can provide a double extension such as .php.gif (the gif is not assigned a handler, but it will be used as a mimetype and the .php extension will be used to determine the handling)
OR
You can upload a .htaccess file which defines .png or some other extension as PHP code

Anyway, it's more common than you might think. Developers generally put only one layer of defense against attacks in place, so if they're already checking the image properties to ensure it's an image, they will likely not place restrictions on file extensions. That said, I most commonly find file extension blacklisting used to defend upload scripts so this trick is often not necessary.

>PHP looks for instances of "/?php" (possibly "/?" as well depending on configuration) and "/?", then interprets the data between the two as code.

I think what you're telling won't work. unless the script lets you upload .php files (nice png header checking, then no extension check/modification... not impossible but...)
or that you have this in your apache conf : AddType application/x-httpd-php .png (hum)

or did i miss something ?

@Mike: Here's an example. http://www.cvedetails.com/cve/CVE-2006-2330/

@Thetestmanager: It depends on how the upload script checked. If it is done using HTML attributes, this only controls the browser's behavior. If the size of the file (not the image dimensions) were checked server-side, this attack would not be possible.

If the upload script checked for max file size like most do. Wouldn't this block the over large comments?

@Dan: Do you know of any examples that I could study, I find this topic particularly interesting, I feel this is one of the areas, often overlooked.

@Mike: This particular trick of combining files has gained me code execution on two or three different penetration tests in the past. This is tried and true. In fact, there are even some antivirus systems which will flag PHP code embedded in images.

It's also worth noting that this concept extends beyond combining PHP and PNG, there are many more applications for this concept.

Have you tried and tested this method or is this purely conceptual?

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment