Potoki rozwoju oprogramowania oferują cyberprzestępcom „wolny zasięg” dostępu do chmury, on-Prem

Naukowcy twierdzą, że potoki ciągłej integracji/ciągłego rozwoju (CI/CD) mogą być najbardziej niebezpieczną potencjalną powierzchnią ataku łańcucha dostaw oprogramowania, ponieważ cyberprzestępcy zwiększają swoje zainteresowanie badaniem słabości.

Rośnie również powierzchnia ataków: potoki CI/CD są coraz częściej stałym elementem zespołów programistycznych dla przedsiębiorstw, które wykorzystują je do budowania, testowania i wdrażania kodu za pomocą zautomatyzowanych procesów. Jednak nadmierne uprawnienia, brak segmentacji sieci oraz słabe sekrety i zarządzanie poprawkami są plagą ich implementacji, oferując przestępcom możliwość narażenia ich na swobodne poruszanie się między środowiskami lokalnymi i chmurowymi.

W Black Hat USA w środę, 10 sierpnia, Iain Smart i Viktor Gazdag z firmy doradczej ds. bezpieczeństwa NCC Group wyjdą na scenę podczas „RCE-as-a-Service: wnioski wyciągnięte z 5 lat rzeczywistego kompromisu w zakresie CI/CD Pipeline”, aby omówić szereg udanych ataków w łańcuchu dostaw, które przeprowadzili w produkcyjnych potokach CI/CD dla praktycznie każdej testowanej firmy.

Grupa NCC nadzorowała kilkadziesiąt udanych kompromisów celów, od małych firm po firmy z listy Fortune 500. Oprócz błędy bezpieczeństwa, naukowcy twierdzą, że nowe nadużycia zamierzonej funkcjonalności w zautomatyzowanych potokach umożliwiły im przekształcenie potoków z prostego narzędzia programistycznego w zdalne wykonywanie kodu (RCE) jako usługę.

„Mam nadzieję, że ludzie okażą więcej miłości swoim potokom CI/CD i zastosują wszystkie lub przynajmniej jedną lub dwie rekomendacje z naszej sesji”, mówi Gazdag. „Mamy również nadzieję, że spowoduje to więcej badań nad bezpieczeństwem na ten temat”.

Tara Seals, redaktor zarządzający Dark Reading ds. wiadomości, usiadła z Viktorem Gazdagiem, konsultantem ds. bezpieczeństwa w NCC Group, aby dowiedzieć się więcej.

Pieczęcie Tary: Jakie są niektóre z najczęstszych słabych punktów bezpieczeństwa w potokach CI/CD i jak można je nadużywać?

Wiktor Gazdag: Regularnie obserwujemy trzy typowe słabości bezpieczeństwa, które wymagają większej uwagi:

1) Zakodowane dane uwierzytelniające w systemie kontroli wersji (VCS) lub zarządzaniu kontrolą źródła (SCM).

Należą do nich skrypty powłoki, pliki logowania, zakodowane na stałe dane uwierzytelniające w plikach konfiguracyjnych, które są przechowywane w tym samym miejscu co kod (nie osobno lub w aplikacjach do zarządzania tajnymi). Często znajdujemy również tokeny dostępowe do różnych środowisk chmurowych (deweloperskich, produkcyjnych) lub niektórych usług w chmurze, takich jak SNS, Database, EC2 itp.

Nadal znajdujemy również poświadczenia dostępu do infrastruktury pomocniczej lub do potoku CI/CD. Gdy atakujący uzyska dostęp do środowiska chmury, może wyliczyć swoje uprawnienia, szukać błędnych konfiguracji lub spróbować podnieść swoje uprawnienia, ponieważ są już w chmurze. Mając dostęp do potoku CI/CD, mogą zobaczyć historię kompilacji, uzyskać dostęp do artefaktów i użytych sekretów (na przykład narzędzie SAST i jego raporty o podatnościach lub tokenach dostępu do chmury) oraz w najgorszych scenariuszach, wstrzyknąć dowolny kod (backdoor, SolarWinds) do aplikacji, która będzie kompilowana, lub uzyskać pełny dostęp do środowiska produkcyjnego.

2) Nadmierne role.

Deweloperzy lub konta usług często mają powiązaną rolę ze swoimi kontami (lub mogą przyjąć taką), która ma więcej uprawnień niż jest to wymagane do wykonania wymaganej pracy.

Mogą uzyskiwać dostęp do większej liczby funkcji, takich jak konfigurowanie systemu lub sekretów w zakresie zarówno środowisk produkcyjnych, jak i programistycznych. Mogą być w stanie ominąć kontrole bezpieczeństwa, takie jak zatwierdzanie przez innych programistów, lub zmodyfikować potok i usunąć wszelkie narzędzia SAST, które pomogłyby w wyszukiwaniu luk w zabezpieczeniach.

Ponieważ potoki mogą uzyskiwać dostęp do środowisk produkcyjnych i testowych, jeśli nie ma między nimi segmentacji, mogą działać jako pomost między środowiskami, nawet między środowiskiem lokalnym a chmurą. Umożliwi to atakującemu ominięcie zapór ogniowych lub wszelkich alertów i swobodne przemieszczanie się między środowiskami, które w innym przypadku nie byłyby możliwe.

3) Brak audytu, monitorowania i ostrzegania.

Jest to najbardziej zaniedbywany obszar iw 90% przypadków stwierdziliśmy brak monitorowania i ostrzegania o wszelkich modyfikacjach konfiguracji lub zarządzaniu użytkownikami/rolami, nawet jeśli inspekcja była włączona lub włączona. Jedyną rzeczą, którą można monitorować, jest udana lub nieudana kompilacja lub kompilacja pracy.

Istnieją również bardziej powszechne problemy z bezpieczeństwem, takie jak brak segmentacji sieci, zarządzanie tajemnicami i zarządzanie poprawkami itp., ale te trzy przykłady są punktami początkowymi ataków, które są wymagane do skrócenia średniego czasu wykrywania naruszeń lub są ważne, aby ograniczyć promień wybuchu ataku.

T: Czy masz jakieś konkretne przykłady z życia wzięte lub konkretne scenariusze, na które możesz wskazać?

bdb: Niektóre ataki w wiadomościach związane z atakami CI/CD lub potoku obejmują:

• Atak CCleaner, Marzec 2018
• Homebrew, sierpień 2018
• Asus ShadowMłot, Marzec 2019
• Naruszenie CircleCI przez osobę trzecią, wrzesień 2019 r.
• SolarWinds, Grudzień 2020
• Skrypt do przesyłania bash Codecov, kwiecień 2021 r.
• TravisCI nieautoryzowany dostęp do tajemnic, wrzesień 2021

T: Dlaczego słabości w zautomatyzowanych potokach są problematyczne? Jak scharakteryzowałbyś ryzyko dla firm?

bdb: W procesach potokowych mogą być używane setki narzędzi i dlatego ogromna wiedza, którą ktoś musi znać, jest ogromna. Ponadto potoki mają dostęp sieciowy do wielu środowisk i wiele poświadczeń dla różnych narzędzi i środowisk. Uzyskanie dostępu do potoków jest jak uzyskanie przepustki na bezpłatny przejazd, która umożliwia atakującym dostęp do dowolnego innego narzędzia lub środowiska związanego z potokiem.

T: Na jakie skutki mogą ucierpieć firmy, jeśli przeciwnik skutecznie odwróci potok CI/CD?

bdb: Wyniki ataku mogą obejmować kradzież kodu źródłowego lub danych intelektualnych, backdoora aplikacji, która jest wdrażana dla tysięcy klientów (takich jak SolarWinds), uzyskanie dostępu (i swobodne poruszanie się między) wieloma środowiskami, takimi jak rozwój i produkcja, zarówno lokalnie, jak i w chmura lub jedno i drugie.

T: Jak wyrafinowani muszą być przeciwnicy, aby złamać potok?

bdb: To, co prezentujemy w Black Hat, to nie są luki dnia zerowego (mimo że znalazłem kilka luk w różnych narzędziach) ani żadne nowe techniki. Przestępcy mogą atakować programistów za pomocą phishingu (przechwytywania sesji, obejścia uwierzytelniania wieloskładnikowego, kradzieży danych uwierzytelniających) lub bezpośrednio potoku CI/CD, jeśli nie są one chronione i są dostępne w Internecie.

Grupa NCC przeprowadziła nawet oceny bezpieczeństwa, podczas których początkowo testowaliśmy aplikacje internetowe. Odkryliśmy, że potoki CI/CD są rzadko rejestrowane i monitorowane za pomocą alertów, innych niż zadanie tworzenia/kompilowania oprogramowania, więc przestępcy nie muszą być tak ostrożni lub wyrafinowani, aby złamać potok.

T: Jak powszechne są tego typu ataki i jak szeroką powierzchnię ataku reprezentują potoki CI/CD?

bdb: Jak wspomniano, w wiadomościach znajduje się kilka przykładów ataków w świecie rzeczywistym. I nadal możesz znaleźć na przykład Instancje Jenkinsa z Shodan w Internecie. Dzięki SaaS przestępcy mogą wyliczać i próbować wymuszać brute-force hasła, aby uzyskać dostęp, ponieważ nie mają domyślnie włączonej funkcji uwierzytelniania wieloskładnikowego ani ograniczeń IP i są dostępni w Internecie.

W przypadku pracy zdalnej potoki są jeszcze trudniejsze do zabezpieczenia, ponieważ programiści chcą mieć dostęp z dowolnego miejsca i o każdej porze, a ograniczenia IP nie są już konieczne, ponieważ firmy kierują się w stronę sieci o zerowym zaufaniu lub mają zmieniające się lokalizacje sieci.

Potoki zwykle mają dostęp sieciowy do wielu środowisk (czego nie powinny) i mają dostęp do wielu poświadczeń dla różnych narzędzi i środowisk. Mogą pełnić rolę pomostu między systemami lokalnymi i chmurowymi lub produkcyjnymi i testowymi. Może to być bardzo szeroka powierzchnia ataku, a ataki mogą pochodzić z wielu miejsc, nawet tych, które nie mają nic wspólnego z samym rurociągiem. W Black Hat przedstawiamy dwa scenariusze, w których początkowo rozpoczęliśmy testowanie aplikacji internetowych.

TS: Dlaczego potoki CI/CD pozostają ślepym punktem bezpieczeństwa dla firm?

bdb: Głównie z powodu braku czasu, czasem ludzi, a w niektórych przypadkach braku wiedzy. Potoki CI/CD są często tworzone przez programistów lub zespoły IT w ograniczonym czasie i z naciskiem na szybkość i dostarczanie, lub programiści są po prostu przeciążeni pracą.

Potoki CI/CD mogą być bardzo lub bardzo złożone i mogą zawierać setki narzędzi, wchodzić w interakcje z wieloma środowiskami i sekretami oraz być używane przez wiele osób. Niektórzy ludzie stworzyli nawet tabelę okresową przedstawiającą narzędzia, które mogą być używane w potoku.

Jeśli firma przydzieli czas na stworzenie modelu zagrożeń dla używanego rurociągu i środowisk wspierających, zobaczy połączenie między środowiskami, granicami i tajemnicami oraz miejscami ataków. Tworzenie i ciągłe aktualizowanie modelu zagrożeń powinno być wykonane, a to wymaga czasu.

T: Jakie są najlepsze praktyki wzmocnienia bezpieczeństwa rurociągów?

bdb: Zastosuj segmentację sieci, użyj zasady najmniejszych uprawnień do tworzenia ról, ogranicz zakres tajemnicy w zarządzaniu tajemnicami, często stosuj aktualizacje zabezpieczeń, weryfikuj artefakty oraz monitoruj i ostrzegaj o zmianach konfiguracji.

T: Czy są jeszcze jakieś myśli, którymi chciałbyś się podzielić?

bdb: Chociaż potoki CI/CD natywne dla chmury lub oparte na chmurze są prostsze, nadal widzieliśmy te same lub podobne problemy, takie jak zbyt liberalne role, brak segmentacji, tajemnice o nadmiernym zakresie i brak alertów. Firmy muszą pamiętać, że mają również obowiązki w zakresie bezpieczeństwa w chmurze.