Supply Chain Attack
☢️ Supply Chain Attack, czyli dostarczenie złośliwego oprogramowania za pośrednictwem samego twórcy, dostawcy. Jedna z najgroźniejszych broni współczesnych cyberprzestępców, która charakteryzuje się:
🌎 Dużą skalą zainfekowanego oprogramowania. Jeżeli źródło – twórca, producent, dostawca oprogramowania wypuszcza zainfekowany software, to znaczy, że wszyscy jego użytkownicy są narażeni na atak.
👾 Wysoką złożonością przeprowadzonego ataku. Przestępcy z reguły muszą najpierw włamać się na serwery producenta, żeby móc podmienić software. Mogą również wstrzyknąć złośliwy kod podczas etapu wytwarzania oprogramowania, np. przejmując konta programistów i dostęp do platform deweloperskich.
🔍Utrudnioną możliwością wykrycia. Nikt nie spodziewa się źródła zagrożenia w oficjalnych kanałach dystrybucji oprogramowania.
Poniżej przedstawiamy najciekawsze przykłady ataków Supply Chain Attack.
Solarwinds
Atak, w którym przestępcy prawdopodobnie powiązani z rosyjską grupą APT Cozy Bear zdołali umieścic backdoor w złośliwej bibliotece BusinessLayer.dll. Co interesujące – złośliwe oprogramowanie czekało aż 12 dni, aby odezwać się do serwera kontrolowanego przez hackerów. Przestępcy na wysokim poziomie są cierpliwi⌛️
Atak został odkryty w grudniu 2020 roku, jednak początek ataku datuje się na marzec 2020 roku.
Przestępcom udało się dostać do infrastruktury firmy SolarWinds poprzez podatne oprogramowanie do monitoringu Orion.
Dlaczego atak na SolarWinds jest uznawany za jeden z najpoważniejszych tego typu ataków w historii? Ponieważ oprogramowanie SolarWinds jest wykorzystywane szeroko przez największe przedsiębiorstwa i firmy na świecie, a jednym z najważniejszych klientów jest… Rząd Stanów Zjednoczonych Ameryki i podległe mu podmioty.
XZ
Atak na bibliotekę XZ, polegał na wprowadzeniu złośliwego kodu do popularnej biblioteki kompresji danych XZ Utils. Przestępca o pseudonimie „Jia Tan” wykorzystał twórcę biblioteki XZ – Lassego Collinsa, zdobywając jego zaufanie, wprowadzając szereg ulepszeń do wspomnianej biblioteki. W końcu, wykorzystując zdrowotne problemy Lassego oraz presję użytkowników biblioteki (prawdopodobnie podstawionych), przejął kontrolę nad projektem i umieścił w nim zaawansowany backdoor, który umożliwiał zdalne wykonanie kodu na zainfekowanych maszynach.
Atak został przypadkowo wykryty przez jednego z inżynierów oprogramowania, który zauważył, że zatrute biblioteką XZ oprogramowanie SSH wykonywało pracę… kilkaset milisekund dłużej niż normalnie.
Akcja jak rodem z filmów szpiegowskich.
Atak NotPetya
Atak, który rozpoczął się od zainfekowanej aktualizacji oprogramowania księgowego MeDoc, które było powszechnie używane na Ukrainie. Według źródeł, program MeDoc miał praktycznie monopol wśród lokalnych przedsiębiorstw, obsługując około 90% ukraińskich firm. Po zainfekowaniu początkowych celów, malware rozprzestrzeniało się w sieciach lokalnych, wykorzystując exploity takie jak EternalBlue oraz narzędzia do uzyskiwania wyższych uprawnień, jak Mimikatz.
Po zainfekowaniu komputerów, Ransomware szyfrował dyski i przedstawiał ofiarom informacje o numerach portfeli bitcoinowych oraz wysokości okupu. Co ciekawe, w wielu przypadkach dane zaszyfrowane przez oprogramowanie było trwale niszczone i nie było możliwe do odzyskania.
Mimo, że atak odbył się w czerwcu 2017, a łatki na exploit EternalBlue były już dostępne od marca, nie przeszkodziło to przestępcom zaatakować wielu firm, a straty były oszacowane na kilkaset milionów dolarów.
Mimo, że atak najbardziej dotknął Ukrainę, podobne infekcje miały również miejsce we Francji, Niemczech czy Polsce.
Rekomendacje
Ataki na łańcuch dostaw, takie jak NotPetya, SolarWinds i atak na bibliotekę XZ, pokazują, jak ważne jest zabezpieczenie całego procesu tworzenia i dystrybucji oprogramowania. Wymaga to ścisłej kontroli nad kodem źródłowym, procesem kompilacji oraz dystrybucją aktualizacji. Przed niektórymi atakami nie da się obronić, ale stosując dobre praktyki i standardy jesteśmy w stanie zminimalizować lub wręcz ograniczyć do zera skutki ataku. Co natomiast mogą zrobić producenci i twórcy oprogramowania?
- Zabezpieczyć środowisko deweloperskie, które powinno być traktowane jako krytyczny element infrastruktury. Klucze 2FA, ACL, zasada najmniejszych uprawnień. Tyczy się to również izolacji środowisk CI/CD, workerów, builderów, runnerów.
- Szczególna troska o certyfikaty i klucze, które służą do podpisywania oprogramowania. Etap podpisywania oprogramowania powinien być szczególnie istotny z punktu widzenia security.
- Wykorzystywanie wtyczek, narzędzi i innego oprogramowania do monitorowania kodu pod kątem bezpieczeństwa.
- Integracja CI/CD z oprogramowaniem takim jak Snyk czy Black Duck od Synopsys, które zarządzają bezpieczeństwem zależności i bibiliotek.
- Wykorzystywanie tzw. deterministycznej kompilacji, która pozwala ustalić czy dany plik wynikowy (binarny) jest skompilowany z zaufanego źródła.
- Weryfikacja wykorzystywanych bibliotek i zależności za pomocą sum kontrolnych, podpisów cyfrowych.