viernes, julio 14, 2006

¿Te hackearon porque debían? ...ó
¿Por qué te hackearon Debian?

Hay un traidor en la comunidad. Este ha sido el primer pensamiento de muchos.

Muchas discusiones que he tenido han circulado sobre la política de parches. Recientemente he publicado un artículo en la revista Esecurity [http://www.esecuritymagazinecom] en su versión escrita, en la sección de opinión, sobre esto mismo [El Mantenimiento de una Infraestructura Segura (I): Sistemas Actualizados].

(Prometo publicarlo aquí que estaba bastante quemado por otro artículo anterior de uno de esos que me motivan y me salio un poco subido de tono, para que podamos discutir bien)

Hoy Debian.org publicaba un mensaje en el que avisaba de que uno de sus servidores, Gluck, había sido comprometido por un ataque. Esto les obligaba a reinstalar el sistema y a parar todos los servicios de Debian para la comunidad hasta que se pudieran parchear los sistemas.

La gente de Zone-h especulaba sobre un exploit de 0-days para el kernel de Linux utilizado, pero este exploit solo puede ser utilizado desde una cuenta del servidor. Al final este parece ser el camino seguido para hackear el servidor.

La respuesta oficial es que una cuenta de uno de los desarrolladores ha sido comprometida (es decir, que le han mangao la password de alguna manera) y luego los atacantes han usado esas credenciales para hackear el sistema. ¿Desde cuando la tenían?

Primero, la política full disclousoure de publicar los bugs en cuanto se conocen va en contra de los procedimientos de las empresas y organismos para la actualización de sistemas, ahí está el caso de estos servidores; para ellos no es facil parar el servicio en cualquier momento y parchear, necesitan planificar. Esto ha llevado a que la misma Debian tuviera sin parchear sus servidores y ahora estén sin servicio un tiempo, vaya,vaya, vaya. ¿Y si reconsideramos un poco la política?

En segundo lugar, un bug, se conozca o no el exploit, es un fallo y hay que arreglarlo.

En tercer lugar, explotable en local, no tiene ningún problema si no tienes usuarios de tu servidor, pero si hay servicio SSH y/o Telnet, cualquier usuario que se conecte es un usuario local del servidor. Es local, siempre y cuando no consigan una cuenta. (mejor aceptar esto, que la tenebrista, especuladora y catastrofista teoría de la conspiración de que haya un traidor)

Bueno, ...Segundos fuera!!

15 comentarios:

Anónimo dijo...

Mejor no te digo donde he montado 8 Debian vulnerables hace poco...no sea que las vayas a hackear ^_^

Esta de moda...bug en "lo que sea" y los críos cepillandose servidores, webs, foros, etc a diestro y siniestro para salir en zone-h en buena posición.

No puedes darle un AK-47 a cada niño de 15 años con conexión y esperar que no dispare ninguno.

Nunca me ha gustado hacer así las cosas, y por supuesto así no las hago, opinando (es mi libre opinión) que así no se deberia hacer.

Aunque...¿que seria del "juaking" sin 0days publicados irresponsablemente? A alguien habrá que hackear despues de que se extienda Longhorn ¿no? ^_^

Chema Alonso dijo...

Vaya, vaya, vaya. Resulta que el exploit era público desde el día 10 de Julio y estos chicos no habían parcheado y el día 12 se encontraron el pastel. Curioso.

http://www.darknet.org.uk/2006/07/linux-kernel-26x-prctl-core-dump-handling-local-r00t-exploit-bid-18874-cve-2006-2451/

Con AKs rulando por ahí es lo que sucede.

ptarra dijo...

Ya que estamos rodeados de autenticos expertos me encantaría que me ayudaseis a conseguir que el exploit funcione en mi ordenador. Uso una SuSE 10.1 parcheada a día de ayer (sorry tengo puestos los parches automáticos) pero no he visto entre los parches ninguno del kernel, de modo que se supone que soy "virgen".

He cogido el exploit, lo he compilado sin problemas, lo he ejecutado, y efectivamente aparece un "sh" en el directorio /tmp aunque no llega a ejecutarse como root sino como mi propio usuario.

Tengo al AppArmor de SuSE activado (¿tendrá esto algo que ver?). Os agradecería que me echaseis una mano para auto-juakearme.

Un saludo

ptarra dijo...

¡Conseguido!. No se porqué el primer exploit no funcionaba pero de los varios que se han publicado en securityfocus uno de ellos va...

Ahora me gustaría saber porque falla el primero, con lo simple que es... y aparentemente lo hace todo bien... a estudiar un rato.

Un saludo

Chema Alonso dijo...

Bueno, la verdad es que como en linux, la compatibilidad va así, como así, quien sabe!. Lo cierto es que cuando sale un bug hay que parchear, que es lo importante, no?

Bies!!

Chema Alonso dijo...

Después del hackeo de Debian, ha aparecido otro exploit en la lista de full-disclousure para otra vulnerabilidad de los kernels 2.16.17.4. No es la misma vulnerabilidad que la que se utilizó con Debian y el código fuente del exploit está disponible para todos los usuarios. Es extremadamente importante que los kernels sean parcheados o podremos tener muchos indicentes de seguridad como el sucedido en Debian. Universidades y Centros educativos en los que es común que los estudiantes tengan cuentas en los servidores para la programación de las prácticas pueden ser un objetivo claro de este tipo de exploits. Puedes ver y descargar el exploit en la siguiente URL:

http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047907.html

Nacho Colunga dijo...

Anda chemita ¡no nos hables de 0-days y parches!

http://www.pcmag.com/article2/0,1895,1989144,00.asp

Un saludo ;)

Chema Alonso dijo...

Hola Nacho!!

por suerte en los servidores no corre el Power Point Server!!! Kernel contra app de usuario? mmm. no es por comparar que no es el caso de post, sino hablar de la política de actualizaciones que ha llevado a la propia Debian a tener problemas.

A parte de el de Power Point, tienes el de excel rulando y el divertido Month o Browser Bugs de HD Moore MOBB

... y los últimos de mambo y

OpenOffice XML File Format Buffer Overflow Vulnerability
2006-07-15
http://www.securityfocus.com/bid/18739

PHPBB 3 Memberlist.PHP SQL Injection Vulnerability
2006-07-15
http://www.securityfocus.com/bid/18969

OpenOffice Java Applet System Access Vulnerability
2006-07-15
http://www.securityfocus.com/bid/18737

PPPD Winbind Plugin Local Privilege Escalation Vulnerability
2006-07-15
http://www.securityfocus.com/bid/18849

MiniBB Multiple Remote File Include Vulnerabilities
2006-07-15
http://www.securityfocus.com/bid/18998

MyBB Client-IP SQL Injection Vulnerability
2006-07-15
http://www.securityfocus.com/bid/18997

Pero repito, ese no es el debate en este post nacho es otro.

Nacho Colunga dijo...

Ya, pero será interesante ver cuanto tarda MS en arreglar los agujeros. Y es que aunque tienes razón con lo de las políticas de actualización de parches si no tenemos parches... de poco nos servirá la política ¿no crees? ;P

Chema Alonso dijo...

Estoy contigo Nacho, por eso el full disclosure, que cómo ya sabrás, incluso da información del fallo con detalles sin que a veces haya parche, no es una buena política, ¿no crees?

Full Disclosure no sólo es que saco el parche en el momento que lo tengo, sino que también doy información del fallo, tenga o no la solución.

Sacate una cuenta de http://bugzilla.mozilla.org y ves como se gestan los parches en full disclosure.

Microsoft, antaño, daba información del fallo en cuanto la tenía (incluso antes de tener solución) y además sacaba los parches sin planificar.

Creo que el modelo de Microsoft es bueno, para situaciones de "riesgo alto" se rompe el ciclo. Me parece un buen comodín.

Pero....

Buuuenas Noches!

Chema Alonso dijo...

Como ves, el parche de esta vulnerabilidad del kernel lo hizo Mr. Linus Torvalds el día 14, es decir 8 días después de publicarse el fallo y 2 antes de la publicación del exploit.

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.17.5

Si te das cuenta en el expediente de seguridad está firmado por Red Hat, es decir, los propios que tienen que salvaguardar a sus clientes dan información de los fallos a todo el mundo sin tener aun solución. ¿Esa es una buena política de SEGURIDAD?

http://www.securityfocus.com/bid/18874

Anónimo dijo...

No es una buena política de seguridad dar facilidades. Seguridad nunca debe ser sinónimo de facilidad (en el aspecto intrusivo).
Como bien dice ANELKAOS parece que está de moda (espero que ya no tanto con esto del anteproyecto de ley), y yo no sé quién es más tonto, si el tonto (el que lo publica con todo lujo de detalles, al menos sin haber esperado a un hotfix, parche o actualización), o el que sigue al tonto (el scriptkiddie o vulgarmente llamado "pulsa aceptar y juankea" que la teoría es para los tontos)..
Microsoft también ha cometido muchos fallos en ese aspecto; también se equivocaba cuando primero sacaba actualizaciones críticas para equipos en-en, y con los demás idiomas, relajados.. Menos mal que a un DC se la suda el idioma que tengan sus compis. Todos los "grandes" han cometido fallos en cuestiones de políticas, sea de cualquier tipología. Pero en el mundo "libre que no gratis" podría darse algún tipo de confusión si privatizasen de algún modo ese tipo de información; y ya no sería un país multicolor! Pienso que hay un vacío bastante grande en ese aspecto.
Por poner un ejemplo, ya no vale tener una política de instalación de equipos basados en Microsoft de hace 3 años, porque si instalas cualquier equipo basado en esa política, llegará el tito blaster y su sobrino sasser, nos dejarán un bonito trojano (en el mejor de los casos) y wualá! un capullín más en nuestros sistemas que se dedicará a despotricar del S.O., que bueno soy, muack muack, soy un superjuanker, bla, bla, bla!
En definitiva, pienso que en todo trabajo, toda política debería cambiar cuando cambie el panorama, o el prisma con que lo miremos.
Saludos Maligno!

ptarra dijo...

Al hilo del tema del bug este en cuestión creo que el problema es mayor que el mero agujero de seguridad, que ya es grave. El principal problema es como han enfocado la aparición del bug y como lo han calificado las distintas distros, quitandole hierro cuando el problema puede ser potencialmente muy grave.

En http://lwn.net (Linux Weekly News) hablan de ello y reparten algo de estopa. Hay que aprender de los errores y en este caso, tratar de "camuflar" el bug calificandolo de DoS y no como lo que realmente es (escalada de privilegios) es grave.

En cualquier caso, los buenos ya hemos parcheado... pero a día de hoy todavía muchos no se lo han tomado en serio.

Parece que el bug afectaba a versiones del kernel entre la 2.6.13 y la 2.6.17 (no todas las del 2.6 como se dijo en un primer lugar), pero algunos como RedHat consiguieron migrar el problema a sus kernels anteriores... en fin...

Un saludo

Anónimo dijo...

La política de "Seguridad por Oscuridad" ya quedo demostrada hace anios que no sirve como modelo.

La pregunta que deberías hacerte es "Por que todos o la mayor parte de los personajes en el modelo de desarrollo Opensource han decidido optar por no ocultar sus problemas?".

Creo que ahí esta la clave del asunto ;-)

Chema Alonso dijo...

Anónimo, muchos usan responsible disclousure,...entre ellos hay algún ejemplillo como el bug que apareció 5 horas después de la release de FF3 y del que no se publicó ningún fallo aún. Se está esperando a que se parchee.

No confundas full disclousure, con responsible disclousure con un mala política de gestión de actualizaciones.

Saludos!

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares