Ezrek GitHubját fertőzhették meg hackerek

Szinte felfoghatatlan mértékű és hatású támadássorozat zajlott le a közelmúltban. Ez atámadás megmutatja, mennyire sérülékeny a a modern szoftverfejlesztés gyakorlata. A „Megalodon” néven emlegetett kampányban támadók több mint 5 ezer GitHub-projektbe juttathattak be olyan módosításokat, amelyek első ránézésre ártalmatlan fejlesztői karbantartásnak tűntek, valójában viszont érzékeny adatok megszerzésére szolgáltak.

A beszámolók szerint a támadás néhány óra alatt több mint 5500 GitHub-tárolót érinthetett. A cél nem az volt, hogy a programok látványosan elromoljanak, vagy hogy a felhasználók azonnal észre vegyenek valamit. Épp ellenkezőleg: a támadók olyan ponton próbáltak beavatkozni, amelyet sok fejlesztői csapat rutinszerűnek kezel, és ezért ritkábban vizsgál át alaposan.

Nem a szoftverbe, hanem annak kiadási folyamatába nyúltak bele

Amikor valaki hackertámadásra gondol, gyakran feltört weboldalak, ellopott jelszavak vagy látványosan leálló rendszerek jutnak eszébe. A Megalodon ennél csendesebb  módszert használt. Nem a szoftver látható részét írta át, hanem azokat a háttérfolyamatokat célozta, amelyek a szoftverek elkészítéséért, teszteléséért és kiadásáért felelnek.

Ez azért veszélyes, mert ezek a rendszerek gyakran nagyon érzékeny adatokhoz férnek hozzá. Egy fejlesztői automatizmusnak szüksége lehet belépési kulcsokra, felhős jogosultságokra vagy kiadási engedélyekre. Ha egy támadó ide jut be, nem csak egyetlen gépet veszélyeztethet, hanem akár egy teljes fejlesztési láncot. Ezzel azt is meg kell értenünk, hogy nem működnek azok a régebbi gyakorlatok, hogy pl. egy külsős fejlesztő cég garantálja, hogy az általa írt kódot ellenőrizte, vagy akár én magam teszem ezt. Sőt, ennél kifinomultabb ellenőrzések elől is rejtve maradhat egy ilyen támadás.

Ártalmatlannak látszó módosításból lehetett adatlopás

A támadók trükkje az volt, hogy a módosítások első pillantásra hétköznapi rendszerfrissítésnek tűntek. Egy elfoglalt fejlesztő vagy karbantartó könnyen átsiklik egy ilyen változtatás felett, különösen akkor, ha az nem a program fő funkcióit érinti.

A háttérben azonban a kártevő olyan adatokat kereshetett, amelyek később további támadásokhoz használhatók. Ilyenek lehetnek a céges rendszerekhez tartozó belépési kulcsok, felhős hozzáférések, fejlesztői tokenek, rejtett beállításfájlok vagy olyan környezeti adatok, amelyeket normál esetben csak a szoftverkiadási folyamat használ.

A támadás egyik legnyugtalanítóbb része, hogy a rosszindulatú kód nem feltétlenül okozott volna azonnal feltűnő hibát. Egyes változatok akár csendben is maradhattak, és csak később aktiválódhattak volna. Ez megnehezíti az észlelést: attól, hogy egy projekt látszólag rendben működik, még nem biztos, hogy a háttérben minden tiszta.

Egy hivatalos kiadás is veszélybe kerülhet

A kampány egyik fontos példája a Tiledesk nevű, nyílt forráskódú ügyfélszolgálati és chatbotplatform volt. A források szerint több kiadott verzióba úgy kerülhetett be a problémás módosítás, hogy nem közvetlenül a csomag kiadói fiókját törték fel. Ehelyett a GitHubon tárolt forrásba kerülhetett be a rosszindulatú változtatás, majd a karbantartó ebből adott ki új verziót.

Ez különösen fontos, mert megmutatja, miért nehéz védekezni az ilyen támadások ellen. A felhasználó vagy egy másik fejlesztő azt látja, hogy a csomag hivatalos forrásból érkezik, megszokott néven, megszokott kiadótól. A baj viszont már korábban, a fejlesztési folyamat egyik kevésbé látványos pontján megtörténhetett.

Nem csak a GitHub problémája

A Megalodon egy nagyobb trend része: a támadók egyre gyakrabban a fejlesztők eszközeit és a szoftverkészítés folyamatát veszik célba. Ennek oka egyszerű. Ha valaki bejut egy népszerű projekt vagy fejlesztői rendszer belsejébe, sokkal nagyobb hatást érhet el, mintha egyesével támadná a végfelhasználókat.

A nyílt forráskódú világ különösen értékes célpont, mert rengeteg cég és fejlesztő épít ilyen projektekre. Egyetlen mérgezett módosítás tovább terjedhet más rendszerekbe, csomagokba vagy vállalati fejlesztési folyamatokba is. Ezért nevezik az ilyen incidenseket ellátásilánc-támadásnak: nem a végpontot, hanem az oda vezető lánc egyik elemét támadják.

Mit kell most ellenőrizni?

Az érintett cégeknek és fejlesztőknek elsősorban azt kell megnézniük, történt-e gyanús változás a projektjeikben 2026. május 18-a körül. Különösen azokat a fájlokat érdemes átnézni, amelyek a háttérben futó automatikus tesztelést, építést vagy kiadást vezérlik.

Ha egy projekt érintett lehet, a gyanús módosításokat vissza kell vonni, a hozzáférési kulcsokat és jelszavakat pedig le kell cserélni. Érdemes átnézni a naplókat is: volt-e szokatlan futtatás, váratlan adatküldés vagy ismeretlen felhős bejelentkezés.

A szakértők szerint önmagában nem elég egy ismert rosszindulatú szerver blokkolása. Ha az adatok már kikerültek, akkor a régi kulcsok és tokenek továbbra is veszélyt jelentenek, ezért azokat érvényteleníteni kell.

Ugyanakkor ez a feladat ennél mégis sokkal összetettebb, ugyanis minden modern szoftver tartalmaz harmadik felekről (pl. A GitHub-ról) származó kód részleteket, könyvtárakat vagy más állományokat, amik végül ennek az újabb szoftvernek is a “részévé” válnak. Azaz minden bizonnyal egy több rétegű és sok összetevős ökoszisztéma borult most meg, ezért indokolt a maximális óvatosság. A tartós javítás is várhatóan hosszú időt fog igénybe venni, hiszen az esetleges támadások felderítése, beépített hátsó ajtók megtalálása és egy tényleg biztonságos javítás nagyon idő-, és munkaigényes folyamat. Mindeközben sokszor közösségi fejlesztésű eszközökről, de mindenképpen korlátozott erőforrású kód-gazdákról van szó, akiktől hiba rra számítani, hogy azonnal hatalmas erőket mozgósítanak.

A tanulság: ezt a támadási vektor még komolyabban kell venni

A Megalodon legfontosabb üzenete, hogy a szoftverbiztonság ma már nem áll meg a programkód ellenőrzésénél, ahogy arra például konkrét elvárások mentén az EU-ban már létező Cyber Resilience Act is kitér. Sok más mellett fontos az is, hogyan készül a szoftver, ki fér hozzá a kiadási folyamathoz, milyen automatizmusok futnak a háttérben, és ezek milyen titkokat érhetnek el.

Tehát ez atámadás azért lehetett hatékony, mert hétköznapinak tűnő módosításokon keresztül próbált bejutni a fejlesztői rendszerekbe.  Az össze helyes következtetés levonása azonban még messze van, hiszen jelenleg inkább még csak a probléma megértése és a helyes stratégiák kidolgozása, vagy frissítése zajlik.