Libretro-komunumo evoluiganta ludkonzolan emulilon kaj distribua kompleto por krei ludkonzolojn , pri hakado de projektaj infrastrukturelementoj kaj vandalismo en deponejoj. La atakantoj povis akiri aliron al la konstruservilo (buildbot) kaj deponejoj sur GitHub.
En GitHub, atakantoj akiris aliron al ĉiuj Libretro-organizo uzante la konton de unu el la fidindaj projektpartoprenantoj. La agado de la atakantoj estis limigita al vandalismo - ili provis malplenigi la enhavon de la deponejoj metante malplenan komencan devontigon. La atako forigis ĉiujn deponejojn listigitajn sur tri el la naŭ Libretro-deponejoj listigitaj paĝoj en Github. Feliĉe, la ago de vandalismo estis blokita de la programistoj antaŭ ol la atakantoj atingis la ŝlosilan deponejon. .
Sur la konstruservilo, la atakantoj difektis la servojn kiuj generas noktajn kaj stabilajn konstruojn, same kiel tiujn respondecajn pri organizado. (netplay vestiblo). Malica agado sur la servilo estis limigita al forigo de enhavo. Ne estis provoj anstataŭigi iujn ajn dosierojn aŭ fari ŝanĝojn al RetroArch-asembleoj kaj ĉefaj pakaĵoj. Nuntempe, la laboro de Core Installer, Core Updater kaj Netplay Lobbie, same kiel retejoj kaj servoj asociitaj kun ĉi tiuj komponantoj (Ĝisdatigi Aktivojn, Ĝisdatigi Overlays, Ĝisdatigi Shaders) estas interrompita.
La ĉefproblemo kiun la projekto alfrontis post la okazaĵo estis la manko de aŭtomatigita rezerva procezo. La lasta sekurkopio de la buildbot-servilo estis farita antaŭ pluraj monatoj. La problemoj estas klarigitaj de la programistoj per la manko de mono por aŭtomata rezerva sistemo, pro la limigita buĝeto por konservi la infrastrukturon. La programistoj ne intencas restarigi la malnovan servilon, sed lanĉi novan, kies kreado estis en la planoj. En ĉi tiu kazo, konstruoj por primaraj sistemoj kiel Linukso, Vindozo kaj Android tuj komenciĝos, sed konstruoj por specialigitaj sistemoj kiel ludkonzoloj kaj malnovaj MSVC-konstruaĵoj bezonos tempon por renormaliĝi.
Oni supozas, ke GitHub, al kiu responda peto estis sendita, helpos restarigi la enhavon de la purigitaj deponejoj kaj identigi la atakanton. Ĝis nun, ni nur scias, ke la hako estis farita de la IP-adreso 54.167.104.253, t.e. La atakanto verŝajne uzis hakitan virtualan servilon en AWS kiel interan punkton. Informoj pri la metodo de penetrado ne estas donitaj.
fonto: opennet.ru