peticiones HTTP y módulos de Apache de ataque: creativos

Question

Un poco ortodoxo pregunta 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 la basura - y la falta de manejo de los módulos personalizados causado Apache en su totalidad a subir en llamas. Ay, ay, ay.

Esta cuestión particular, se fijó por suerte, pero que ha surgido de la cuestión de si existe o no puede haber otras vulnerabilidades similares.

Ahora mismo tengo una herramienta a mi disposición que me permite enviar una solicitud HTTP pura al servidor (o más bien, los datos en bruto a través de una conexión TCP establecida que podría interpretarse como una solicitud HTTP si siguiera la forma de una, por ejemplo, "GET ...") y estoy tratando de llegar a otras ideas. (TCP ataques nivel 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 preocupaciones acerca de la codificación de Apache -. Me imagino que sólo hace malabares bytes sin formato)
• Cosas que apenas es demasiado largo, seguido de un 0 bytes, seguido de chatarra?
• 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 a lo largo), que es por eso estoy esperando 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

En función de qué otros módulos que tiene en forma de gancho, y lo que más les activa (o se trata sólo las solicitudes demasiado grandes?), Es posible que desee probar algunos de los siguientes:

• codificaciones Bad - por ejemplo, overlong UTF-8 como usted ha mencionado, hay escenarios donde los módulos dependen de que, por ejemplo, ciertos parámetros.
• manipulación de parámetros -. De nuevo, dependiendo de lo que los módulos hacen, ciertos parámetros pueden meterse con ellos, ya sea por cambio de valores, la eliminación de parámetros esperados, o añadiendo otros inesperados
• contrario a su otra sugerencia, me gustaría ver a los datos que es apenas lo suficientemente corto , es decir, uno o dos bytes inferior al máximo, pero en diferentes combinaciones - diferentes parámetros, encabezados, cuerpo de la petición , etc.
• HTTP Solicitud de contrabando (también aquí y aquí ) - cabeceras de petición o malas combinaciones no válidas, tales como múltiples Content-Length, o terminadores no válidos, podría que el módulo malinterpretar el comando de Apache .
• Considera también gzip, fragmentada codificación, etc. Es probable que implementa el módulo de encargo, la comprobación de la longitud y de la decodificación, fuera de servicio.
• ¿Qué hay de petición parcial? por ejemplo las solicitudes que causa un 100-Continuar respuesta, o rango solicitudes?
• La herramienta de formación de pelusa, melocotón , recomendado por @TheRook, es también una dirección buena, pero no esperes gran ROI primera vez de usarlo.
• Si usted tiene acceso al código fuente, una revisión del código de seguridad enfocada es una gran idea. O incluso un escaneo automatizado de código, con una herramienta como Coverity (como se ha mencionado @TheRook), o uno mejor ...
• Incluso si usted no tiene acceso al código fuente, considere una prueba de penetración de la seguridad, ya sea experimentado 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 sería nada fácil y lo recomiendo cortar los dientes de alguna presa más fácil. En comparación, es más común ver vulnerabilidades en otros HTTPDs como este en Nginx que hoy he visto (no es broma). Ha habido otros vulnerablites divulgación de código fuente que son muy similares, me gustaría ver la dirección esta y aquí es otra . lhttpd ha sido abandonado en sf.net durante casi una década y no se sabe búfer desbordamientos que la afectan, que la convierte en una divertida aplicación de prueba.

Cuando se ataca un proyecto que debería mirar qué tipo de vulnerabilidades se han encontrado en el pasado. Su probable que los programadores cometen los mismos errores una y otra vez y, a menudo hay patrones que emergen. Siguiendo estos patrones se pueden encontrar más defectos. Usted debe tratar de buscar las bases de datos vulnerablites como la búsqueda del NIST para CVEs . Una cosa que usted verá es que los módulos de Apache son los más comúnmente comprometidas.

Un proyecto como Apache ha sido fuertemente Fuzzed. Existen marcos Fuzzing como melocotón . Melocotón con ayuda fuzzing de muchas maneras, una forma en que puede ayudar no es por darle algunos datos de prueba desagradables para trabajar. Fuzzing no es un método muy bueno para los proyectos maduros, si usted va esta ruta me gustaría apuntar Apache módulos con el menor número posible de descargas. (Advertencia proyectos con realmente descargas de baja esté rota o difíciles de instalar.)

Cuando una empresa está preocupada por Secuirty menudo pagan mucho dinero para una herramienta de análisis de la fuente automatizada como Coverity. El Departamento de Seguridad Nacional dio Coverity un montón de dinero para proyectos de código abierto de prueba y Apache es uno de ellos . Te puedo decir de primera mano que he encontrado un desbordamiento de memoria intermedia con fuzzing que Coverity no se recuperó arriba. Coverity y otra de análisis de código fuente de herramientas como las ratas de código abierto 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.

(cuando por primera vez RATAS corrió en el núcleo de Linux casi me caigo de la silla porque mi pantalla aparece miles de llamadas a strcpy () y strcat (), pero cuando se hundieron en el código de todas las llamadas en las que se trabaja con texto estático, que es seguro.)

La vulnerabilidad Resarch un desarrollo exploit es un montón de diversión . Recomiendo la explotación de las aplicaciones PHP / MySQL y explorar El Whitebox . Este proyecto es importante porque muestra que hay algunas vulnerabilidades del mundo real que no se puede encontrar a menos que lea bien 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 a los ataques. De hecho estas dos aplicaciones en las que abandonaron debido a problemas de seguridad. Una aplicación web fuzzer como Wapiti o acuentix violará a estas aplicaciones y que son como él.Hay un truco con el blog. Una instalación fresca no es vulnerable a mucho. Usted tiene que utilizar la aplicación de un poco, trate de iniciar sesión como administrador, crear una entrada de blog y luego escanearlo. Al probar una aplicación aplicación web para hacer la inyección sql seguro de que el informe de errores está activada. En php se puede establecer display_errors=On en su php.ini.

Buena suerte!