Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



24.05.2022

Nowe możliwości w zakresie...

VMware rozszerza ofertę zabezpieczeń end-to-end dla obciążeń cloud-native poprzez ochronę...
24.05.2022

Zarządzanie kluczami

IBM przedstawił nowe rozwiązanie do zarządzania kluczami w wielu chmurach, oferowane jako...
24.05.2022

Ochrona przed zagrożeniami

ESET wprowadził nowe wersje swoich produktów biznesowych do ochrony stacji roboczych,...
24.05.2022

Value Stream Management

Micro Focus zaprezentował nową platformę do zarządzania strumieniem wartości VSM (ang....
24.05.2022

Unijna decyzja Value Stream...

Komisja rynku wewnętrznego i ochrony konsumentów Parlamentu Europejskiego poparła...
24.05.2022

Nowy laptop Dynabooka

Sprzęt waży 1,45 kg, a jego grubość to 17,8 mm. Jest odporny na czynniki zewnętrzne, gdyż...
24.05.2022

Przepływ pracy

QNAP oferuje model TS-435XeU wykorzystujący procesor Marvell OCTEON TX2 CN9131 2,2 GHz z...
24.05.2022

Wideo bez wstrząsów

Kamera stałopozycyjna firmy Axis Communications służy do monitoringu miejsc zagrożonych...
24.05.2022

Akceleratory dla naukowców

Firma AMD ogłosiła wprowadzenie do sprzedaży opartych na architekturze AMD CDNA 2...

Ochrona łańcuchów dostaw SLSA

Data publikacji: 03-02-2022 Autor: Maciej Olanicki

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.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"