Šta 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 ne shvata odgovornost koju ona podrazumijeva.

razvijačDa, uzimamo CI/CD bezbjednost ozbiljno i imati snažnu kontrolu nad održavateljima koda, pregledati commitprije spajanja; poslovi i pipelineodržavaju ih viši službenici, oni vode računa da se tajne ne cure. pipelines. A alat je instaliralo osoblje koje poznaje tu stvar. Šta može poći po zlu?

Poštovani programer, CI/CD Sistemi su složeni. Njegova široka površina za napad privukla je zlonamjerne aktere. Bolje biti oprezan i nikada ne 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 sistema ili oko procesa i konteksta pipeline i kako se to aktivira.

U ovom postu ćemo se staviti u ulogu loših glumaca. Zamislite da čitamo razmišljanja M3M3N70 (Sjećanje na smrt?) i Bijes u močvari negdje na mračnom webu, vjerovatno na nekom nezapadnjačkom jeziku, ali nikad ne propustite da se zlo širi širom svijeta.

 

U dobra stara vremena to je bilo tako lako…

M3M3N70Nazad u dobra stara vremena, naš posao je bio taaako lak... Zero-day sistemi su bili lako dostupni, aplikacije su bile širom otvorene s lako iskoristivim ranjivostima, a mi smo mogli da se krećemo bočno u trenu.

Bijes u močvariJebem ti! Ima još nekih gluposti, ali stvari su se promijenile. Veliki igrači su uložili mnogo novca u to AppSec sranje.

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

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

PipelineTrebaju nam 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 historiji Gita .env datoteka (programer je zaboravio da je doda 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 radnom procesu .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 smo dodali i sting jer se činilo da ti momci nisu bili svjesni. Bingo! Kakva kampanja…

Zlonamjerni akter je jednostavno koristio AWS ključeve za postavljanje modificirane aplikacije sa zlonamjernim softverom, a zatim pokrenuo naredbu za deploy s tim podacima. Procurile tajne, zajedno s informacijama sadržanim u pipeline„Kakva kampanja!“ vjerovatno znači da je Memento izazvao haos u jadnoj žrtvi.

Ono što nam Memento ovdje govori je da kada dođe do curenja 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 historije Gita je teško (čak su i najtvrđe autoritarne države pokušale takvo prepravljanje historije, bezuspješno) i vjerovatno neefikasne (naši prijatelji su možda klonirali prije repozitorija sa tajnim curenjem commit). Odmah rotirajte tipke i molite se dok čitate zapise aktivnosti za ciljani račun tokom perioda izloženosti!

Vjerovatno bi organizacije trebale zabrana korištenja dugoročnih tajni u CI/CD pipelinesi zamijenite ih privremenim akreditivima. U prethodnom primjeru s AWS ključevima u GitHub akcijama, sigurnije je koristiti Pružatelj OpenID Connecta (OIDC) da dobije kratkoročne akreditacije potrebne za radnje.

Bijes u močvariImao si sreće! Curenje skripti sa hard-kodiranim ključevima bila je uobičajena praksa u stara vremena, čak i na javno dostupnim S3 bucketima. Sve što je trebalo uraditi je pregledati objekte u bucketu i izvršiti grepping da bi se pronašle zanimljive stvari.

Ponekad je područje korišteno za implementaciju (AWS S3 bucket u ovom primjeru) bilo otvoreno za čitanje od strane vanjskih korisnika zbog greške u konfiguraciji (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 vjerovatno kreirana u šablonu za obezbjeđivanje koji bi se mogao automatski skenirati zbog sigurnosnih propusta.

Zadana konfiguracija alata bila je igračka za nas

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

Bijes u močvariSjećate li se onog polja za potvrdu "Omogući sigurnost" u Jenkinsu i koliko je organizacija odlučilo da ga ne aktivira zbog praktičnosti? I onih "Bilo ko može uraditi bilo šta"kombinacije dozvola kao zadane? I oni dosadni Jenkins dodaci, poput GitHub OAuth dodatakTip koji ga je konfigurisao odabrao je i "Dodijeli dozvole za ČITANJE svim autentificiranim korisnicima" i "Koristi dozvole za GitHub repozitorij", dajući nam pristup svim njihovim projektima.

(Izvinjavam se, Jenkins, što sam te stavio kao primjer 😉

Budite vješti (čak i ovisni) o sigurnosnim principima. Jedan je Sigurno po defaultu princip: kontrole bi trebale biti postavljene na najsigurnije moguće postavke. Sigurnost bi trebala biti ugrađena u CI/CD alata i pipelineod temelja, umjesto da bude 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: Nikada ne koristite ugrađene mehanizme autentifikacije u JenkinsuBolje se odlučite za mehanizam treće strane (SAML, LDAP, Google...), s dodatkom za strategiju autorizacije zasnovanu na ulogama („RBAC“). I budite izuzetno oprezni s admin račun.

Vodite računa o tome kako obavljate posao i pipeline Datoteke u Jenkinsu se obrađuju. Isto je i sa Dodatak za konfiguraciju kao kod i njegove konfiguracijske datoteke, koje se primjenjuju na Jenkins konfiguraciju.

Prelazak sa samostalnog hostinga CI/CD Prelazak sa SaaS sistema na cloud-bazirane SaaS sisteme eliminiše neke potencijalne rizike omogućavajući lateralno kretanje unutar organizacijske mreže, ali dodaje i druge, poput potrebe za otvaranjem eksternih veza između postojećih internih sistema i eksternalizovanih. CI/CD alat.

Organizacije bi trebale da se potrudecisdužna pažnja pri kaljenju CI/CD sistem, počevši od najrestriktivnijih postavki i postepeno se otvarajući s minimalnim potrebnim dozvolama za pipeline stepenice.

Konfigurisanje sigurnosti u CI/CD Alati mogu biti složen poduhvat. Mnogi imaju dodatke ili ekstenzije koji imaju većinu ranjivosti i potrebno ih je ažurirati.

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

Ubrizgavanje koda u pipeline naredbe za zabavu i profit

M3M3N70Jeste li ikada koristili nepouzdane provjere koda, te ranjive akcije i skripte podložne ubrizgavanju naredbi?

Ovaj odjeljak pokazuje da pipeline sam po sebi može imati greške u kodu koje omogućavaju zlonamjernim akterima da ubace proizvoljno izvršavanje koda u pipeline bez promene pipeline sam izvorNa primjer, korištenje PR-a

Prvi primjer jednog nesretan GitHub radni proces:

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

Kombinujući pull_request_target Okidanje radnog procesa s eksplicitnim preuzimanjem nepouzdanog PR-a je opasna praksa koja može dovesti do kompromitiranja repozitorija. U primjeru, nesretna kombinacija:

• pull_request_target događaj, koji po defaultu ima dozvolu za pisanje u ciljni repozitorij i tajne ciljnog repozitorija, čak i iz vanjskih forkova, i pokreće se u kontekstu ciljnog repozitorija PR-a,
• provjerite PR kod iz izvora, nepouzdani repozitorij,
• pokrenuti bilo koji skript koji može raditi na PR kontroliranom sadržaju, kao u slučaju npm install, I
• 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 nepouzdan unos (iz problema, komentara ili pull request) kao izvor za argumente proslijeđene pipeline komanda putem izraza. Ovo je pipeline verzija ranjivosti ubrizgavanja komandi operativnog sistema.

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

Operacija pokretanja generira privremeni shell skript na osnovu predloška, ​​sa $ zamijenjen, što ga čini ranjivim na ubrizgavanje shell komandi. 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 momci su otvarali vrata za ubrizgavanje komandi jednostavnim otvaranjem problema...

Postojale su ranjivosti u izvršavanju koda u GitHub akcijama, kao što su gajira-komentar, sada popravljeno. Molimo pročitajte „Nepouzdan unos u GitHub radnim procesima“ za sve detalje.

Moral priče: Nikada nemojte provjeravati i kreirati PR-ove iz nepouzdanih izvora bez prethodnog pregleda PR-a. 'Nepouzdano' ovdje, osim ako nije pod drakonskom autentifikacijom porijekla, može značiti bilo koji potencijalno otet račun programera.

 

Nenamjerno postavljanje zlonamjernog softvera ovdje!

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

Rizici potpuno automatizovanog raspoređivanja iz izvora commit za produkcijske sisteme uključuju mogućnost da se zlonamjerni kod implementira u produkcijska okruženja bez otkrivanja, kao i mogućnost da greške u procesu implementacije uzrokuju poremećaje ili prekide u radu.

Kako bi se ublažili ovi rizici, često se preporučuje da organizacije implementiraju „tvrdi prekid“ u svom procesu implementacije, što zahtijeva ljudsko odobrenje 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 najlijenji programer ga koristi!

M3M3N70Borimo se protiv 2FA, ali to nije tako lako. Teško je prevariti te ljude putem spear-phishinga, jer... "Scatter Swine" je uradio sa TwiliomSa WebAuthn ključevima je mnogo teže. Barem možemo pokušati krađa kolačića kako bi se zaobišao MFA, ali treba provaliti u kutiju programera.

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

Bijes u močvariDevOps momci se bude. Imaju prokletu stvar sa "najmanjim privilegijama" u krvi. I više nisu programski majmuni. Sada nas recenzenti hvataju na djelu.

Zapravo, 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 čitaoca: da li je proces izgradnje softvera iz izvornog koda i njegovog implementacije u produkciju rizičan posao? Možete li zamisliti svoj DevOps u fazi... dobra stara vremena za loše momke?

Završne preporuke

Odakle početi CI/CD pipelines?

Prva preporuka je ovdje jednostavna: Pažljivo pregled pipelines (oni su kritičan resursi) za sigurnosne probleme. Pregledi su skupi, ali neophodni i treba ih pravilno obaviti. Recenzenti trebaju biti svjesni na šta treba obratiti pažnju. 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 servisima, izbjegavajući gnjavažu oko rukovanja dugoročnim akreditivima.
• Kako ograničiti pipelines na tačan skup resursa kojima je potreban pristup. Princip najmanjih privilegija ponovo blista.
• Kako napisati korake za izradu pipelines reproducibilnim poput pinovanja verzija i izbjegavanjem ranjivosti ubrizgavanja komandi.
• Kako odobriti implementacije iz sigurnosne perspektive (oni su drugi!): koja sigurnost standards trebaju biti usklađeni i kako dodati odgovarajuće provjere/kapije u pipelines.

Treća preporuka je da konfigurirati CI/CD sistem s dužnom pažnjomSnažna autentifikacija, bez zadanih lozinki ili nesigurnih postavki, minimalne privilegije… Vodite računa o ranjivostima u instaliranim dodacima i ekstenzijama. Ovo bi mogao biti fokus narednih 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 kontejnera ili automatizirani detektori vremena izvođenja (DAST i zlonamjerni softver) mogu se rutinski pokretati na pipelineI vaša organizacija može provoditi standardo izvještavanju o sigurnosnom skeniranju u CI/CD.

Podsjećamo, ovi alati ipak ne isključuju stručnu procjenu iz jednačine, u suprotnom biste mogli imati lažni osjećaj sigurnosti.

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

Napomena o odricanju od odgovornosti

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

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

Da pročitate više

• Haymore, A. i dr. 10 priča iz stvarnog svijeta o tome kako smo pravili kompromise CI/CD pipelines ”NCC Grupa, januar 2022.
• configure-aws-credentials Radnja na GitHubu i Konfigurisanje OpenID Connect-a u Amazon Web Services-u za detalje o tome kako pokrenuti AWS naredbe za implementaciju u GitHub workflow-ovima.
• Lobačevski J. „Održavanje sigurnosti vaših GitHub akcija i radnih procesa 1. dio: Sprečavanje pwn zahtjeva“GitLab Sigurnosna laboratorija, decembar 2020.
• Lobačevski J. „Održavanje sigurnosti vaših GitHub akcija i radnih procesa - 2. dio: Nepouzdani unos“GitLab Sigurnosna laboratorija, januar 2021.
• OWASP. "OWASP Top 10" CI/CD Sigurnosni rizici”Jul 2022.
• Saltzer J. i Schroeder M. "Zaštita informacija u računarskim sistemima"April 1975. Principi sigurnosti su se razvijali zajedno s tehnologijom, ali 47 godina kasnije većina S&S ideja ostaje na snazi.
• NCSC Ujedinjenog Kraljevstva. "Osigurajte izgradnju i implementaciju" pipeline"Nacionalni centar za sajber sigurnost Ujedinjenog Kraljevstva, februar 2019.