Seguridad x Redes

domingo, 27 de diciembre de 2015

Apache – GLPI: Los descuidos se pagan

My Github
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.
Etiquetas Archivo del blog

802.1x
(3) ► 
2022
(4)
► 

apache
(1) ► 
2021
(4)
► 

dhcp
(2)
► 
2017
(4)
► 

DNIe
(2)
► 
2016
(7)
► 

DoS
(1)
▼ 
2015
(10)
▼ 

firewall
(2)
▼ 
diciembre
(2)
▼ 

FreeRadius
(1)
Apache –
glpi
(1) GLPI: Los
Hacking
(9) descuidos
se pagan
hardening
(1)
HTB
(5) VPN IPSec
(II):
IPSEC
(2) Autentifican
MANA Toolkit
(1) do con
DNIe o
monitorizacion
certific...
(1)
nagios
(1) ► 
noviembre
(3)
► 

  networking
(1) ► 
octubre
(5)
► 

Oracle
(1)
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 OSCP
(2)
sobre el que se sustenta la aplicación juega un papel importante en la seguridad de nuestra aplicación.

pentesting
(8)
rstp
(1)
seguridad
(18)
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.
SGSI
(1)
SMB
(1)
SQLI
(1)
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 STP
(1)
verdadero nombre) denominado xxxx.dominio.com.
VoIP
(1)
VPN
(2)

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

Datos personales

@seguridadxredes
“xxxx.dominio.com/front/lostpassword.php?lostpassword=1
Ver todo mi perfil
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.

Publicado por
@seguridadxredes
en
14:48

Etiquetas:
apache,
glpi,
seguridad

No hay comentarios:
Publicar un comentario
Introduce tu comentario...

Comentar como:
Carlos Javier M Cerrar sesión

Vista previa
Publicar
Avisarme

Entrada más reciente Inicio Entrada antigua

Suscribirse a:
Enviar comentarios (Atom)

Copyright © 2015 @SeguridadxRedes. Tema Sencillo. Imágenes del tema: gaffera. Con la tecnología de Blogger.