Antalogía de las grandes cagadas: SUBIR UN SERVIDOR A LA DMZ SIN SECURIZARLO ANTES

Comenzamos una nueva serie dedicada a ... ¡¡grandes cagadas!! ... En este caso, las prisas podrían haber hecho que nos "rooteen" un servidor en la DMZ.

1. BASADO EN HECHOS REALES.

Tristemente, es bastante común que alguno de tus clientes te pida que subas a producción un servidor nuevo que no ha pasado ningún tipo de revisión de seguridad. Lo más divertido viene cuando, tras auditarlo, acabas enviando un mail para solicitar que se quite de producción. Pero el daño ya está hecho.

2. DESCRIPCIÓN DEL SERVIDOR.

El servidor es un linux con un apache y el gestor de contenidos Joomla instalado. Se trata de la nueva web corporativa de un banco, que clama al cielo que tenga joomla, pero bueno, y por ello es crítico que estemos seguros de que todo está bien.

Antes de pasar a hablar del escaner de joomla, por curiosidad, voy a mencionar algunas de las cosas que hemos encontrado:

- lo han subido a la DMZ sin ningún tipo de detector de intrusos ni nada.
- los archivos .htaccess son legibles.
- hay más de un archivo de configuración, entre ellos info.php, que da toda la info del servidor, que debería haberse quitado.
- puede verse que la versión de joomla es la 1.5 porque pueden leerse los javascripts, donde está el valor a pelo.

Y unas cuantas cosas más que no viene a cuento mencionar, por no extendernos.

Lo que si quiero comentar es el contenido del fichero .htaccess, que contenía una IP estática con acceso permitido a la consola de administración del joomla. ¿Qué haría un hacker si ve ese fichero? Pues ver a qué empresa pertenece e intentar entrar allí, con lo cual se nos cuela a nosotros (un banco) en la DMZ. Es un ejemplo de como una metedura de pata en principio no grave puede llevar a un cataclismo sin precedentes.

Mal, muy mal ...

3. STATUS DE JOOMLA.

Como íbamos diciendo, Joomla es uno de los gestores de contenido más de moda ahora mismo. En principio, se supone que, comparado con otros, es relativamente seguro. Aunque si uno mira los foros underground, es bastante obvio que es una mala idea poner algo así en un banco. Te arriesgas, literalmente, a despertar un día y ver un defacement como la copa de un pino.

Lo primero que vemos es que el propio joomla recomienda su actualización a la versión 1.5.11 con carácter de urgencia:



Mal empezamos.

Está bastante claro, sin mirar más, que este servidor no puede ponerse alegremente en producción. Pero necesitamos justificar esto mismo sin ningún tipo de dudas.

3. BUSCANDO EXPLOITS PARA JOOMLA 1.5.

Lo primero es buscar si existe o no un exploit para joomla 1.5. Basta poner "exploit joomla 1.5" en google para ir a éste. Para asegurarnos, lo que haremos es simplemente ir al código fuente y echarle un ojo dentro del servidor. Si bien es cierto que es ligeramente distinto, la única diferencia es que se valida la longitud del input, y eso no es suficiente para asegurar que todo está resuelto, aunque haga difícil hacer que funcione.

Alguien que sepa de sql-injection en php no creo que tuviera muchos problemas para reventarlo, pero como tenemos limitaciones de tiempo ...

4. JOOMSCAN

Para asustar al cliente (sí, para asustarle, no estoy de broma), lo que hicimos fue buscar un escaner de seguridad para joomla. Y encontramos joomscan. Joomscan es un script en perl que mira los módulos disponibles y chequea las vulnerabilidades conocidas, principalmente sql-injection y XSS.

Los scripts que chequean vulnerabilidades se actualizan muy a menudo. Así que, antes de usarlo, vamos a comprobar que está debidamente actualizado:

[11:18][root@localhost/joomscan-latest]# perl joomscan.pl check

OWASP Joomla! Vulnerability Scanner Program Update
(c) Aung Khant, http://yehg.net/lab

~Scanner Update is now available!
~Downloading and saving as joomscan1.pl ...
~Done. Please check joomscan1.pl if it works.
have fun!

~[*] Time Taken: 2 sec
~[*] Send bugs, suggestions, contributions to joomscan@yehg.net



Renombramos la actualización a joomscan.pl y lo lanzamos:



Y nos genera un report con todos los fallos de seguridad encontrados. Entre ellos, podemos ver el mencionado en milw0rm:

# 1
Info: Joomla Remote Admin Password Change
Versions Affected: 1.5.5 <=
Check: /components/com_user/controller.php
Exploit: 1. Go to url : target.com/index.php?option=com_user&view=reset&layout=confirm 2. Write into field "token" char ' and Click OK. 3. Write new password for admin 4. Go to url : target.com/administrator/ 5. Login admin with new password
Vulnerable: No


Hay que tener mucho cuidado con interpretar esto como que NO es vulnerable ya que, realmente, el exploit no funciona por la validación de longitud que mencionábamos arriba. Pero el código PHP sigue siendo vulnerable, al menos hasta que se demuestre lo contrario ...

En todo caso, el report serviría a un hacker para saber qué versiones hay instaladas y por dónde atacar. El resto, cuestión de tiempo.

5. CONCLUSIÓN.

Tras numerosas batallas diplomáticas, hemos solicitado y ¡¡conseguido!! que quiten esa pesadilla de producción. Aparte, están reinstalando todo, incluído mod_security. Un logro.

Y Desde luego, tenemos que aprender una importante lección: los procedimientos están para seguirlos.

Fuente: hacking-Avanzado

Saludos

Dr.White