Jak pojedynczy token GitHub ominął obwód obronny globalnego giganta farmaceutycznego

Novo Nordisk utrzymuje wielowarstwową infrastrukturę bezpieczeństwa. Firma stosuje zaawansowane wykrywanie punktów końcowych, segmentację sieci oraz dedykowane centrum operacji bezpieczeństwa (SOC). Te zabezpieczenia kosztują miliony dolarów rocznie. Mimo to, cała architektura zawaliła się z powodu pojedynczego ciągu tekstowego na publicznej stronie internetowej. Naruszenie u duńskiego giganta farmaceutycznego to studium przypadku architektonicznego paradoksu nowoczesnego tworzenia oprogramowania. Ogromna inwestycja w obronę obwodową zawiodła, ponieważ pojedynczy token uwierzytelniający znalazł się w niewłaściwym miejscu.

Spędziłem lata komunikując się z badaczami bezpieczeństwa przez Signal i kanały szyfrowane PGP. Większość z nich nie szuka złożonych podatności typu zero-day w utwardzonych firewallach. Szukają linii najmniejszego oporu. W incydencie Novo Nordisk tą ścieżką był wysoko uprzywilejowany osobisty token dostępu (PAT) GitHub pozostawiony w kodzie JavaScript po stronie klienta na mało znanej subdomenie. To nie był wyrafinowany atak. To było ćwiczenie z rekonesansu. Gdy tylko grupa zagrożeń znana jako FulcrumSec znalazła token w marcu, formalny obwód bezpieczeństwa przestał mieć znaczenie. Token zapewnił uwierzytelniony dostęp. Dla systemów wewnętrznych atakujący byli legalnymi programistami.

Anatomia cichej intruzji

FulcrumSec działało wewnątrz sieci Novo Nordisk przez ponad dwa miesiące przed wykryciem. W tym okresie grupa wykorzystała początkowy token GitHub do klonowania prywatnych repozytoriów. Repozytoria te zawierały coś więcej niż tylko kod. Znajdowały się w nich wtórne poświadczenia, definicje infrastruktury i dokumentacja wewnętrzna. Jest to powszechny schemat w nowoczesnych intruzjach. Atakujący wykorzystuje mały przyczółek do zebrania potężniejszych tajemnic. Nie muszą wykorzystywać błędów w oprogramowaniu, gdy mają klucze do drzwi wejściowych.

Do czasu, gdy Novo Nordisk ujawniło incydent 11 czerwca, atakujący zdążyli wytransferować 1,3 TB danych. Ten zbiór obejmował 700 000 plików. Choć firma początkowo opisywała wpływ jako ograniczony do pseudonimizowanych danych pacjentów i rekordów pracowników służby zdrowia, rzeczywistość wydaje się poważniejsza. Skradzione dane obejmują zastrzeżone informacje o lekach wprowadzonych na rynek i jeszcze niewydanych, badania kliniczne oraz wewnętrzne modele AI. FulcrumSec twierdzi, że te informacje mogą zaoszczędzić konkurencji od trzech do pięciu lat prac rozwojowych. To definicja awarii systemowej. Naruszenie ewoluowało od prostego wycieku tokena do utraty kluczowej własności intelektualnej.

Dlaczego potoki programistyczne są systemami produkcyjnymi

Platformy programistyczne to systemy o najwyższej wartości w nowoczesnym przedsiębiorstwie. Większość programów bezpieczeństwa nie dostrzega tej rzeczywistości. Repozytorium kodu nie jest już zwykłym schowkiem na pliki tekstowe. To plan całej cyfrowej infrastruktury. Zawiera konfiguracje środowisk chmurowych i potoki wdrożeniowe (pipelines), które przesyłają kod do klientów. Gdy atakujący uzyskuje dostęp do repozytorium, widzi całe „okablowanie” organizacji.

Matt Kimpel, dyrektor ds. bezpieczeństwa informacji w Magna5, zauważa, że programiści mają stały dostęp do systemów, które liczą się najbardziej. Posiadają poświadczenia do potoków budowania i środowisk chmurowych. Systemy te znajdują się „powyżej” środowiska produkcyjnego. Jeśli atakujący naruszy kod przed jego skompilowaniem, kontroluje produkt końcowy. To sprawia, że stacja robocza programisty i repozytorium są bardziej krytyczne niż sam serwer produkcyjny. Tradycyjne zabezpieczenia, takie jak zatwierdzanie gałęzi (branch approvals) i przeglądy kodu, zakładają, że osoba wykonująca czynność jest zaufanym pracownikiem. Jeśli tożsamość zostanie przejęta, te same mechanizmy kontrolne ułatwiają atak.

Niewidzialne ryzyko tożsamości maszynowych

Organizacje traktują zarządzanie tajemnicami (secrets management) jako problem narzędziowy. Kupują sejf (vault) i zakładają, że problem jest rozwiązany. Incydent Novo Nordisk dowodzi, że zarządzanie tajemnicami to problem tożsamości. Wyciekły token GitHub to tożsamość maszynowa. W przeciwieństwie do kont ludzkich, poświadczenia maszynowe często nie mają wyraźnych właścicieli. Nie posiadają spójnych harmonogramów rotacji. Często brakuje im sensownego monitoringu. Tokeny te trwają miesiącami lub latami bez zmian.

Shane Barney, CISO w Keeper Security, wskazuje, że ta niewidzialność zmienia pojedynczy token w długoterminową intruzję. Gdy poświadczenie maszynowe posiada szerokie uprawnienia i nikt nie monitoruje jego użycia, atakujący nie musi eskalować uprawnień. Dostęp już tam jest. Promień rażenia obejmuje całe środowisko. To dlatego atakujący pozostali niewykryci przez 60 dni. Nie włamywali się do systemu. Używali systemu tak, jak został zaprojektowany.

Pojawienie się wtórnych grup zagrożeń

Druga grupa zagrożeń, nazywająca się TheUSERS007, również twierdziła, że uzyskała dostęp do systemów Novo Nordisk między 5 a 7 czerwca. Grupa ta celowała w dane związane z badaniami nad AI. Sugeruje to, że gdy dojdzie do poważnego wycieku, inni aktorzy zaczynają badać tę samą infrastrukturę. Pojedyncza podatność w potoku programistycznym często wskazuje na szersze słabości systemowe. Jeśli jeden programista zostawia token w publicznym skrypcie, inni prawdopodobnie powielają podobne niebezpieczne wzorce. Powierzchnia ataku nie jest statyczną mapą. To dynamiczne środowisko, w którym jeden błąd zachęca do dalszej analizy ze strony wielu przeciwników.

Ta wtórna intruzja podkreśla ryzyko dla wewnętrznych modeli AI. Modele te reprezentują przyszłość badań farmaceutycznych. Są budowane na latach zastrzeżonych danych i ogromnych inwestycjach obliczeniowych. Utrata tych modeli to nie tylko wyciek danych. To utrata przewagi konkurencyjnej. Środowisko cyfrowe nie ma fizycznych ścian. Gdy logika systemu zostanie ujawniona poprzez kod źródłowy i wagi modeli, szkody są trwałe.

Przejście od narzędzi reaktywnych do proaktywnej kontroli tożsamości

Aby złagodzić te ryzyka, organizacje muszą zmienić sposób postrzegania dostępu programistów. Sejf to pudełko na tajemnice. Zarządzanie tożsamością to kontrola nad tym, kto może otworzyć pudełko i na jak długo. Celem jest skrócenie okresu przydatności każdej tajemnicy. Jeśli token wygasa po czterech godzinach, wyciek w pliku JavaScript jest tymczasową niedogodnością. Jeśli token jest ważny przez rok, wyciek jest katastrofą.

Centralizacja zarządzania tajemnicami to niezbędny krok. Każda tożsamość w środowisku powinna kierować się zasadą najmniejszych uprawnień. Oznacza to, że token GitHub powinien mieć dostęp tylko do konkretnych repozytoriów wymaganych do zadania. Nie powinien mieć szerokich uprawnień administracyjnych nad całą organizacją. Automatyczna rotacja gwarantuje, że poświadczenia nie przeżyją swojego celu. Ta dyscyplina nie powstrzyma atakującego przed znalezieniem tokena, ale ograniczy to, co może z nim zrobić.

Praktyczne kroki dla bezpieczeństwa potoków

Organizacje powinny zacząć od inwentaryzacji tożsamości niebędących ludźmi. Większość firm nie wie, ile kluczy API lub kont usługowych istnieje w ich środowisku. Nie można chronić tego, czego się nie widzi. Inwentaryzacja ta powinna obejmować zakres każdego klucza i datę jego ostatniego użycia. Wiele organizacji odkrywa, że duży procent ich aktywnych tokenów nie jest już potrzebny. Te osierocone tajemnice są celami o wysokiej wartości dla atakujących.

Monitorowanie tożsamości maszynowych jest tak samo istotne, jak monitorowanie logowań ludzkich. Zespoły ds. bezpieczeństwa muszą wyznaczyć linię bazową normalnego zachowania dla kont usługowych. Jeśli token GitHub zazwyczaj uzyskuje dostęp do trzech repozytoriów ze znanego adresu IP i nagle zaczyna klonować 500 repozytoriów z innego regionu, system powinien wywołać alert. Wykrywanie musi odbywać się na warstwie tożsamości. Łatanie oprogramowania jest ważne, ale w erze, w której tożsamości są głównym celem, widoczność użycia poświadczeń jest jedynym sposobem na schwytanie cichego intruza.

Kroki dla natychmiastowej redukcji ryzyka

1. Skanuj wszystkie zasoby publiczne pod kątem ujawnionych tajemnic. Używaj zautomatyzowanych narzędzi do znajdowania tokenów, kluczy API i poświadczeń bazy danych w kodzie po stronie klienta.
2. Wdróż tokeny krótkotrwałe. Zastąp długowieczne osobiste tokeny dostępu precyzyjnymi poświadczeniami o ograniczonym czasie trwania wszędzie tam, gdzie platforma to umożliwia.
3. Przeprowadź audyt uprawnień repozytoriów. Usuń dostęp administracyjny z tokenów programistów. Upewnij się, że żaden pojedynczy token nie ma uprawnień do sklonowania całej bazy kodu.
4. Włącz skanowanie tajemnic w potoku CI/CD. Blokuj każdy commit zawierający tajemnicę w tekście jawnym, zanim trafi ona do repozytorium.
5. Monitoruj anomalną aktywność w repozytoriach. Ustaw alerty dla masowego klonowania lub dostępu z nietypowych lokalizacji.

Ten incydent przypomina, że obwód bezpieczeństwa się przesunął. Nie znajduje się już na krawędzi sieci. Istnieje na poziomie pojedynczego tokena i konkretnej tożsamości. Jeśli nie zarządzasz tymi tożsamościami z taką samą rygorystycznością jak serwerami produkcyjnymi, Twoja obrona jest iluzją.

Źródła: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), raporty DataBreaches.net.

Zastrzeżenie: Ten artykuł ma charakter wyłącznie informacyjny i edukacyjny. Nie zastępuje profesjonalnego audytu cyberbezpieczeństwa ani usług reagowania na incydenty.