Ya hablé de esto hace mucho tiempo, solo que como ha vuelto a salir el nombre de Debian por aquí, pues he decidido sacar este artículo que publiqué en una revista en el verano pasado. Asi que nada, lo dejo aquí por si acaso os apetece leerlo. Nada más.
Seguridad. ¿Qué pasó con Gluck?
Estar a salvo de un ataque hacker es imposible, las alternativas son dos: Te van a atacar sí o sí. No te vas a salvar ni por ser Microsoft (já, eso sí que sería divertido) ni por ser una distribución del “lado del bien” o por ser cualquier otro. Así durante estos últimos meses hemos vivido el hackeo de http://experts.microsoft.fr, un servidor gestionado con DotNetNuke en el dominio de Microsoft Francia que levanto todas las alarmas porque pudiera ser debido a un exploit de día 0 en Internet Information Services 6.0 (que resultó ser un exploit de DotNetNuke), el hackeo de los servidores web de Kevin Mitnick con mensajes “poco elegantes” hacia él y los consultores de seguridad, pero quizás el hackeo más impactante ha sido el que se produjo en gluck.debian.org, un servidor de desarrollo de la propia Debian, reconocida por todo el mundo como una de las mejores distribuciones de Linux.
El pasado 12 de Julio nos encontramos con un mensaje en la lista de correo de desarrollo de Debian con el siguiente texto que nos dejaba a todos expectantes:
Hi,
Early this morning we discovered that someone had managed to compromise gluck.debian.org. We've taken the machine offline and are preparing to reinstall it. This means the following debian.org services are currently offline:
cvs, ddtp, lintian, people, popcon, planet, ports, release
Based on the results of our initial investigation we've locked down most other debian.org machines, limiting access to DSA only, until they can be fixed for what we suspect is the exploit used to compromise gluck.
We're still investigating exactly what happened and the extent of the damage. We'll post more info as soon as we reasonably can.
Vaya, ¿qué habrá pasado? Que ataquen Debian tiene muchas implicaciones tecnológicas, sociales (si atendemos al origen hacktivista – motivados por ideales políticos - de muchos ataques) y sobre todo marketinianas. En primer lugar, la rápida conclusión que se extrae es que no se salva nadie por la tecnología que use de intentar ser atacado y eventualmente ser vulnerado. En segundo lugar, la pregunta para los trabajadores de la seguridad informática es, ¿Dónde estuvo el fallo? En algún lugar se ha tenido que producir una brecha de seguridad. Como Gluck es una máquina que se utiliza para desarrollar en Debian, tiene muchas cuentas de usuario que se conectan desde todas las partes del mundo, ¿habrá algún traidor? Este mensaje parecía el comienzo de un libro de Agatha Christie.
Especulaciones
La gente de Zone-h, una de los sitios web de referencia mundial en la comunidad de defacers y hacktivistas, especulaba sobre un exploit de 0-days para el kernel de Linux, pero para utilizar ese exploit es necesario poseer una cuenta de usuario del servidor que se ataca.
Ante este panorama hay dos cosas a tener en cuenta, primero: si es un exploit de 0-días, ¿quién fue el primero que lo hizo público? ya que el que hace pública una vulnerabilidad de esas características, es decir, sin estar arreglado, deja a todos los clientes sin protección alguna, y en segundo lugar: si por el contrario, no es un exploit de 0-días, es decir, que ya hay solución por parte del fabricante, en este caso de kernel.org, lo que habrá fallado habrá sido la política de actualizaciones de la organización/empresa, que en este caso sería Debian.org.
¿Qué pasó realmente?
Tras mirar el exploit que se utilizó, podemos comprobar que es correcta la información que ofrecían en Zone-h y no solo eso, sino que estaba publicado el expediente de seguridad desde el 6 de Julio de 2006, es decir, 6 días antes de que se produjera el ataque ya se había hecho público para todo el mundo. Además, en el expediente de seguridad vemos que el fallo fue descubierto por el equipo de seguridad de Red Hat, los cuales hemos de suponer tienen un especial interés en proteger a sus clientes.
Vaya, 6 días antes y descubierto por RedHat. ¿Habrá dejado RedHat a los usuarios de los kernels afectados al descubierto publicando un expediente de seguridad sin que existiera aún una solución por parte de kernel.org? Bueno, mirando el expediente de seguridad vemos que la solución se ofrecía en linux-2.6.17.4 o en la 2.6.16.24, que fueron publicados los días 6 de Julio de 2006.
Respectivamente:
06/06/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.17.4
06/06/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.24
Entonces, ¿qué paso realmente?
Parece ser que en todo caso la brecha se produjo en la administración del servidor en Debian.org. ¿Qué rama de kernel usaba dicho servidor? Si el proceso de actualización de software de seguridad conlleva una fase costosa de pruebas e implantación 6 días es un tiempo razonable, pero durante ese periodo se deberían haber implantado algunas contramedidas mitigadoras en sistemas Firewall y/o en los Sistemas de Detección de Intrusos (IDS).
Para sacarnos de dudas se mandó una actualización de información en forma de mensaje en la lista de correo de Debian, el día 13 de Julio con la siguiente información:
“Short version: A developer's debian.org account was compromised some time ago. This account was then used to exploit the recent prctl vulnerability (CVE-2006-2451) on gluck and gain root privileges.”
[…]
“gluck was running Linux 2.6.16.18. Unfortunately it had not yet been updated to 2.6.16.24 or 2.6.17.4 both of which were released on 2006-07-06.”
Bien, cómo se puede observar en estos dos párrafos extraidos del mensaje completo, el problema fue, claramente, de la administración del servidor, ya que el sistema no estaba actualizado, pero… ¿desde cuándo estaban así?
Si nos paramos a mirar con detenimiento todas las actualizaciones que le faltaban desde la versión 2.6.16.18 hasta la 2.6.16.24 mirando los ficheros de cambio que nos ofrece kernel.org podremos extraer alguna conclusión:
30/05/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.19
05/05/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.20
20/05/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.21
22/05/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.22
30/05/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.23
06/06/2006: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.24
Reflexiones
O sea, nos encontramos con un sistema que lleva un mes y medio sin que se le aplique ninguna actualización de seguridad. Además, se puede ver que las actualizaciones que se nos ofrecen del kernel, mirando las fechas de publicación de cada una de ellas, así como del resto de los paquetes que tiene un servidor GNU/Linux, no tienen una periodicidad clara y definida, ya que la política de actualización en muchos paquetes/proyectos que se utilizan en un sistema GNU/Linux es “en cuanto esté” para dejar el menor tiempo sin información ni protección a los clientes. Esto conlleva que sea, casi imposible, conseguir que un día no haya un parche/actualización de seguridad que aplicar en alguno de los múltiples paquetes que corren un servidor lo que nos lleva a una administración de actualizaciones de seguridad “al día”. Si tenemos un servidor un mes y medio sin actualizar software (solo se reconoce que estaba sin actualizar el kernel) ¿cuántos otros paquetes habrá con alguna vulnerabilidad dentro de ese mismo servidor?
Además, en este caso concreto, para lanzar el exploit se necesitaba una cuenta de usuario del sistema y según se desgrana de la conversación posterior, no existía una política férrea de gestión de contraseñas lo que permitió que no fuera complicado para el atacante conseguir una. No había un traidor como se especulaba. En Gluck había cuentas de usuario que utilizaban contraseñas triviales como el nombre de usuario como contraseña o dejando passwords de diccionario. Tras la intrusión en el sistema se decidió aplicar e incluso se especulaba sobre utilizar sistemas de certificación para conseguir un sistema más robusto.
Para terminar toda esta disertación me gustaría hacerlo con un mensaje que le envían al administrador del servidor y su equipo, después de tener a Gluck un mes y medio sin actualizar, después de no tener una política fortificada de contraseñas y después de ser hackeado: “You do an Excellent Job”[7]
Hombre, vale que nadie está libre de ser hackeado en este Internet de hoy en día, pero tanto como estar haciendo un “excellent job”…. (Tal vez en otras partes de su trabajo sí, pero en seguridad no se ha hecho un excellent job.
Estoy sufriendo un tremendo deja-vu... http://elladodelmal.blogspot.com/2006/08/retorno-al-paraso.html
ResponderEliminarEjem...tu amigo vuelve a la carga...
ResponderEliminarhttp://www.diarioip.com/archivo/200
7/01/internet_explor.html
Cierto Txipi, solo que este era un artículo, a ver si lo puedo acabar de formatear bien, que ahora estoy en plena sesión con el abuelo en sevilla. Cómo salio el tema....
ResponderEliminarAnónimo, ya le leimos ese. Ya hablaremos...
No seguí el caso de cerca aunque por supuesto me enteré y me llamó la atención, puesto que fui el que publicó el exploit de kernel que mencionas y que se utilizó para rootear la máquina:
ResponderEliminarhttp://www.rs-labs.com/exploitsntools/rs_prctl_kernel.c
El proceso de desarrollo de kernel de Linux es complejo, recibes muuuchos correos de LKML, se aplican un montón de parches, etc. Y sobre todo, hay cierta oscuridad cuando se parchean problemas de seguridad... vamos, que no lo anuncian a bombo y platillo, ni sacan advisory ni nada. Muchas veces repasas el changelog de un kernel reciente cualquiera y descubres que hay security-fixes... Pero te tienes que molestar tu en mirar!!!
Si a eso le unes el coste de actualizar un kernel (por ejemplo, un reboot, con el consiguiente peligro de que la máquina no arranque bien, fastidias a quien hubiera dejado procesos trabajando, etc), el ritmo que llevan los kernel 2.6 (que sacan nuevas versiones cada 2x3)... el resultado es obvio: no puedes irte actualizando a todas las versiones que van saliendo. Si a esto le unes, aunque creo que en gluck no es el caso, que utilizas un parche como grsec, tienes que esperar a que spender&co saque la modificación del patch correspondiente...
En fin, que no trato de justificar a nadie, pero tampoco se le puede echar la gran bulla a los administradores de esa máquina (si acaso una mediana ;-)).
Por mi parte, yo todavía utilizo 2.4.x. Es más estable, el ritmo de actualizaciones es más que asequible (básicamente sólo actualizan cuando salen fallos gordos, muchos de ellos son de seguridad) y es el recomendado por la gente de grsec (entiendo que, en gran medida, por las razones anteriores.
Respecto a lo que comentas de IDS... un exploit de kernel es muy dificil de mitigar (aunque a posteriori salieron diversos workarounds para el exploit en particular, algunos de los cuales eran faciles de saltar modificando el exploit mínimamente, eran de aplicación para este bug/exploit en concreto; tienes que tener muchos recursos como para permitirte instalar workarounds de todos los hipotéticos fallos de kernels que van saliendo...).
-r
Roman, tienes mis respetos again!
ResponderEliminarVaya currazo!. Estoy contigo en que no es fácil, pero... ese es el reto, no?
Me encantan tus reflexiones tio! Gracias por ponerlas aquí!! Máquina!!!
cabe destacar en la lista de debian se publico y como lo mencionan aqui mismo, le kernel sarge 2.6.8 no tnia el exploit y el 2.4 es recomendado, lo que tambien quiere decir algo que contradice lo expuesto mayormente en el articulo "ctualizar a lo actual" es confiar en algo no comprobado, y si es un kernel implica un reboot.
ResponderEliminarEntonces lo actual tampoco es lo mejor, siempre es mejor lo "seguro" y "estable" y eso siempre no es lo actual sino lo relativamente no muy actual.
Hola anónimo,
ResponderEliminaresa aseveración vale con las actulizaciones de funcionalidades. No metas una nueva funcionalidad si no es estable, pero no con las actualizaciones de seguridad, pues el no meterlas garantiza que el sistema esté peor, pues cuando sale una actualización es pq se sabe a ciencia cierta que algo está mal en lo que hay.
Saludos
A ver a ver a ver. ¿Tanto rollo para explicar algo tan sencillo como que Debian tiene algunas Brechas? ¿Pero tu a quien quieres vender el mapa de la caza del Oso, a unos ignorantes o que?
ResponderEliminarNo hace falta tanto rollo para explicar que no existe un SO completamente blindado, y menos si debe estar rooteado o firewaleado en Internet.
Decenas de lineas para nada. macho diles que FreeBSD tambien tiene brechas, o diles que detras de los ataques a puntos criticos de Linux esta la mano negra de la desacreditacion del supermonnopolio de Microsoft, pero no te enrrolles con filosofias Infomaticas tipo Satory o Shamadi, macho que pecas de lo mismo, hablas mucho y solo haces que asustar al lector usuario.
A veces parece que trabajes para Microsof o que te pageun el hostin de este webblog.
No todos somos unos ingenuos, y nos chupamos el dedo. Debian tiene sus Bug como los tiene Umbutu, Rethat, Fedora, Slackware, Centos, FreeBSD, KnoppysSTD, PackedMaster, Debian Neinst, y toda la larga lista de Linux existentes precisamente por que no existe el Kernerl perfecto, como tampoco existe el programado perfecto tio, eso es lo que les deberias de decir a tu lectores, y no todas esas chorradas.
¿Y tu donde demonios curras que te voy a hacer una visita y vamos a tener una larga charla -sin cafe- sobre que es informatica y seguridad en la vida real y no en blog, porque no tienes ni idea de las cosas que hablas.
Haces coppy Paste, copiar y pegar lo que otros escriben.
Y no te hackee el blog por que no quise, que lo sepas.
@anónimo,
ResponderEliminarpuff, toy acojonao. Vente a vernos en el Security Day y hablamos de seguridad y esas cosas sin café. Y por favor, hackea Blogspot, que me haría mucha ilu, venga, un XSS, un CSRF o algo así que pueda mangarme la pass. Ya si encuentras un RFI me encantaría postear sobre ello.
Más acojonao!
Anda, relajate. El sexo es bueno para los ataques de adrenalina!
Saludos malignos!