Tysiące aplikacji, które skorzystały z zalet oprogramowania typu open source Indeks pakietów Pythona Pakiety oprogramowania (PyPI) są narażone na przejęcie i dywersję przez osoby o złych zamiarach, co otwiera możliwość poważnych ataków na łańcuchy dostaw, które mogą dotknąć jeszcze większą liczbę organizacji i użytkowników niższego szczebla.
To jest według badaczy zagrożeń z jFrogktóry zidentyfikował technikę wykorzystywaną w środowisku naturalnym przeciwko pakietowi pingdomv3 – części szeroko stosowanej usługi monitorowania witryn Pingdom API, należącej do SolarWinds – podczas monitorowania ekosystemu open source. Zespół nazwał tę technikę Revival Hijacking.
Sama technika jest podobna w swoich podstawach do typosquatting – gdzie atakujący wykorzystują powszechne błędy ortograficzne, aby rejestrować złośliwe domeny.
W ataku Revival Hijack na pakiet pingdomV3 nieujawniony sprawca ataku wykorzystał funkcję PyPl, dzięki której po usunięciu pakietu lub jego usunięciu z repozytorium jego nazwa natychmiast staje się ponownie dostępna do użycia.
Jak sama nazwa wskazuje, oznacza to, że pakiet można skutecznie ożywić i przejąć w celu wykorzystania go w niecnych celach.
Brian Moussali, szef zespołu badawczego zajmującego się złośliwym oprogramowaniem w firmie JFrog i współautor raportu, stwierdził, że technika Revival Hijack jest szczególnie niebezpieczna z trzech głównych powodów.
Po pierwsze, w przeciwieństwie do typosquattingu, technika ta nie polega na tym, że ofiara popełni błąd podczas instalowania złośliwego pakietu. Po drugie, aktualizacja znanego bezpiecznego pakietu do najnowszej wersji jest powszechną praktyką, którą wielu deweloperów uważa za minimalnie ryzykowną – mimo że tak nie jest. Po trzecie, wielu CI/CD maszyny zostaną skonfigurowane tak, aby automatycznie instalować aktualizacje pakietów.
„Revival Hijack to nie tylko teoretyczny atak – nasz zespół badawczy widział już, jak jest on wykorzystywany w praktyce. Wykorzystanie podatnego zachowania w obsłudze usuniętych pakietów pozwoliło atakującym na przejęcie istniejących pakietów, co umożliwiło zainstalowanie ich w systemach docelowych bez żadnych zmian w przepływie pracy użytkownika” – powiedział Moussali.
„Powierzchnia ataku na pakiety PyPI stale rośnie. Pomimo proaktywnej interwencji użytkownicy powinni zawsze zachować czujność i podjąć niezbędne środki ostrożności, aby chronić siebie i społeczność PyPI przed tą techniką przejęcia kontroli”.
Moussali i jego współbadacz Andrey Polkovnichenko twierdzą, że na podstawie liczenia usuniętych pakietów PyPI na serwetce, potencjalnie może zostać przejętych nawet 120 000. Po odfiltrowaniu tych, które mają mniej niż 100 000 pobrań, nie są aktywne długo lub są ewidentnie podejrzane, liczba ta nadal przekracza 22 000.
Biorąc pod uwagę, że średnio 309 projektów PyPI jest usuwanych miesięcznie, każdy, kto chciałby wykorzystać technikę Revival Hijack, ma stały strumień potencjalnych nowych ofiar.
Co się stało z pingdomV3?
W przypadku pingdomV3 pierwotny właściciel pakietu, który najwyraźniej odszedł, ostatnio zaktualizował go w kwietniu 2020 r., a następnie zamilkł do 27 marca 2024 r., kiedy to wysłał krótką aktualizację, w której nakazał użytkownikom unikanie korzystania z pakietu, ponieważ został porzucony. Następnie usunął go 30 marca, w którym to momencie nazwa pojawiła się do rejestracji.
Prawie natychmiast użytkownik z adresem Gmail opublikował pakiet pod tą samą nazwą z nowszym numerem wersji, twierdząc, że jest to przebudowa i wskazując na repozytorium GitHub. Ta wersja zawierała standardowy kod pingdomV3, chociaż powiązane repozytorium GitHub tak naprawdę nigdy nie istniało.
Następnie, 12 kwietnia, automatyczne skanery jFrog wykryły dziwną aktywność, gdy właściciel wprowadził podejrzany, zaciemniony ładunek Base64. To wywołało alarm i skłoniło do wszczęcia dochodzenia i późniejszego ujawnienia. Pakiet został całkowicie usunięty przez PyPI 12 kwietnia, a jego nazwa została zakazana do użytku.
Sam ładunek wyglądał na trojana-złośliwego Pythona, którego zadaniem było sprawdzenie, czy jest uruchomiony w Jenkins CI ustawienie, w którym to przypadku wykonuje żądanie HTTP GET do adresu URL kontrolowanego przez atakującego. Zespół JFrog nie był w stanie pobrać ostatecznego ładunku, który by to dostarczyło, co sugeruje, że złośliwy aktor albo chciał opóźnić swój atak, albo ograniczył go do określonego zakresu adresów IP. W każdym razie został on udaremniony.
Zaniepokojeni potencjalną skalą problemu, Moussali i Polkovnichenko zaczęli przejmować kontrolę nad najczęściej pobieranymi porzuconymi pakietami i zastępować je pustymi, nieszkodliwymi pakietami, wszystkie z numerem wersji 0.0.0.1, aby mieć pewność, że nie zostaną przypadkowo pobrane w automatycznych aktualizacjach.
Po kilku dniach sprawdzili ponownie i odkryli, że puste pakiety PyPI zostały pobrane ponad 200 000 razy.
Oczywiście, ponieważ pakiety zastępcze są puste, nie można z całą pewnością stwierdzić, że złośliwy atakujący mógłby rzeczywiście za każdym razem wykonać kod, ale „można z dużą dozą pewności stwierdzić”, że w większości przypadków tak by się stało – powiedział Moussali.
Odpowiedź PyPI
Według jFroga, PyPI rozważało zmianę polityki dotyczącej usuniętych pakietów, która wyeliminowałaby tę lukę, ale z jakiegoś powodu w ciągu ponad dwóch lat obrad nie osiągnięto żadnych konkluzji w tej sprawie.
W przypadku usunięcia wyraźnie zaznaczono, że nazwa zostanie udostępniona do użytku innym osobom, a także zapobiega się usuwaniu określonych wersji pakietów, zgodnie z Zalecenia OpenSSF.
Jednakże, jak stwierdził Moussali, chociaż jest to pomocne, potencjalny zakres techniki Revival Hijack jest tak szeroki, że konieczne jest podjęcie dalszych działań.
„W pełni popieramy przyjęcie przez PyPI bardziej rygorystycznej polityki, która całkowicie zabrania ponownego używania nazwy pakietu. Ponadto użytkownicy PyPI muszą być świadomi tego potencjalnego wektora ataku, rozważając uaktualnienie do nowej wersji pakietu” – napisał.
Henrik Plate, badacz ds. bezpieczeństwa w Laboratoria Endorpowiedział: „To ryzyko jest realne i zależy od popularności pakietu. Ryzyko prawdopodobnie maleje, jeśli pakiety zostały usunięte dawno temu, ponieważ im dłużej pakiet był usuwany, tym więcej deweloperów i potoków zauważyło jego niedostępność i dostosowało swoje deklaracje zależności.
„W tym kontekście należy zauważyć, że podany przykład został przywrócony tuż po usunięciu, co może wskazywać, że atakujący monitorował usuwanie pakietów w PyPI.
„Przywracanie usuniętych pakietów to znany problem. Taksonomia wektorów ataków na łańcuch dostaw wizualizowana przez Endor Labs Risk Explorer (odgałęzienie projektu GitHub sap/risk-explorer) obejmuje ten wektor jako [AV-501] Wiszące odniesieniei przykłady pomocnicze obejmują ożywione repozytoria GitHub, zmieniono nazwy repozytoriów GitHub i ożywił pakiety npm”, powiedział Plate w komentarzu przesłanym e-mailem dla Computer Weekly.
Plate kontynuował, stwierdzając, że podkreśla to znaczenie bardziej rygorystycznych wytycznych bezpieczeństwa dla repozytoriów pakietów, takie jak te sugerowane przez OpenSSF.
Według niego, obrońcy powinni chronić programistów przed takimi atakami, korzystając z wewnętrznych rejestrów pakietów, które będą odzwierciedlać pakiety open source, tak aby pozostały dostępne nawet po usunięciu. Jednak, jak ostrzega Plate, takie wewnętrzne rejestry muszą być skonfigurowane tak, aby nowe, potencjalnie złośliwe wersje pakietów były dokładnie sprawdzane przed ich odzwierciedleniem.