Stan zabezpieczeń środowiska DevOps

3 min

Wraz ze wzrostem cyberataków na systemy zarządzania kodem źródłowym i potokami ciągłej integracji/ciągłego dostarczania zabezpieczanie platform DevOps przed różnymi zagrożeniami zidentyfikowanymi w macierzy zagrożeń DevOps ma kluczowe znaczenie. Takie cyberataki mogą umożliwić iniekcję kodu, eskalację uprawnień i eksfiltrację danych, co może potencjalnie prowadzić do rozległego wpływu.

Zarządzanie stanem metodyki DevOps to funkcja w Microsoft Defender dla Chmury, która:

Zapewnia wgląd w stan zabezpieczeń całego cyklu życia łańcucha dostaw oprogramowania.
Używa zaawansowanych skanerów do dogłębnych ocen.
Obejmuje różne zasoby, od organizacji, potoków i repozytoriów.
Umożliwia klientom zmniejszenie obszaru ataków przez ujawnienie podanych zaleceń i działanie na ich podstawie.

Skanery DevOps

Aby zapewnić wyniki, zarządzanie stanem devOps używa skanerów DevOps do identyfikowania słabych stron w zarządzaniu kodem źródłowym i ciągłej integracji/ciągłego dostarczania potoków, uruchamiając kontrole konfiguracji zabezpieczeń i kontroli dostępu.

Skanery usługi Azure DevOps i GitHub są używane wewnętrznie w firmie Microsoft do identyfikowania zagrożeń związanych z zasobami DevOps, zmniejszania obszaru ataków i wzmacniania firmowych systemów DevOps.

Po nawiązaniu połączenia środowiska DevOps Defender dla Chmury automatycznie konfiguruje te skanery w celu przeprowadzania cyklicznych skanowań co 24 godziny w wielu zasobach DevOps, w tym:

Kompilacje
Zabezpieczanie plików
Grupy zmiennych
Połączenia z usługami
Organizacje
Repozytoria

Zmniejszenie ryzyka macierzy zagrożeń metodyki DevOps

Zarządzanie stanem metodyki DevOps ułatwia organizacjom odnajdywanie i korygowanie szkodliwych błędów konfiguracji na platformie DevOps. Prowadzi to do odpornego, zerowego zaufania środowiska DevOps, które zostało wzmocnione przed szeregiem zagrożeń zdefiniowanych w macierzy zagrożeń DevOps. Podstawowe mechanizmy zarządzania stanem obejmują:

Ograniczony dostęp do wpisów tajnych: zminimalizuj narażenie poufnych informacji i zmniejsz ryzyko nieautoryzowanego dostępu, wycieków danych i penetracji, zapewniając, że każdy potok ma dostęp tylko do wpisów tajnych niezbędnych do jego funkcji.
Ograniczenie własnych modułów uruchamiających i wysokich uprawnień: zapobiegaj nieautoryzowanym wykonywaniem i potencjalnymi eskalacjami, unikając własnych modułów uruchamiających i zapewniając, że uprawnienia potoku są domyślnie przeznaczone tylko do odczytu.
Rozszerzona ochrona gałęzi: zachowaj integralność kodu przez wymuszanie reguł ochrony gałęzi i zapobieganie wstrzyknięciu złośliwego kodu.
Zoptymalizowane uprawnienia i bezpieczne repozytoria: zmniejsza ryzyko nieautoryzowanego dostępu, modyfikacji przez śledzenie minimalnych uprawnień podstawowych i włączanie ochrony wypychanej wpisów tajnych dla repozytoriów.

Macierz zagrożeń metodyki DevOps

Naszym celem opracowania macierzy zagrożeń dla metodyki DevOps jest zbudowanie kompleksowej bazy wiedzy, za pomocą których usługa Defender może śledzić i tworzyć zabezpieczenia przed odpowiednimi technikami ataków. Korzystając ze struktury MITRE ATT&CK jako podstawy, zebraliśmy techniki i wektory ataków skojarzone ze środowiskami DevOps i utworzyliśmy macierz dedykowaną metodom ataków DevOps.

Warto zauważyć, że taktyka w tej macierzy musi być przyjrzena z perspektywy metodyki DevOps. Na przykład techniki wykonywania na maszynie wirtualnej z systemem operacyjnym Windows lub Linux różnią się od wykonywania w potoku DevOps. W przypadku systemu Linux wykonanie oznacza uruchamianie kodu w systemie operacyjnym. Gdy mówimy o środowiskach DevOps, oznacza to uruchamianie kodu w potoku lub zasobach DevOps. Oprócz używania tej macierzy zagrożeń do kategoryzowania ataków i odpowiednich metod obrony, obrońcy mogą współpracować z czerwonymi zespołami w celu ciągłego testowania założeń i znajdowania nowych potencjalnych technik ataku.

MITRE ATT&CK Zdefiniowane

Macierz MITRE ATT&CK jest publicznie dostępnym baza wiedzy do zrozumienia różnych taktyk i technik stosowanych przez osoby atakujące podczas cyberataku.

Baza wiedzy jest zorganizowana w kilka kategorii: przed atakiem, dostępem początkowym, wykonywaniem, trwałością, eskalacją uprawnień, uchylaniem się od obrony, dostępem poświadczeń, odnajdywaniem, przenoszeniem bocznym, kolekcją, eksfiltracją i kontrolą.

Taktyka (T) reprezentuje "dlaczego" techniki ATT&CK lub techniki podrzędnej. Jest to cel taktyczny przeciwnika: powód wykonywania akcji. Na przykład atakujący może chcieć uzyskać dostęp do poświadczeń.

Techniki (T) reprezentują "jak" przeciwnik osiąga cel taktyczny, wykonując akcję. Na przykład atakujący może zrzucić poświadczenia w celu uzyskania dostępu do poświadczeń.

Common Knowledge (CK) w ATT&CK oznacza wspólną wiedzę, zasadniczo udokumentowany modus operandi taktyki i technik wykonywanych przez przeciwników.

Dostęp początkowy

Początkowa taktyka dostępu odnosi się do technik, których osoba atakująca może użyć do uzyskania dostępu do zasobów Metodyki DevOps — repozytoriów, potoków i zależności. Następujące techniki mogą być warunkiem wstępnym dla następnych kroków:

Uwierzytelnianie za pomocą funkcji zarządzania kodem źródłowym (SCM) — dostęp za pomocą metody uwierzytelniania do zarządzania kodem źródłowym organizacji. Może to być osobisty token dostępu (PAT), klucz SSH lub inne dozwolone poświadczenia uwierzytelniania. Przykładem metody, za pomocą których osoba atakująca może osiągnąć tę technikę, jest użycie ataku wyłudzania informacji w organizacji.

Uwierzytelnianie za pomocą ciągłej integracji i ciągłego dostarczania (CD) — podobnie jak w przypadku uwierzytelniania SCM osoba atakująca może wykorzystać uwierzytelnianie do usługi ciągłej integracji/ciągłego wdrażania w celu ataku na metodyki DevOps organizacji.

Repozytoria publiczne organizacji — dostęp do publicznych repozytoriów organizacji skonfigurowanych za pomocą funkcji ciągłej integracji/ciągłego wdrażania. W zależności od konfiguracji organizacji te repozytoria mogą mieć możliwość wyzwolenia uruchomienia potoku po utworzeniu żądania ściągnięcia.

Naruszenie zabezpieczeń punktu końcowego — przy użyciu istniejącego naruszenia zabezpieczeń osoba atakująca może wykorzystać stację roboczą dewelopera, a tym samym uzyskać dostęp do menedżera ZCM, rejestru organizacji lub dowolnego innego zasobu, do którego ma dostęp deweloper.

Skonfigurowane elementy webhook — gdy organizacja ma skonfigurowany element webhook, osoba atakująca może użyć jej jako początkowej metody dostępu do sieci organizacji przy użyciu samego programu SCM w celu wyzwolenia żądań do tej sieci. Może to przyznać osobie atakującej dostęp do usług, które nie mają być uwidocznione publicznie lub są uruchomione stare i podatne na zagrożenia wersje oprogramowania w sieci prywatnej.

Wykonanie

Taktyka wykonywania odnosi się do technik, które mogą być używane przez złośliwego przeciwnika w celu uzyskania dostępu do wykonywania zasobów potoku — samego potoku lub zasobów wdrażania. Niektóre techniki w tej sekcji zawierają wyjaśnienia dotyczące różnych sposobów ich wykonania lub metod, które nazywamy technikami podrzędnymi:

Wykonywanie zatrutego potoku (PPE) — odnosi się do techniki, w której osoba atakująca może wstrzyknąć kod do repozytorium organizacji, co powoduje wykonanie kodu w systemie ciągłej integracji/ciągłego wdrażania repozytorium. Istnieją różne techniki podrzędne służące do wykonywania kodu:

Bezpośrednie środki ochrony danych (d-PPE) — przypadki, w których osoba atakująca może bezpośrednio zmodyfikować plik konfiguracji wewnątrz repozytorium. Ponieważ potok jest wyzwalany przez nowe żądanie ściągnięcia i uruchamiany zgodnie z plikiem konfiguracji , osoba atakująca może wstrzyknąć złośliwe polecenia do pliku konfiguracji, a te polecenia są wykonywane w potoku.
Pośrednie środki ochrony danych (i-PPE) — przypadki, w których osoba atakująca nie może bezpośrednio zmienić plików konfiguracji lub że te zmiany nie są uwzględniane po wyzwoleniu. W takich przypadkach osoba atakująca może zainfekować skrypty używane przez potok w celu uruchomienia kodu, na przykład tworzenia plików, skryptów testowych, skryptów kompilacji itp.
Publiczne środki ochrony danych — przypadki, w których potok jest wyzwalany przez projekt open source. W takich przypadkach osoba atakująca może użyć d-PPE lub i-PPE w repozytorium publicznym w celu zainfekowania potoku.

Manipulowanie zależnościami — odnosi się do techniki, w której osoba atakująca może wykonać kod w środowisku DevOps lub środowisku produkcyjnym przez wstrzyknięcie złośliwego kodu do zależności repozytorium. W związku z tym po pobraniu zależności jest wykonywany złośliwy kod. Niektóre techniki podrzędne, których można użyć do wykonania kodu, obejmują:

Zamieszanie zależności publicznych — technika, w której przeciwnik publikuje publiczne złośliwe pakiety o takiej samej nazwie jak pakiety prywatne. W takim przypadku, ponieważ wyszukiwanie pakietów w mechanizmach kontroli pakietów zwykle najpierw wygląda w publicznych rejestrach, pobierany jest złośliwy pakiet.
Przejęcie pakietu publicznego ("repo-jacking") — przejęcie pakietu publicznego przez przejęcie kontroli nad kontem osoby odpowiedzialnej za utrzymanie, na przykład przez wykorzystanie funkcji zmiany nazwy użytkownika w usłudze GitHub.
Typosquatting — publikowanie złośliwych pakietów o podobnych nazwach do znanych pakietów publicznych. W ten sposób osoba atakująca może mylić użytkowników w celu pobrania złośliwego pakietu zamiast żądanego.

Naruszenie zabezpieczeń zasobów devOps — potoki są podstawowym zestawem zasobów obliczeniowych wykonujących agentów ciągłej integracji/ciągłego wdrażania, a także innym oprogramowaniem. Osoba atakująca może kierować te zasoby, wykorzystując lukę w zabezpieczeniach systemu operacyjnego, kod agenta, inne oprogramowanie zainstalowane na maszynach wirtualnych lub inne urządzenia w sieci w celu uzyskania dostępu do potoku.

Kontrola wspólnego rejestru — osoba atakująca może przejąć kontrolę nad rejestrem używanym przez organizację, co skutkuje złośliwymi obrazami lub pakietami wykonywanymi przez maszyny wirtualne potoku lub produkcyjne maszyny wirtualne.

Trwałość

Taktyka trwałości składa się z różnych technik, których osoba atakująca może użyć do utrzymania dostępu do środowiska ofiar:

Zmiany w repozytorium — przeciwnicy mogą używać automatycznych tokenów z wewnątrz potoku, aby uzyskać dostęp do repozytorium i wypchnąć kod (przy założeniu, że token automatyczny ma wystarczające uprawnienia, aby to zrobić). Mogą one osiągnąć trwałość w ten sposób przy użyciu kilku technik podrzędnych:

Zmień/dodaj skrypty w kodzie — możemy zmienić niektóre skrypty inicjowania/dodać nowe skrypty, więc pobierają backdoor/starter dla osoby atakującej, więc za każdym razem, gdy potok wykonuje te skrypty, kod osoby atakującej również zostanie wykonany.
Zmiana konfiguracji potoku — możemy dodać nowe kroki w potoku, aby pobrać skrypt kontrolowany przez osobę atakującą do potoku przed kontynuowaniem procesu kompilacji.
Zmień konfigurację lokalizacji zależności — aby użyć pakietów kontrolowanych przez osobę atakującą.

Wstrzykiwanie w artefaktach — niektóre środowiska ciągłej integracji mają funkcje tworzenia artefaktów, które mają być współużytkowane między różnymi wykonaniami potoku. Na przykład w usłudze GitHub możemy przechowywać artefakty i pobierać je przy użyciu akcji GitHub z konfiguracji potoku.

Modyfikowanie obrazów w rejestrze — w przypadkach, gdy potoki mają uprawnienia dostępu do rejestru obrazów (na przykład do zapisywania obrazów w rejestrze po zakończeniu kompilacji), osoba atakująca może zmodyfikować i zasiąć złośliwe obrazy w rejestrze, co będzie nadal wykonywane przez kontenery użytkownika.

Tworzenie poświadczeń usługi — złośliwy przeciwnik może wykorzystać dostęp, który już ma w środowisku, i utworzyć nowe poświadczenia do użycia w przypadku utraty początkowej metody dostępu. Można to zrobić, tworząc token dostępu do programu SCM, do samej aplikacji, do zasobów w chmurze i nie tylko.

Eskalacja uprawnień

Techniki eskalacji uprawnień są używane przez osobę atakującą w celu podniesienia uprawnień w środowisku ofiary, uzyskując wyższe uprawnienia dla już naruszonych zasobów:

Wpisy tajne w repozytoriach prywatnych — wykorzystując już początkową metodę dostępu, osoba atakująca może skanować prywatne repozytoria pod kątem ukrytych wpisów tajnych. Prawdopodobieństwo znalezienia ukrytych wpisów tajnych w prywatnym repozytorium jest wyższe niż w repozytorium publicznym, ponieważ z punktu widzenia dewelopera jest to niedostępne spoza organizacji.

Zatwierdzanie/wypychanie do chronionych gałęzi — potok ma dostęp do repozytorium, które można skonfigurować z dostępem permissywnym, co może umożliwić wypychanie kodu bezpośrednio do chronionych gałęzi, co umożliwia przeciwnikowi wstrzykiwanie kodu bezpośrednio do ważnych gałęzi bez interwencji zespołu.

Certyfikaty i tożsamości z usług metadanych — gdy osoba atakująca jest uruchomiona w potokach hostowanych w chmurze, osoba atakująca może uzyskać dostęp do usług metadanych z wewnątrz potoku i wyodrębnić certyfikaty (wymaga wysokich uprawnień) i tożsamości z tych usług.

Dostęp poświadczeń

Techniki dostępu do poświadczeń są używane przez osobę atakującą do kradzieży poświadczeń:

Poświadczenia użytkownika — w przypadkach, gdy klient wymaga dostępu do usług zewnętrznych z potoku ciągłej integracji (na przykład zewnętrznej bazy danych), te poświadczenia znajdują się wewnątrz potoku (mogą być ustawiane przez wpisy tajne ciągłej integracji, zmienne środowiskowe itp.) i mogą być dostępne dla przeciwnika.

Poświadczenia usługi — istnieją przypadki, w których osoba atakująca może znaleźć poświadczenia usługi, takie jak nazwy główne usługi (SPN), tokeny sygnatury dostępu współdzielonego (SAS) i nie tylko, co może umożliwić dostęp do innych usług bezpośrednio z potoku.

Ruch boczny

Taktyka ruchu bocznego odnosi się do technik używanych przez osoby atakujące do przechodzenia przez różne zasoby. W środowiskach ciągłej integracji/ciągłego wdrażania może się to odwoływać do przenoszenia do zasobów wdrażania, do tworzenia artefaktów i rejestrów lub do nowych obiektów docelowych.

Naruszenie artefaktów kompilacji — podobnie jak w przypadku innych ataków łańcucha dostaw, gdy osoba atakująca ma kontrolę nad potokami ciągłej integracji, może zakłócać artefakty kompilacji. W ten sposób można wstrzyknąć złośliwy kod do materiałów konstrukcyjnych przed rozpoczęciem tworzenia, dlatego wstrzyknięcie złośliwych funkcji do artefaktów kompilacji.

Iniekcja rejestru — jeśli potok jest skonfigurowany z rejestrem artefaktów kompilacji, osoba atakująca może zainfekować rejestr złośliwymi obrazami, które później zostaną pobrane i wykonane przez kontenery przy użyciu tego rejestru.

Rozłożenie na zasoby wdrażania — jeśli potok jest skonfigurowany z dostępem do zasobów wdrażania, osoba atakująca ma taki sam dostęp do tych zasobów, aby umożliwić osobie atakującej rozprzestrzenianie się. Może to spowodować wykonanie kodu, eksfiltrację danych i nie tylko w zależności od uprawnień przyznanych potokom.

Uchylanie się od obrony

Techniki uchylania się od obrony mogą być używane przez osoby atakujące do pomijania obrony używanych w środowisku DevOps i umożliwiają kontynuowanie ataków pod radarem:

Manipulowanie dziennikami usług — dzienniki usługi umożliwiają usłudze Defender wykrywanie ataków w ich środowisku. Osoba atakująca działająca w środowisku (na przykład w potokach kompilacji) może zmienić dzienniki, aby uniemożliwić usłudze Defender obserwowanie ataku. Jest to podobne do zmiany dzienników historii na maszynie z systemem Linux przez osobę atakującą, co uniemożliwia obserwatorowi wyświetlanie poleceń wykonywanych przez osobę atakującą.

Manipulowanie kompilacją — jeśli osoba atakująca nie chce pozostawić żadnych śladów w usłudze SCM, osoba atakująca może zmienić proces kompilacji w celu wstrzyknięcia złośliwego kodu. Można to zrobić na kilka sposobów:

Zmiana kodu na bieżąco — zmiana kodu bezpośrednio przed rozpoczęciem procesu kompilacji bez zmiany go w repozytorium i pozostawienia w nim śladów.
Kompilator naruszony — zmiana kompilatora w środowisku kompilacji w celu wprowadzenia złośliwego kodu bez opuszczania śladów przed rozpoczęciem tego procesu.

Ponowne konfigurowanie ochrony gałęzi — narzędzia ochrony gałęzi umożliwiają organizacji konfigurowanie kroków przed zatwierdzeniem żądania ściągnięcia/zatwierdzenia w gałęzi. Gdy osoba atakująca ma uprawnienia administratora, może zmienić te konfiguracje i wprowadzić kod do gałęzi bez żadnej interwencji użytkownika.

Wpływ

Taktyka wpływu odnosi się do technik, których osoba atakująca może użyć do wykorzystania dostępu do zasobów ciągłej integracji/ciągłego wdrażania do złośliwych celów, a nie jako kolejny krok w ataku, ponieważ te techniki mogą być hałaśliwe i łatwe do wykrycia:

Rozproszona odmowa usługi (DDoS) — atakujący może użyć zasobów obliczeniowych, do których uzyskali dostęp w celu wykonania rozproszonych ataków typu "odmowa usług" (DDoS) na obiekty docelowe zewnętrzne.

Górnictwo kryptowalut — zasoby obliczeniowe mogą być używane do wyszukiwania kryptograficznego kontrolowanego przez przeciwnika.

Lokalna odmowa usługi (DoS) — gdy osoba atakująca działa w potokach ciągłej integracji, atakujący może wykonać atak typu "odmowa usługi" z tych potoków do klientów, zamykając agentów, ponownie uruchamiając lub przeciążając maszyny wirtualne.

Usuwanie zasobów — osoba atakująca mająca dostęp do zasobów (zasoby w chmurze, repozytoria itp.) może trwale usunąć zasoby w celu uzyskania odmowy usług.

Wyprowadzanie

Taktyka eksfiltracji odnosi się do różnych technik, które mogą być używane przez osobę atakującą do eksfiltracji poufnych danych ze środowiska ofiar:

Klonowanie repozytoriów prywatnych — gdy osoby atakujące mają dostęp do potoków ciągłej integracji, uzyskują również dostęp do repozytoriów prywatnych (na przykład GITHUB_TOKEN mogą być używane w usłudze GitHub) i w związku z tym mogą klonować kod i uzyskiwać do nich dostęp, uzyskując dostęp do prywatnego adresu IP.

Dzienniki potoku — atakujący może uzyskać dostęp do dzienników wykonywania potoku, wyświetlić historię dostępu, kroki kompilacji itp. Te dzienniki mogą zawierać poufne informacje o kompilacji, wdrożeniu, a w niektórych przypadkach nawet poświadczenia usług, kontach użytkowników i nie tylko.

Eksfiltruj dane z zasobów produkcyjnych — w przypadkach, w których potoki mogą uzyskiwać dostęp do zasobów produkcyjnych, osoby atakujące będą również mieć dostęp do tych zasobów. W związku z tym mogą nadużywać tego dostępu do eksfiltracji danych produkcyjnych.

Zalecenia dotyczące zarządzania stanem metodyki DevOps

Gdy skanery DevOps odkrywają odchylenia od najlepszych rozwiązań w zakresie zabezpieczeń w systemach zarządzania kodem źródłowym i potokach ciągłej integracji/ciągłego dostarczania, Defender dla Chmury generuje dokładne i możliwe do działania zalecenia. Te zalecenia mają następujące korzyści:

Ulepszona widoczność: uzyskiwanie kompleksowego wglądu w stan zabezpieczeń środowisk DevOps, zapewniając dobrze zaokrąglone zrozumienie wszelkich istniejących luk w zabezpieczeniach. Zidentyfikuj brakujące reguły ochrony gałęzi, zagrożenia eskalacji uprawnień i niezabezpieczone połączenia, aby zapobiec atakom.
Akcja oparta na priorytetach: najpierw filtruj wyniki według ważności, aby efektywniej wydać zasoby i wysiłki przez rozwiązanie najbardziej krytycznych luk w zabezpieczeniach.
Zmniejszenie obszaru podatnego na ataki: rozwiązanie wyróżnionych luk w zabezpieczeniach w celu znacznego zminimalizowania narażonych powierzchni ataków, co zwiększa ochronę przed potencjalnymi zagrożeniami.
Powiadomienia w czasie rzeczywistym: możliwość integracji z automatyzacjami przepływu pracy w celu otrzymywania natychmiastowych alertów w przypadku zmiany bezpiecznych konfiguracji, co pozwala na podejmowanie monitów i zapewnienie stałej zgodności z protokołami zabezpieczeń.