Firma Google zaprezentowała framework SLSA (Supply-chain Levels for Software Artifacts), który podsumowuje dotychczasowe doświadczenia związane z ochroną infrastruktury rozwoju przed atakami, które występują na etapie pisania kodu, testowania, budowania i dystrybucji produktu.
Procesy rozwoju stają się coraz bardziej skomplikowane i zależne od zewnętrznych narzędzi, co stwarza korzystne warunki dla promowania ataków, które nie dotyczą wykrywania i eksploatacji luk w końcowym produkcie, ale kompromitacji samego procesu rozwoju (ataki „supply chain”, zazwyczaj ukierunkowane na wprowadzenie złośliwych zmian w procesie pisania kodu oraz podmiany rozsyłanych komponentów i zależności).
Framework uwzględnia 8 rodzajów ataków związanych z zagrożeniami wprowadzania złośliwych zmian na etapie rozwoju kodu, budowania, testowania i dystrybucji produktu.
- A. Włączenie do kodu źródłowego zmian zawierających backdoory lub ukryte błędy prowadzące do luk.
Przykład ataku: „Hypocrite Commits” — próba wprowadzenia do jądra Linux poprawek zawierających luki bezpieczeństwa.
Proponowana metoda ochrony: niezależne przeglądanie każdej zmiany przez dwóch programistów.
- B. Kompromitacja platformy zarządzania kodem źródłowym.
Przykład ataku: wprowadzenie złośliwych commitów z backdoorem do repozytorium Git projektu PHP po wycieku haseł programistów.
Proponowana metoda ochrony: zwiększenie zabezpieczeń platformy zarządzania kodem (w przypadku PHP atak został przeprowadzony przez mało używany interfejs HTTPS, który umożliwiał wysyłanie zmian po zalogowaniu się hasłem bez weryfikacji klucza SSH, przy tym do haszowania haseł stosowano niepewny MD5).
- C. Wprowadzanie zmian na etapie przesyłania kodu do systemu budowania lub ciągłej integracji (kompilowany jest kod, który nie odpowiada kodowi z repozytorium).
Przykład ataku: wprowadzenie backdoora do Webmina przez modyfikację infrastruktury budowlanej, co doprowadziło do użycia plików z kodem różniących się od plików w repozytorium.
Proponowana metoda ochrony: Weryfikacja integralności i identyfikacja źródła pochodzenia kodu na budowie. serwerze.
- D. Kompromitacja platformy budowy.
Przykład ataku: atak SolarWinds, podczas którego na etapie budowy zapewniono wprowadzenie backdoora do produktu SolarWinds Orion.
Proponowana metoda zabezpieczenia: wprowadzenie rozszerzonych środków ochrony platformy do tworzenia oprogramowania.
- E. Promowanie złośliwego oprogramowania za pomocą niskiej jakości zależności.
Przykład ataku: wprowadzenie backdoora do popularnej biblioteki event-stream poprzez dodanie nieszkodliwej zależności, a następnie uwzględnienie w jednym z aktualizacji tej zależności złośliwego kodu (złośliwa zmiana nie była odzwierciedlona w repozytorium git, a była obecna tylko w gotowym pakiecie MNP).
Proponowana metoda zabezpieczenia: rekurencyjne stosowanie wymagań SLSA do wszystkich zależności (w przypadku event-stream, weryfikacja ujawniłaby skompilowany kod, który nie odpowiadał treści głównego repozytorium Git).
- F. Pobieranie artefaktów, które nie zostały stworzone w systemie CI/CD.
Przykład ataku: dodanie złośliwego kodu do skryptu CodeCov, które umożliwiło hakerom pozyskiwanie informacji przechowywanych w środowiskach klientów systemów ciągłej integracji.
Proponowana metoda zabezpieczenia: kontrola źródła i integralności artefaktów (w przypadku CodeCov mogłoby zostać wykryte, że skrypt Bash Uploader dostarczany z witryny codecov.io nie odpowiadał kodowi z repozytorium projektu).
- G. Kompromitacja repozytoriów pakietów.
Przykład ataku: badacze udało się uruchomić lustra niektórych popularnych repozytoriów pakietów w celu rozpowszechnienia przez nie złośliwych pakietów.
Proponowana metoda zabezpieczenia: weryfikacja, że rozpowszechniane artefakty zostały skompilowane z zadeklarowanych kodów źródłowych.
- H. Wprowadzenie w błąd użytkownika, aby zainstalował niewłaściwy pakiet.
Przykład ataku: wykorzystanie wyłudzania nazwy (NPM, RubyGems, PyPI) do umieszczania w repozytoriach pakietów, które są podobne do popularnych aplikacji (na przykład coffe-script zamiast coffee-script).
Aby zablokować wskazane zagrożenia, SLSA proponuje zestaw zaleceń oraz narzędzi do automatyzacji tworzenia metadanych do audytu. SLSA uogólnia typowe metody ataków i wprowadza pojęcie poziomów ochrony. Każdy poziom stawia określone wymagania infrastrukturze, co pozwala na zapewnienie integralności artefaktów używanych w procesie tworzenia. Im wyższy poziom SLSA jest wspierany, tym więcej środków ochrony jest wdrożonych i lepiej infrastruktura jest chroniona przed typowymi atakami.
- SLSA 1 — wymaga, aby proces budowania był w pełni zautomatyzowany i generował metadane („provenance”) dotyczące tego, jak artefakty są zbierane, w tym informacje o źródłowych kodach, zależnościach i procesie budowy (dla GitHub Actions zaproponowano przykład generatora metadanych do audytu). SLSA 1 nie obejmuje elementów ochrony przed wprowadzeniem złośliwych zmian, a jedynie w prosty sposób identyfikuje kod i dostarcza metadanych do zarządzania lukami i analizy ryzyka.
- SLSA 2 — rozszerza pierwszy poziom o wymaganie stosowania systemu zarządzania wersjami oraz usług budowlanych generujących uwierzytelnione metadane. Zastosowanie SLSA 2 pozwala śledzić pochodzenie kodu i zapobiega wprowadzaniu nieautoryzowanych zmian w kodzie, gdy korzysta się z zaufanych usług budowlanych.
- SLSA 3 — potwierdza, że źródłowe kody i platforma budowlana spełniają wymagania standardów, które zapewniają możliwość przeprowadzania audytu kodu i zapewnienia integralności dostarczonych metadanych. Zakłada się, że audytorzy mogą certyfikować platformy pod kątem zgodności z wymaganiami standardów.
- SLSA 4 — najwyższy poziom, który uzupełnia poprzednie poziomy o następujące wymagania:
- Obowiązkowa recenzja wszystkich zmian przez dwóch różnych programistów.
- Wszystkie kroki budowania, kod i zależności muszą być w pełni zadeklarowane, wszystkie zależności muszą być wydobyte i zweryfikowane osobno, a proces budowy musi być realizowany bez dostępu do sieci.
- Zastosowanie procesu powtarzalnego budowania — możliwość powtórzenia procesu budowy samodzielnie i upewnienia się, że plik wykonywalny został zbudowany z dostarczonych źródłowych kodów.
Źródło: opennet.ru
