Hackean servidor de Linux kernel.org

Justo en los 20 años de aniversario de Linux, ocurre esto, pero les dejo la noticia traducida (espero se entienda) del sitio kernel.org donde explican como y que fue lo que ocurrió:

Kernel.org ya tomó cartas en el asunto

Violación de la seguridad en kernel.org

A principios de este mes, un número de servidores en la infraestructura de kernel.org se vio comprometido. Descubrimos esto el 28 de agosto. Actualmente creemos que los repositorios de código fuente no se vieron afectados, estamos en proceso de verificar de esto y tomar medidas para mejorar la seguridad de toda la infraestructura de kernel.org.

¿Qué pasó?

• Intrusos tuvieron acceso root en el servidor de Hera. Creemos que puede haber obtenido este acceso a través de una credencial de usuario comprometida, ¿cómo se las arreglaron para explotar esto y acceder como root, se desconoce y se está investigando.
• Archivos que pertenecen a ssh (OpenSSH, openssh-server y openssh-clientes) se han modificado funcionando en live.
• Un archivo de inicio troyano fue introducido en el sistema inicio de scripts.
• Se han registrado interacciones de usuarios, así como un código de explotación. Hemos mantenido esto por ahora.
• El Troyano, descubierto inicialmente por el mensaje de error Xnest / dev / mem w / o Xnest instalado; se ha visto en otros sistemas. No está claro si los sistemas que presentan este mensaje son susceptibles al peligro o no. Si los desarrolladores ven esto, y  no tienes instalado Xnest, por favor, investiguen.
• Al “aparienciar” el 3.1-rc2 podría haber bloqueado el exploit de inyección, no sé si esto es intencional o un efecto secundario de otro de corrección de errores o cambios

Qué se ha hecho hasta ahora

• Ahora hemos puesto las cajas off line para hacer una copia de seguridad y está en proceso la reinstalación completa.
• Hemos notificado a las autoridades de los Estados Unidos y Europa para ayudar en la investigación
• Vamos a hacer una reinstalación completa en todas las cajas en kernel.org
• Estamos en el proceso de hacer un análisis sobre el código dentro de git, y confirmar que paquetes no se han modificado.

La comunidad de Linux y kernel.org toman la seguridad de los dominios kernel.org muy en serio, y están llevando a cabo todas las vias para investigar este ataque y prevenir  futuros ataques.

Sin embargo, también es útil señalar que el daño potencial de kernel.org grietas es mucho menor que los repositorios de software típico. Eso es porque el desarrollo del kernel se realiza mediante el sistema de control distribuido git revisión, diseñado por Linus Torvalds. Para cada uno de los cerca de 40.000 archivos en el kernel de Linux, una seguridad criptográfica hash SHA-1 se calcula únicamente para definir el contenido exacto de dicho archivo. Git está diseñado para que el nombre de cada versión del kernel dependa de la historia de desarrollo completo que conduce a esa versión. Una vez que se publica, no es posible cambiar las versiones antiguas sin que se note.

Los archivos y los valores hash correspondiente existen no sólo en la máquina de kernel.org y sus mirrors, en los discos duros de cada uno de los desarrolladores del kernel de varios miles, la distribución, y otros usuarios de kernel.org. Cualquier alteración de cualquier archivo en el repositorio de kernel.org se da cuenta cada desarrollador inmediatamente, ya que actualiza su repositorio personal, la mayoría lo hacemos a diario.

Actualmente estamos trabajando con los 448 usuarios de kernel.org para cambiar sus credenciales y cambiar sus claves SSH.

También estamos de auditoría todas las políticas de seguridad para hacer kernel.org más seguro, pero confiamos en que nuestros sistemas, en concreto git, tienen un diseño excelente para prevenir el daño real de este tipo de ataques.

Personalmente y como dicen en kernel.org, pienso que linux no es invencible como muchos piensan, pero es este tipo de cosas lo que fortalece más a la comunidad y al kernel. Además de que se ha desmostrado que la forma en como se administra el kernel funciona, ya que fue un muy poco tiempo el que se necesitó para dar respuesta ante el ataque, comparado con por ejemplo Sony u otras compañias que llegan a tardar meses en solucionar problemas derivados de ataques.

Seguiré informando de la situación y las novedades.

Fuente: www.kernel.org