Mimo rosnącej w imponującym tempie skuteczności oprogramowania w wykrywaniu zagrożeń zarówno na poziomie infrastruktury, jak i punktów końcowych, a także coraz większego poziomu bezpieczeństwa oferowanego przez same systemy operacyjne, wciąż borykamy się z klasą zagrożeń, która zdaje się wymykać nawet najlepiej skonstruowanej ochronie – z atakami na łańcuchy dostaw.

Gdy prześledzimy największe i najpoważniejsze ataki ostatnich kilku lat, to szybko stanie się jasne, że spora część z nich rozpoczęła się właśnie od przejęcia łańcucha dostaw. Choć ogromna kampania ransomware NotPetya z 2017 r. kojarzona jest przede wszystkim z gigantyczną liczbą zaszyfrowanych urządzeń, to przecież szkodnik trafił na nie dzięki spenetrowaniu serwerów aktualizacji ukraińskiego dostawcy oprogramowania MEDoc. Napastnicy wykorzystali znaną z kampanii WannaCry podatność w SMB i rażące zaniedbania twórców MEDoc, by uwierzytelnionym kanałem zaufanego dostawcy oprogramowania wykorzystywanego także w administracji państwowej rozesłać spreparowaną aktualizację MEDoc ze wstrzykniętym złośliwym kodem. Straty wyceniono na 10 mld dolarów.

Nie trzeba jednak sięgać tak daleko wstecz, by przytoczyć nie mniej poważne skutki przejęcia łańcucha dostaw. W minionym roku zaatakowane zostały przecież serwery firmy SolarWinds. Z oprogramowania Orion korzystało ok. 33 tys. organizacji na całym świecie, a wśród nich znalazły się liczne amerykańskie agencje rządowe, Microsoft czy VMware. Szacuje się, że w wyniku ataku na łańcuch dostaw Oriona napastnikom udało się uzyskać dostęp do infrastruktury ponad 18 tys. wszystkich klientów SolarWinds, co zapewne będzie miało długofalowe negatywne skutki dla tej marki.

Ataki na łańcuchy dostaw nie muszą jednak być zawsze gigantyczne, zakrojone na globalną skalę i być przeprowadzane przez najbardziej zaawansowane grupy hakerskie opłacane przez rządy światowych mocarstw. Nie mniej groźne są podatności dziedziczone po bibliotekach, pakietach czy paczkach wykorzystywanych przez narzędzia programistyczne. Osobny wektor ataku, przez który w zasadzie dowolny pakiet może zostać zainfekowany groźnym kodem, stanowią zewnętrzne repozytoria i inne serwisy dystrybucyjne.

Rok 2021 zakończyliśmy z przytupem w związku z ujawnieniem podatności w służącej do logowania bibliotece Log4j. Jest ona niezwykle popularna, przez co trudna do oszacowania liczba aplikacji Java (tak przeglądarkowych, jak i offline'owych) pozwalała na zdalne wykonanie kodu i przejęcie pełnej kontroli nad środowiskiem. W połowie grudnia podatną wersję Log4j wykorzystywało wciąż prawie 36 tys. paczek Java, czyli ok. 8% najpopularniejszego repozytorium. Według Google Security wpływ podatności Log4j na bezpieczeństwo będzie „ogromny”, zaś eksperci z Tenable mówią wprost o „Fukushimie” dla całej branży cybersec. Kwestią czasu jest zapewne, aż niezaktualizowana wersja biblioteki posłuży do przejęcia serwerów dystrybucji oprogramowania.

> OCHRONA PRZED ATAKAMI NA DOSTAWY

Na rosnące zagrożenie wynikające z przejęcia łańcuchów dostaw nałożyło się wiele zróżnicowanych czynników, jednak kluczowe zdają się zmiany w sposobach dystrybucji oprogramowania. Konieczność utrzymywania niemal ciągłego połączenia z serwerami producenckimi stała się standardem, a jak widać na przykładzie SolarWinds, gwarancji ich bezpieczeństwa, nawet w przypadku najbardziej cenionych dostawców, zwyczajnie nie ma. Trudno sobie wyobrazić, aby przywoływany jako przykład Orion siał takie spustoszenie, gdyby oprogramowanie było dystrybuowane na nośnikach fizycznych.

Nie mniej ważny jest sposób aktualizacji, która w dobie CD/CI skutkuje nawet codziennym pobieraniem drobnych poprawek. Z jednej strony możemy liczyć na szybsze łatanie błędów, także zagrażających bezpieczeństwu, z drugiej musimy autoryzować niemal stałe połączenie z zewnętrzną infrastrukturą, co do bezpieczeństwa której nigdy nie możemy mieć całkowitej pewności. Zwłaszcza że jest to komunikacja składająca się z wielu węzłów – jeśli nawet serwery dostawcy oprogramowania pozostaną bezpieczne, to do przejęcia łańcucha może dojść np. w niezależnym repozytorium lub poprzez zależność z podatną biblioteką.

To właśnie ten ostatni czynnik także wpływa na coraz dotkliwsze konsekwencje ataków na dostawy. Architektura współczesnego oprogramowania jest dalece zmodularyzowana, używa się ogromnej liczby prekonfigurowanych komponentów, mikrousług i zależności od zewnętrznego oprogramowania. Poza wąskimi specjalizacjami rzadko spotyka się dziś kod wysokiego poziomu pisany w całości od zera. W rezultacie do przejęcia łańcucha dostaw może dojść, nawet jeśli zarówno infrastruktura, jak i autorski kod dostarczanego do klientów oprogramowania będzie bezpieczny.

Ze względu na złożoność całego procesu rozwoju oprogramowania, jasnym jest, że ochrona przed przejęciami łańcuchów dostaw jest niezwykle trudnym wyzwaniem. Do ataku może dojść jeszcze przed kompilacją kodu źródłowego, a następnie każdy kolejny etap dostarczania aktualizacji także jest podatny na atak. Nie będzie przesady w twierdzeniu, że rozwój dystrybucji oprogramowania przez internet i to w sposób niemalże ciągły spopularyzował się na dużą skalę, jeszcze zanim opracowano skuteczne metody zabezpieczania takiego ruchu.

> SLSA

Można pokusić się o hipotezę, że przez długie lata nie przywiązywano do problemu odpowiedniej wagi, co mogło być spowodowane brakiem pomysłu na kompleksowe utwardzenie całego procesu dostarczania oprogramowania i aktualizacji. Zamiast tego stopniowo zwiększano bezpieczeństwo każdego z węzłów z osobna i to w sposób niezbyt skoordynowany. To się ma jednak wkrótce zmienić dzięki SLSA, czyli Supply chain Levels for Software Artifacts.

SLSA (wymawiane po prostu jako „salsa”) to framework opracowywany przez ekspertów ds. bezpieczeństwa Google'a, dzięki któremu łańcuchy dostaw oprogramowania będzie można zabezpieczyć end-to-end, zapewniając integralność pomiędzy wszystkimi etapami rozwoju oprogramowania. Całość rozwijana jest na podstawie rozwiązania stosowanego dotąd wewnętrznie w Google'u, czyli na mechanizmie uwierzytelniania binarnego wykorzystywanego w systemie zarządzania klastrami Borg.

> SLSA JAKO FRAMEWORK

Na aktualnym etapie SLSA stanowi przede wszystkim zestaw instrukcji czynności, jakie muszą spełnić twórcy oprogramowania w celu zapewnienia zgodności z frameworkiem. Jest to zatem dość wczesne stadium rozwoju, w którym trzeba ręcznie wykonywać wszelkie operacje zabezpieczające, a następnie samodzielnie sprawdzać skuteczność zastosowanych rozwiązań.

Google zapewnia jednak, że w docelowej formie SLSA będzie oprogramowaniem, dzięki któremu wszelkie procedury będą nie tylko wymuszane, ale także zautomatyzowane. Framework będzie także generował metadane, których audytu będzie można dokonać z użyciem silników polityk, co poskutkuje przyznaniem danej paczce odpowiedniej certyfikacji. Można więc oczekiwać, że Google będzie dążyło do tego, aby z SLSA uczynić standard integralności oprogramowania z naciskiem na ochronę przed przejęciem łańcucha dostaw na wszystkich etapach tworzenia i dostarczania. Wówczas aplikacje klienckie na stacjach roboczych mogłyby weryfikować wiarygodność certyfikatu i dopiero po tym kroku instalować aktualizację. Trzeba przyznać, że plany są ambitne, niemniej już na wczesnym etapie rozwoju SLSA wygląda na rozwiązanie, które faktycznie może zmniejszyć liczbę udanych przejęć.

Na podstawie przejęć łańcuchów dostaw z ostatnich kilkunastu miesięcy prześledźmy zatem przykładowe zagrożenia oraz odpowiedź SLSA na te wyzwania. W przypadku ataku na SolarWinds napastnik uzyskał dostęp do platformy, gdzie tworzono buildy, a następnie wstrzyknął kod, przez który każda kolejna kompilacja powstająca na tej platformie była szkodliwa. W przypadku wyższych poziomów SLSA (o których więcej za moment) taki atak nie mógłby mieć miejsca, gdyż każda usługa buildowa musiałaby przejść audyt, by móc pracować w środowisku produkcyjnym. Podobne mechanizmy akredytacji będzie można stosować także wobec kontroli kodu źródłowego.

[...]

Dziennikarz, redaktor, bloger. Entuzjasta i popularyzator wolnego oprogramowania.