Se ha descubierto que UnrealIRCd, un popular servidor de IRC, estaba troyanizado y disponible desde la página oficial al menos desde
noviembre. Los atacantes reemplazaron el código fuente de la versión para sistemas Unix/Linux, y la modificación ha pasado inadvertida
durante unos 8 meses. A raíz del incidente, han comenzado a firmar su código. ¿Qué errores han cometido?
UnrealIRCd es un popular servidor IRC para Linux y Windows. Los responsables del programa (en una entrada en su web que comienza con
la frase «Esto es embarazoso…») han hecho público que la versión disponible para descarga desde noviembre de 2009 contiene una puerta
trasera, y permite a un atacante ejecutar código arbitrario (con los mismos privilegios con los que se ejecute el programa) en el servidor
donde se instale. La única versión que ha sido reemplazada en los servidores oficiales ha sido el código fuente para Unix/Linux
(Unreal3.2.8.1.tar.gz) y no las versiones ya compiladas para Windows.
El problema ahora lo tienen los administradores que se hayan visto afectados (que han compilado e instalado la versión con la puerta
trasera). Realmente, los servidores que han ejecutado esta versión (aunque sea durante poco tiempo), no pueden ser ya confiables, puesto
que el atacante ha podido obtener información de todo tipo. Es de esperar que pocos administradores ejecutasen el servidor IRC como root,
lo que limitaría los poderes de los atacantes. Aun así, esto no evita que en este tiempo, no hayan conseguido robar información accesible por
el usuario bajo el que corre el servidor IRC, o escalar privilegios aprovechando cualquier vulnerabilidad en el kernel.
Se trata de un hecho relevante que, efectivamente, resulta embarazoso para los desarrolladores del programa. Lo tomamos como excusa para
repasar lo que pueden ser algunos malos hábitos adquiridos tanto por parte de los programadores como de los usuarios.
Hashes para comprobar la integridad
UnrealIRCd se había tomado la molestia de publicar los hashes de los archivos para que los usuarios pudieran comprobar que realmente se
descargaban el fichero «oficial». Esta medida ha resultado poco efectiva por varias razones.
* Según podemos comprobar por la caché de Google, a fecha de 22 de mayo, al parecer los atacantes también habían modificado el hash MD5 de la
página oficial de descarga. Esto quiere decir que los usuarios que descargaran la fuente y comprobasen el hash con la página oficial, no
notarían nada raro. Este es uno de los puntos débiles de esta medida de seguridad: si un atacante consigue comprometer un servidor como para
sustituir un archivo, si es cuidadoso, debería sustituir también el hash en la misma página. Esta medida es útil sin embargo, cuando existen
numerosos servidores desde donde descargar el archivo (y los usuarios se toman la molestia de comprobarlo en diferentes servidores).
* En los foros oficiales de UnrealIRCd (forums.unrealircd.com), sin embargo, el hash publicado desde hace meses era el correcto. Por tanto,
cualquier usuario que efectivamente hubiese comparado los hashes, lo debería haber notado.
* Como detalle menor, a fecha de 22 de mayo, UnrealIRCd solo publicaban el hash MD5. No es ningún secreto que MD5 está «roto» y que es mucho más
seguro utilizar (como parece que ya hacen) SHA.
Auditorías
A pesar de ser un programa veterano (desde 1999), un cambio en los archivos fuente de ciertos servidores ha pasado desapercibido durante
unos 8 meses. Es uno de los periodos más largos que podemos recordar en los que un programa troyanizado ha pasado inadvertido. Los
desarrolladores deberían haber realizado una mínima auditoría del estado de sus servidores y archivos. No se tiene información de cómo han
conseguido entrar en los servidores.
Creemos que es irrelevante que la puerta trasera fuese «visible» en el código fuente descargado. Esto no ha «acelerado» su detección. Aunque ha
sido compilado por (probablemente miles de) administradores, nadie ha detectado el problema (o nadie ha avisado). Esto es lógico en proyectos
de cierta envergadura: simplemente, es muy poco probable que un usuario ocasional detecte algo «raro» en un código ajeno de miles de líneas.
Mantenerlo a punto es responsabilidad de los desarrolladores principales, no de las personas que lo descargan.
Criptografía
Como hemos dicho, usar un hash para comprobar la integridad es útil en algunas ocasiones, pero es una medida limitada. Los programadores de
UnrealIRCd han necesitado pasar este mal trago para darse cuenta de que deben firmar criptográficamente los ficheros. Acaban de anunciar una
clave pública GPG con la que, a partir de ahora, firmarán sus archivos.
Solo queda que los usuarios que descarguen su programa, comprueben la firma.
Aprendiendo la lección
Varios desarrolladores importantes han «sufrido» recientemente el problema de hacer público software troyanizado (aunque ninguno durante
tanto tiempo). A Mozilla le ocurrió en febrero de 2010 y a mediados de 2008. En marzo de 2007, la versión de WordPress fue troyanizada
igualmente. Tampoco firmaban digitalmente sus archivos (y siguen sin hacerlo).
En 2002, las versiones 3.4 y 3.2 de OpenSSH fueron troyanizadas desde ftp.openssh.com y ftp.openbsd.org. Poco después, el servidor HTTP de
Tcpdump, fue comprometido (el 11 de noviembre de 2002), y su descarga no fue deshabilitada hasta el día 13. El código troyanizado ignoraba el
tráfico del puerto 1963, desde donde un atacante podría controlar la máquina en la que se ejecutase.
Aproximadamente el 28 de septiembre de 2002 comprometieron ftp.sendmail.org (el servidor de correo más usado del mundo). No fue
hasta el 6 de octubre de ese año que se deshabilitó la descarga del programa envenenado.
Al menos, los responsables de UnrealIRCd parece que han aprendido la lección. Según el aviso oficial «Simplemente no lo notamos, deberíamos
haberlo hecho; No comprobamos los ficheros en los servidores de forma regular. Deberíamos haberlo hecho; No firmamos los archivos con PGG/GPG,
deberíamos haberlo hecho».
El archivo troyanizado es Unreal3.2.8.1.tar.gz, con hash md5 752e46f2d873c1679fa99de3f52a274d. La versión oficial, sin embargo,
debería devolver el hash 7b741e94e867c0a7370553fd01506c66. Al parecer solo algunos servidores de descarga fueron comprometidos, y no los
repositorios de código fuente.
Aparte del hash, para saber si se está corriendo una versión con esta puerta trasera, se puede hacer un:
grep DEBUG3_DOLOG_SYSTEM include/struct.h
en el directorio del programa. Si devuelve dos líneas, está troyanizado.
¿Te resultó interesante? Compártelo ...
