jueves, mayo 01, 2014

Heartbleed puede desangrarte vivo. Tómatelo en serio.

Aunque últimamente ando bastante falto de tiempo libre debido a la cantidad de proyectos que intento llevar en paralelo pero mi carácter curioso e impulsivo me la ha vuelto a jugar y me ha hecho perder un poco de tiempo jugando con un servidor. Por motivos que no vienen al caso, estaba yo echando un vistazo a la página web de alguien relacionado con mi trabajo, el de experto en sistemas de automatización industrial concretamente, que ya sabéis que es de lo que me gusta hablar a mí en mis artículos, pero me topé con un bug de HeartBleed en un puerto menos habitual y he querido hacer este artículo para enfatizar estas cosas:
1.- HeartBleed puede estar en cualquier parte
2.- Es muy fácil de explotar
3.- Cambia las passwords
4.- Pon un segundo factor de autenticación a tus cuentas.
Fase 1: Descubriendo la Vulnerabilidad de HeartBleed

Mientras leía la web y me interesaba por lo que allí había hice lo que cualquier persona normal -, lancé un nmap al servidor donde se aloja - vale, supongo que esto de normal encajaría solo dentro de los que estamos por estas comunidades y que no será tan normal en otros lares -. De entre todos los servicios y puertos que salieron en los resultados hubo uno de todos ellos que me llamó la atención.

Figura 1: Lanzando nmap contra el servidor

Era un servidor de Plesk 11.0.9, algo que no es que sea inhabitual, pero que abre siempre las puertas de poder encontrar algo interesante especialmente al estar alojado en un puerto menos habitual al escaneo, especialmente esos días que la vulnerabilidad de Heartbleed estaba en todo su esplendor.

Figura 2: Plugin de HeartBleed para FOCA

Como aún no había sacado Eleven Paths su plugin de HeartBleed para FOCA que puedes ver en la imagen superior, me fui a buscar cualquiera funcional en exploit-db, y use este en concreto. Lo lancé y esperé el resultado.

Figura 3: Lanzando el exploit al puerto 8443

Como podéis ver, es vulnerable y devuelve 16384 bytes de información de la memoria del proceso OpenSSL dentro de este servidor, pero en este primer intento no hay información de interés en la respuesta que pueda considerarse jugosa. Por el momento.

Figura 4: El servidor es vulnerable al exploit

Fase 2: Explotando HeartBleed de forma automatizada

A estas alturas, como os habéis podido imaginar, ya no tengo mayor interés por la página web que estaba leyendo y me centro en mi vulnerable amigo. Decido pedir la página de login del panel y probar a introducir algunas combinaciones habituales de usuario y contraseña de las que no espero resultados. Ya sabéis, los "sospechosos habituales" admin/admin, admin/Abc123456, admin/123456, etcétera. Creo que hacer esto es un mecanismo de mi cerebro para poder pensar mientras las manos son comandadas por el sistema parasimpático.

Tras varias pruebas obviamente infructuosas vuelvo a lanzar el script de Python y obtengo en el volcado de la memoria la última combinación user/password que había utilizado. Perfecto, es cuestión de hacer peticiones hasta que el usuario legítimo entre al panel, cosa bastante improbable teniendo en cuenta la hora que es.

Figura 5: Opción de fijar el ataque de HeartBleed en el Plugin de FOCA

Esto es algo que hoy en día está bastante automatizado en todos los ataques de HeartBleed, y por eso en el plugin de HeartBleed para FOCA se ha añadido de la opción de lanzar el ataque cada 5 segundos y generar un log, algo que ya podían haber publicado antes y no habría tenido que hacérmelo yo.

Como no tenía claro si a la mañana siguiente tendría tiempo de ponerme de nuevo, preparé un pequeño script en Bash que me hiciera el trabajo sucio de explotar la vulnerabilidad periódicamente guardando los datos cada 30 segundos hasta que pueda volver a evadirme de las obligaciones y centrarme en las diversiones.

Figura 6: Script en Bash para fijar la explotación del bug de HeartBleed

Poco que explicar, sencillo pero funcional. Abro una conexión ssh hacia el equipo que se va quedar haciendo el trabajo y creo una sesión con Screen, me parece una buena opción cuando abro terminales de forma remota porque al cerrar la conexión la sesión se queda abierta en el servidor. Solo queda esperar el tiempo suficiente.

Al día siguiente, cerca del mediodía echo un vistazo al log y sorpresa, en algún momento se ha conectado alguien con credenciales de administrador y éstas han sido capturadas.

Figura 7: Una password en el log

Llegados a este punto no puedo vencer la tentación y entro al panel a echar un vistazo, solo un vistazo, os lo juro, para poder mostrar esta captura y conseguir enfatizar el mensaje final de este artículo.

Figura 8: El panel accesible

Conclusiones sobre HeartBleed

Una de las webs alojadas en este servidor pertenece a un bufete de abogados, por lo que para que quede claro desde el principio el carácter didáctico del ataque he decidido ponerme en contacto con ellos directamente y que sean ellos los que se encarguen de exigir a quien estimen conveniente que apliquen una política de seguridad adecuada.

Hoy en día HeartBleed es ya una vulnerabilidad conocida en profundidad, explotada de manera habitual por todas las herramientas, pero seguro que seguiremos encontrándola aún en multitud de sitios durante años. Es muy fácil de automatizar y sería más que recomendable que tomaras en serio las recomendaciones del principio de este artículo. Haz un escaneo profundo de todos equipos de la red - todos, incluidos los dispositivos de red - y por todos los puertos - todos los puertos - buscando cualquier OpenSSL vulnerable que pueda estar ahí.

Por supuesto, todas las passwords que tuvieras antes de HeartBleed deben ser cambiadas, al igual que los certificados digitales, deben ser cambiadas, porque mucha gente ha estado haciendo estas mismas pruebas y pueden estar en manos de cualquiera. Pon un segundo factor de autenticación a cada identidad que puedas o Latch si puedes a tu web que como dice este artículo "Con Latch el problema de Heartbleed no hubiera sido tan grande". Además, visto este ejemplo de hoy, tal vez sería bueno que el equipo de Eleven Paths - o alguien - sacara un plugin de Latch para Plesk, que parece que hace falta.

Autor: Juan Luis Valverde Padilla
jl.valverde@jvalverde.es

5 comentarios:

  1. Ojo, que tan importante como cambiar contraseñas es esperar a que el servicio que sea esté actualizado y parcheado. Que en cuanto se publicó lo de Heartbleed la gente se lanzó en masa a cambiar los passwords, pero no todo el mundo arregló el problema inmediatamente.

    ResponderEliminar
  2. entonces, no sirve de nada cambiar la pass, si el servidor no se encuentra parchado. :(

    ResponderEliminar
  3. Buen artículo. Os dejamos un artículo sobre cómo solucionar el problema de esta vulnerabilidad en centralitas basadas en Asterisk... por si os puede interesar. Un saludo.
    

    http://www.masip.es/protege-asterisk-heartbleed/

    ResponderEliminar
  4. Interesante articulo

    ResponderEliminar
  5. Que interesante artículo.
    Realmente está genial, no lo conocia hasta apenas que lo muestras y creo que lo voy a probar.
    Mira que andaba buscando algo sobre los mejores web Hosting de México y di con esto, la verdad es estupendo.

    ResponderEliminar