Ataki na Łańcuch Dostaw w Ekosystemach Open-Source 

Analitycy cyberbezpieczeństwa odnotowali znaczny wzrost zainteresowania cyberprzestępców środowiskami programistycznymi, takimi jak PyPI, npm, Ruby Gems, NuGet, Dart Pub i Rust Crates. Coraz częściej stają się one celem tzw. ataków na łańcuch dostaw (z ang. supply chain attacks), w których cyberprzestępcy wykorzystują te ekosystemy, by uzyskać dostęp do firm – podobnie jak w głośnej sprawie SolarWinds. 

Wzrost Zainteresowania Cyberprzestępców Środowiskami Programistycznymi

Badacze z Checkmarx, Yehuda Gelb i Elad Rapaport, wskazują, że cyberprzestępcy mogą wykorzystywać punkty wejścia do wykonywania złośliwego kodu, gdy uruchamiane są określone komendy. Stwarza to poważne ryzyko w ekosystemach open-source, ponieważ deweloperzy mogą nieświadomie pobrać zainfekowane pakiety i uruchomić złośliwy kod podczas budowania projektu. W zależności od stopnia złośliwej ingerencji w pakiety lub moduły, kod ten może zostać uruchomiony zarówno na maszynach deweloperów, jak i bezpośrednio w środowisku korporacyjnym, co niesie ryzyko rozprzestrzenienia się zagrożenia na większą skalę.  

Firma Checkmarx zauważa, że tego rodzaju ataki, oparte na punktach wejścia, pozwalają cyberprzestępcom na bardziej podstępny i trwały sposób kompromitacji systemów, który może skutecznie ominąć tradycyjne mechanizmy zabezpieczeń. 

Jednym ze sposobów nadużyć stosowanych przez cyberprzestępców jest wykorzystanie mechanizmu pakowania w Pythonie, który umożliwia programistom udostępniać określoną funkcjonalność jako narzędzie wiersza poleceń (tzw. console_scripts). Alternatywnie, mechanizm ten może także służyć do ładowania wtyczek, które rozszerzają funkcje pakietu. 

Command-Jacking i Fałszywe Komendy: Podstępne Ataki na Programistów

Checkmarx zauważył, że entry points mogą być użytecznym narzędziem zwiększającym modularność oprogramowania, , to samo rozwiązanie może zostać wykorzystana do dystrybucji złośliwego kodu.. Atakujący mogą to osiągnąć m.in. poprzez tzw. „command-jacking” oraz tworzenie złośliwych wtyczek dla różnych narzędzi i frameworków. 

Command-jacking polega na podszywaniu się pod popularne komendy i narzędzia, np. aws lub docker, dzięki czemu w momencie instalacji złośliwego pakietu (nawet w formacie wheel .whl), mogą zbierać wrażliwe informacje. Popularnymi celami takiego ataku mogą być komendy, takie jak npm, pip, git, kubectl, terraform, gcloud, heroku i dotnet

Case Study: Złośliwy Pakiet „awscli” w PyPI
Jak cyberprzestępcy mogą przejąć kontrolę nad popularnymi komendami jak „aws”?

Wyobraźmy sobie, że atakujący tworzy złośliwy pakiet w ekosystemie Python PyPI, który naśladuje popularną bibliotekę lub narzędzie, na przykład awscli (popularne narzędzie używane przez programistów do zarządzania usługami Amazon Web Services z wiersza poleceń). Ten fałszywy pakiet zawiera wpis console_scripts skonfigurowany tak, by odpowiadał komendzie „aws”. Gdy nieświadomy programista przypadkowo pobierze ten pakiet zamiast oryginalnego, użycie komendy „aws” spowoduje uruchomienie złośliwego kodu, który może np. zebrać dane uwierzytelniające lub wysłać poufne informacje na serwery atakującego. 

Ponieważ złośliwy pakiet działa w tle, a komenda „aws” wykonuje się normalnie, programista nie dostrzega żadnych oznak kompromitacji, a atakujący może dalej zbierać dane lub uzyskać długotrwały dostęp do środowiska. 

 Atakujący tworzy pakiet, który udaje oficjalną bibliotekę, np. „awscli”. W pliku setup.py (który służy do konfiguracji pakietu) dodaje wpis console_scripts tak, aby komenda „aws” wywoływała złośliwą funkcję. 

Co się dzieje, gdy programista uruchomi komendę „aws” 

  1. Po instalacji tego fałszywego pakietu, programista może wpisać komendę „aws” w wierszu poleceń, myśląc, że korzysta z oryginalnego narzędzia AWS CLI. 
  1. Zamiast wywołać autentyczne narzędzie, uruchamiany jest kod zawarty w złośliwej funkcji malicious_code. 
  1. Ta funkcja może wykonać złośliwe operacje, np. przesłać dane uwierzytelniające lub inne wrażliwe informacje na zdalny serwer. 

Dzięki wpisowi console_scripts fałszywa komenda „aws” zachowuje się tak, jakby była oryginalną komendą, co może zwieść użytkownika i sprawić, że nie zauważy zagrożenia. 

Atakujący mogą również używać nazw rzeczywistych komend systemowych, takich jak touch, curl, cd, ls i mkdir, aby przejąć kontrolę nad procesem wykonywania poleceń, tworząc złośliwe punkty wejścia. Sukces tego podejścia zależy głównie od kolejności ścieżek (PATH), gdyż jeśli katalog zawierający złośliwy punkt wejścia jest wymieniony wcześniej niż systemowe katalogi, to fałszywa komenda zostanie wykonana zamiast systemowej. Jest to bardziej prawdopodobne w środowiskach deweloperskich, gdzie lokalne katalogi pakietów są zazwyczaj priorytetowane. 

Command-Wrapping: Dyskretna Manipulacja Komendami. Dlaczego command-wrapping sprawia, że cyberatak pozostaje niewidoczny?

Checkmarx zauważa również, że skuteczność ataku typu command-jacking można zwiększyć, stosując technikę znaną jako „command wrapping”. Polega ona na stworzeniu komendy, która nie zastępuje oryginalnej, lecz działa jako otoczka, uruchamiając złośliwy kod równocześnie z legalną komendą. W efekcie złośliwy kod jest wykonywany dyskretnie, podczas gdy oryginalna funkcjonalność pozostaje nienaruszona. Taki zabieg sprawia, że atak jest bardzo trudny do wykrycia, ponieważ z perspektywy użytkownika komenda działa normalnie, bez widocznych oznak kompromitacji. 

Charakterystyczne dla tej techniki jest to, że oryginalna komenda nadal działa, a jej wynik i zachowanie pozostają bez zmian, co sprawia, że nie ma widocznych oznak kompromitacji. Dzięki temu atakujący mogą utrzymywać długotrwały dostęp do systemu i potencjalnie wykradać dane bez wzbudzania podejrzeń użytkownika czy systemów monitorujących. 

Przykład ataku typu: „Command-Wrapping” 

Przykładowo, atakujący może stworzyć pakiet zawierający złośliwą wersję komendy „git”. Zamiast całkowicie podmieniać oryginalną komendę, skrypt uruchamia zarówno prawdziwy git, jak i dodatkowy kod złośliwy. W efekcie użytkownik widzi, że „git” działa zgodnie z oczekiwaniami, a złośliwy kod wykonuje się w tle. 

Atakujący może osiągnąć ten efekt na kilka sposobów. Jedną z metod jest stworzenie pakietu o nazwie bardzo podobnej do oryginalnego, np. „git-helper” lub „gittools”, co może zmylić użytkownika, by pomyślał, że jest to dodatkowe narzędzie do gita. Innym sposobem jest manipulacja zależnościami – zainfekowanie innego popularnego pakietu tak, aby pobierał „git-helper” jako zależność. Taki pakiet podczas instalacji automatycznie dodaje skrypt do lokalnych ścieżek (PATH) użytkownika. 

Jeśli katalog zawierający złośliwy skrypt „git” znajdzie się wyżej w PATH niż oryginalny katalog systemowy, system priorytetowo uruchomi złośliwą wersję komendy. W środowiskach deweloperskich, szczególnie w skryptach budowania lub kontenerach Docker, takie pakiety mogą zostać zainstalowane niezauważenie, co sprawia, że atak jest trudny do wykrycia i może mieć szeroki zasięg w całej organizacji. 

Przykład setup.py z command wrapping dla „git”: 

   

Co się dzieje, gdy użytkownik uruchomi „git”: 

  1. Programista wpisuje komendę „git” z przekonaniem, że uruchamia oryginalne narzędzie. 
  1. Skrypt wrapped_git_command najpierw wykonuje złośliwy kod, który może np. przesłać dane na serwer atakującego. 
  1. Następnie wywołuje oryginalną komendę „git” (np. „git –version”), której wynik jest taki sam, jak w przypadku autentycznego narzędzia. 

Efekt? Dla użytkownika komenda „git” działa zgodnie z oczekiwaniami, a jednocześnie złośliwy kod pozostaje niewidoczny, co czyni atak wyjątkowo trudnym do wykrycia. 

Rekordowy Wzrost Złośliwych Pakietów – Dane z Raportu Sonatype

Inną popularną techniką wykorzystywaną przez cyberprzestępców jest implementacja złośliwych wtyczek i rozszerzeń do narzędzi deweloperskich, które zyskują szeroki dostęp do kodu źródłowego. Dzięki temu atakujący mogą modyfikować zachowanie programu lub manipulować procesem testowania, aby kod sprawiał wrażenie działającego poprawnie, mimo że zawiera złośliwe elementy. Taka manipulacja pozwala złośliwemu kodowi trafić do produkcji niezauważenie, co zwiększa ryzyko dla całej organizacji.  

Jak Chronić Środowiska Open-Source Przed Atakami?

Checkmarx podkreśla, że niezbędne jest opracowanie kompleksowych środków bezpieczeństwa, które uwzględnią zagrożenia wynikające z mechanizmów pakowania i dostępu do komend. Zrozumienie tych ryzyk i skuteczne przeciwdziałanie im pozwoli stworzyć bezpieczniejsze środowisko dla pakietów Pythona, chroniąc zarówno niezależnych deweloperów, jak i systemy przedsiębiorstw przed zaawansowanymi atakami na łańcuch dostaw oprogramowania.  

Z kolei firma firma Sonatype, w swoim corocznym raporcie „State of the Software Supply Chain”, ujawniła, że od listopada 2023 roku odkryto już ponad 512 847 złośliwych pakietów w ekosystemach open-source dla języków Java, JavaScript, Python i .NET, co stanowi wzrost o 156% w porównaniu do poprzedniego roku.. 

Sonatype zauważa, że tradycyjne narzędzia ochrony często nie są w stanie wykryć nowych typów ataków na łańcuch dostaw, co czyni deweloperów i zautomatyzowane środowiska budowania wyjątkowo podatnymi na zagrożenia. Obecna dynamika ataków pokazuje, że konieczne jest nie tylko stosowanie zaawansowanych mechanizmów ochrony, ale także regularne monitorowanie zagrożeń i edukacja w zakresie bezpieczeństwa, aby skutecznie chronić ekosystemy open-source przed eskalacją tego rodzaju incydentów.  

Jeśli zainteresował Cię ten artykuł, zaobserwuj nasz profil na Linkedin.