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!!
Mejor no te digo donde he montado 8 Debian vulnerables hace poco...no sea que las vayas a hackear ^_^
ResponderEliminarEsta 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? ^_^
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.
ResponderEliminarhttp://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.
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?
ResponderEliminarBies!!
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:
ResponderEliminarhttp://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047907.html
Hola Nacho!!
ResponderEliminarpor 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.
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?
ResponderEliminarFull 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!
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.
ResponderEliminarhttp://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
No es una buena política de seguridad dar facilidades. Seguridad nunca debe ser sinónimo de facilidad (en el aspecto intrusivo).
ResponderEliminarComo 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!
La política de "Seguridad por Oscuridad" ya quedo demostrada hace anios que no sirve como modelo.
ResponderEliminarLa 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 ;-)
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.
ResponderEliminarNo confundas full disclousure, con responsible disclousure con un mala política de gestión de actualizaciones.
Saludos!