Co może pójść nie tak z CI/CD pipelines?

Ciągła integracja i ciągłe dostarczanie (CI/CD) pipelines stanowią fundament każdej organizacji zajmującej się oprogramowaniem, która tworzy oprogramowanie w „nowoczesny” sposób. Automatyzacja daje ogromną moc, ale większość programistów nie dostrzega odpowiedzialności, jaka się z nią wiąże.

Deweloper: Tak, bierzemy CI/CD bezpieczeństwo poważnie i mieć silną kontrolę nad osobami odpowiedzialnymi za utrzymanie kodu, przejrzyj commits przed połączeniami; zadania i pipelinesą utrzymywane przez kadrę kierowniczą, która dba o to, aby nie wyciekły żadne tajemnice pipelines. A narzędzie zostało zainstalowane przez personel, który się na tym zna. Co może pójść nie tak?

Szanowny deweloperze, CI/CD Systemy są złożone. Ich szeroki obszar ataku przyciągał wrogich graczy. Lepiej być ostrożnym i nigdy nie być zbyt pewnym siebie.

Domyślna konfiguracja jest czasami zachowywana i staje się najlepszym sprzymierzeńcem hakerów. Krytyczne błędy mogą występować w CI/CD pipeline źródeł, w konfiguracji systemu lub wokół procesu i kontekstu pipeline i jak jest uruchamiany.

W tym wpisie wcielimy się w rolę złych aktorów. Wyobraźmy sobie, że czytamy rozważania M3M3N70 (Memento Mori?) i Wściekłość bagienna gdzieś w ciemnej sieci, prawdopodobnie w języku nie-zachodnim, ale nie przegap tego, że zło rozprzestrzenia się na cały świat.

 

Dawniej było tak łatwo...

M3M3N70:Wracając do dobrych starych czasów, nasz biznes był taki prosty… Zero-day'e były łatwym celem, aplikacje były szeroko otwarte i zawierały łatwe do wykorzystania luki w zabezpieczeniach, a my mogliśmy błyskawicznie się poruszać.

Wściekłość bagienna: Kurwa! Jeszcze kilka szalonych osób się tu znalazło, ale sytuacja się zmieniła. Wielkie firmy włożyły mnóstwo wysiłku w to całe AppSec.

M3M3N70: Tak. Ale nowymi głupcami są deweloperzy. Dla nas łatwiej było sięgnąć po narzędzia, których używają ci ludzie. Zwłaszcza CI to prawdziwa kopalnia złota! Tokeny dostępu do chmury, SCM dane uwierzytelniające, hasła do baz danych produkcyjnych, prywatne klucze SSH, dane uwierzytelniające innych użytkowników CI… Przejście od nudnych kwestii programistycznych do konkretów było raczej trywialne.

Automatyzacja tworzenia, testowania i wdrażania oprogramowania z CI/CD Narzędzie często wymaga przekazywania sekretów do poleceń krok po kroku. Często są one ujawniane, co ma tragiczne konsekwencje.

PipelinePotrzebne są sekrety, które czasami wyciekają

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Być może dawne dobre czasy polegały na znalezieniu w historii Gita .env plik (deweloper zapomniał go dodać) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

który został użyty w przepływie pracy GitHub .github/deploy.yaml który zawierał coś takiego:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: wow! Te klucze AWS działały! Najpierw przetestowaliśmy nieszkodliwą zmianę w aplikacji, a potem dodaliśmy szantaż, bo ci goście wydawali się nieświadomi. Bingo! Co za kampania…

Złodziej po prostu użył kluczy AWS do przesłania zmodyfikowanej aplikacji ze złośliwym oprogramowaniem, a następnie uruchomił polecenie wdrożenia z takimi danymi uwierzytelniającymi. Wyciekłe sekrety wraz z informacjami zawartymi w pipeline„Co za kampania!” prawdopodobnie oznacza, że ​​Memento wywołało spustoszenie w życiu biednej ofiary.

Memento mówi nam tutaj, że jeśli doszło do wycieku tajnych informacji, np. kluczy dostępu do AWS w przykładzie, należy unieważnić tajne informacje (obrócić powyższe klucze) natychmiast. Zawsze jest okno ekspozycji między przeciekami commit i tajne unieważnienie; przepisywanie historii Git jest trudne (nawet najbardziej zacięte państwo autorytarne próbowało takiego przepisania historii, ale bezskutecznie) i prawdopodobnie nieskuteczne (nasi przyjaciele mogli sklonować się przed repozytorium z tajnym wyciekiem) commit). Natychmiast obróć klucze i módl się, czytając dzienniki aktywności dla wybranego konta w czasie trwania okna ekspozycji!

Prawdopodobnie organizacje powinny zakaz używania długoterminowych tajemnic w CI/CD pipelinesi zastąp je tymczasowymi danymi uwierzytelniającymi. W poprzednim przykładzie z kluczami AWS w akcjach GitHub bezpieczniej jest użyć Dostawca OpenID Connect (OIDC) aby uzyskać krótkotrwałe uprawnienia potrzebne do podjęcia działań.

Wściekłość bagienna: Miałeś tyle szczęścia! Wyciekanie skryptów z zakodowanymi na stałe kluczami było powszechną praktyką w dawnych czasach, nawet w publicznie dostępnych kontenerach S3. Wystarczyło przeszukać obiekty w kontenerze i trochę poszperać, żeby znaleźć interesujące rzeczy.

Czasami obszar używany do wdrożenia (w tym przykładzie kontener AWS S3) był otwarty na odczyt przez osoby z zewnątrz z powodu błędu konfiguracji (który nie został wykryty). Wściekłość bagienna użyto czegoś takiego:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Zasobnik został prawdopodobnie utworzony w szablonie, który może być automatycznie skanowany w celu wykrycia luk w zabezpieczeniach.

Domyślna konfiguracja narzędzia była dla nas zabawką

Aby podać konkretne przykłady, porozmawiajmy o Jenkins, jedno z najpopularniejszych narzędzi CI.

Wściekłość bagienna: Pamiętasz to pole wyboru „Włącz zabezpieczenia” w Jenkinsie i ile organizacji zdecydowało się go nie aktywować dla wygody? I te „Każdy może zrobić wszystko„Domyślnie kombinacje uprawnień? A te irytujące wtyczki Jenkinsa, takie jak Wtyczka GitHub OAuthOsoba, która to konfigurowała, zaznaczyła opcje „Przyznaj uprawnienia do odczytu wszystkim uwierzytelnionym użytkownikom” i „Użyj uprawnień repozytorium GitHub”, dając nam dostęp do wszystkich swoich projektów.

(Przepraszam, Jenkins, że dałem ci przykład 😉

Bądź biegły (a nawet uzależniony) w przestrzeganiu zasad bezpieczeństwa. Jednym z nich jest Bezpieczne domyślnie Zasada: sterowanie powinno domyślnie korzystać z najbezpieczniejszych ustawień, jakie jest możliwe. Bezpieczeństwo powinno być wbudowane CI/CD narzędzia i pipelines od podstaw, a nie jako dodatek. Jednak przyjazność dla użytkownika i wygoda często kolidują z bezpieczeństwem.

W przypadku Jenkinsa wbudowane uwierzytelnianie jest zbyt kruche: nigdy nie używaj wbudowanych mechanizmów uwierzytelniania w JenkinsieLepiej wybrać mechanizm innej firmy (SAML, LDAP, Google…) z wtyczką strategii autoryzacji opartej na rolach („RBAC”). Zachowaj szczególną ostrożność w przypadku admin konta.

Zadbaj o to, jak wygląda praca i pipeline Pliki w Jenkinsie są obsługiwane. To samo dotyczy Wtyczka konfiguracji jako kod i jego pliki konfiguracyjne, które odnoszą się do konfiguracji Jenkinsa.

Przejście z hostingu własnego CI/CD Przejście z systemów SaaS w chmurze eliminuje niektóre potencjalne ryzyka, umożliwiając ruch boczny w obrębie sieci organizacji, ale dodaje inne, takie jak konieczność otwierania połączeń zewnętrznych między istniejącymi systemami wewnętrznymi a systemami zewnętrznymi CI/CD narzędziem.

Organizacje powinny ćwiczyćcisnależytej staranności przy hartowaniu CI/CD system, zaczynając od najbardziej restrykcyjnych ustawień i stopniowo otwierając się na minimalne wymagane uprawnienia dla pipeline kroki.

Konfigurowanie zabezpieczeń w CI/CD Narzędzia mogą być skomplikowanym zadaniem. Wiele z nich ma wtyczki lub rozszerzenia, które zawierają większość luk i wymagają aktualizacji.

Pomocne mogą okazać się skanery błędnej konfiguracji zabezpieczeń takich skomplikowanych narzędzi lub testy porównawcze.

Wstrzykiwanie kodu pipeline polecenia dla zabawy i zysku

M3M3N70:Czy kiedykolwiek korzystałeś z Untrusted Code Checkouts, czyli podatnych na ataki typu command-injection działań i skryptów?

W tej sekcji pokazano, że pipeline sam w sobie może zawierać błędy kodowania, które umożliwiają nieuczciwym graczom wstrzyknięcie wykonania dowolnego kodu pipeline bez zmiany pipeline samo źródłoNa przykład używając PR

Pierwszy przykład niefortunny przepływ pracy w GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

łącząc pull_request_target wyzwalacz przepływu pracy z jawnym wyewidencjonowaniem niezaufanego żądania ściągnięcia to niebezpieczna praktyka, która może prowadzić do naruszenia bezpieczeństwa repozytorium. W tym przykładzie niefortunne połączenie:

• pull_request_target zdarzenie, które domyślnie ma uprawnienia do zapisu do repozytorium docelowego i sekretów repozytorium docelowego, nawet z zewnętrznych rozwidleń, i jest uruchamiane w kontekście repozytorium docelowego PR,
• sprawdź kod PR ze źródła, niezaufanego repozytorium,
• wyzwolić dowolny skrypt, który może działać na treściach kontrolowanych przez PR, jak w przypadku npm install,
• nieużywanie warunku do wyzwalania pull_request_target zdarzenie, które zostanie uruchomione tylko wtedy, gdy do PR zostanie przypisana etykieta „to PR zostało sprawdzone” (użytkownicy zewnętrzni nie mogą przypisywać etykiet do PR).

Drugi przykład dotyczy niewiarygodnych danych wejściowych (z problemu, komentarza lub pull request) jako źródło argumentów przekazywanych do pipeline polecenie za pomocą wyrażeń. To jest pipeline wersja luki w zabezpieczeniach polegającej na wstrzykiwaniu poleceń systemu operacyjnego.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Operacja uruchomienia generuje tymczasowy skrypt powłoki na podstawie szablonu, z $ podmieniony, co czyni go podatnym na wstrzyknięcie poleceń powłoki. Atakujący z fałszywym kontem GitHub może stworzyć problem z tytułem a"; bad_code_goes_here;#i bum! 

Wściekłość bagienna:Och, ci goście otwierali drzwi dla wstrzykiwania poleceń po prostu przez otwieranie zgłoszenia...

W działaniach GitHub występowały luki w zabezpieczeniach umożliwiające wykonanie kodu, takie jak komentarz-gajira, teraz naprawione. Proszę przeczytać „Niezaufane dane wejściowe w przepływach pracy GitHub” dla pełnych szczegółów.

Morał tej historii: Nigdy nie sprawdzaj i nie twórz PR-ów z niepewnych źródeł bez wcześniejszego sprawdzenia PR-u. „Niezaufane” w tym przypadku, chyba że na podstawie drakońskich zasad uwierzytelniania pochodzenia, może oznaczać każde potencjalnie przejęte konto programisty.

 

Tutaj doszło do niezamierzonego rozpowszechnienia złośliwego oprogramowania!

Ciągłe wdrażanie jest punktem kulminacyjnym automatyzacji, ale ten punkt kulminacyjny może zostać udaremniony przez brak odpowiednich kontroli zatwierdzania pipeline przepływu.

Ryzyko związane z całkowicie zautomatyzowanym wdrażaniem ze źródła commit Do zagrożeń dla systemów produkcyjnych zalicza się ryzyko wdrożenia złośliwego kodu w środowiskach produkcyjnych bez wykrycia, a także ryzyko wystąpienia błędów w procesie wdrażania, które mogą spowodować zakłócenia lub przerwy w działaniu.

Aby ograniczyć te ryzyka, często zaleca się organizacjom wdrożenie „twardego przerwania” w procesie wdrażania, co wymaga ludzka aprobata przed wdrożeniem wersji w środowiskach końcowych.

Zamykają drzwi

Wściekłość bagienna:Te radosne domyślne hasła w CI/CD narzędzia są czyszczone. Dostęp do /var/lib/jenkins/secrets/initialAdminPassword to teraz martwy szlak. Wiele narzędzi oferuje teraz 2FA, które spopularyzował Covid, i nawet najbardziej leniwy programista z niego korzysta!

M3M3N70Walczymy z 2FA, ale to nie jest takie proste. Trudno jest ich atakować metodą spear-phishing, ponieważ „Scatter Swine” z TwilioZ kluczami WebAuthn jest to znacznie trudniejsze. Przynajmniej możemy spróbować ukraść pliki cookie, aby ominąć MFA, ale trzeba włamać się do skrzynki programisty.

Uwierzytelnianie wieloskładnikowe to krok w dobrym kierunku, ograniczający ryzyko wycieku poufnych danych uwierzytelniających. Większość nowoczesnych narzędzi DevOps obsługuje uwierzytelnianie wieloskładnikowe (MFA). Klucze uwierzytelniające w ramach WebAuthn/U2F (patrz: Projekt FIDO2) są prawdopodobnie najlepszą opcją dla MFA w DevOps, jeśli są odpowiednio zarządzane.

Wściekłość bagienna: Faceci od DevOps się budzą. Mają we krwi to cholerne „najmniejsze uprawnienia”. I nie są już małpami programistycznymi. Teraz jesteśmy łapani na gorącym uczynku przez recenzentów.

W rzeczywistości, pipelinesą teraz nieco bardziej odporne niż kilka lat temu, z usuniętymi słabymi akcjami i skryptami oraz dodatkowymi etapami testów bezpieczeństwa, które wykrywają nawet nasze droppery ukryte w trybie stealth commiti pakiety, które przejęliśmy.

Pytanie do czytelnika: czy proces budowania oprogramowania ze źródeł i wdrażania do produkcji jest ryzykowny? Czy widzisz swój DevOps na etapie stare dobre czasy dla złych facetów?

Ostateczne rekomendacje

Od czego zacząć CI/CD pipelines?

Pierwsza rekomendacja jest tutaj prosta: ostrożnie  pipelines (oni są krytyczny (zasoby) pod kątem bezpieczeństwa. Przeglądy są kosztowne, ale konieczne i powinny być przeprowadzane prawidłowo. Recenzenci powinni wiedzieć, na co zwracać uwagę. Każdy krok musi zostać sprawdzony pod kątem wad.

Być może pomocne mogłoby okazać się połączenie wysiłków ekspertów, którzy dokonują recenzji i dysponują automatycznymi skanerami złośliwego kodu.

Drugim zaleceniem jest szkolić programistów, którzy piszą pipelinei utrzymuj je w bezpiecznym stanie. Rzeczy do rozważenia:

• Jak prawidłowo obsługiwać uwierzytelnianie w usługach wewnętrznych i w chmurze, unikając uciążliwości związanych z obsługą długoterminowych poświadczeń.
• Jak ograniczyć pipelines do dokładnego zestawu zasobów, do których potrzebuje dostępu. Zasada najmniejszych uprawnień znów się sprawdza.
• Jak napisać kroki, aby to zrobić pipelinepowtarzalność, np. przypinanie wersji i unikanie luk w zabezpieczeniach związanych z wstrzykiwaniem poleceń.
• Jak zatwierdzać wdrożenia z perspektywy bezpieczeństwa (to inni!): jakie zabezpieczenia standardpowinny być dopasowane i jak dodać odpowiednie kontrole/bramki w pipelines.

Trzecią rekomendacją jest skonfigurować CI/CD system z należytą starannościąSilne uwierzytelnianie, brak domyślnych haseł i niebezpiecznych ustawień, minimalne uprawnienia… Uważaj na luki w zabezpieczeniach zainstalowanych wtyczek i rozszerzeń. To może być tematem kolejnych postów, bądź na bieżąco.

Czwarta rekomendacja to wykorzystać CI/CD pipelines dla automatyzacji zabezpieczeń. Analiza kodu źródłowego (SAST), analiza składu źródeł (SCA), skanowanie wycieków sekretów, narzędzia antywirusowe, skanery bezpieczeństwa kontenerów lub automatyczne detektory czasu wykonania (DAST i złośliwe oprogramowanie) mogą być uruchamiane rutynowo na pipeline. A Twoja organizacja może egzekwować standardo zasięgu skanowania bezpieczeństwa w CI/CD.

Należy pamiętać, że narzędzia te nie wykluczają jednak opinii ekspertów, ponieważ mogłoby to wywołać złudne poczucie bezpieczeństwa.

Jeśli znasz listę dziesięciu najważniejszych projektów OWASP, dobrym niedawnym projektem jest OWASP Top 10 CI/CD Ryzyko bezpieczeństwa.

Uwaga dotycząca wyłączenia odpowiedzialności

(1) Przykłady w tym poście wykorzystują GitHub jako SCM, AWS jako dostawca chmury i GitHub Actions lub Jenkins jako CI/CD Narzędzie. Nie są słabsze / bezpieczniejsze niż ich alternatywy. Nie ma w tym nic złego! Te narzędzia są potężne i należy ich używać w odpowiedni sposób.

(2) M3M3N70 oraz Wściekłość bagienna są postaciami fikcyjnymi. Jakiekolwiek podobieństwo do osób lub grup, żyjących lub zmarłych, jest jedynie przypadkowe… czy na pewno?

Aby przeczytać więcej

• Haymore, A. i wsp. „10 prawdziwych historii o tym, jak naruszyliśmy bezpieczeństwo CI/CD pipelines ". NCC Group, styczeń 2022.
• configure-aws-credentials Akcja GitHub oraz Konfigurowanie OpenID Connect w Amazon Web Services Aby uzyskać szczegółowe informacje na temat uruchamiania poleceń AWS w celu wdrażania w przepływach pracy GitHub.
• Łobaczewski J. „Zapewnianie bezpieczeństwa akcji i przepływów pracy w GitHub. Część 1: Zapobieganie żądaniom pwn”GitLab Security Lab, grudzień 2020 r.
• Łobaczewski J. „Zapewnianie bezpieczeństwa akcji i przepływów pracy w serwisie GitHub. Część 2: Niezaufane dane wejściowe”GitLab Security Lab, styczeń 2021 r.
• OWASP. „10 najlepszych OWASP CI/CD „Zagrożenia bezpieczeństwa”Lipiec 2022.
• Saltzer J. i Schroeder M. „Ochrona informacji w systemach komputerowych”Kwiecień 1975. Zasady bezpieczeństwa ewoluowały wraz z technologią, ale 47 lat później większość idei bezpieczeństwa i ochrony zdrowia nadal obowiązuje.
• Brytyjskie NCSC. „Zabezpiecz kompilację i wdrożenie pipeline"Brytyjskie Narodowe Centrum Cyberbezpieczeństwa, luty 2019 r.