martes, 24 de abril de 2012

Una historia de hackers [Parte I]

Martes por la mañana, hace más de una hora desde que llegué a trabajar. En ese momento me encontraba algo aburrido terminando de configurar un Apache. De pronto, tras una revisión de rutina, un compañero observó en los registros del UTM un UDP Flood proveniente de un servidor de nuestra red interna. El día comenzaba a ponerse interesante.

A decir por la IP de destino, el ataque estaba dirigido a un servidor de hosting de alguna empresa norteamericana. Hasta ese momento tenía una idea clara del problema: alguien había comprometido nuestro servidor de alguna manera y ahora lo estaba utilizando para lanzar ataques de denegación de servicio.

En los últimos días habíamos tenido problemas con el ancho de banda. Muchos usuarios habían llamado para quejarse porque no podían entrar a tal o cual web. No demoramos en establecer una relación causa/efecto entre el ataque que acabábamos de descubrir y la lentitud de la red en los últimos días. Así que el jefe ordenó resolver este problema cuanto antes (aunque el problema de lentitud resultó ser por otros motivos xD).

Lo primero fue identificar el servidor que había sido comprometido. El UTM solo nos mostraba una IP que sabíamos pertenecía a nuestra red, pero no era del segmento donde están nuestros servidores, era de un segmento diferente así que probablemente el servidor pertenecía a alguna dependencia o facultad y estaba fuera de nuestra administración.

No fue difícil identificarlo, era un servidor web y el título de su página principal daba muchas luces sobre el nombre de la dependencia a la que pertenecía. Luego solo hubo que consultar el directorio telefónico interno y después de algunos minutos y llamadas por teléfono ya teníamos el nombre y el anexo del responsable. Le llamamos, pero nadie respondió así que insistiríamos más tarde.

En ese momento me puse a pensar en que le hubiera dicho al administrador si hubiera contestado el teléfono. Obviamente que su servidor había sido "hackeado" y que debía configurarlo mejor y parchear sus bugs porque nos estaba trayendo problemas a nosotros. Pero ¿me habría hecho caso? O tan siquiera ¿me habría entendido? Estaba dejando muchas preguntas sueltas ¿Qué configuraciones están mal? ¿Qué fallos hay que corregir? ¿Cómo se hace eso? ¿Con qué se come? Aún no tenía todas las respuestas.

Como dicen por ahí, si un sistema ha sido comprometido es por que debe tener un fallo bien gordo. Así que no debería ser demasiado difícil encontrar la causa del problema. En realidad, esa premisa, no me termina de convencer, pero poco a poco la experiencia me está mostrando que tiene mucho de cierto.

Puesto que el problema del ancho de banda era prioridad, el jefe no tubo inconvenientes en dejarme investigar el caso. Así que dejé pendiente la configuración del servidor web y lancé un nmap contra la IP en cuestión. El resultado fue por lo menos preocupante, era un windows y tenía todos los puertos imaginables abiertos: 445, 80, 21, 3306, 3389, 1433, 53... Pero claro, yo había hecho el escaneo desde la red interna, el atacante tubo que haberlo hecho desde fuera y no pudo ver todos esos puertos. Recordé entonces que hace poco habíamos reconfigurado el firewall externo dejando accesibles solo los servicios más usados. Así que decidí concentrarme en esos servicios: web y ftp.

Como es lo que más se me da, empece por la página web. Era un CMS de aquellos. Comencé a interactuar con la web, dando clics en los enlaces buscando algo que llamara mi atención, confiando en cierto instinto de perro sabueso, pero todo parecía normal: sin formularios, sin "ids", sin plugins con nombres raros, ni scripts de cosecha propia. De pronto un enlace roto me hizo ver la luz.

Fig. 1 - Enlace roto.
El icono anaranjado en la barra de direcciones es inconfundible: XAMPP.

Sucede que desde la página principal se veía un favicon personalizado pero al generar un error 404 XAMPP muestra su página de error por defecto con su propio favicon.

Nota: XAMPP es un "enlatado" con todo lo necesario para montar un servidor web: Apache, Mysql, Php y Perl (entre otras cosas). De echo su nombre proviene de las iniciales del sofware que instala. La X inicial se reemplaza por W cuando es para Windows y por L cuando es para Linux. El problema con XAMPP es que deja una configuración inicial funcional pero insegura.

Lo siguiente fue pedir la página de administración de XAMPP, algo como http://www.servidor.com/xampp. Si el administrador había sido descuidado esa página estaría sin contraseña y accesible para todo el mundo. Así fue.

Desde la página de administración de XAMPP se puede acceder a un enlace que muestra información sobre el "estado de seguridad" del servidor. Básicamente te dice a que servicios le falta cambiar la contraseña por defecto. Desde ahí me enteré que el servicio FTP aún seguía con las credenciales por defecto: usuario "nobody" y  clave "lampp" (o al menos eso es lo que decía XAMPP).

El ataque empezó a perfilarse con mayor claridad: el "hacker" accedió al FTP con las credenciales por defecto, subió un script php para hacer Flood UDP, y lo ejecutó desde el servicio web. Ahora solo me faltaba demostrar mi teoría, debía acceder al FTP y buscar el script php que había subido el intruso. Esa evidencia sería suficiente.

Sin embargo quedé frustrado ni tan siquiera empezar. Las credenciales no eran válidas. No lo entendía XAMPP mostraba claramente que el FTP mantenía el usuario y clave por defecto y que eran nobody y lampp respectivamente. Pero puestos a pensar un poco, no tenía mucho sentido, el servidor era un windows y la clave lampp evidentemente se refería a un linux (por la L inicial).

Resultó ser un problema al traducir la página de XAMPP al español. Los que hicieron la documentación debieron haber obviado ese detalle. Buscando un poco encontré las verdaderas credenciales por defecto de XAMPP en windows: usuario "newuser" y clave "wampp".

Con estas nuevas credenciales ya pude acceder al FTP. Sin embargo por más que busqué no llegué a encontrar el script. La cantidad de archivos era inmensa y el hacker pudo haberlo puesto en cualquier parte. Necesitaría algo de ayuda. Extrañe el comando grep de linux y sus complicadas expresiones regulares. Quizá si tuviera los logs...

Ya había pasado bastante tiempo, era hora de insistir por el teléfono. En esta ocasión alguien levantó la bocina al otro extremo.

- Oficina de..., buenas tardes.

- Buenas tardes, le llamo del área de servidores. Hemos encontrado un problema de seguridad en su servidor. - No sé exactamente lo que pasa por la cabeza de un administrador cuando le dices esto pero algo sí es seguro: tienes su total atención.

- Le escucho.

- Bien, ¿ustedes tienen el dominio ...unmsm.edu.pe ?

- Sí.

- ¿Y su servidor es un windows ?

- Sí...

- ¿Y tiene instalado un XAMPP ?

- Umm... Sí.

- Pues bien, ha olvidado cambiar la clave por defecto del usuario "newuser" en el FTP.

- ¿newuser? No sabía que existía ese usuario.

- Sí, newuser - ¿Por que no me sorprende? Pensé.

Luego le hablé del UDP Flood que había detectado el UTM, de la lentitud de la red y que su servidor estaba siendo usado para ataques DDoS. También le expliqué mi teoría del script php que no llegué a encontrar y le hice algunas recomendaciones.
  • Configurar un firewall.
  • Cambiar las claves por defecto.
  • Desactivar el acceso a la página de administración de XAMPP.
  • Y borrar cualquier php que le parezca sospechoso.
Con ello y el compromiso de solucionar el problema lo más pronto posible, terminamos la comunicación y yo volví a mi trabajo con el servidor web. Mientras configuraba el mod_evasive, pensaba en lo sucedido y me sentía reconfortado por las horas que he invertido investigando como hacer hardening de Apache y por no instalar simplemente un XAMPP para linux.

Esta historia no termina aquí, lo acontecido durante el resto de la semana fue de lo más inusual que me ha sucedido en la vida... Pero ya lo contaré en otro post.

Saludos...

8 comentarios:

  1. pffff(pifias) cuando continua?

    ResponderEliminar
  2. No se... cuando tenga ganas y tiempo de escribir la segunda parte xD

    ResponderEliminar
  3. Yo sé quien era el que doseaba a los gringos... comienza con C y termina esar

    ResponderEliminar
  4. Buena narracion XD
    R....

    ResponderEliminar
  5. Jaja no es el único , hay admin por defecto en sistemas antiguos en php colgados por ai sólo debes dar con la dirección XD. . Digo nomas u.u

    Esperando segunda parte...

    Pd:xrvre césar ya activas la vista móvil se ve xrvre

    ResponderEliminar
  6. Un dato muy interesante amigo mío }:]

    Saludos.

    ResponderEliminar
  7. xito carajo queremos que continues con la historia.. :D

    ResponderEliminar