La communauté Libretro, qui développe et maintient le code de l'émulateur de console de jeu RetroArch populaire et de la distribution Linux pour créer des consoles de jeu Lakka, unmis en garde contre le piratage de l'infrastructure du projet et le vandalisme dans les dépôts.
Dans ce rapport, ils commentent que les attaquants ont pu accéder au buildbot et aux référentiels sur GitHub. Toujours sur GitHub, les attaquants ont eu accès à tous les référentiels de l'organisation Libretro en utilisant le compte de l'un des participants de confiance du projet.
L'activité des cybercriminels était limité au vandalisme: ils ont essayé de supprimer le contenu à partir des référentiels en plaçant un commit initial vide.
Avec lequel l'attaque a supprimé tous les référentiels figurant dans trois des neuf listes à partir des référentiels Libretro Github.
Nous avons été la cible d'une cybercriminalité préméditée contre notre infrastructure clé.
Le pirate a fait les dégâts suivants:
- Il a accédé à notre serveur buildbot et a arrêté les services buildbot nocturnes / stables et le service de lobby netplay. Pour le moment, Core Updater ne fonctionnera pas. Les sites Web pour ceux-ci sont également devenus inaccessibles pour le moment
- Il a eu accès à notre organisation Libretro sur Github en se faisant passer pour un membre très fiable de l'équipe et a forcé un commit vierge initial avec un bon pourcentage de nos référentiels, les supprimant ainsi. Il a réussi à endommager 3 des 9 pages des référentiels. RetroArch et tout ce qui le précède à la page 3 ont été laissés intacts avant que l'accès ne soit réduit.
Nous attendons toujours une sorte de réponse ou de soutien de Github. Nous espérons que vous pourrez nous aider à restaurer certains de ces référentiels Github brisés à leur état correct, et également nous aider à réduire l'identité de l'attaquant.
Heureusement, les développeurs ils ont bloqué la tentative avant que les attaquants n'atteignent le référentiel de clés de RetroArch.
Quant au serveur de build, les attaquants ont endommagé les services qui génèrent les compilations test et stables, ainsi que les responsables de l'organisation des jeux en réseau (netplay lobby).
Les tentatives de remplacement de certains fichiers n'ont pas été enregistrées ou apportez des modifications aux versions et aux packages principaux de RetroArch.
Actuellement, le travail du Core Installer, du Core Updater et de Netplay Lobbie, ainsi que des sites et services liés à ces composants (Update Assets, Update Overlays, Update Shaders) est interrompu.
Nous évaluons toujours la situation, mais à l'avenir, nous pensons qu'il est probablement préférable de ne pas aller de l'avant avec le serveur buildbot qui a été compromis aujourd'hui. Nous avions des plans de migration à long terme pour le passage à un nouveau serveur, mais cela a toujours été retardé car nous estimions que nous n'étions pas prêts pour la migration.
Le problème principal auquel le projet a été confronté après l'incident était l'absence d'un processus de sauvegarde automatisé.
La dernière sauvegarde du serveur buildbot a été effectuée il y a quelques mois. Les développeurs ont expliqué les problèmes dus au manque d'argent pour le système de sauvegarde automatique, en raison du budget limité pour la maintenance de l'infrastructure.
Les développeurs n'ont pas l'intention de restaurer l'ancien serveur, mais d'en lancer un nouveau, dont la création était prévue. Dans ce cas, les builds pour des systèmes tels que Linux, Windows et Android s'exécuteront immédiatement, mais il faudra du temps pour restaurer les builds pour les systèmes spécialisés, tels que les consoles de jeu et les anciennes builds MSVC.
Cela signifierait que les versions les plus courantes pour Linux / Windows / Android seraient disponibles immédiatement, mais tous les systèmes spécialisés comme les consoles, les anciennes versions de MSVC et tout cela devraient attendre plus tard jusqu'à ce que nous l'ayons adapté avec succès au nouveau système.
GitHub est censé, auquel la demande correspondante a été envoyée, aidera à restaurer le contenu des référentiels propres et à identifier l'attaquant. Jusqu'à présent, nous savons seulement que le piratage a été effectué à partir de l'adresse IP 54.167.104.253, ce qui signifie que l'attaquant utilisait probablement un serveur virtuel AWS compromis comme point intermédiaire.
Si vous souhaitez en savoir plus, vous pouvez consulter la note dans le lien suivant.