-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Extraido de Barrapunto
Traducci�n a vuelapluma (Puntos:5, Informativo) por pobrecito hablador el S�bado, 29 de Noviembre 2003, a las 14:18h (n�239979) Hola, Nota: Hay que tener en cuenta que: a) la informaci�n sobre la intrusi�n viene de m�quinas comprometidas, por lo que debe ser tomada con el suficiente escepticismo. b) la investigaci�n sigue adelante - de forma que la informaci�n que estoy escribiendo puede ser inv�lida seg�n salgan a la luz m�s datos [O no, depende de c�mo vaya]. Detecci�n El 20 de Noviembre se comprob� que master estaba teniendo fallos de n�cleo. Mientras est�bamos investig�ndolo, se descubri� que murphy estaba teniendo los mismos fallos. Adem�s tanto murphy como gluck tienen instalados ayudantes para monitorizar los cambios en el sistema de archivos y casi al mismo tiempo comenzaron a alertar que /sbin/init hab�a sido reemplazado y que hab�an sido cambiados los timestamps de mtime y de ctime de /usr/lib/locale/en_US. La investigaci�n revel� que la causa de ambas cosas hab�a sido el root kit 'Suckit' (ver el ap�ndice "Suckit" para m�s informaci�n). �Que ha ocurrido? El 19 de Noviembre de 2003, aproximadamente a las 5pm GMT, una contrase�a robada (sniffed) fu� usada para acceder a una cuenta sin privilegios en klecker.debian.org. De alguna manera consiguieron root en klecker e instalaron el Suckit en �l. La misma cuenta fu� utilizada entonces para acceder a master y ganar el root (e instalar el Suckit) tambi�n. Entonces intentaron entrar en murphy con la misma cuenta. Esto fall�, porque murphy es una m�quina restringida a la que s�lo pueden acceder una peque�a porci�n de desarrolladores. Entonces usaron su acceso raiz en master para acceder a una cuenta de administraci�n utilizada para hacer los backups, y la usaron para ganar acceso a murphy. Consiguieron root en murphy e instalaron tambi�n all� el Suckit. Al d�a siguiente usaron una contrase�a robada (sniffed) de master para acceder a gluck, conserguir root, e instalar Suckit. Ver el ap�ndice "L�nea de Tiempos" para m�s detalles de los tiempos. Respuesta Gluck fu� desactivado, y se hizo una imagen de sus discos para hacer un an�lisis forense. Debido a que no tenemos acceso f�sico a klecker, fu� desconectado de Internet, y las im�genes fueron realizadas a trav�s de consola serie a una m�quina local que se encontraba tras una conexi�n de red con cortafuegos. master y murphy se mantuvieron en funcionamiento durante un tiempo, el suficiente para anunciar el compromiso, despu�s de lo cual, fueron desconectados y realizadas sus im�genes. Limpieza Despu�s de la limpieza y reinstalaci�n de los archivos modificados, los archivos non-US y los de seguridad fueron verificados buscando cambios en los logs de los mirrors y comparando los checksums MD5 de los archivos de klecker con los de tres de los mirrors seguros. Gluck, Master y Murphy fueron borrados y reinstalados desde CD. Los datos y servicios est�n en proceso de ser restaurados. Todas las m�quinas y toda la informaci�n fu� comprobada buscando devices fuera de /dev, ejecutables suid, archivos con permiso de escritura, etc. y todos los archivos sospechosos fueron borrados. Los servicios (y sus programas/ scripts) fueron comparados con fuentes garantizados y sanitizados antes de ser reactivados. Ya que sab�amos que ten�amos cuentas comprometidas y sniffers entre nuestras manos, deb�amos suponer que un n�mero desconocido de cuentas estaban comprometidas, por lo que se bloquearon todas las cuentas, se invalidaron todas las contrase�as,y las claves ssh autorizadas fueron borradas. �C�mo pudo suceder esto? Todas las m�quinas comprometidas corr�an n�cleos recientes [1] y ten�an casi todas las actualizaciones de seguridad [2]. De todas formas hab�a dos problemas. (1) Los n�cleos que corr�an en las m�quinas en cuesti�n, no todos ellos ten�an el ptrace arreglado como a uno le hubiera gustado. Gluck, Master y Murphy tuvieron el nuevo kernel en mayo, pero Gluck, por diferentes razones no fu� actualizado hasta Agosto (aunque creo que ten�a /proc/sys/kernel/modprobe arreglado para bloquear los exploit m�s comunes hasta entonces). (2) Master ten�a una copia de su viejo disco duro por accidente. Desafortunadamente era muy vieja, con binarios suid sin parchear. Aunque ese pudo ser el verctor de ataque, yo no lo creo. (2) no parece ser ya que master no fu� la primera m�quina comprometida, por lo que sabemos. Aunque es posible que un atacante con acceso local a gluck pudiera conseguir root a trav�s de (1), parece improbable que esperaran durante meses para utilizarlo entonces en varias m�quinas s�lo para instalar el rootkit en varias m�quinas de debian.org y por lo menos un sistema (que sepamos) no relacionado (y que no ten�a la vulnerabilidad de ptrace). Basado en ello, y en el estudio forense del sistema no relacionado mencionado antes, creo que hab�a un exploit local de root todav�a no conocido que fu� utilizado para pasar de tener acceso local sin privilegios hasta ganar el root. �Hacia d�nde va la cosa? Desafortunadamente debido a que (creo que) hay un desconocido exploit local de root 'in the wild', no podemos desbloquear todav�a las cuentas en Debian. Obviamente no podemos continuar sin las cuentas LDAP por mucho tiempo. Por ahora, pido un poco m�s de paciencia a) mientras se completa la tarea dolorosa y cuidadosa de restaurar las m�quinas una por una y b) mientras intentamos y agotamos todas las posibilidades razonables de investigaci�n para determinar c�mo el atacante consigui� root desde una cuenta sin privilegios. Obviamente estamos mirando c�mo asegurar nuestras m�quinas y ajustar nuestros procedimientos para intentar evitar que ocurra de nuevo. Comunicar� m�s detalles sobre esto m�s tarde. Finalmente Los desarrolladores preocupados por sus m�quinas deber�an echar un vistazo a http://www.wiggy.net/debian/developer-securing/ [wiggy.net] Ap�ndices Gracias a Adam Heath y Brian Wolfe, a Wichert Akkerman, Dann Frazier y Matt Taggart, Michael Stone y Robert van der Meulen, Jaakko Niemi, Colin Watson, Josip Rodin. [Este texto est� basado en el borrador realizado por Wichert Akkerman]. L�nea de Tiempos Todas las horas son GMT. # Klecker init timestamp: Nov 19 17:08 # Master sk timestamp: Nov 19 17:47 # Murphy sk timestamp: Nov 19 18:35 # Los fallos en Murphy comenzaron: Nov 19 19:25 # Los fallos en Master comenzaron: Nov 20 05:38 # Gluck init timestamp: Nov 20 20:54 Suckit Suckit es un rootkit que instala un sniffer, un ocultador de procesos, un ocultador de archivos, y una puerta trasera de entrada a nivel de n�cleo. Aparentemente hab�a un fallo en su c�digo que hizo que saltaran los fallos de kernel en master y en murphy. Esto tambi�n explicar�a porqu� /sbin/init fu� reemplazado: el nuevo init carga Suckit en el n�cleo y despu�s procede a arrancar el verdadero init, asegur�ndose que todav�a est� activo despu�s del rearranque. Notas [1] Klecker: 2.4.22, Master y Murphy: 2.4.21-rc2, Gluck: 2.4.22rc2 [2] A klecker le faltaba la �ltima actualizaci�n de postgresql. El ssh en todas las m�quinas era una versi�n personalizada para DSA a la que le faltaban s�lo la tercera parte y �ltima (esto es, los parches de Solar Designer) de las actualizaciones de ssh. PD. Como siempre, hablo s�lo en mi nombre. James Saludos.- - -- - -- Sebasti�n D. Criado - [EMAIL PROTECTED] L.U.G.R.o - http://www.lugro.org.ar GNU/Linux Registered User # 146768 - ------------------------------------------------------------------- "Si el Universo fuera un programa estar�a hecho en C, y correr�a sobre un sistema UNIX" An�nimo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/yWo+8hmHQ8ZCg0IRAt2aAKCOs75tC05z26OQn3L638GDd4WJkwCbBnnW jplZJhoa46S4HpA1B9TMmvc= =6LGN -----END PGP SIGNATURE----- _______________________________________________ Lugro mailing list [EMAIL PROTECTED] http://www.lugro.org.ar/mailman/listinfo/lugro
