Crónica de la intrusión en blogs.perl.org con resultado de casi 3000 cuentas hackeadas

 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
(http://blogs.perl.org/users/meta/2014/01/security-breach.html) 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
(http://movabletype.org/news/2013/01/movable_type_438_patch.html) 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
(http://openwall.com/lists/oss-security/2013/01/22/3).

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 erróneamente 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 ha
cambiar esa contraseña que usa también en el repositorio de código,
donde guardan celosamente las fuentes de una aplicación de miles de
dólares?

Fuente

__________

NOTA: Los interesados en información sobre contrato de soporte Asistencia Tecnica de SATINFO y/o licencia de uso/actualizaciones de sus utilidades, contacten con info@satinfo.es
__________

Este blog no se hace responsable de las opiniones y comentarios de los textos en los que se cita la Fuente, ofreciendo su contenido solo para facilitar el acceso a la información del mismo.

Puedes seguir cualquier respuesta a esta entrada mediante el canal RSS 2.0. Los comentarios y los pings están cerrados.

Los comentarios están cerrados.

 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies