WEB HACKING – Módulos y Librerías en servidores web Apache – AMON y MOD_DEFLATE – Parte VIII

Cuando se instala un servidor web Apache, es importante dedicar tiempo suficiente para realizar tareas de tunning y fortalecer la seguridad del servidor ante las múltiples amenazas que se encuentran en entornos poco fiables como internet. En este sentido, los módulos y las librerías que pueden ser instaladas, habilitadas y posteriormente configuradas representan una pieza fundamental en este puzzle de tener un servidor web en condiciones para atender usuarios de forma segura garantizando la confidencialidad e integridad de la información. En esta publicación se hablará un poco sobre la librería AMON.SO y el módulo MOD_DEFLATE, en próximas publicaciones se hablará sobre más librerías y módulos interesantes para Apache.

Librería AMON.SO

Se trata de una librería muy interesante, que permite interceptar y sanear comandos que se puedan ejecutar sobre un sistema Linux, se trata de una librería que se integra con el interprete de PHP e intercepta cualquier tipo de system call llevada a cabo por medio del interprete de PHP, esto significa que permite adicionar una capa de protección extra contra vulnerabilidades en aplicaciones web del tipo “OS Commanding”, evitando de esta forma que un atacante pueda ejecutar comandos en el sistema (algo que es más común de lo que se suele admitir). Esta librería se encuentra escrita en C y se ofrece de forma libre desde el sitio web del desarrollador aquí: http://www.lucaercoli.it/en/index.html por lo tanto puede ser compilada y construida utilizando íntegramente GCC

El primer paso es descargar el código fuente de la librería, que no es más que un fichero con extensión .C desde aquí:

http://www.lucaercoli.it/amon/amon.c

Ahora, el siguiente paso es compilar dicha librería y generar su correspondiente fichero .so

El comando anterior generará la librería amon.so la cual realizará todas las labores de filtrado de comandos contra el sistema operativo desde una aplicación web utilizando Apache.

Ahora, partiendo de que la instalación de Apache donde se va a instalar esta librería cuenta con el modulo de PHP instalado, (tal como se ha visto en publicaciones anteriores de esta serie), es necesario incluir este módulo recién creado en el directorio lib de la raíz del servidor web. Posteriormente es necesario editar los ficheros <APACHE_INST>/bin/envvars-std y <APACHE_INST>/bin/envvars para que tengan el siguiente contenido:

El contenido por defecto, solamente incluye las 2 primeras lineas, la ultima linea es la que se debe incluir, en donde se indica que debe exportar la librería amon.so que se encuentra ubicada en el directorio lib

NOTA: Estas indicaciones solamente son validas cuando se trata de un servidor web Apache que se ha construido desde código fuente e incluyendo PHP como se ha indicado en una publicación anterior en esta serie (Es decir, con el interprete de PHP ejecutándose en el proceso principal del servidor web de Apache). Existen otros métodos en el caso de que se trate de una versión de Apache precompilada o con el modulo mod_fcgid o Apache con soporte suEXEC. Para mayor información sobre estos modos de instalación ver: http://www.lucaercoli.it/en/amon.html

Se procede a crear un fichero con phpinfo para ver si el módulo se ha cargado correctamente e iniciar el servidor web

<!--?php phpinfo(); ?-->

Al visualizar esta página, se debe poder ver en la sección de variables la variable LD_PRELOAD con el valor amon.so y en la sección de variables de PHP la variable ENV[“LD_PRELOAD”] con el valor de amon.so

Esto indica que la librería se ha incluido en el interprete de PHP y que se encuentra cargada.

Ahora, para probar su funcionamiento solamente es necesario utilizar una página vulnerable, en este sentido el uso de Moth viene muy bien, ya que cuenta con algunas páginas de Test para vulnerabilidades OS Commanding. Como se ha comentado en entradas posteriores de este blog (por ejemplo aquí: https://thehackerway.com/2011/06/01/funcionamiento-de-w3af-%E2%80%93-encontrando-vulnerabilidades-y-ejecutando-exploits/)

Moth es una “batería” de pruebas para medir el funcionamiento de W3AF, sin embargo puede ser utilizada para realizar pruebas con otras herramientas o para verificación manual. Lo primero, es instalar Moth, para ello solamente es necesario realizar un checkout desde el repositorio SVN donde se encuentran alojados todos los ficheros y recursos que componen esta batería de pruebas:

Este comando se debería ejecutar desde el directorio donde se encuentran las aplicaciones web del servidor (típicamente en htdocs) o en el directorio donde a donde apunte un host virtual especificado en el fichero de configuración de Apache tal como se ha explicado en previas publicaciones de esta serie.

Ahora bien, desde la siguiente ruta en Moth, se puede verificar una vulnerabilidad OS Commanding: http://localhost:666/w3af/audit/os_commanding/simple_osc.php?cmd=ls antes de habilitar el módulo de Amon.so el resultado de cargar la página anterior es similar al siguiente (dependiendo de los contenidos del directorio que se esta listando con el comando “ls” que es el que se esta ejecutando contra el servidor web)

Después de habilitar la librería amon.so el resultado obtenido tras cargar la misma página vulnerable anterior ha sido el siguiente

Como puede verse, la librería ha conseguido interceptar la petición a la llamada al sistema y la ha filtrado, por ese motivo no se visualiza absolutamente nada en la respuesta, evitando de esta forma la ejecución de comandos desde la aplicación web.

MÓDULO MOD_DEFATE

Este módulo permite que un servidor web Apache pueda generar respuestas comprimidas para reducir el tamaño de sus respuestas a los clientes tal como lo dicta el protocolo HTTP 1.1 en su especificación. Usando este módulo, cualquier cliente web puede especificar al servidor que desea que sus respuestas sean comprimidas antes de ser enviadas, el cliente (en la mayoría de los casos, el navegador web, se encargará de realizar el proceso de descompresión). Este módulo contiene menos directivas que otros módulos tales como mod_ssl y mod_security (que se verá más adelante) lo que hace que su uso sea mucho más simple e incluso intuitivo.

El módulo mod_deflate hace uso de filtros en Apache para compresión y descompresión de respuestas. En Apache, un filtro es simplemente una utilidad que permite realizar algún tipo de preprocesamiento a las respuestas o las peticiones que entran/salen del servidor web, en este caso concreto, como el lector ya se imaginará, los filtros utilizados por mod_deflate están relacionados con la compresión de las respuestas y la descompresión de las peticiones enviadas por los clientes, en este sentido, existen dos tipos distintos de filtros en apache, los filtros de salida que son empleados para filtrar las respuestas que emite el servidor web y los filtros de entrada que son empleados para filtrar las peticiones de los clientes.

Para utilizar filtros de entrada o salida, se pueden utilizar las siguientes directivas:

AddOutputFilterByType, SetOutputFilter y SetInputFilter

Dichas directivas pueden ser ubicadas en múltiples sitios dentro del fichero de configuración del servidor web, por ejemplo en la configuración global, dentro de directivas <Directory> <Location> o <VirtualHost> algunos ejemplos del uso de dichas directivas:

AddOutputFilterByType DEFLATE text/html text/plain

Con esto, se especifica el filtro DEFLATE que se encarga de comprimir contenidos, en este caso concreto la directiva AddOutputFilterByType con el mencionado filtro, intentará comprimir todas las respuestas a los clientes cuyo tipo de contenido (tipo MIME) sea text/html o text/plain

Del mismo modo que la directiva AddOutputFilterByType con esto se establece como filtro de salida DEFLATE para todas las respuestas emitidas por el servidor, la diferencia entre esta directiva y la anterior radica en que la directiva AddOutputFilterByType permite filtrar el tipo de contenidos que serán comprimidos, mientras que la directiva SetOutputFilter intentará comprimir todas las respuestas a los clientes dependiendo del contexto en el que se defina dicha directiva, por ejemplo, si se incluye dentro de una directiva <Directory> solamente aplicará para respuestas que estén relacionadas a peticiones al recurso contenido en <Directory>, lo mismo aplica para otras directivas como <Location> o <VirtualHost>

Con esta directiva se puede definir un filtro de entrada, que permite descomprimir todas las peticiones de los clientes que vienen comprimidas usando gzip

Ahora bien, no todos los clientes soportan de forma adecuada las respuestas comprimidas y en algunos casos pueden existir problemas (como por ejemplo, con el uso de navegadores IE). En tales casos se suele utilizar la directiva BrowserMatch la cual permite definir una expresión regular que será utilizada contra el User-Agent incluido en la petición del usuario. Ademas de la expresión regular que pude indicarse en esta directiva, también permite establecer notas que son simplemente variables que indican el tipo de contenido o tipo de compresión que puede (o no puede) utilizarse.

Algunos ejemplos validos pueden ser:

Indica que cualquier User-Agent que comience con Mozilla/4 deberá utilizar compresión gzip solamente para el contenido de las páginas web (content-type text/html)

Para versiones concretas de Mozilla (en este caso Mozilla/4.06 Mozilla/4.07 y Mozilla/4.08) no se utilizará gzip en lo absoluto para llevar a cabo el proceso de compresión, ya que existen bastantes problemas en dichos navegadores.

Esta restricción es concreta para navegadores web IE, dado que dichos clientes contienen también el User-Agent con “Mozilla” se busca en toda el texto del User-Agent el contenido de MSIE, que identifica de forma inequívoca que el cliente es un navegador web IE, en este caso no se utilizará ningún tipo de compresión.

Otras directivas para controlar el proceso de compresión con Mod_Deflate

Finalmente, algunas de las directivas más interesantes de este modulo son:

DeflateBufferSize

Se trata del tamaño en bytes de los fragmentos que Zlib podrá comprimir al tiempo antes de generar un fichero consolidado. El valor por defecto de esta directiva es de 8096 bytes.

DeflateCompressionLevel

Se trata simplemente de un valor numérico que determinará el nivel que se desea utilizar para el proceso de compresión, entre más alto sea este valor, mejor será la compresión, sin embargo esto también producirá que el uso de la CPU sea mayor. Los valores disponibles van desde 1 (valor más bajo) hasta 9 (valor más alto). Para servidores que deben atender muchas peticiones y cuyas respuestas deben de ser comprimidas, no se recomienda definir un valor superior a 7.

DeflateMemLevel

Esta directiva es similar a la anterior, con la diferencia de que aquí se define el uso de la memoria que será utilizada para el proceso de compresión, los posibles valores están entre 1 y 9.

Ahora bien, cuando se captura una petición desde un cliente a un servidor web Apache, este puede contener el siguiente Header Accept-Encoding: gzip,deflate lo cual indica que la petición ira comprimida hacia el servidor. Posteriormente la respuesta del servidor al cliente podrá contener la siguiente información:

Vary: Accept-Encoding

Content-Encoding: gzip

Lo que le indicará al cliente que la respuesta se encuentra comprimida y que debe descomprimirla para poder precesarla.

En próximas publicaciones, más sobre módulos en Apache.