nuevo sobre piratear la infraestructura de la plataforma de mensajería descentralizada Matrix, sobre la cual por la mañana. El vínculo problemático a través del cual penetraron los atacantes fue el sistema de integración continua Jenkins, que fue pirateado el 13 de marzo. Luego, en el servidor con Jenkins, se interceptó el inicio de sesión de uno de los administradores, redirigido por el agente SSH, y el 4 de abril los atacantes obtuvieron acceso a otros servidores de infraestructura.
Durante el segundo ataque, el sitio web Matrix.org fue redirigido a otro servidor (matrixnotorg.github.io) cambiando la configuración de DNS, utilizando la clave de la API del sistema de entrega de contenido de Cloudflare interceptada durante el primer ataque. Al reconstruir el contenido de los servidores después del primer hack, los administradores de Matrix solo actualizaron nuevas claves personales y omitieron actualizar la clave a Cloudflare.
Durante el segundo ataque, los servidores Matrix permanecieron intactos, los cambios se limitaron únicamente a la sustitución de direcciones en el DNS. Si el usuario ya cambió la contraseña después del primer ataque, no es necesario cambiarla una segunda vez. Pero si aún no se ha cambiado la contraseña, conviene actualizarla lo antes posible, ya que se ha confirmado la filtración de la base de datos con hashes de contraseñas. Actualmente planeamos forzar un proceso de restablecimiento de contraseña en el próximo inicio de sesión.
Además de la filtración de contraseñas, también se confirmó que las claves GPG utilizadas para generar firmas digitales para paquetes en el repositorio de Debian Synapse y las versiones de Riot/Web cayeron en manos de los atacantes. Las claves estaban protegidas con contraseña. De momento, las claves ya han sido revocadas. Las claves fueron interceptadas el 4 de abril, desde entonces no se han publicado actualizaciones de Synapse, pero sí se lanzó el cliente Riot/Web 1.0.7 (una verificación preliminar mostró que no estaba comprometido).
El atacante publicó una serie de informes en GitHub con detalles del ataque y consejos para aumentar la protección, pero fueron eliminados. Sin embargo, los informes archivados .
Por ejemplo, el cracker informó que los desarrolladores de Matrix deberían haber autenticación de dos factores, o al menos no utilizar la redirección del agente SSH (“ForwardAgent sí”), se bloquearía la penetración en la infraestructura. La escalada del ataque también podría detenerse otorgando a los desarrolladores sólo los privilegios necesarios, en lugar de en todos los servidores.
Además, se ha criticado la práctica de almacenar claves para crear firmas digitales en servidores de producción, para lo cual es necesario asignar un host aislado por separado. Todavía atacando que si los desarrolladores de Matrix auditaran regularmente los registros y analizaran anomalías, habrían notado rastros de un hack en una etapa temprana (el hack de CI pasó desapercibido durante todo un mes). Otro problema almacenar todos los archivos de configuración en Git, lo que hizo posible evaluar la configuración de otros hosts cuando uno de ellos fue pirateado. Acceso SSH a servidores de infraestructura limitado a una red interna segura, que le permitía conectarse a ellos desde cualquier dirección externa.
fuenteopennet.ru
nuevo sobre piratear la infraestructura de la plataforma de mensajería descentralizada Matrix, sobre la cual por la mañana. El vínculo problemático a través del cual penetraron los atacantes fue el sistema de integración continua Jenkins, que fue pirateado el 13 de marzo. Luego, en el servidor con Jenkins, se interceptó el inicio de sesión de uno de los administradores, redirigido por el agente SSH, y el 4 de abril los atacantes obtuvieron acceso a otros servidores de infraestructura.
Durante el segundo ataque, el sitio web Matrix.org fue redirigido a otro servidor (matrixnotorg.github.io) cambiando la configuración de DNS, utilizando la clave de la API del sistema de entrega de contenido de Cloudflare interceptada durante el primer ataque. Al reconstruir el contenido de los servidores después del primer hack, los administradores de Matrix solo actualizaron nuevas claves personales y omitieron actualizar la clave a Cloudflare.
Durante el segundo ataque, los servidores Matrix permanecieron intactos, los cambios se limitaron únicamente a la sustitución de direcciones en el DNS. Si el usuario ya cambió la contraseña después del primer ataque, no es necesario cambiarla una segunda vez. Pero si aún no se ha cambiado la contraseña, conviene actualizarla lo antes posible, ya que se ha confirmado la filtración de la base de datos con hashes de contraseñas. Actualmente planeamos forzar un proceso de restablecimiento de contraseña en el próximo inicio de sesión.
Además de la filtración de contraseñas, también se confirmó que las claves GPG utilizadas para generar firmas digitales para paquetes en el repositorio de Debian Synapse y las versiones de Riot/Web cayeron en manos de los atacantes. Las claves estaban protegidas con contraseña. De momento, las claves ya han sido revocadas. Las claves fueron interceptadas el 4 de abril, desde entonces no se han publicado actualizaciones de Synapse, pero sí se lanzó el cliente Riot/Web 1.0.7 (una verificación preliminar mostró que no estaba comprometido).
El atacante publicó una serie de informes en GitHub con detalles del ataque y consejos para aumentar la protección, pero fueron eliminados. Sin embargo, los informes archivados .
Por ejemplo, el cracker informó que los desarrolladores de Matrix deberían haber autenticación de dos factores, o al menos no utilizar la redirección del agente SSH (“ForwardAgent sí”), se bloquearía la penetración en la infraestructura. La escalada del ataque también podría detenerse otorgando a los desarrolladores sólo los privilegios necesarios, en lugar de en todos los servidores.
Además, se ha criticado la práctica de almacenar claves para crear firmas digitales en servidores de producción, para lo cual es necesario asignar un host aislado por separado. Todavía atacando que si los desarrolladores de Matrix auditaran regularmente los registros y analizaran anomalías, habrían notado rastros de un hack en una etapa temprana (el hack de CI pasó desapercibido durante todo un mes). Otro problema almacenar todos los archivos de configuración en Git, lo que hizo posible evaluar la configuración de otros hosts cuando uno de ellos fue pirateado. Acceso SSH a servidores de infraestructura limitado a una red interna segura, que le permitía conectarse a ellos desde cualquier dirección externa.
Fuente: opennet.ru
[:]