Zagrożenia łańcucha dostaw

Atak na łańcuch dostaw oprogramowania narusza bezpieczeństwo organizacji nie przez bezpośrednie włamanie, lecz przez skażenie czegoś, czemu organizacja ufa i czego używa: biblioteki, narzędzia do budowania, bazowego obrazu kontenera lub serwera aktualizacji.

Ponieważ współczesne oprogramowanie powstaje z setek komponentów innych firm, jedno zatrute ogniwo trafia do każdego kolejnego użytkownika. Atakujący inwestuje raz i dociera do wielu ofiar.

• Odwrócenie zaufania — granica bezpieczeństwa przesuwa się poza własny kod
• Promień rażenia zależności przechodnich — jeden złośliwy pakiet trafia do tysięcy kompilacji

Dodanie jednej bezpośredniej zależności często powoduje pobranie dziesiątek zależności przechodnich, których nigdy nie wybrano. Typowa aplikacja Node lub Python deklaruje kilka pakietów, ale ostatecznie korzysta z setek.

Należy wyświetlić pełne drzewo rozwiązanych zależności, a nie tylko manifest, aby zobaczyć, co rzeczywiście jest dostarczane:

Atakujący publikują złośliwe pakiety o nazwach przypominających popularne pakiety, licząc na fatalną literówkę.

• Typosquatting — reqeusts zamiast requests
• Combosquatting — python-requests naśladujące prawdziwą nazwę
• Dependency confusion — opublikowanie publicznego pakietu o tej samej nazwie co wewnętrzny pakiet prywatny, aby nieprawidłowo skonfigurowany mechanizm rozwiązywania zależności pobrał wersję atakującego

Ochronę zapewniają przypięcie zaufanego wewnętrznego rejestru oraz używanie prywatnych pakietów z zakresem lub przestrzenią nazw.

Legalny, powszechnie zaufany pakiet może stać się złośliwy, jeśli konto jego opiekuna zostanie przejęte albo złośliwy współtwórca uzyska uprawnienia do publikowania.

Niedawne incydenty w świecie rzeczywistym pokazują, że atakujący wyłudzają dane uwierzytelniające opiekunów, a następnie publikują skażone wydanie poprawkowe, które podczas instalacji wykrada tokeny.

• Należy wymagać 2FA na wszystkich kontach publikujących
• Należy preferować pakiety z tokenami publikowania ograniczonymi do zakresu i chronionymi wydaniami
• Należy monitorować nieoczekiwane pojawienie się nowych opiekunów w przypadku krytycznych zależności

Wiele ekosystemów uruchamia kod podczas instalacji, zanim aplikacja zostanie uruchomiona. Polecenie npm install może wykonać funkcję postinstall, która wykradnie zmienne środowiskowe lub klucze SSH.

W CI należy wyłączyć wykonywanie dowolnych skryptów instalacyjnych i przeprowadzić audyt każdego pakietu, który ich wymaga:

Samo środowisko budowania jest cennym celem. Jeśli atakujący zatruje kompilator, obraz agenta CI lub wtyczkę procesu budowania, każdy wytworzony przez nie artefakt będzie zawierał tylną furtkę, nawet gdy kod źródłowy jest bezpieczny.

Klasycznym przykładem jest zmodyfikowany mechanizm aktualizacji, który podpisuje złośliwe oprogramowanie prawidłowym kluczem podpisywania kodu, dzięki czemu ofiary uznają je za autentyczne.

• Infrastrukturę budowania należy traktować jak środowisko produkcyjne i w pełni ją zabezpieczyć
• Należy używać tymczasowych, odtwarzalnych agentów budowania
• Klucze podpisywania należy przechowywać oddzielnie od hosta budowania

Plik blokady przypina dokładne wersje i skróty zawartości, dzięki czemu ponowne rozwiązanie zależności nie może po cichu podmienić artefaktu na inny. Należy zawsze zatwierdzać go w repozytorium i pozwalać CI go weryfikować, zamiast swobodnie rozwiązywać zależności ponownie.

Pole integralności przechowuje skrót; jeśli pobrane archiwum nie pasuje do tego skrótu, instalacja kończy się niepowodzeniem.

Wersje ze znanymi podatnościami, śledzonymi jako CVE, są najczęstszą słabością łańcucha dostaw. Narzędzia do analizy składu oprogramowania (SCA) porównują rozwiązane zależności z bazami danych podatności.

Skanowanie należy uruchamiać w CI i kończyć proces budowania niepowodzeniem w przypadku krytycznych ustaleń:

Zakresy wersji bez przypięcia, takie jak ^1.2.0, pozwalają na automatyczne włączanie nowych wydań. Jest to wygodne, ale naraża na złośliwą wersję poprawkową.

• Należy przypinać zależności do dokładnych wersji i świadomie weryfikować aktualizacje
• W przypadku obrazów kontenerów należy przypinać za pomocą skrótu, a nie zmiennych znaczników, takich jak latest
• Krytyczne zależności należy utrzymywać we własnym repozytorium lub mirrorze, aby ich usunięcie z repozytorium źródłowego nie mogło przerwać działania ani zagrozić systemowi

Zabezpieczanie łańcucha dostaw to proces ciągły, a nie jednorazowe skanowanie. Należy wiedzieć co jest dostarczane, skąd to pochodzi i kiedy staje się podatne.

• Należy generować SBOM dla każdego wydania (w następnej lekcji)
• Należy rejestrować pochodzenie procesu budowania, aby można było wykazać, jak powstał artefakt
• Należy subskrybować komunikaty o zagrożeniach, aby nowo ujawniona CVE powodowała ponowną ocenę wydań już dostarczonych

Należy odwzorować każdy etap, na którym pojawiają się niezaufane dane wejściowe: komputery deweloperów, system kontroli wersji, rejestry zależności, system budowania, magazyn artefaktów i kanał aktualizacji. Każdy z nich może być punktem wstrzyknięcia.

Dla każdego etapu należy zadać pytania: kto może tu zapisywać dane, co umożliwiłoby tej osobie przejęcie oraz jak można byłoby to wykryć? W ten sposób powstaje uporządkowana według priorytetów lista zabezpieczeń, a nie ogólna lista kontrolna.

Wiesz już, dlaczego zależności są wektorami ataku i jak ograniczać związane z nimi ryzyko.

• Odwrócenie zaufania oznacza, że bezpieczeństwo zależy od stron trzecich, nad którymi nie ma się kontroli
• Najważniejsze zagrożenia to: typosquatting, dependency confusion, przejęcie konta opiekuna pakietu, złośliwe skrypty instalacyjne oraz przejęte narzędzia procesu budowania
• Najważniejsze zabezpieczenia to: pliki blokady ze skrótami integralności, skanowanie SCA, przypinanie dokładnych wersji za pomocą skrótu, 2FA dla publikujących oraz ciągłe monitorowanie

Następnie zostanie dokładnie zinwentaryzowana zawartość oprogramowania za pomocą SBOM.