● news.bsdnet.hu

A GitHub megerősítette, hogy jogosulatlan hozzáférést vizsgál a saját belső repository-jaihoz. A cég közlése szerint a támadás kiindulópontja egy alkalmazotti gép volt, amely egy harmadik fél által publikált, mérgezett VS Code extension miatt kompromittálódott. A GitHub jelenlegi értékelése szerint az incidens GitHub-internal repository-k exfiltrációjára korlátozódott, az ügyfelek enterprise organizationjeire vagy customer repository-kra egyelőre nincs bizonyíték. Ez a mondat papíron nyugtató, a gyakorlatban viszont elég kellemetlen. A támadó kb. 3 800 repository megszerzését állította, a GitHub pedig azt írta, hogy ez a szám "directionally consistent" a vizsgálat jelenlegi állásával. Magyarul: nem arról van szó, hogy valaki a levegőbe beszélt. A belső repository-khoz való hozzáférés megtörtént, az adatmennyiség pedig nagyságrendileg stimmelhet. A támadási lánc különösen kínos, mert nem valami egzotikus nulladik napi varázslatról van szó. Egy fejlesztői eszköz, egy VS Code extension mérgezett verziója futott le egy alkalmazotti gépen. Az Nx Console v18.95.0 postmortemje szerint a rosszindulatú extension credential stealert tartalmazott, amely többek között GitHub tokeneket, npm credentialöket, AWS és Kubernetes titkokat, Vault tokeneket és aktív 1Password CLI sessionből elérhető adatokat is célzott. Aki fejlesztői gépen tartós tokeneket, CLI sessionöket és széles jogosultságokat hagy, az gyakorlatilag előkészíti a terepet egy ilyen támadásnak. És itt jön a kellemetlenebb rész: ha egyetlen kompromittált alkalmazotti endpointból több ezer belső repository elérhetővé válhat, akkor nagyon nehéz nem feltenni a kérdést, hogy milyen szinten működik a need-to-know, a least privilege, a blast radius korlátozása és a fejlesztői endpointok kontrollja. Lehet azt mondani, hogy "csak belső repository-k" érintettek, de ez inkább kármentés, nem biztonsági sikertörténet. A GitHub természetesen reagált: eltávolították a rosszindulatú extension-verziót, izolálták az érintett endpointot, incident response indult és kritikus secreteket rotáltak. Ez az elvárt minimum. A lényegi kérdés viszont nem az, hogy utólag hány tokent rotáltak, hanem az, hogy egy ilyen credential stealer miért tudott ekkora hatókörrel dolgozni. A fejlesztői workstation ma már nem "csak egy laptop". Production attack surface. Rajta vannak a GitHub credentialök, cloud hozzáférések, package registry tokenök, SSH kulcsok, lokális konfigurációk, CI/CD-hez kapcsolódó titkok és gyakran a fejlesztői szervezet belső tudása. Ha erre a gépre egy extensionen keresztül bejut valaki, akkor nem a jelszót kell kitalálnia, hanem a már hitelesített user contextet kell kihasználnia. Ezért különösen problémás, ha egy olyan cég, mint a GitHub, látszólag nem tudta elég szűkre húzni a belső repository-khoz való hozzáférés határait. A GitHub nem egy átlagos szoftvercég. Ők üzemeltetik azt a platformot, amelyen a világ szoftverellátási láncának jelentős része mozog. Pont nekik kellene a legjobban tudniuk, hogy a developer tooling, a VS Code extensionök, az automatikus frissítések és a long-lived tokenök együtt veszélyes keveréket alkotnak. Az eset tanulsága nem az, hogy senki ne használjon VS Code extensiont. A tanulság az, hogy a kényelmi fejlesztői modell, az automatikus extension update, a széles belső repo-hozzáférés és a tartós credentialök együtt vállalhatatlanul nagy blast radius-t adnak. Ez nem modern biztonsági architektúra, hanem bizalmi alapú kényelem, ami addig működik, amíg egyszer nem. A korrektség kedvéért: a GitHub jelenlegi állítása szerint nincs bizonyíték ügyfél repository-k érintettségére. Ez fontos különbség. De ettől még az eset rossz fényt vet a belső biztonsági alapelvek gyakorlati érvényesítésére. Egy kompromittált alkalmazotti gépnek nem szabadna tömeges belső repository-exfiltrációhoz vezetnie. Ha mégis vezethet, akkor a probléma nem csak a mérgezett extension, hanem a köré épített jogosultsági és endpoint-biztonsági modell is. A kérdés innentől egyszerű: a GitHub ezt egyszeri supply-chain incidensként kezeli, vagy végre kimondja, hogy a fejlesztői gép és a fejlesztői tooling is első osztályú védendő infrastruktúra? Mert ha a világ egyik legfontosabb kódhosting platformjánál egy rossz extension ilyen messzire jut, akkor máshol sem érdemes sok illúziót kergetni. (A cikk 100%-banMesterséges Intelligenciaáltal szolgáltatott adatokattartalmaz, így a tartalmát érdemes duplán ellenőrizni!)