Apache – GLPI: Los descuidos se pagan

Es importante tras la instalación de una aplicación seguir las recomendaciones de instalación y configuración del fabricante, verificando que la aplicación cumple con unas condiciones de seguridad óptimas.

 

Para ello, además de hacer caso a lo que el fabricante/producto nos recomienda tras la instalación, también hay que ser conscientes de que el servidor Web sobre el que se sustenta la aplicación juega un papel importante en la seguridad de nuestra aplicación.


En esta ocasión les contaré como un simple descuido puede dejar al descubierto a una organización y facilitar el compromiso de sus sistemas.

Durante la evaluación de diferentes servicios Web de la Organización en cuestión, nos encontramos con un servicio, (por razones obvias se ha ocultado su verdadero nombre) denominado xxxx.dominio.com.


Una búsqueda en Google de xxxx.dominio.com  y “version”  nos dio como resultado entre otros el siguiente enlace:


“xxxx.dominio.com/front/lostpassword.php?lostpassword=1
Un correo electrónico le será enviado y podrá elegir una contraseña nueva. GLPI version 0.80.7 Copyright (C) 2003-2015 INDEPNET Development Team”.






Mirando las cabeceras:

HTTP/1.1 200 OK
Date: Tue, 15 Dec 2015 12:05:42 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze19


Por lo tanto teníamos un servidor Debian, con Apache 2.2.16, con php 5.3.3 y corriendo la aplicación GLPI versión 0.80.7.

Aunque a simple vista, la versión del servidor Web es vulnerable a un conocido bug, y que además la aplicación no soporta https y puede ser vulnerable al robo de credenciales, en esta ocasión nos llamaba más la atención la aplicación GLPI.

GLPI (Gestionnaire Libre de Parc Informatiqué), es un proyecto de software abierto para la gestión del parque informático de una organización y gestión de HelpDesk.

Entre sus funcionalidades destaca su sistema de gestión de tickets, donde el soporte técnico de una organización puede gestionar las diferentes incidencias que se producen en su organización, realizar seguimientos y documentar todo aquello que sea necesario en la misma incidencia, adicionalmente, se permite adjuntar archivos a la propia incidencia.

También dispone de una base de conocimiento y de contratos, donde se puede subir contenido e información en diferentes formatos.

Realmente un solución muy completa para un servicio de helpdesk.

La aplicación está desarrollada totalmente en PHP.

La instalación es muy  sencilla, básicamente tras descargar y descomprimir el software bajo una carpeta de tu servidor web, te conectas a http://ip-servidor/glpi y el proceso de instalación es guiado.

Antes de proceder con la instalación, la documentación de GLPI indica que tienes que dar permisos de lectura/escritura a las carpetas "files" y "config", para el usuario con el que corre el servidor Web Apache.

Estas carpetas se encuentran accesibles a través del servidor web y por su cometido son carpetas muy interesantes.

La instalación crea 4 usuarios por defecto:

glpi/glpi para la cuenta de Administrador.
tech/tech para la cuenta de Técnico.
normal/normal para la cuenta Normal.
post-only/post-only para la cuenta postonly

Aunque es obvio, lo primero por lo tanto sería probar si alguno de estos usuarios está disponible, nunca está de más.

Mala suerte el administrador los ha eliminado o modificado.

Como hemos comentado el directorio files es un directorio muy interesante, bajo él se guarda todos los archivos/documentos que los usuarios suben a GPLI.

GLPI dispone de una funcionalidad de “Documentos” en el mismo ticket que permite subir archivos en diferentes formatos.

El siguiente paso es comprobar si podemos, sin autentificarnos en la aplicación, acceder a ese directorio, ya que podría ser una importante fuente de información.

http://xxxxx.dominio.com/glpi/files/

bingo, tenemos un listado de directorios.

El listado muestra carpetas por tipo de extensión (TXT, HTML, PDF, etc).


El directorio es visible y podemos acceder a todo su contenido, así como descargarnos los archivos.





Realmente la cantidad de información que puede llegar a manejar un servicio de helpdesk es impresionante, y en este caso no era una excepción, se encontró todo tipo de documentación, entre está información, documentos con credenciales de usuario, posiblemente intercambiadas en incidencias.
Las credenciales nos dieron acceso al servicio como usuario, lo que nos permitió profundizar en la  explotación del servicio.


El poder abrir incidencias a través del sistema de helpdesk de la organización pasándonos por un usuario de la misma, abría las puertas a nuevas fuentes de explotación.

Con un poco de ingeniería social podíamos ampliar nuestro ataque, la idea fue abrir una incidencia con el servicio técnico informático de la organización, subiendo un archivo html con javascript embebido,  GLPI por defecto en su configuración permite subir archivos con extensión html.

 

Teníamos un servidor con un dominio muy reconocido donde habíamos guardado un html con un XSS creado por nosotros.


La pregunta es ¿porqué pudimos acceder al directorio habiendo seguido las instrucciones de instalación de GLPI.

GLPI protege los directorios files y config con un archivo .htaccess cuyo contenido es el siguiente:

/var/www/glpi/files# cat .htaccess
deny from all

/var/www/glpi/config# cat .htaccess
deny from all

Evidentemente, por alguna razón la configuración de estos archivos no estaban teniendo efecto.

La razón de ello la podíamos encontrar en la configuración del virtual host del servidor Web Apache:

/etc/apache2/sites-available# cat default
<Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from All
        </Directory>


La directiva AllowOverride None implica que el fichero .htaccess no es leído.
La directiva allow from All implica que cualquiera puede acceder a los directorios bajo www.
La directiva Indexes implica que el contenido del directorio será mostrado.

Una posible solución:

<Directory /var/www/>
                Options FollowSymLinks MultiViews
                AllowOverride All -> De forma que lea los .htaccess de GLPI.
                Order allow,deny
                allow from All
        </Directory>




Como hemos visto, cuando instalamos una aplicación web, es muy importante tener en cuenta no solo las recomendaciones del producto, también la configuración de nuestro servidor Web.

Por otro lado, no está de más repasar todas las funcionalidades que la aplicación ofrece a sus usuarios y que podrían implicar riesgos para la seguridad, como por ejemplo, el poder subir archivos de tipo “html”al sistema.