Informe de la investigación tras los compromisos de los servidores de Debian
2 de diciembre de 2003
El equipo de administración y los expertos de seguridad de Debian pueden finalmente precisar el método usado para entrar ilegalmente en cuatro máquinas del proyecto. Sin embargo, aún no se ha descubierto el responsable de la intrusión
El intruso no alteró los paquetes de los archivos.
Los equipos de seguridad y de administración de Debian comprobaron estos archivos (security, us, non-us) en primer lugar y luego continuaron con la investigación y el proceso de reinstalación. Éste es el motivo por el que el proyecto ha podido volver a abrir el archivo de seguridad de nuevo y confirmar que la actualización estable (3.0r2) no estaba comprometida.
Si el proyecto hubiera podido anticipar el compromiso mientras se implementaba la actualización estable, las personas implicadas en el desarrollo lo habrían retrasado. Sin embargo, los paquetes actualizados ya estaban instalados en el archivo estable y los servidores de réplica cuando se descubrió la intrusión, de tal forma que no fue posible retenerlo más.
Se usaron varios métodos basados en diferentes datos de control para verificar los paquetes y asegurar que el atacante no alteró los archivos:
- listas de sumas MD5 almacendas externamente durante las semanas anteriores en máquinas no comprometidas
- archivos .changes firmados digitalmente de los archivos externos de debian-devel-changes en máquinas no comprometidas
- archivos .changes firmados digitalmente sobre los respectivos archivos de los servidores
- archivos de registro de las réplicas almacenadas externamente
Cronología
Debajo hay una cronología con el decubrimiento y recuperación de las máquinas comprometidas. Todas las horas están en formato UTC. Algunas horas son sólo estimaciones, porque nuestra conversación no tenía marcas temporales exactas.
- Sep 28 01:33 Linus Torvalds publica 2.6.0-test6 con la corrección para do_brk()
- Oct 02 05:18 Marcelo Tosatti aplica la comprobación de límites do_brk()
- Nov 19 17:00 El atacante ingresa en klecker con una contraseña robada (esnifada)
- Nov 19 17:08 Root-kit instalado en klecker
- Nov 19 17:20 El atacante ingresa en master con la misma contraseña robada (esnifada)
- Nov 19 17:47 Root-kit instalado en master
- Nov 19 18:30 El atacante ingresa en murphy con una cuenta de servicio desde master
- Nov 19 18:35 Root-kit instalado en murphy
- Nov 19 19:25 Comienzan los oopses en murphy
- Nov 20 05:38 Comienzan los oopses en master
- Nov 20 20:00 Descubrimiento de los oopses en master y murphy
- Nov 20 20:54 Root-kit instalado en gluck
- Nov 20 22:00 Confirmación de que debian.org estaba comprometida
- Nov 21 00:00 Desactivación de todas las cuentas
- Nov 21 00:34 security.debian.org echado abajo
- Nov 21 04:00 gluck (www, cvs, people, ddtp) echado abajo
- Nov 21 08:30 Apuntar www.debian.org a www.de.debian.org
- Nov 21 10:45 Anuncio público
- Nov 21 16:47 Actualizada la información de desarrollo
- Nov 21 17:10 murphy (lists) y master echados abajo
- Nov 22 02:41 security.debian.org está en línea de nuevo
- Nov 25 07:40 lists.debian.org está en línea de nuevo
- Nov 28 22:39 Linux 2.4.23 publicado
Descubrimiento
El martes 20 de noviembre de por la tarde (GMT) el equipo de administración se percató de varios oopses del núcleo en master. Como había estado sin problemas durante mucho tiempo, el sistema se puso en mantenimiento para una investigación más concienzuda sobre potenciales problemas de hardware. Sin embargo, al mismo tiempo una segunda máquina, murphy, estaba experimentando exactamente los mismos problemas, lo que provocó las sospechas de los administradores.
klecker, murphy y gluck tenían el «Entorno Avanzado de Detección
de Instrusión - Advanced Intrusion Detection Environment» (paquete
aide) instalado para
monitorizar cambios en el sistema de archivos y más o menos al mismo
tiempo comenzó a alertar de que /sbin/init
había sido
reemplazado y que los valores de mtime y ctime habían cambiado para
/usr/lib/locale/en_US
.
Una investigación más minuciosa mostró que la causa de ambos problemas era el root-kit SucKIT (1.3b). Incluía robo de contraseñas (esnifado) y detección de capacidades de evasión (p. ej., herramientas para ocultar procesos y archivos), que estaban instalados directamente en el núcleo, lo que causaba que se tuviera noticia de los oopses.
Análisis detallado del ataque
El miércoles 19 de noviembre, a las 5pm GMT aproximadamente, se usó una contraseña robada (esnifada) para ingresar en una cuenta de desarrollador sin privilegios en la máquina klecker (.debian.org). El atacante recuperó luego el código fuente mediante HTTP para un aprovechamiento local del núcleo desconocido (en ese momento) y obtuvo permisos de root mediante este aprovechamiento. Tras esto, se instaló el root-kit SucKIT.
Se usó la misma cuenta y los mismos datos para ingresar en la máquina master, para obtener permisos de root con el mismo aprovechamiento y también para instalar el root-kit SucKIT.
El atacante intentó más tarde obtener acceso al host murphy con la misma cuenta. Pero falló porque murphy es una máquina restringida y su único propósito es actuar como servidor de listas de correo y sólo un pequeño subconjunto de los desarrolladores puede ingresar allí. Ya que falló el intento de ingreso inicial, esta persona usó su acceso como root en master para acceder a una cuenta administrativa que se usaba para propósitos de copia de seguridad y obtener acceso también a murphy. También se instaló en esta máquina el root-kit SucKIT.
El día siguiente, el atacante usó una contraseña robada (esnifada) de master para ingresar en gluck, convertirse en root allí e instalar también el root-kit SucKIT.
El análisis forense reveló las fechas y horas exactas en las que se
sobreescribió el programa /sbin/init
y se instaló el
root-kit. El análisis también descubrió el archivo ejecutable que se
usó para obtener acceso como root en las máquinas, que estaba protegido
y ofuscado con Burneye. Tras desenvolver y desensamblar el
aprovechamiento, los expertos de seguridad descubrieron qué error del
núcleo se había utilizado.
Se había aprovechado una llamada al sistema brk para sobreescribir la memoria del núcleo (cambiando los bits de protección de página). Al hacer esto, el atacante obtuvo control pleno sobre el espacio de memoria del núcleo y podía alterar cualquier valor en memoria.
Aunque este código del núcleo lo mejoró en septiembre Andrew Morton y lo copió en una versión previa de los núcleos de octubre, no se habían considerado las implicaciones de seguridad de esta mejora. Por tanto, ningún vendedor publicó avisos de seguridad. Sin embargo, tras haberse descubierto que se usó como aprovechamiento local de root, el proyecto «Common Vulnerabilities and Exposures - Exposiciones y Vulnerabilidades Comunes» le asignó a este problema el identificador CAN-2003-0961. Está corregido en Linux 2.4.23 y se publicó el fin de semana pasado en el aviso de seguridad de Debian DSA 403.
Linux 2.2.x no es vulnerable a este aprovechamiento porque antes se hacía la comprobación de límites. También se cree que los núcleos para Sparc y PA-RISC no son vulnerables porque las direcciones del núcleo y del usuario se guardan en diferentes espacios de direcciones en estas arquitecturas.
Por favor, comprenda que no podemos hacer público el aprovechamiento usado a gente que no conocemos. Así que, por favor, no nos lo pida.
Recuperación
Después de haber echado abajo las máquinas, se crearon imágenes de los discos duros comprometidos y se almacenaron en una máquina distinta. Se distribuyeron a los encargados de hacer el análisis forense. Se reinstalaron las tres máquinas de los EE.UU. (master, murphy, gluck) y se fueron configurando los servicios uno a uno tras la investigación de los administradores de los servicios más relevantes.
En klecker, sin embargo, esta tarea se pospuso hasta un mantenimiento de seguridad para que el archivo de seguridad se pudiera poner en línea antes que los otros servicios. En esos momentos tampoco teníamos acceso por consola a klecker, por tanto la recuperación se tenía que hacer remotamente. Tras haber ingresado por consola vía puerto serie a una máquina local en una conexión de red con cortafuegos, se eliminó el root-kit, se cambió y se comprobó el núcleo, se comprobaron dos veces los binarios y el archivo de seguridad se verificó con respecto a varias fuentes externas distintas. Esta máquina se volverá a instalar en las próximas semanas.
Como precaución de seguridad, se desactivaron todas las cuentas de los desarrolladores en LDAP y se eliminaron las claves SSH de las máquinas más importantes, para que no se pudieran comprometer más máquinas. Esto, sin embargo, desactivó de forma efectiva cualquier trabajo que implicara subir archivos y acceder a los depósitos CVS.
Todas las contraseñas usadas en quantz (p. ej., todas las contraseñas de Alioth, arch y subversion) también se invalidaron. También se han eliminado todas las claves SSH autorizadas. Por favor, use el sistema para las contraseñas perdidas para recibir una contraseña nueva.
Cuando todos los servicios estén funcionando de nuevo y se hayan asegurado suficientemente las máquinas, LDAP será reconfigurado para que todos los desarrolladores puedan crear una contraseña nueva otra vez. Sin embargo, no se puede predecir cuándo ocurrirá esto.
Tras la recuperación, se reinstalará SSH en todas las máquinas comprometidas. Por tanto, habrá nuevas claves RSA y huellas dactilares de claves para esas máquinas. Las claves se incluirán en LDAP tan pronto como se creen y se podrán recoger desde aquí.
Consecuencias
Renueve sus contraseñas
Ya que las contraseñas fueron esnifadas de las máquinas comprometidas, cualquier conexión saliente en la que haya una contraseña se considerará también comprometida (p. ej., se considera que el atacante conocía la contraseña). Por tanto, se debería cambiar inmediatamente.
Además, si alguien tenía acceso a una máquina de Debian y estaba usando la misma contraseña o frase de paso en otras máquinas o claves le recomendamos encarecidamente que cambie la contraseña o frase de paso respectivamente tan pronto como le sea posible.
Si se había generado un clave SSH o se había guardado en una de esas
máquinas y se usaba para ingresar en otras máquinas (p. ej., instalándola
en .ssh/authorized_keys
), también se debería eliminar.
Las claves GnuPG/PGP que se encuentren en máquinas de debian.org también se eliminaron de los anillos de claves de Debian y, por tanto, se desactivaron.
Los desarrolladores que estén preocupados por sus propias máquinas deberían al menos lanzar chrootkit y observar su salida. Matt Taggart mantiene una migración de la versión actual para woody en la siguiente dirección:
- deb http://lackof.org/taggart/debian woody/chkrootkit main
- deb-src http://lackof.org/taggart/debian woody/chkrootkit main
Además, Wichert Akkerman y Matt Taggart mantienen una lista detallada de tareas por precaución.
Root-Kit SucKIT
SucKIT es un root-kit presentado en el número 58 de Phrack, artículo 0x07 ("Parcheo de Linux al vuelo sin LKM", por sd y devik). Éste es un root-kit completo que se carga a través de /dev/kmem, p. ej. no necesita un núcleo con soporte para carga de módulos. Proporciona una shell respaldada por una conexión de acceso remoto protegida por una contraseña, que se inicia con un paquete específico (saltándose la mayoría de configuraciones de cortafuegos), y puede ocultar procesos, archivos y conexiones.
Normalmente, SucKIT se lanza como /sbin/init en el arranque del sistema,
se divide (haciendo un fork) para instalarse en el núcleo, inicia una
puerta trasera y lanza una copia del binario original «init» desde el padre
(con pid 1). Cualquier ejecución sucesiva de /sbin/init
se redirige al «init» original.
Protección Burneye de TESO
Burneye es un modo de ofuscación de los binarios ELF en la plataforma UNIX presentado en el número 58 de Phrack, artículo 0x05 ("Armando el ELF: Cifrado binario en la plataforma UNIX", por grugq y scut). Usando herramientas como Burneye de TESO, un atacante puede modificar un programa ejecutable para que cifre su verdadero propósito, ocultándolo de los filtros de los cortafuegos, sistemas de detección de intrusión, software antivirus y de los entrometidos ojos de los investigadores
Agradecimientos
- James Troup y Ryan Murray, por su trabajo en general en todas las máquinas
- Adam Heath y Brian Wolfe, por su trabajo en master y murphy
- Wichert Akkerman, por su trabajo en klecker
- Dann Frazier y Matt Taggart, por su trabajo en gluck
- Michael Stone y Robert van der Meulen, por su trabajo forense
- Marcus Meissner, por desensamblar el aprovechamiento usado
- Jaakko Niemi, por su trabajo en la verificación y reactivación de lists.debian.org
- Colin Watson, por su trabajo en la verificación y reactivación de bugs.debian.org
- Josip Rodin, por su trabajo en la verificación y reactivación de los archivos web de las listas
Respuesta de la prensa
- Slashdot, 21 nov 2003
- eWeek, 21 nov 2003
- InternetNews, 21 nov 2003
- Heise Newsticker, 21 nov 2003 (alemán)
- Pro-Linux, 21 nov 2003 (alemán)
- Linux-Community, 21 nov 2003 (alemán)
- BarraPunti, 21 nov 2003 (castellano)
- Newsforge, 21 nov 2003
- SearchEnterpriseLinux.com, 22 nov 2003
- Debian Planet, 22 nov 003
- PC World, 24 nov 2003
- ZDNet UK, 24 nov 2003
- Enterprise Linux IT, 24 nov 2003
- The Age, 24 nov 2003
- Sydney Morning Herald, 24 nov 2003
- Windows & .NET Magazine, 24 nov 2003
- Infoworld, 24 nov 2003
- Linux Insider, 24 nov 2003
- eCommerce Times, 24 nov 2003
- TechNewsWorld, 24 nov 2003
- The Register, 28 nov 2003
- Newsforge, 28 nov 2003
- Slashdot, 28 nov 2003
- Slashdot, 1 dic 2003
- The Age, 1 dic 2003
- Sydney Morning Herald, 1 dic 2003
- Pro-Linux, 2 dic 2003 (alemán)
- Heise Newsticker, 2 dic 2003 (alemán)
- Golem, 2 dic 2003 (alemán)
- LWN, 2 dic 2003
- The Register, 2 dic 2003
- ZDnet DE, 2 dic 2003 (alemán)
- Linux-Community, 2 dic 2003 (alemán)
- Heise, 2 dic 2003 (alemán)
- Heise Newsticker, 2 dic 2003 (alemán)
- Symlink, 2 dic 2003
- Pro-Linux, 2 dic 2003 (alemán)
- Heise Newsticker, 4 dic 2003 (alemán)
- Symlink, 4 dic 2003 (alemán)
- Symlink, 4 dic 2003 (alemán)
- Newsforge, 4 dic 2003
- Newsforge, 5 dic 2003
- OSnews, 10 dic 2003
- Cnet, 10 dic 2003
- Newsforge, 30 dic 2003
Información de contacto
Para más información puede visitar las páginas web de Debian o enviar un correo-e a press@debian.org.