Firewalls de
aplicaciones web (WAF) son parte de la defensa en el modelo de profundidad para
soluciones de seguridad de la información. Aunque no es un sustituto para el
código de seguridad, ofrece grandes opciones para el filtrado de una entrada
maliciosa. A continuación se muestra una historia a partir de un escaneo de
vulnerabilidades real donde una empresa implemento un dispositivo de este tipo
que fue vulnerable a ser pasado por alto. La vulnerabilidad es uno de los malos
diseños y / o configuraciones y como un atacante fue muy útil.
Escaneo de vulnerabilidades de una aplicación en su despliegue de producción es importante.
Mientras que esta aplicación podría haber sido evaluada en desarrollo o en
control de calidad, al implementar es posible introducir nuevos tipos de ataque
debido a problemas de configuración acuerdo a los expertos de soluciones de seguridad de la información. Tal fue el caso con nuestro cliente ficticio
Heisenberg Bank.
Durante el escaneo de
vulnerabilidades corremos rápidamente a problemas en todos los puntos de
aplicación, ver más abajo (captura de pantalla aproximada):
Al poco rato de
investigación en los blogs de los expertos de soluciones de seguridad de la
información supimos que estábamos en contra de un WAF que estaba provocando
algunos problemas:
§ Sucesión rápida de la solicitud POST a
formularios
§ Sucesión rápida de la solicitud GET a la
mayoría de las páginas
§ La falta de un token CSRF
§ Los malos caracteres
Después de que se
reúna una de estas condiciones nos bloquearan con dicho código de error durante
5 minutos.
El método normal la
codificación de playloads y eludir la expresión regular de WAF es impredecible
en estos días. Aun así, se puede probar.
Decidimos hacer más
investigación sobre WAF. Mientras pasaba por varias guías de implementación WAF
me encontré con un blog de soluciones de seguridad de la información en el que
se menciona la integración de un WAF con su servicio de caché / dispositivo. La
guía de productos menciona que se puede poner en o la lista blanca a los
dispositivos basados en IP, lo que les permite no ser inspeccionado por WAF.
Después de leer más,
nos encontramos con que en vez de hacer una búsqueda real sobre las peticiones
de entrada (algo parecido a REMOTE_ADDR o algo similar), el WAF estaba viendo
hacia una cabecera HTTP *personalizada*.
Así es como se supone
que debe funcionar si un usuario u otro servidor contacta el WAF:
En vez de que, la WAF
comprobara los requisitos de los cabeceras HTTP. La implementación específica
estaba revisando la solicitud de la cabecera X-originating-IP.
Entonces, ¿a quién
podría confiar este WAF? En este caso, el defecto fue la propia WAF.
Dado que, durante el
escaneo de vulnerabilidades, estamos controlando todas las peticiones de HTTP
enviadas fuera de mi navegador puedo agregar fácilmente esta cabecera engañando
al WAF para que piense que era ella misma, lo que me permite desviarse de su protección
por completo:
Después de más
investigación con ayuda de blog de soluciones de seguridad de la información,
hay varias cabeceras que se pueden definir para WAF a la lista blanca
§ X-forwarded-for
§ X-remote-IP
§ X-originating-IP
§ x-remote-addr
También hay una lista
de resultados de tipos de direcciones / configuraciones que pueden ser
blanqueadas en la lista fácilmente durante el escaneo de vulnerabilidades:
Después de averiguar
la desviación, el resto de escaneo de vulnerabilidades produjo muchas otras
vulnerabilidades y se aceleró debido al hecho de que podía pasar por alto la
WAF. Era tan simple como tener mi línea de intercepción de proxy añadida a la
cabecera de todas las solicitudes.
Según expertos de
soluciones de seguridad de la información, también se puede auditar la
seguridad de las cabeceras HTTP en tu sitio usando Gethead.
Aquí es la herramienta
para hackear firewalls la aplicación web usando las cabeceras HTTP
https://github.com/codewatchorg/bypasswaf
0 comments:
Post a Comment