[LUG.ro] Debian informa del asalto a sus servidores

[Sebastián D. Criado]

-----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 - scriado@ciudad.com.ar
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-----