Y es que los desarrolladores no están libres de pecado a la hora de elegir contraseñas y parece ser que el ataque vino por culpa de un programador muy perezoso a la hora de elegir su clave de acceso.
Tras darse cuenta de que el servidor estaba comprometido, los desarrolladores no tardaron en cerrar el acceso al servidor y comenzar la investigación del ataque para intentar revelar sus causas. Tras varios días de búsqueda, los programadores encontraron que el ataque venía de la mano de una contraseña demasiado débil de uno de ellos. Así cuando el cracker se hizo con el control de esa cuenta, aprovechó una vulnerabilidad recién descubierta en los dos últimos kernel estables: 2.6.13 y 2.6.16 y consiguió ganar algunos privilegios.
Afortunadamente los archivos a los que tenía acceso esa cuenta eran pequeñas
Tras recuperar gluck, los desarrolladores han decidido bloquear el acceso a 4 de ellos mismos porque tenían contraseñas demasiado débiles y fáciles de averiguar por los crackers.
Una vez más vemos que hasta el sistema más seguro no está a salvo si no se tiene una buena política de contraseñas y una revisión de seguridad cada cierto tiempo.
