Zatrute rozszerzenie VS Code wykradło 3800 wewnętrznych repozytoriów GitHuba

GitHub bada nieautoryzowany dostęp do swoich wewnętrznych repozytoriów i potwierdza, że atakującemu udało się wyprowadzić dane z około 3800 z nich. Włamanie weszło przez zatrute rozszerzenie Visual Studio Code zainstalowane przez pracownika, dając napastnikowi dostęp do tej maszyny, a stąd do kodu wewnętrznego, który powinien pozostawać za murami samej firmy.

Granica, na którą wskazuje GitHub, między repozytoriami wewnętrznymi a platformą obsługującą klientów, jest jedyną rzeczą oddzielającą zamknięty incydent od globalnego kryzysu łańcucha dostaw. GitHub hostuje około 100 milionów programistów i znaczącą część kodu open source, na którym opiera się współczesny internet. Kiedy firma mówi „wewnętrzny”, ma na myśli kod własnej platformy, swoje narzędzia, konfigurację operacyjną, materiał, z którego GitHub buduje i prowadzi sam siebie. Organizacje klientów, przedsiębiorstwa oraz publiczne i prywatne repozytoria, które ci klienci trzymają na GitHubie, znajdują się według samej firmy poza promieniem oddziaływania tego włamania.

To rozróżnienie wykonuje sporo pracy w oświadczeniu opublikowanym przez firmę na jej oficjalnym koncie X. „Chociaż obecnie nie mamy dowodów na wpływ na informacje klientów przechowywane poza wewnętrznymi repozytoriami GitHuba”, głosi tekst, „uważnie monitorujemy naszą infrastrukturę pod kątem dalszej aktywności”. Sformułowanie jest precyzyjne, a precyzja w komunikacie o naruszeniu zwykle oznacza, że śledztwo wciąż trwa. „Brak dowodów na wpływ” to nie to samo co „brak wpływu”. Incydenty na dużych platformach mają zwyczaj rosnąć w miarę, jak analiza forensyczna dogania aktywność napastnika, a linia między systemami wewnętrznymi a obsługującymi klientów rzadko bywa czystą fizyczną ścianą. To zestaw kontroli dostępu, poświadczeń i kont serwisowych, które trzeba przemyśleć jeden po drugim.

Może Ci się spodobaćEndflame ogłasza Silent Road: Psychologiczny horror osadzony w Japonii

Mechanizm jest tą częścią tej historii, która powinna niepokoić każdego programistę. Visual Studio Code to dominujący edytor kodu na planecie, używany w niemal każdej dużej organizacji inżynierskiej. Jego sklep z rozszerzeniami działa na zaufaniu społeczności: każdy może publikować, a większość inżynierów instaluje wtyczki z taką samą lekkością, z jaką dodaje zakładki do przeglądarki. Zatrute rozszerzenie dostarczone tym kanałem i uruchomione na maszynie programisty daje napastnikowi dostęp do wszystkiego, czego sesja tego programisty może dosięgnąć: repozytoriów, tokenów, rejestrów pakietów, usług wewnętrznych. Konkretna nazwa rozszerzenia użytego w tym przypadku nie została jeszcze ujawniona, ale wzorzec nie jest nowy. Nx Console, popularne rozszerzenie do narzędzi dla programistów, padło ofiarą podobnego naruszenia.

Grupa nazywająca się TeamPCP przyznała się do włamania i wystawia zbiór danych na sprzedaż na podziemnych forach z minimalną ceną pięćdziesięciu tysięcy dolarów. Sformułowanie grupy, „to nie jest okup”, samo w sobie jest sygnałem. Nie próbują bezpośrednio szantażować GitHuba. Traktują skradziony wewnętrzny kod źródłowy tak, jak inni przestępcy traktują dumpy kart kredytowych: jako towar z nabywcami. Ktokolwiek skończy z tym archiwum 3800 repozytoriów, przeczesze je w poszukiwaniu wbudowanych poświadczeń, sekretów zaszytych w kodzie, szczegółów przydatnych do ataku na samą infrastrukturę GitHuba i wszystkiego, co posłużyłoby do skompromitowania celów położonych dalej w łańcuchu. Tej samej grupie przypisuje się również robaka Mini Shai-Hulud, który uderzył w pakiet durabletask w PyPI, co podkreśla prawdziwe tło tej historii: ataki na łańcuch dostaw oprogramowania przeszły ze scenariusza teoretycznego w operacyjne rzemiosło.

Reakcja GitHuba w zakresie ograniczenia szkód była, według własnego opisu firmy, szybka. Skompromitowane urządzenie zostało odizolowane. Złośliwe rozszerzenie zostało usunięte. Firma deklaruje, że zrotowała kluczowe sekrety, dając pierwszeństwo poświadczeniom o największym wpływie, i powiadomi dotkniętych klientów przez swoje utarte kanały reagowania na incydenty, jeśli śledztwo się rozszerzy. Spółka zależna Microsoftu nie wskazała pracownika GitHuba, którego maszyna została skompromitowana, nie nazwała rozszerzenia ani nie sprecyzowała, jak długo napastnik miał dostęp przed wykryciem. Te szczegóły zwykle pojawiają się w dłuższym raporcie po incydencie, który przychodzi tygodnie po pierwotnym komunikacie.

Dla reszty branży praktyczny morał jest prostszy niż opakowanie wywiadu o zagrożeniach sugeruje. Każda organizacja inżynierska jest o jedną nieuważną instalację rozszerzenia od tego samego incydentu. Każdy, kto kiedykolwiek zainstalował rozszerzenie VS Code polecone w wątku forum, podjął to samo ryzyko, które spadło na pracownika GitHuba. Skuteczne zabezpieczenia są znane i nierówno stosowane: ograniczenie instalacji rozszerzeń do zweryfikowanej allow-listy, izolowanie stacji programistów od poświadczeń produkcyjnych, rotowanie sekretów w szybkiej kadencji. To naruszenie wepchnie je wyżej na listy priorytetów w firmach, które je odsuwały.

GitHub nie podał terminu pełnego publicznego post-mortemu. Dochodzenia tej wielkości na platformach tego rozmiaru zwykle wymagają kilku tygodni, aby pokazać pełny zasięg, a aktualizacje będą przychodzić oficjalnymi kanałami firmy w miarę ich powstawania. Następną rzeczą do obserwacji jest to, czy archiwum 3800 repozytoriów rzeczywiście pojawi się na sprzedaż, i na jakim poziomie ustabilizuje się dolna granica ceny, gdy podziemny rynek będzie miał kilka dni na przejrzenie indeksu.

Więcej podobnych

Warstwa tożsamości, której internet nigdy nie miał, jest teraz budowana pod syntetyczną presją

ICARUS: Console Edition zapowiedziane na PlayStation 5 i konsole Xbox Series

Dragonkin: The Banished i wzrost znaczenia społeczności w rozwoju gier RPG

Autonomiczny dron ze Starlink przekształca dyspozytornię ratunkową w algorytmiczną decyzję

Oppo Find X9 Ultra ma 10x zoom optyczny i zdejmowany obiektyw 300 mm

Sztuczna inteligencja napisała exploit zero-day — Google przechwycił go pierwszy