Solicitudes HTTP y módulos Apache: vectores de ataque creativos

Question

Pregunta poco ortodoxa aquí:

Actualmente estoy tratando de romper un Apache con un puñado de módulos personalizados.

Lo que dio lugar a la prueba es que Apache solicita internamente hacia delante que considera demasiado grande (por ejemplo, 1 MB de basura) a los módulos conectados en forma adecuada, obligándolos a hacer frente a los datos de basura - y la falta de manejo de los módulos personalizados causado Apache en su totalidad para ir en llamas. Ay, ay, ay.

Afortunadamente, se solucionó ese problema en particular, pero surge la pregunta de si puede haber otras vulnerabilidades similares o no.

Ahora tengo una herramienta a mi disposición que me permite enviar una solicitud HTTP sin procesar al servidor (o más bien, datos brutos a través de una conexión TCP establecida que podría interpretarse como una solicitud HTTP si seguía la forma de uno , por ejemplo, "GET ...") y estoy tratando de encontrar otras ideas. (Ataques a nivel de TCP como Slowloris y Nkiller2 son no mi enfoque en este momento.)

¿Alguien tiene un par de buenas ideas de cómo confundir módulos personalizados del servidor hasta el punto de servidor-inmolación?

• Broken UTF-8? (Aunque dudo que Apache se preocupe por la codificación, imagino que solo hace malabares con los bytes crudos.)
• ¿Cosas que son apenas demasiado largas, seguidas de 0 bytes, seguidas de basura?
• etcétera

Yo no me considero un muy buen probador (que estoy haciendo esto por la necesidad y la falta de mano de obra; por desgracia no tienen ni siquiera una comprensión más básica del funcionamiento interno de Apache que me ayudaría), y es por eso que espero una respuesta perspicaz o dos o tres. ¿Tal vez algunos de ustedes han hecho algunas pruebas similares para sus propios proyectos?

(Si stackoverflow no es el lugar adecuado para esta pregunta, me disculpo. No estoy seguro de dónde si no ponerlo.)

Answer 1

Dependiendo de qué otros módulos que ha conectado en, y lo que más les activa (o es sólo las solicitudes demasiado grandes?), Es posible que desee probar algunos de los siguientes:

• Bad codificaciones - p.ej demasiado tiempo utf-8 como usted mencionó, hay escenarios donde los módulos dependen de eso, por ejemplo, ciertos parámetros.
• manipulación de parámetros - nuevamente, dependiendo de lo que hagan los módulos, ciertos parámetros pueden interferir con ellos, ya sea cambiando los valores, eliminando los parámetros esperados o agregando los inesperados.
• contrario a su otra sugerencia, me gustaría ver datos que es apenas lo suficientemente corto como, es decir, uno o dos bytes inferior al máximo, pero en diferentes combinaciones diferentes parámetros -, encabezados, cuerpo de solicitud, etc.
• Busque en HTTP Request Smuggling (también here y here): los encabezados de solicitud incorrecta o las combinaciones no válidas, como múltiples Content-Length o terminadores no válidos, pueden causar que el módulo malinterprete el comando de Apache.
• Considere también gzip, codificación fragmentada, etc. Es probable que el módulo personalizado implemente la verificación de longitud y la decodificación, fuera de servicio.
• ¿Qué hay de la solicitud parcial? por ejemplo, solicitudes que provocan una respuesta 100-Continuar o solicitudes de rango?
• La herramienta fuzzing, Peach, recomendada por @TheRook, también es una buena dirección, pero no espere un gran retorno de la inversión la primera vez que la use.
• Si tiene acceso al código fuente, una revisión de código de seguridad enfocada es una gran idea. O incluso un escaneo automático de códigos, con una herramienta como Coverity (como se menciona @TheRook), o una mejor ...
• Incluso si no tiene acceso al código fuente, considere una prueba de penetración de seguridad, ya sea por experiencia consultor/pentester, o al menos con una herramienta automatizada (hay muchos por ahí) - por ejemplo appscan, webinspect, netsparker, acunetix, etc. etc.

Answer 2

Apache es uno de los proyectos de software más endurecidos en la superficie del planeta. Encontrar una vulnerabilidad en el HTTPD de Apache no sería una hazaña pequeña y recomiendo cortarle los dientes a una presa más fácil. En comparación, es más común ver vulnerabilidades en otros HTTPD como este en Nginx que vi hoy (no es broma). Ha habido otros vulnerablites de divulgación de código fuente que son muy similares, me gustaría ver this y aquí está another. lhttpd ha sido abandonado en sf.net durante casi una década y se conocen desbordamientos de búfer que lo afectan, lo que lo convierte en una aplicación divertida de prueba.

Al atacar un proyecto, debe ver qué tipo de vulnerabilidades se han encontrado en el pasado. Es probable que los programadores cometan los mismos errores una y otra vez y, a menudo, surgen patrones. Siguiendo estos patrones puedes encontrar más defectos. Intente buscar bases de datos de vulnerablites como Nist's search for CVEs. Una cosa que verá es que los módulos de Apache son los más comúnmente comprometidos.

Un proyecto como Apache ha sido muy borroso. Hay marcos fuzzing como Peach. Peach ayuda con el fuzzing de muchas maneras, una de las formas en que puede ayudarte es dándote datos desagradables de prueba para trabajar.Fuzzing no es un enfoque muy bueno para proyectos maduros, si sigues esta ruta apuntaré al apache modules con la menor cantidad de descargas posible. (Advertencia proyectos con muy bajas descargas podrían romperse o difíciles de instalar.)

Cuando una empresa está preocupada por Secuirty frecuencia con la que pagar un montón de dinero para una herramienta de análisis automatizada como fuente Coverity. El Departamento de Seguridad Nacional dio a Coverity una tonelada de dinero para probar proyectos de código abierto y Apache is one of them. Puedo decirte de primera mano que he encontrado a buffer overflow con fuzzing que Coverity no recogió. Coverity y otras herramientas de análisis de código fuente como el open source Rats producirán una gran cantidad de falsos positivos y falsos negativos, pero ayudan a reducir los problemas que afectan a una base de código.

(La primera vez que ejecuté RATS en el kernel de Linux casi me caí de la silla porque mi pantalla enumeraba miles de llamadas a strcpy() y strcat(), pero cuando busqué en el código, todas las llamadas funcionaban con texto estático, que es seguro.)

Vulnerabilidad resarch un desarrollo de exploit es a lot of fun. Recomiendo explotar aplicaciones PHP/MySQL y explorar The Whitebox. Este proyecto es importante porque muestra que hay algunas vulnerabilidades del mundo real que no se pueden encontrar a menos que lea el código línea por línea manualmente. También tiene aplicaciones del mundo real (un blog y una tienda) que son muy vulnerables al ataque. De hecho, ambas aplicaciones se abandonaron debido a problemas de seguridad. Un fuzzer de aplicación web como Wapiti o acuentix violará estas aplicaciones y otras similares. Hay un truco con el blog. Una nueva instalación no es vulnerable a mucho. Tienes que usar un poco la aplicación, intentar iniciar sesión como administrador, crear una entrada de blog y luego escanearla. Al probar una aplicación de aplicación web para la inyección sql, asegúrese de que esté activada la generación de informes de errores. En php puede establecer display_errors=On en su php.ini.

¡Buena suerte!