Barrapunto

Parece que la cosa está bastante complicada sobre cómo se consiguió acceder a root con una cuenta sin privilegios. Se han hecho eco en Slashdot [slashdot.org] y en ZDNet [zdnet.co.uk].

Saludos C4

No se por qué, pero eso de que alguien haya entrado en Debian [debian.org] a través de Klequer [debian.org], máquina administrada por Wichert Akkerman [wiggy.net], que tiene su clave gnupg comprometida [gnupg.org] según Werner Koch [www.guug.de] (mantenedor de gnupg [gnupg.org]), me parecen demasiadas coincidencias...

pub 1024D/2FA3BC2D 1998-07-05 Wichert Akkerman
uid Wichert Akkerman
sub 2048G/C76F38D2 1998-07-05

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 h

18 de Noviembre
---------------
Un intruso, que llamaremos 'dick' entra en Klequer usando una contraseña trivial (jane/sex).

'dick' es un poco lamer y no se da cuenta que el servidor es vulnerable al viejo exploit local ptrace, así que 'dick' esnifea trafico (en debian todavía no usan SSL, pero /dev/eth0 esta en modo promiscuo por defecto) y analiza un mogollón de correos usando la clave gpg del usuario local 'jane'.

Aburrido y cansado, 'dick' se desconecta.

19 de Noviembre
---------------
Lo que no sabe 'dick' es que su maquina esta comprometida, y que la cuenta jane/sex ya esta rulando por efnet. Un hacker que llamaremos 'bob' ya sabe como entrar en Klequer. 'bob' rula el exploit ptrace, obtiene uid=0, instala suckit y entra en Master usando la misma cuenta (jane/sex).

Por suerte o desgracia, Master no es vulnerable al exploit ptrace, ¡¡¡pero que mas da!!!! 'bob' tiene un 0day no publicado y peta Master, Murphy y Gluck (LOL, u 3v1l hax0r!)

Luego 'bob' modifica la pila TCP del núcleo de tal manera que se produce un kernel panic cada vez que aparece la palabra 'GNU' en los datagramas (sin SSL).

20 de Noviembre
---------------
Por culpa de un syslog remoto, Master no para de hacer oops.

Descubrir cómo el atacante se hizo con un acceso de superusuario a través de una cuenta sin privilegios permitiría arreglar el fallo de seguridad en el programa que fuera. Y después agradecerle a los atacantes no haber colaborado para informar de cómo lo obtuvieron como buenos hackers.

No consideraríamos igual un ataque a cualquier otra organización, simplemente por el aprecio que tenemos a la labor realizada por los mantenedores de Debian. Y que sea así por mucho tiempo. ¡Ánimo Debian!

Vamos, los núcleos ya són los últimos, hay algún parche de la DSA las bitácolas han alarmado en un tiempo más que aceptable pero creo que algo como Grsecurity [grsecurity.net] seria la monda. Vamos, que seguro que un poco más blindado i facilito de mantener sí se puede.

Una pregunta:
Es seguro ir diciendo por ahí el software que usas para proteger a tu maquina. Claro esta que luego cada uno se lo configu7D«. su gusto.

Tras ler todos lo comentarios se ha subcitado una polemica sobre la seguridad de debian asi como de la politica de transparencia, vamos a analizarlo:

• Los servidores de debian son atacados
• los administradores se dan cuenta de ello
• para evitar males mayores avisan del poblema y paralizan los servidores
• aquellas personas que han actualizado recientemente revisan sus programas para comprobar su integridad
• los servidores se analizan y se restauran copias de seguridad
• se descubre el problema, se soluciona y se da la solucion que sirva a terceros

ahora revisemos otra politica

• los servidores de debian son atacados
• lo desarrolladores se dan cuenta
• preparan los servidores para ser analizados (mientras tanto los usarios siguen descargando de los servidores comprometidos)
• reparan los servidores y analizan el problema
• resuelven el problema, nadie se ha enterado pero un numero exponencial de usuarios puede tener cualquier cosa en su ordenador y no saberlo incluso pueden tener el mismo fallo de seguridad que los servidores de debian
• tiempo despues sale la noticia de que los servidores de debian han quedado comprometidos
• la confianza para con debian cae en picado

me parece qeun politica transparente es mucho mejor

Pues me parece una forma correcta la que ha usado debian para informar de los fallos de seguridad. Confío en que encontrarán el fallo lo solucionarán y nos lo explicarán. Esa es la virtud del software libre.

TAluek.

Cierta empresa que tu te sabes gasta miles de millones en intentar que sus productos sean, por las buenas o por las malas, los únicos que la gente use y que la gente pague.

No es, ni mucho menos, el mismo caso. Debian no intenta venderte nada. No intenta que pienses que su producto es el mejor o el único. Debian ofrece un servicio a todo el mundo. Hay una diferencia, no me seas hartosopas.

Y, que te parezca lo que sea. Es estupendo que hayan hayan hecho público todo este asunto. Y será más estupendo aún cuando averigüen qué ha pasado, lo solucionen y nos lo cuenten a todos.

Se puede y se debe confiar en Debian. Porque han detectado el problema a tiempo. Porque lo han contado a todo el mundo. Porque seguirán ofreciéndonos la oportunidad de contar con un S.O. fantástico.

Salud.

Seguramente ya esté corregido en las nuevas versiones actualizadas de los programas.

Es más fácil atacar una máquina con algún fallo de seguridad conocido en un programa no actualizado y seguramente esa era la vulnerabilidad.

Eso no tiene mérito y no demuestra nada sobre la calidad de la distribución actual.

Dejad de decir tonterías, por favor.

Lo que bajo mi punto de vista es bastante seguro es que si Mandrake/RedHat han recibido intrusiones de ese tipo no lo han hecho público.

Lo que me lleva a pensar... ¿No hubiese sido mejor que la gente de Debian no hubiese hecho pública esta intrusión? ¿No hará esto que mucha gente deje de confiar sus servidores a Debian contrarrestando esto el fuerte empuje que estaba teniendo Debian en la empresa según yo había oido? Yo opino que les hará perder confianza de mucha gente, aunque no la mía.

A mí me da confianza que Debian sepa reconocer la entrada y nos expliquen que les ha pasado, ya que demuestra que saben que les ha pasado y han puesto medidas para dificultar que vuelva a pasar. De todos modos me temo que mucha gente no va a opinar lo mismo.

La diferencia entre decir las cosas y esconderlas es mucha. ¿De verdad crees que Microsoft publica todos los bugs, accesos a sus sistemas, etc, que tiene? Cuando hay transparencia hay que alabarla. Cuando hay oscuridad, criticarla. Donde está cada cosa yo ya lo se. Y donde está la cerrazón, también. ¿Lo sabes tu?

>Si está noticia se refiriera a la compañía de Redmont...

Eso es mentira: M$ acaba de reconocer 7 fallos en su IE [geeknews.net], y nadie ha comentado nada...:

Microsoft is not aware of anyone actively exploiting the holes or of any impact on customers.

Two holes are critical and could allow an attacker to run a program that would delete files, crash the machine or take control of it from a remote location

C4

TROOOOOOOOOL

en definitiva: la verdad nos hara libre, con esto queda todo dicho.

Mira tonto ignorante!

Personalmente, ya no he leido nada más de tu comentario.