La comunidad de Libretro, que desarrolla y se encarga de mantener el código del popular emulador de consola de juegos RetroArch y la distribución de Linux para crear consolas de juegos Lakka, advirtió sobre el hackeo de la infraestructura del proyecto y el vandalismo en los repositorios.

En él informen comentan que los atacantes pudieron obtener acceso al buildbot y a los repositorios en GitHub. Así mismo en GitHub, los atacantes obtuvieron acceso a todos los repositorios de la organización Libretro utilizando la cuenta de uno de los participantes confiables del proyecto.

La actividad de los ciberdelincuentes se limitó al vandalismo: intentaron borrar el contenido de los repositorios colocando una confirmación inicial vacía.

Con lo cual el ataque borró todos los repositorios presentados en tres de las nueve listas de repositorios de Libretro Github.

Fuimos el objetivo de un ataque de ciberdelito premeditado en nuestra infraestructura clave.

El hacker hizo el siguiente daño:

• Accedió a nuestro servidor buildbot y paralizó los servicios buildbot nocturnos / estables, y el servicio de lobby netplay. En este momento, Core Updater no funcionará. Los sitios web para estos también se han vuelto inaccesibles por el momento
• Obtuvo acceso a nuestra organización Libretro en Github haciéndose pasar por un miembro muy confiable del equipo y forzó un compromiso inicial en blanco con un porcentaje justo de nuestros repositorios, eliminándolos de manera efectiva. Se las arregló para dañar 3 de las 9 páginas de los repositorios. RetroArch y todo lo que lo precede en la página 3 se ha dejado intacto antes de que se redujera su acceso.

Todavía estamos esperando algún tipo de respuesta o apoyo de Github. Esperamos que puedan ayudarnos a restaurar algunos de estos repositorios de Github destrozados a su estado correcto, y también que nos ayuden a reducir la identidad del atacante.

Afortunadamente, los desarrolladores bloquearon el intento antes de que los atacantes llegaran al repositorio clave de RetroArch.

En cuanto al servidor de compilación, los atacantes dañaron los servicios que generan las compilaciones de prueba y estables, así como los encargados de organizar juegos en red (netplay lobby).

No se registraron los intentos de sustituir algunos archivos o realizar cambios en las compilaciones de RetroArch y los paquetes principales.

Actualmente, el trabajo del Core Installer, Core Updater y Netplay Lobbie, así como los sitios y servicios relacionados con estos componentes (Update Assets, Update Overlays, Update Shaders) está roto.

Todavía estamos evaluando la situación, pero en el futuro, creemos que probablemente sea mejor no seguir adelante con el servidor buildbot que se vio comprometido hoy. Teníamos algunos planes de migración a largo plazo para el cambio a un nuevo servidor, pero esto siempre se retrasó porque sentimos que no estábamos listos para la migración.

El principal problema que enfrentó el proyecto después del incidente fue la falta de un proceso de respaldo automatizado.

La última copia de seguridad del servidor buildbot se realizó hace unos meses. Los desarrolladores explicaron los problemas por la falta de dinero para el sistema de respaldo automático, debido al presupuesto limitado para el mantenimiento de la infraestructura.

Los desarrolladores no tienen la intención de restaurar el servidor anterior, sino de lanzar uno nuevo, cuya creación estaba planeada. En este caso, las compilaciones para sistemas como Linux, Windows y Android se ejecutarán de inmediato, pero llevará tiempo restaurar las compilaciones para sistemas especializados, como consolas de juegos y compilaciones de MSVC más antiguas.

Esto significaría que las compilaciones más comunes para Linux / Windows / Android estarían disponibles de inmediato, pero todos los sistemas especializados como consolas, compilaciones antiguas de MSVC y todo eso tendrían que esperar más tarde hasta que lo hayamos adaptado correctamente al nuevo sistema.

Se supone que GitHub, al que se envió la solicitud correspondiente, ayudará a restaurar el contenido de los repositorios limpios e identificar al atacante. Hasta el momento, solo sabemos que el hackeo se realizó desde la dirección IP 54.167.104.253, es decir, el atacante probablemente estaba usando un servidor virtual de AWS comprometido como punto intermedio.

Si quieres conocer mas al respecto, puedes consultar la nota en el siguiente enlace.