Što može poći po zlu CI/CD pipelines?

Kontinuirana integracija i kontinuirana isporuka (CI/CD) pipelinesu temelj svake softverske organizacije koja gradi softver na „moderan“ način. Automatizacija pruža veliku moć, ali većina programera propušta odgovornost koju ona podrazumijeva.

razvijačDa, uzimamo CI/CD sigurnosti ozbiljno i imati snažnu kontrolu nad održavateljima koda, pregledati commitprije spajanja; poslovi i pipelineodržavaju ih viši djelatnici, oni paze da se tajne ne otkriju pipelines. Alat je instaliralo osoblje koje poznaje tu stvar. Što može poći po zlu?

Poštovani programer, CI/CD Sustavi su složeni. Njegova široka površina napada privukla je zlonamjerne aktere. Bolje biti oprezan i nikada previše samouvjeren.

Zadana konfiguracija se ponekad zadržava i postaje najbolji prijatelj hakerima. Kritični nedostaci mogu biti prisutni u CI/CD pipeline izvora, u konfiguraciji sustava ili oko procesa i konteksta pipeline i kako se pokreće.

U ovom postu stavit ćemo se u ulogu negativaca. Zamislite da čitamo razmišljanja M3M3N70 (Sjećanje na smrt?) i Bijes u močvari negdje na mračnom webu, vjerojatno na nekom nezapadnjačkom jeziku, ali nikad ne propustite da se zlo širi svijetom.

 

U dobra stara vremena bilo je tako lako…

M3M3N70Natrag u dobra stara vremena, naš posao je bio taaako jednostavan... Zero-day planovi su bili lako dostupni, aplikacije su bile širom otvorene s lako iskoristivim ranjivostima, a mi smo se mogli lateralno kretati u trenu.

Bijes u močvari: Jeb#@Dovraga! Ima još nekih gluposti, ali stvari su se promijenile. Veliki dečki su uložili puno novca u to AppSec sranje.

M3M3N70Da. Ali novi budale su developeri. Za nas je bilo lakše odabrati alate koje ovi dečki koriste. Konkretna integracija je rudnik zlata! Tokeni za pristup oblaku, SCM vjerodajnice, lozinke za produkcijsku bazu podataka, SSH privatni ključevi, vjerodajnice drugih CI korisnika… Skok s dosadnih razvojnih stvari na pravu stvar bio je prilično trivijalan.

Automatizacija za izgradnju, testiranje i implementaciju softvera s CI/CD Alat često zahtijeva postupno prosljeđivanje tajni naredbama. I često se one otkriju, s neslavnim posljedicama.

PipelineTrebaju tajne koje ponekad procure

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.

Možda su dobra stara vremena bila pronaći u povijesti Gita .env datoteka (razvojni programer ju je zaboravio dodati u .gitignore):

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

koji je korišten u GitHub tijeku rada .github/deploy.yaml koji je sadržavao nešto poput ovoga:

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: vau! Ti AWS ključevi su radili! Prvo smo testirali inocuos promjenu u aplikaciji, a zatim dodali sting jer se činilo da ti dečki nisu bili svjesni. Bingo! Kakva kampanja…

Zlonamjerni akter je jednostavno koristio AWS ključeve za prijenos modificirane aplikacije sa zlonamjernim softverom, a zatim pokrenuo naredbu za postavljanje s tim vjerodajnicama. Procurile tajne, zajedno s informacijama sadržanim u pipeline„Kakva kampanja!“ vjerojatno znači da je Memento uništio jadnu žrtvu.

Ono što nam Memento ovdje govori jest da kada se dogodi curenje tajne informacije, poput AWS pristupnih ključeva u primjeru, morate opozvati tajnu informaciju (rotirati gornje ključeve). odmahUvijek postoji prozor ekspozicije između curenja commit i tajno poništavanje; Prepisivanje povijesti Gita je teško (čak su i najtvrđe autoritarne države pokušale takvo prepravljanje povijesti, bezuspješno) i vjerojatno neučinkovite (naši prijatelji su možda klonirali prije repozitorija s tajnim curenjem commit). Odmah rotirajte tipke i molite se dok čitate zapisnike aktivnosti za ciljani račun tijekom vremenskog okvira izloženosti!

Vjerojatno bi organizacije trebale zabraniti korištenje dugoročnih tajni u CI/CD pipelinesi zamijenite ih vremenskim vjerodajnicama. U prethodnom primjeru s AWS ključevima u GitHub akcijama, sigurnije je koristiti Pružatelj OpenID Connecta (OIDC) kako bi dobili kratkotrajne vjerodajnice potrebne za radnje.

Bijes u močvariImao si sreće! Curenje skripti s čvrsto kodiranim ključevima bila je uobičajena praksa u stara vremena, čak i na javno dostupnim S3 bucketima. Sve što si trebao učiniti je pregledati objekte u bucketu i napraviti grepping kako bi pronašao zanimljive stvari.

Ponekad je područje korišteno za implementaciju (u ovom primjeru AWS S3 bucket) bilo otvoreno za čitanje od strane vanjskih korisnika zbog konfiguracijske greške (koja je ostala neotkrivena). Bijes u močvari korišteno je bilo nešto ovako:

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>'"

Kanta je vjerojatno kreirana u predlošku za opskrbu koji se može automatski skenirati zbog sigurnosnih nedostataka.

Zadana konfiguracija alata bila nam je igračka

Da bismo dali konkretne primjere, razgovarajmo o Jenkins, jedan od najpopularnijih CI alata.

Bijes u močvariSjećate li se one kućice "Omogući sigurnost" u Jenkinsu i koliko je organizacija odlučilo da je ne aktivira zbog praktičnosti? I one "Svatko može učiniti bilo što"kombinacije dozvola kao zadane? I oni dosadni Jenkins dodaci, poput GitHub OAuth dodatakTip koji ga je konfigurirao odabrao je i "Dodijeli dozvole za ČITANJE svim autentificiranim korisnicima" i "Koristi dozvole za GitHub repozitorij", dajući nam pristup svim njihovim projektima.

(Oprosti, Jenkins, što te stavljam kao primjer 😉

Budite vješti (čak i ovisni) o sigurnosnim načelima. Jedno je Sigurno prema zadanim postavkama načelo: kontrole bi trebale biti postavljene na najsigurnije moguće postavke. Sigurnost bi trebala biti ugrađena u CI/CD alata i pipelineod temelja, a ne kao naknadna misao. Ali jednostavnost korištenja i praktičnost često se sukobljavaju sa sigurnošću.

U slučaju Jenkinsa, ugrađena autentifikacija je previše krhka: nikad ne koristite ugrađene mehanizme autentifikacije u JenkinsuBolje se odlučite za mehanizam treće strane (SAML, LDAP, Google...), s dodatkom za strategiju autorizacije temeljenu na ulogama („RBAC“). I budite izuzetno oprezni s admin račun.

Pazite na posao i pipeline Datoteke u Jenkinsu se obrađuju. Isto je i s Dodatak za konfiguraciju kao kod i njegove konfiguracijske datoteke koje se primjenjuju na Jenkins konfiguraciju.

Prelazak s vlastitog hostinga CI/CD Prelazak na SaaS sustave temeljene na oblaku eliminira neke potencijalne rizike omogućujući lateralno kretanje unutar organizacijske mreže, ali dodaje i druge, poput potrebe za otvaranjem vanjskih veza između postojećih internih sustava i eksternaliziranih. CI/CD alat.

Organizacije bi se trebale potruditicisdužna pažnja pri kaljenju CI/CD sustav, počevši s najrestriktivnijim postavkama i postupno se otvarajući s minimalnim potrebnim dozvolama za pipeline stepenice.

Konfiguriranje sigurnosti u CI/CD alati mogu biti složen podvig. Mnogi imaju dodatke ili proširenja koja imaju većinu ranjivosti i potrebno ih je ažurirati.

Skeneri za sigurnosne pogreške u konfiguraciji za takve složene alate ili mjerila mogu pomoći.

Ubrizgavanje koda u pipeline naredbe za zabavu i profit

M3M3N70Jeste li ikada koristili nepouzdane provjere koda, te ranjive akcije i skripte ranjive na ubrizgavanje naredbi?

Ovaj odjeljak pokazuje da pipeline sam po sebi može imati greške u kodu koje omogućuju zlonamjernim akterima ubacivanje proizvoljnog izvršavanja koda u pipeline bez promjene pipeline sam izvorNa primjer korištenjem odnosa s javnošću

Prvi primjer jednog nesretan GitHub tijek rada:

# 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 ...

Kombinirajući pull_request_target Okidanje tijeka rada s eksplicitnom provjerom nepouzdanog PR-a je opasna praksa koja može dovesti do kompromitiranja repozitorija. U primjeru, nesretna kombinacija:

• pull_request_target događaj, koji prema zadanim postavkama ima dopuštenje za pisanje u ciljni repozitorij i tajne ciljnog repozitorija, čak i iz vanjskih forkova, i izvodi se u kontekstu ciljnog repozitorija PR-a,
• provjerite PR kod iz izvora, nepouzdano spremište,
• pokrenuti bilo koji skript koji može raditi na PR kontroliranom sadržaju, kao u slučaju npm installi
• nekorištenje uvjeta za okidanje pull_request_target događaj će se pokrenuti samo ako je zahtjevu za prijavu dodijeljena neka vrsta oznake 'ovaj zahtjev za prijavu je provjeren' (vanjski korisnici ne mogu dodijeliti oznake zahtjevu za prijavu).

Drugi primjer uzima nepouzdane podatke (iz problema, komentara ili pull request) kao izvor za argumente proslijeđene pipeline naredba putem izraza. Ovo je pipeline verzija ranjivosti ubrizgavanja naredbi OS-a.

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

Operacija pokretanja generira privremenu shell skriptu na temelju predloška, ​​s $ zamijenjen, što ga čini ranjivim na ubrizgavanje naredbi u shell. Napadač s lažnim GitHub računom mogao bi stvoriti problem s naslovom a"; bad_code_goes_here;#, i bum! 

Bijes u močvariOh, ti tipovi su otvarali vrata za ubrizgavanje naredbi jednostavnim otvaranjem problema...

Postojale su ranjivosti u izvršavanju koda u GitHub akcijama, kao što su gajira-komentar, sada ispravljeno. Molimo pročitajte „Nepouzdan unos u GitHub tijekovima rada“ za pune detalje.

Pouka priče: Nikada nemojte provjeravati i izrađivati ​​PR-ove iz nepouzdanih izvora bez prethodnog pregleda PR-a. 'Nepouzdano' ovdje, osim ako nije pod drakonskom provjerom porijekla, moglo bi značiti bilo koji potencijalno otet račun razvojnog programera.

 

Nenamjerno postavljanje zlonamjernog softvera ovdje!

Kontinuirana implementacija je vrhunac automatizacije, ali taj vrhunac mogao bi biti osujećen nedostatkom odgovarajućih kontrola odobravanja na pipeline teći.

Rizici potpuno automatiziranog uvođenja iz izvora commit za produkcijske sustave uključuju mogućnost implementacije zlonamjernog koda u produkcijska okruženja bez otkrivanja, kao i mogućnost da pogreške u procesu implementacije uzrokuju prekide ili prekide rada.

Kako bi se ublažili ovi rizici, često se preporučuje da organizacije implementiraju „tvrdi prekid“ u svom procesu implementacije, što zahtijeva ljudsko odobravanje prije nego što se izdanja implementiraju u krajnja okruženja.

Zatvaraju vrata

Bijes u močvariTe radosne zadane lozinke u CI/CD alati se brišu. Pristup /var/lib/jenkins/secrets/initialAdminPassword je sada slijepi put. Mnogi alati sada pružaju 2FA, koju je Covid učinio popularnom, pa čak i najlijeniji programer ga koristi!

M3M3N70Borimo se protiv 2FA, ali to nije tako lako. Teško je spear-phishingati te tipove, jer "Scatter Swine" je napravio s TwiliomS WebAuthn ključevima je puno teže. Barem možemo pokušati krađa kolačića za zaobilaženje MFA-a, ali treba provaliti u kutiju programera.

Višefaktorska autentifikacija dobar je korak u pravom smjeru za ograničavanje rizika od curenja autentifikacijskih tajni. Većina modernih DevOps alata podržava MFA. I autentifikacijski ključevi pod WebAuthn / U2F (vidi FIDO2 projekt) su možda najbolja opcija za MFA u DevOpsu, ako se njima pravilno upravlja.

Bijes u močvariDevOps dečki se bude. Imaju tu prokletu stvar s "najmanjim privilegijama" u krvi. I više nisu programski majmuni. Sad nas recenzenti hvataju na djelu.

U stvari, pipelinesu sada malo robusniji nego prije nekoliko godina, s uklonjenim slabim akcijama i skriptama te s dodatnim koracima sigurnosnog testiranja koji su čak otkrili naše droppere skrivene u stealthu. commiti pakete koje smo oteli.

Pitanje za čitatelja: je li proces izgradnje softvera iz izvornog koda i implementacije u produkciju rizičan posao? Možete li vidjeti svoj DevOps u fazi dobra stara vremena za loše momke?

Završne preporuke

Gdje početi s CI/CD pipelines?

Prva preporuka je ovdje jednostavna: Pažljivo Recenzijom u pipelines (oni su kritičan resursi) za sigurnosne probleme. Pregledi su skupi, ali nužni i trebaju se pravilno obaviti. Pregledatelji bi trebali biti svjesni na što treba paziti. Svaki korak mora se provjeriti zbog nedostataka.

Možda bi mogla pomoći kombinacija stručnih recenzenata naoružanih automatiziranim skenerima zlonamjernog koda.

Druga preporuka je da obučite programere koji pišu pipelinei održavati ih na sigurnomStvari koje treba uzeti u obzir:

• Kako pravilno upravljati autentifikacijom s internim i cloud uslugama, izbjegavajući gnjavažu oko rukovanja dugoročnim vjerodajnicama.
• Kako ograničiti pipelines točno onim skupom resursa kojima treba pristupiti. Princip najmanjih privilegija ponovno blista.
• Kako napisati korake za izradu pipelinereproducibilno poput pinninga verzija i izbjegavanje ranjivosti ubrizgavanja naredbi.
• Kako odobriti implementacije iz sigurnosne perspektive (to su drugi!): koja sigurnost standardtrebaju se podudarati i kako dodati odgovarajuće provjere/vrata u pipelines.

Treća preporuka je da konfigurirajte CI/CD sustav s dužnom pažnjomSnažna autentifikacija, bez zadanih lozinki ili nesigurnih postavki, minimalne privilegije… Pobrinite se za ranjivosti u instaliranim dodacima i proširenjima. Ovo bi mogao biti fokus sljedećih objava, molimo vas da pratite novosti.

Četvrta preporuka je da iskoristiti CI/CD pipelineza sigurnosnu automatizacijuAnaliza izvornog koda (SAST), analiza sastava izvora (SCA), skeniranje curenja tajni, alati protiv zlonamjernog softvera, skeneri sigurnosti spremnika ili automatizirani detektori vremena izvođenja (DAST i zlonamjerni softver) mogu se rutinski pokretati na pipelineI vaša organizacija može provoditi standardo pokrivenosti sigurnosnog skeniranja u CI/CD.

Podsjetimo, ovi alati ipak ne isključuju stručnu procjenu iz jednadžbe, inače biste mogli imati lažni osjećaj sigurnosti.

Ako ste vješti u OWASP top desetkama, dobar nedavni projekt je OWASP Top 10 CI/CD Sigurnosni rizik.

Napomena o odricanju odgovornosti

(1) Primjeri u ovom postu koriste GitHub kao SCM, AWS kao pružatelj usluga u oblaku i GitHub Actions ili Jenkins kao CI/CD alat. Nisu slabiji/sigurniji od svojih alternativa. Nema loše namjere za tisak! Ovi alati su moćni i treba ih koristiti na odgovarajući način.

(2) M3M3N70 i Bijes u močvari su izmišljeni likovi. Svaka sličnost s osobama ili grupama, živima ili mrtvima, samo je slučajna... ili jest?

Da pročitate više

• Haymore, A. i sur. 10 priča iz stvarnog svijeta o tome kako smo kompromitirali CI/CD pipelines "NCC Grupa, siječanj 2022.
• configure-aws-credentials Radnja na GitHubu i Konfiguriranje OpenID Connecta u Amazon Web Services za detalje o tome kako pokrenuti AWS naredbe za implementaciju u GitHub tijekovima rada.
• Lobačevski J. „Održavanje sigurnosti vaših GitHub akcija i tijekova rada 1. dio: Sprječavanje pwn zahtjeva“GitLab Security Lab, prosinac 2020.
• Lobačevski J. „Održavanje sigurnosti vaših GitHub akcija i tijekova rada 2. dio: Nepouzdani unos“GitLab Security Lab, siječanj 2021.
• OWASP. „OWASP Top 10“ CI/CD Sigurnosni rizici”srpanj 2022.
• Saltzer J. i Schroeder M. "Zaštita informacija u računalnim sustavima"Travanj 1975. Sigurnosna načela su se razvijala s tehnologijom, ali 47 godina kasnije većina S&S ideja i dalje je na snazi.
• NCSC Ujedinjenog Kraljevstva. "Osigurajte izgradnju i implementaciju" pipeline"Nacionalni centar za kibernetičku sigurnost Ujedinjenog Kraljevstva, veljača 2019.