Kaspersky Hybrid Cloud Security
W ostatnim miesiącu strony internetowe o tematyce IT informowały, że RubyGems, oficjalny kanał dystrybucji bibliotek dla języka programowania Ruby, został zatruty. Atakujący przesłał fałszywe pakiety zawierające szkodliwy skrypt, zatem wszyscy programiści, którzy użyli tego kodu w swoich projektach, niechcący zainfekowali komputery użytkowników szkodliwym oprogramowaniem, które zmieniało adresy portfeli kryptowalut.
Oczywiście nie był to pierwszy atak na łańcuch dostaw z wykorzystaniem publicznego repozytorium. Jednak taki scenariusz wydaje się zdobywać popularność, co nie jest zaskoczeniem: jeden pomyślny atak może zhakować dziesiątki lub setki tysięcy użytkowników. Wszystko zależy od popularności oprogramowania przygotowanego w oparciu o kod z zatrutego repozytorium.
W jaki sposób szkodliwe pakiety dostają się do repozytoriów?
W przypadku RubyGems cyberprzestępca utworzył wiele projektów w repozytoriach, których nazwy nawiązywały do popularnych legalnych pakietów. Technika ta jest znana jako porywanie URL i polega na niepoprawnym wprowadzeniu przez programistów nazwy pakietu i pobraniu tego szkodliwego przez pomyłkę lub uzyskaniu listy nazw pakietów w wyszukiwarce, bez informacji, który z nich jest oryginalny. Taktyka ta jest ogólnie uznawana za zatruwanie cyberzasobów i jest stosowana w atakach za pośrednictwem repozytorium Python Package Index oraz w przesyłaniu fałszywych obrazów do Docker Hub.
W incydencie związanym z portfelem kryptowaluty Copay atakujący użyli biblioteki, której repozytorium zostało umieszczone w serwisie GitHub. Jej autor przestał się nią zajmować i oddał uprawnienia administratora, doprowadzając do zhakowania tej popularnej biblioteki, której wielu programistów użyło w swoich produktach.
Czasami cyberprzestępcy potrafią użyć konta legalnego programisty bez jego wiedzy i zastąpić prawdziwe pakiety fałszywymi. Taka sytuacja miała miejsce w przypadku narzędzia ESLint, którego biblioteki zostały umieszczone w bazie internetowej npm (Node Package Manager).
Zhakowanie środowiska kompilacji
Dla hakerów trudniących się atakami APT potencjalnie interesującym celem są również firmy tworzące oprogramowanie. Przypadki atakowania przez nich klientów takich firm przyciągają co jakiś czas uwagę ekspertów ds. bezpieczeństwa:
- W sierpniu 2017 roku część aktorów działających w obszarze APT umieściła w programie utworzonym przez NetSarang szkodliwe moduły. Według badaczy atakujący mogli zhakować serwery z wersjami oprogramowania.
- W 2018 roku cyberprzestępcy zainfekowali serwer z wersjami aplikacji Piriform, po czym zainfekowali podczas kompilacji kod źródłowy jednej z wersji programu CCleaner.
- W 2019 roku nasi eksperci zidentyfikowali kampanię ShadowHammer APT, podczas której przestępcy osadzili backdoora w oprogramowaniu kilku firm. Według wyników badania atakujący mieli dostęp do kodu źródłowego lub wprowadzili szkodliwy kod na etapie kompilacji.
Zhakowanie środowiska kompilacji nie tylko umożliwia „infekcję” produktu finalnego, ale także może również skutkować dystrybucją zainfekowanego szkodliwego programu zawierającego legalny podpis cyfrowy od zaufanego programisty. Z tego względu proces rozwoju wymaga lepszej ochrony przed interwencją z zewnątrz.
Źródło problemu
W rzeczywistości zagrożenie leży nie w używaniu publicznych repozytoriów, lecz w niepoprawnym podejściu do produkcji oprogramowania — metodologii DevOps. Jest ona zestawem praktyk, których celem jest skracanie cyklu rozwoju programu. Rozwój zawsze musi uwzględniać zarówno bezpieczeństwo, jak i użyteczność. Aby być konkurencyjnym na rynku, programiści muszą dziś udostępniać nowe wersje programów tak szybko, jak to możliwe, jednak zwiększanie użyteczności zwykle oznacza równolegle spadek jakości produktu lub wydłużenie czasu wprowadzenia go na rynek. Z tego względu programiści zawsze minimalizują lub całkowicie pomijają interwencję personelu odpowiedzialnego za bezpieczeństwo w swoich działaniach.
W rezultacie dział bezpieczeństwa informacji praktycznie nie ma kontroli nad ta częścią infrastruktury. Jednak rozwój, kwestie IT i bezpieczeństwo to elementy wspólne składające się na dobry jakościowo, bezpieczny i dostarczony na czas produkt. Aktualizacja nie jest dobra, jeśli zawiera backdoora lub moduł szpiegowski; dlatego według nas branża ta musi zacząć stosować metodologię DevSecOps.
DevSecOps to próba wyeliminowania luki między bezpieczeństwem a DevOps poprzez wprowadzenie kultury cyberbezpieczeństwa i praktyczne wdrożenie kontroli na wszystkich etapach procesu tworzenia oprogramowania, bez uszczerbku na elastyczności i szybkości działania. Firma Kaspersky ma w swojej ofercie stosowne narzędzie, które zostało przygotowane z myślą o technicznej stronie tego procesu.
Nasze rozwiązanie
Na rynku brakuje narzędzi do zabezpieczania samego procesu rozwoju oprogramowania. Z tego względu, aktualizując nasz Kaspersky Hybrid Cloud Security uwzględniliśmy potrzeby programistów i wyposażyliśmy komponenty tego rozwiązania w technologie umożliwiające integrację narzędzi bezpieczeństwa z procesem rozwoju, bez obniżania wydajności. Technologie te służą głównie do skanowania repozytoriów, obrazów i kontenerów — których zadaniem jest zapobieganie atakom na łańcuch dostaw.
Rozwiązanie Kaspersky Hybrid Cloud Security zawiera interfejsy zapewniające współdziałanie platform ciągłej integracji (CI) i ciągłego dostarczania (CD), takich jak TeamCity czy Jenkins. Nasze rozwiązanie może zostać zintegrowane z procesem rozwoju poprzez wiersz poleceń lub interfejs programowalny aplikacji.
To oczywiście nie jedyna nowość w naszym rozwiązaniu. Więcej informacji na temat produktu Kaspersky Hybrid Cloud Security i zabezpieczania procesów DevOps znajduje się na stronie produktu.
Porady