El pasado día 25, Aaron Crane, uno de los administradores del dominio blogs.perl.org, la plataforma de federación de blogs del lenguaje Perl, publicó una entrada donde anunciaba que el sitio había sido víctima de una intrusión. Los datos de casi 3000 cuentas de usuario habían sido publicados.
Vamos a analizar como se realizó la intrusión con la información que Crane y otros usuarios aportaron y que medidas tomaron tras el episodio.
La mañana del 22 de enero, los administradores del sitio, fueron alertados de la intrusión. No comentan si esta fue descubierta al ver las cuentas publicadas o el defacement. Los atacantes dejaron un mensaje reivindicativo en blogs.perl.org/icrg.php pero, al parecer, no tocaron el index. Algo bastante típico en este tipo de ataques, por lo que supuestamente el mensaje no aparecía visitando la raíz.
En el leak de las cuentas, subido a https://www.quickleak.org/QtPly6aEpuede observarse la fecha del volcado de la base de datos: 21.01.2014 y la página creada el 22.01.2014 unas cuatro horas después, por lo que cabe la posibilidad de que alguien que lo viese diera la voz de alarma a los administradores. Tras el aviso, desactivaron la parte dinámica del sitio (los módulos Perl y PHP de Apache) para determinar que estaba ocurriendo, en ese momento solo se ofrecía contenido estático.
blogs.perl.orgcorre una plataforma Movable Type versión 4, podemos verlo simplemente accediendo al código HTML de cualquier página generada. Movable Type es una plataforma de contenido para blogs realizada en el lenguaje Perl para la gestión y PHP para la publicación. Esto es un dato curioso ya que los atacantes usaron PHP en el ataque mientras que la vulnerabilidad estaba presente en un módulo de Perl. Otro dato naturalmente importante es que la versión 4 ya no recibe soporte oficial desde hace bastante tiempo.
¿Qué vulnerabilidad usaron?
No usaron un 0day, ni una vulnerabilidad conocida pero sin exploit publicado, tampoco usaron una vulnerabilidad conocida con un exploit publicado al que hay que retocar algo el código para que funcione correctamente. En el ataque se usó una vulnerabilidad que permite inyectar código Perl arbitrario en remoto, sobre la que se conoce su existencia desde hace un año y de la cual se tiene un exploit funcionalen la suite por excelencia: Metasploit (http://www.exploit-db.com/exploits/24321/)
La vulnerabilidad se encuentra en «mt-upgrade.cgi» cuya funcionalidad reside en “lib/MT/Upgrade.pm”. Esta vulnerabilidad se encuentra perfectamente descrita en http://www.sec-1.com/blog/2013/402y tiene asignado el CVE-2013-0209.
Básicamente es un script que es usado durante la instalación y actualización de la plataforma. El problema es que puede ser invocado desde el exterior, sin necesidad de autenticación y (sin parche) contiene una función con un parámetro que efectúa un ‘eval‘ sobre cualquier código Perl que inyectemos vía petición HTTP POST.
Afortunadamente para los usuarios que no podían permitirse la migración o actualización, Movable Type publicó un parche para las ramas afectadas: 4.2 y 4.3. Dicho parche fue publicado hace justamente un año, días antes del anunció de la vulnerabilidad.
Recapitulando, blogs.perl.org llevaba más de un año funcionando con una vulnerabilidad que permitía ejecutar código arbitrario en su sitio. Con un exploit publicado. Corriendo un software con una versión fuera de soporte y sin aplicar un parche que lleva igualmente un año disponible para tapar el agujero. La pregunta quizás no es por qué no se molestaron en revisar la seguridad sino como han sido capaces de permanecer intactos un año entero…si es que realmente han permanecido intactos.
Evaluación de daños
Aunque no lo relatan directamente es bastante probable que los atacantes usaran la vulnerabilidad para subir una shell en PHP. Crane comenta en la entrada «borramos la herramienta del atacante«, por lo que es asumible que hicieran esto último.
Las medidas que tomaron fue el borrado del script PHP, aplicación del parche correspondiente y otro parche más, creado por ellos mismos, que cambia el algoritmo de generación de los hashes a SHA-512.
Públicamente solo se tiene conocimiento del mensaje y el leak de la tabla «mt_author» que contiene, entre otros datos, el correo, contraseña y nombre.
De las contraseñas se almacena el hash usando la función «crypt» de Perl, básicamente una envoltura de la función correspondiente de la librería C (ver «unistd.h» o man 3 crypt). Esta función contiene dos parámetros: un texto en claro y una sal y devuelve el hash en forma de 13 bytes siendo los dos primeros la sal. Se puede «experimentar» con la función con un simple oneliner:
perl -e ‘ print crypt(“cadena”, “sal”) . “\n” ’
Internamente “crypt” usa el algoritmo DES ligeramente modificado, aunque puede utilizar otros. Solo se usan los ocho primeros bytes de la cadena por lo que las contraseñas ven reducidas su longitud efectiva a ese tamaño. DES y su actualización Triple DES son considerados inseguros y sobre ellos pueden usarse diversos tipos de ataques con éxito. Otra nota curiosa es que la función, tanto en Perl como en C, es llamada «crypt» lo que hace pensar erroneamente que se «cifran» las contraseñas.
El verdadero problema de los leaks con los hashes es el uso cruzado que puede darse de las contraseñas. Teniendo información del usuario (correo, nombre, etc) puede darse el caso de que una misma contraseña sea usada en múltiples sitios (ssh, correo, ftp…). En una conversación privada se ha comentado que con un simple portátil alguien ya ha conseguido el 20% de las contraseñas en solo 3 horas.
Cuando ocurre una brecha de esta clase cabe preguntarse ¿Hasta donde han podido ramificar el ataque? ¿Le habrá dado tiempo al usuario x a cambiar esa contraseña que usa también en el repositorio de código, donde guardan celosamente el código fuente de una aplicación de miles de dólares?
David García
Twitter: @dgn1729
Deja una respuesta