Jak używanie fałszywych bibliotek zagraża bezpieczeństwu Twojej aplikacji?

Jeśli obserwujecie na naszych łamach wpisy Grzegorza Siewruka, wiecie, że skupia się głównie na bezpieczeństwie w kontekście procesu tworzenia oprogramowania. Jednym z kluczowych zagadnień w tej materii jest zadbanie o bezpieczeństwo bibliotek, której używamy. I o tym właśnie przeczytacie dzisiaj.

Czy zdajesz sobie sprawę, że istnieją ataki skierowane bezpośrednio na programistów? Takich, którzy importują biblioteki w sposób podobny do otrzymywania SMS-ów proszących o dopłatę 1,23 zł do przesyłki zatrzymanej przez kuriera?

Prosimy, kliknij w ten link!

Ataki, mające na celu przekonanie użytkownika do kliknięcia w przesłany link, to od dawna czołówka najgroźniejszych zagrożeń w cyberprzestrzeni. Najbardziej typowy scenariusz obejmuje rejestrację domeny na tyle podobnej do znanej marki, by przestępca mógł się pod nią podszyć. Następnie wysyła taki link do użytkownika z nadzieją, że ten kliknie. W efekcie na stronie pojawia się logo Facebooka, ale niezauważalny dla wielu jest fakt, że domena to nie facebook.com, lecz na przykład facebook-app.app.

Pod koniec kwietnia premierę miał raport CERT Orange Polska za rok 2023. W nim na potwierdzenie powyższej tezy możecie znaleźć np. taki wykres:

Powyższy wykres może ilustrować skalę zagrożeń (skupiając się głównie na atakach obserwowanych w polskiej przestrzeni internetowej), z którymi na co dzień mierzą się specjaliści ds. bezpieczeństwa. Z drugiej strony pokazuje, z jak dużą czujnością użytkownicy powinni podchodzić do wiadomości, którymi są atakowani z różnych stron.

Przykłady domen, pod które podszywają się atakujący:

Zaznaczam jednak, że nie jestem ekspertem w tej dziedzinie, ani na co dzień nie analizuję tego typu przypadków. Jeśli jesteś zainteresowany tematem podszywania się pod domeny oraz sposobami, w jakie firmy walczą z tym zagrożeniem, polecam kilka wartościowych materiałów:

1. https://www.youtube.com/watch?v=7ufih0kr_84 ta prezentacja przedstawia jak niektóre instytucje próbują walczyć aby chronić swoich użytkowników
2. https://www.youtube.com/watch?v=Z20XNp-luNA ta prezentacja koncentruje się na analizie i zrozumieniu phishingu, ze szczególnym uwzględnieniem jego psychologicznych aspektów.
3. https://www.youtube.com/watch?v=Sd5NFVc9Wzs ta prezentacja koncentruje się na rosnącej roli zestawów phishingowych w gospodarce cyberprzestępczości.

Instalacja bibliotek programistycznych

W inżynierii oprogramowania przyjęły się dwie główne zasady: KISS – “keep it simple, stupid” (nie przekombinuj, głupcze) oraz DRY – “don’t repeat yourself” (nie powtarzaj się). Skupmy się na tej drugiej. Na przykład, jeśli funkcjonalność, tak jak sortowanie, jest już dostępna, dobrą praktyką jest skorzystać z niej, zamiast pisać własną funkcję sortującą. Prawdopodobnie możesz sobie wyobrazić, że większość metod, realizujących różnorodne logiki biznesowe, została już napisana i udostępniona. Aby móc z nich skorzystać, należy skorzystać z odpowiednich bibliotek, dostępnych w rejestrze, czy repozytorium, co umożliwi korzystanie z implementowanych w niej metod i funkcji.

I tutaj przychodzą z pomocą pluginy integracyjne, takie jak Maven, Gradle, npm czy pip. To narzędzia kluczowe w procesie rozwoju oprogramowania, ułatwiające zarządzanie zależnościami oraz automatyzację budowania i dystrybucji aplikacji. Oto jak pomagają one w codziennej pracy programistów i jak można użyć je do instalowania nowych bibliotek:

1. Zarządzanie zależnościami: Automatycznie zarządzają zależnościami projektu, pobierając potrzebne biblioteki i ich zależności z centralnych repozytoriów, takich jak Maven Central.
2. Automatyzacja budowania: Pozwalają na definiowanie procesów budowania projektu, w tym kompilacji, testowania i pakowania aplikacji.
3. Standardyzacja projektów: Umożliwiają tworzenie standardowych szablonów projektów, co ułatwia współpracę i utrzymanie spójności w wielu projektach.

W praktyce, w zależności od pluginu musimy utrzymywać listę pakietów wykorzystywanych przez naszą aplikacje.

• dla MVN mamy plik pom.xml
• dla Gradle mamy build.gradle
• dla npm mamy packages.json
• dla PIP mamy requirements.txt

Importowanie pakietów

Zwykle, aby zainstalować jakąś bibliotekę Open Source, wystarczy zmodyfikować kod, np. plik pom.xml, albo skorzystać z konkretnej komendy, jak npm install -g marked. Ta komenda pobierze paczkę z rejestru i automatycznie zmodyfikuje package.json.

Często, gdy programista musi przeprowadzić taką operację, kopiuje kod bezpośrednio z dokumentacji (dostępnej na stronach takich jak npmjs.com, mvnrepository.com/repos/central lub GitHub), co minimalizuje ryzyko pomyłki. Skąd więc wziąć się może zagrożenie?

Pojawia się wtedy, gdy próbujemy działać na szybko, „z ręki”, „na słuch”. Na Slacku ktoś może napisać: „wykorzystaj bibliotekę marked z npmjs”, i w efekcie możemy wpisać npm install -g markedjs. Jeśli popełnimy błąd, NPM nas o tym poinformuje, ale co, jeśli taki pakiet jednak istnieje?

Jak widzimy na screenie powyżej, na górze znajduję się zrzut z npmjs.com dla poprawnego pakietu. Pod nim natomiast – screen z podrobionego pakietu o nazwie markedjs. Nazwa pakietu, zarówno w adresie URL jak i w nagłówku strony opisana jest mniejszą czcionką niż nagłówek H1 w pliku readme.md, renderowanym na stronie (który jest identyczny co oryginał). Nawet linki do repozytorium z kodem oraz stroną domową projektu są poprawne. Może uśpić czujność, prawda?

Na szczęście popularnie wykorzystywane rejestry, w których internauci i organizacje OpenSource umieszczają artefakty w postaci obrazów dockerowych, czy bibliotek, od dawna widzą ten problem i starają się proaktywnie wychwytywać tego typu sytuacje. Dzisiaj pakiet, który przedstawiłem powyżej wygląda tak:

Pakiety, które w ten sposób są usuwane z rejestru można liczyć w dziesiątkach dziennie.

Zagrożenia, dotyczące zarządzania zależnościami

Tego typu zagrożenia mogą przyjmować 3 formy:

1. Malicious Package (Złośliwy Pakiet). Atak polegający na tworzeniu i rozpowszechnianiu pakietów zawierających złośliwy kod, podszywając się pod inne znane pakiety. Mogą być dodane do publicznych repozytoriów, jak npm, PyPI, czy Maven Central. Celem jest infekcja jak największej liczby systemów poprzez zainstalowanie takiego pakietu jako zależności w różnych projektach. Złośliwe pakiety mogą ukrywać malware, skrypty szpiegujące, ransomware, czy inne formy złośliwego oprogramowania, aktywowane po zainstalowaniu.
2. Trojan Package (Pakiet Trojański). Pakiety z pozoru bezpieczne i użyteczne, zawierające ukryty, złośliwy kod. Cel to przekonanie użytkownika do zainstalowania pakietu pod pretekstem jego użyteczności, podczas gdy w rzeczywistości służy on do szkodliwych działań.
3. Dependency Confusion (Pomyłka Zależności). Atak wykorzystujący niejednoznaczność i luki w zarządzaniu zależnościami przez systemy budowania aplikacji. Celem jest wykorzystanie błędów w konfiguracji zależności (np. niewłaściwe rozróżnienie między zależnościami wewnętrznymi a publicznymi). Atakujący rejestruje publicznie dostępny pakiet o tej samej nazwie, co używany wewnętrznie przez firmę, ale z wyższą wersją. Systemy automatycznie wybierają tę publiczną, wyższą wersję, co prowadzi do zainstalowania złośliwego kodu.

OWASP Top 10 dla CICD

Jeśli jeszcze tego nie wiesz, OWASP poza popularną listą zagrożeń dla aplikacji Internetowych od jakiegoś czasu udostępnia listę najgroźniejszych zagrożeń dla procesu CICD:

Znalazły się tutaj 2 zagrożenia CICD-SEC-2 oraz CICD-SEC-8, które pośrednio lub bezpośrednio odnoszą się do opisywanych powyżej problemów. Chcę tym jeszcze bardziej zwrócić Twoją uwagę na zagrożenia, jakie mogą wynikać z braku weryfikacji tego z czego korzysta Twoja aplikacja.

Jak się chronić przed zagrożeniami dla bibliotek?

1. Przykładaj uwagę do tego co importujesz do swojej aplikacji – jeśli kopiujesz kod, który trafia do pliku pom.xml itp., bierz go z oficjalnych źródeł
2. Zaimplementuj mechanizm weryfikacji wykorzystywanych bibliotek. Dbaj o to, by używać narzędzi, weryfikujących bezpieczeństwo zależności
3. Twórz aplikacje w bezpiecznej architekturze. W najgorszym scenariuszu, w którym uruchomiony został złośliwy pakiet – powinien mieć on jak najmniejsze pole do popisu, a cała komunikacja wychodząca powinna być domyślnie blokowana.

Grzegorz Siewruk