MANIPULACION DE VERBOS...Permitiendo el Acceso al atacante saltándonos la Autenticación y Autrización HTTP del Aplicativo Web


El otro día realizando tareas habituales de Pentest me encontré con esta vulnerabilidad que era marcada como Crítica por el “scanner de turno” de obligada utilización en ciertos entornos corporativos.. pero, que como en las mayorías de las ocasiones, necesitaba de validación y explotación manual.
Lo raro es que nunca me había “saltado” un Verb Tampering” (verb o method) en un Pentest oficial que tenía marcado en calendario .. y bueno, pues había que, primero verificar que no era un falso positivo y luego “darle candela”.
Como ya me lo había encontrado muchas veces en pentesting no oficiales ( es decir, los que hago en mi casa, no en mi trabajo..) pues tampoco tenía problema.  Pero el hecho de “no salir” nunca en entornos corporativos y encontrármelo es más que suficiente para que aprendáis este ataque y su correspondiente “vacuna”.











COMO Y POR QUÉ SE PRODUCE
Muchas aplicaciones web están basados en este tipo de autenticación y autorización, que está basado en métodos ( o verbos) HTTP, donde GET y POST por ejemplo están dentro de estos métodos (verbs) formando parte de las “decisiones de seguridad ” a la hora de producirse esta acción.
En entornos Java este error se produce en el archivo web.xml por una configuración errónea del mismo.
Que contiene este archivo? nos podemos encontrar desde servlets, JSP, definiciones de los propios servlets etc, pero lo interesante, es que este fichero DEBE incluir de manera obligatoria restricciones de seguridad dentro de la  etiqueta <security-constraint>. Ya con el nombre del tag, os tenéis que hacer una idea de donde va a estar el problema ..
SI ESTÁS RESTRICCIONES DE SEGURIDAD NO SON CONFIGURADAS DE MANERA, NO SOLO CORRECTA, SINO ADECUADA, UN ATACANTE PUEDE SALTARSE LOS CONTROLES DEL APLICATIVO WEB teniendo CONTROL TOTAL al todo “lo restringido” ofreciendo así la posibilidad de tener control total de la aplicación web.
Estos mecanismos de autorización y control que nos vamos a saltar se les conoce como VBAAC
Ejemplo de fichero web.xml típico
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Vamos por partes ( volver a leeros el código que lo habéis hecho una vez y de pasada … )
<url-pattern>: Para que lo entendais, si os fijais,existe un <role-name></role-name> y este rol es “admin” bien? Por lo tanto ya tenemos que lo que se está especificando en <url-pattern> se aplicará únicamente al ROL ADMIN .. y esto de momento nos interesa.
Y estos ROLES? Donde se encuentran? Están en los fichero application.xml y application-bnd.xmi. Aquí  están TODOS  los parámetros de localización de CADA USUARIO en EL DIRECTORIO ACTIVO.. por lo tanto, esto, de memoria..
Tenemos que el “admin” podrá acceder a /pages/index.jsp y a /admin/*.do … y que vemos más? Tenemos los MÉTODOS que se permiten y estos están indicados en <http-method>
Entonces, los ” USUARIOS CON EL ROL ADMIN PODRÁN ACCEDER CON LOS MÉTODOS GET/POST A LAS URL´S /pages/index.jsp y a /admin/*.do”.
Bien , se que muchos de vosotros (dependiendo del conocimientos sobre los lenguajes webs que tengáis) ya habéis visto el “como” .. pero quiero que se entienda como si fuera la papilla de un bebé… MASCADITO.
Volver a leer “…   CON LOS MÉTODOS GET/POST……..” ummmmm GET/POST, GET/POST … pero, que webOS..la RESTRICCIÓN SOLO SE APLICA A ESTOS MÉTODOS … Entonces.. por qué no “lanzamos” el resto de métodos que conocemos?
Claro, aquí está el gran error ... podemos usar HEAD .. De tal manera que realizando una petición HEAD hacemos “bypass”, nos saltamos la restricción y ACCEDEMOS A LAS URL PROTEGIDAS, que casualmente son las del rol “admin”.
Ejemplo
HEAD /admin/ListadoUsuarios.do HTTP/1.1
Host: www.example.com
y si usas un método INVENTADO ( el típico Foo) entra también .. solo fíjate en el código y verás que , esta vez, ” SI INVENTAS, ENTRAS” 😉
Que otros métodos te vienen a la cabeza ??? .. pues claro !! PUT TRACE TRACK DELETE,como si quieres poner “JUAN” .. ENTRA !!
Por cierto OWASP WebScarab es muy útil para empezar a “tocar” todo esto y enviar HEAD GET etc y ver que pasa .. curiosidad? ya sabes.. !!
Pero la RFC 2616 tendría que saberse al dedillo como en todos los ataque. .. por lo menos leerla, porque si no sabemos como funciona HTTP nunca entenderás el por qué realmente de este “bypass”. Estoy seguro que  has entendido el ataque en si .. pero por qué http se come esto? Bájate la RFC y lo entenderás .. pero eso es trabajo tuyo.
Por ejemplo, os doy una pista de que webs y aplicaciones aceptarían HEAD u que “enchufando” GET, si es vulnerable, entraríamos hasta “la cocina”… ( leeros la RFC, que merece la pena.. en serio)
IIS 6.0
WebSphere 6.1.(x)
WebLogic 8.x
JBoss 4.2.x
Tomcat 6.x
Apache 2.2.x
La siguiente tabla muestra los mecanismos de seguridad web más importantes y como les afecta estas técnicas

ISS



Overriding Verb in ASP.net


Htaccess
Una herramienta para atacar?? Entre WebScarab y esta.. De SOBRA !!!
VERBY HTTP


Cada lenguaje tiene 
su método                               

Como es lógico, quieres atacar Java, tendrás que estudiar los mecanismos de Autenticación de Java.. si es ASP.net tienes TODO en el MSDN.. pero el método es lo mismo para todos, cambian los métodos como en todo lenguaje .
LA SOLUCIÓN
SI NO ESPECIFICAS NINGÚN MÉTODO, SE APLICARÁN TODOS … Y LISTOS !!! Ya está ..!!!
Por lo tanto , aplicando esta regla, al fichero anterior web.xml, “el bueno” quedaría así
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Un saludo
Juan Carlos 
Live Free Or Die Hacking
Juan Carlos García 

HabemusCurso

Entradas populares de este blog

SHELLCODES por un tubo ....

Proteger ASP.NET de inyecciones SQL How T0? BEST PRACTICES

CERTIFICACIONES DE SEGURIDAD