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/QtPly6aE
puede 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.org
corre 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 funcional
en 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/402
y 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
No hay comentarios:
Publicar un comentario