Los desarrolladores de la plataforma móvil LineageOS (la que reemplazó a CyanogenMod) advirtieron sobre la identificación de rastros dejados de un acceso no autorizado en su infraestructura. Se observa que a las 6 en punto de la mañana (MSK) del 3 de mayo, el atacante logró obtener acceso al servidor principal del sistema de administración de configuración centralizada SaltStack a través de la explotación de la vulnerabilidad de la que hasta el momento no hay parches.

Solo se informa que el ataque no afectó las claves para generar firmas digitales, el sistema de compilación y el código fuente de la plataforma. Las claves se ubicaron en un host completamente separados de la infraestructura principal administrada a través de SaltStack y los ensambles se detuvieron por razones técnicas el 30 de abril.

A juzgar por los datos en la página status.lineageos.org, los desarrolladores ya han restaurado el servidor con el sistema de revisión de código, el sitio web y la wiki de Gerrit. Los servidores con compilaciones (builds.lineageos.org), el portal para la descarga de archivos (download.lineageos.org), servidores de correo y un sistema para coordinar el reenvío a los espejos están deshabilitados de momento.

Sobre el fallo

El 29 de abril se liberó una actualización de la plataforma SaltStack 3000.2 y cuatro días después (el 2 de mayo) fueron eliminadas dos vulnerabilidades.

El problema radico en que, de las vulnerabilidades que se informaron, una se publicó el 30 de abril y fue a la que se le asigno el más alto nivel de peligro (aquí la importancia de publicar la información varios días o semanas después de su descubrimiento y liberación de los parches o soluciones del fallo).

Ya que el fallo permite que un usuario sin autenticación, pueda realizar la ejecución remota de código como el anfitrión de control (salt-master) y todos los servidores administrados a través de él.

El ataque fue posible por el hecho de que el puerto de red 4506 (para acceder a la SaltStack) no fue bloqueado por el firewall para solicitudes externas y en el cual el atacante tuvo que esperar a actuar antes de que los desarrolladores de Lineage SaltStack y ekspluatarovat intentaran instalaran alguna actualización para corregir el fallo.

Se aconseja a todos los usuarios de SaltStack que actualicen con urgencia sus sistemas y verifiquen si hay signos de hackeo.

Aparentemente, los ataques a través de SaltStack no se limitaron solo a afectar a LineageOS y se generalizaron durante el día, varios usuarios que no tuvieron tiempo de actualizar SaltStack notaron que sus infraestructuras estaban comprometidas por el código de alojamiento para minería o puertas traseras.

También informa un hack similar en la infraestructura del sistema de administración de contenido Ghost, que afectó los sitios y la facturación de Ghost (Pro) (se alega que los números de tarjeta de crédito no se vieron afectados, pero los hash de contraseña de los usuarios de Ghost podrían caer en manos de los atacantes).

• La primera vulnerabilidad (CVE-2020-11651) es causada por la falta de comprobaciones adecuadas al llamar a los métodos de la clase ClearFuncs en el proceso salt-master. La vulnerabilidad permite a un usuario remoto acceder a ciertos métodos sin autenticación. En particular, a través de métodos problemáticos, un atacante puede obtener un token para el acceso root al servidor maestro y ejecutar cualquier comando en los hosts servidos que ejecutan el demonio salt-minion. Hace 20 días se publicó un parche que corrige esta vulnerabilidad, pero después de que su aplicación apareciera, se produjeron cambios regresivos que provocaron bloqueos e interrupción de la sincronización de archivos.
• La segunda vulnerabilidad (CVE-2020-11652) permite, a través de manipulaciones con la clase ClearFuncs, el acceso a los métodos a través de la transferencia de rutas definidas de cierta manera, que se pueden utilizar para el acceso completo a directorios arbitrarios en el FS del servidor maestro con privilegios de root, pero requiere acceso autenticado (dicho acceso se puede obtener usando la primera vulnerabilidad y usar la segunda vulnerabilidad para comprometer completamente toda la infraestructura).