Kaj lahko gre narobe CI/CD pipelines?

Neprekinjena integracija in neprekinjena dobava (CI/CD) pipelineso temelj vsake organizacije za programsko opremo, ki gradi programsko opremo na »sodoben« način. Avtomatizacija zagotavlja veliko moč, vendar večina razvijalcev spregleda odgovornost, ki jo prinaša.

RazvojniJa, vzamemo CI/CD varnost resno in imeti močan nadzor nad vzdrževalci kode, pregledati commitpred združitvami; delovna mesta in pipelineVzdržujejo jih višji uslužbenci, ki skrbijo, da skrivnosti ne razkrijejo. pipelineIn orodje je namestilo osebje, ki se na to spozna. Kaj lahko gre narobe?

Spoštovani razvijalec, CI/CD Sistemi so kompleksni. Njegova široka površina napada je privabljala zlonamerne akterje. Bolje je biti previden in nikoli preveč samozavesten.

Privzeta konfiguracija se včasih ohrani in postane najboljši prijatelj hekerjev. Kritične pomanjkljivosti so lahko prisotne v CI/CD pipeline virov, v konfiguraciji sistema ali okoli procesa in konteksta pipeline in kako se sproži.

V tej objavi se bomo postavili v kožo slabih igralcev. Predstavljajte si, da beremo razmišljanja M3M3N70 (Spomin na smrt?) in Močvirska jeza nekje na temnem spletu, verjetno v nezahodnem jeziku, vendar nikoli ne spreglejte, da se zlo širi po vsem svetu.

 

V dobrih starih časih je bilo tako enostavno ...

M3M3N70Nazaj v dobre stare čase, naše poslovanje je bilo taaako enostavno ... Ničelni dnevi so bili lahko dosegljivi, aplikacije so bile na široko odprte z lahko izkoriščevalnimi ranljivostmi in v hipu smo se lahko premaknili stran od podjetja.

Močvirska jezaJebem ti! Nekaj ​​norcev je že tam zunaj, ampak stvari so se spremenile. Veliki fantje so veliko denarja vložili v to sranje z AppSec-om.

M3M3N70Ja. Ampak novi bedaki so razvijalci. Za nas je bilo lažje izbrati orodja, ki jih uporabljajo ti fantje. Še posebej CI je pravi rudnik zlata! Žetoni za dostop do oblaka, SCM poverilnice, gesla za produkcijsko bazo podatkov, zasebni ključi SSH, poverilnice drugih uporabnikov CI ... Skok iz dolgočasnih razvojnih stvari na pravo bistvo je bil precej trivialen.

Avtomatizacija za gradnjo, testiranje in uvajanje programske opreme z CI/CD Orodje pogosto zahteva posredovanje skrivnosti ukazom v korakih. In pogosto pride do razkritja, kar ima za posledico zloglasne posledice.

PipelinePotrebujejo skrivnosti, ki včasih pricurljajo na dan

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.

Morda so bili dobri stari časi, da smo v zgodovini Gita našli .env datoteka (razvijalec jo je pozabil dodati v .gitignore):

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

ki je bil uporabljen v delovnem procesu GitHub .github/deploy.yaml ki je vseboval nekaj takega:

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! Tisti AWS ključi so delovali! Najprej smo preizkusili spremembo Inocuos v aplikaciji, nato pa smo dodali še Sting, saj se ti fantje niso zavedali. Bingo! Kakšna kampanja ...

Zlonamerni akter je preprosto uporabil ključe AWS za nalaganje spremenjene aplikacije z zlonamerno programsko opremo in nato s temi poverilnicami izvedel ukaz za uvajanje. Razkrite skrivnosti so bile skupaj z informacijami, ki jih je vseboval pipeline»Kakšna kampanja!« verjetno pomeni, da je Memento ubogi žrtvi povzročil opustošenje.

Kar nam Memento tukaj pove, je, da morate po uhajanju tajne informacije, kot so na primer dostopni ključi AWS v primeru, preklicati skrivnost (zamenjati zgornje ključe). takojVedno obstaja okno osvetlitve med puščanjem commit in tajno razveljavitev; Prepisovanje zgodovine Gita je težko (tudi najtrša avtoritarna država je poskušala s takim prepisovanjem zgodovine, a brez uspeha) in verjetno neučinkovito (naši prijatelji so morda klonirali pred odlaganjem tajnih informacij v repozitorij commit). Takoj zavrtite tipke in molite, medtem ko berete dnevnike dejavnosti za ciljni račun v času izpostavljenosti!

Verjetno bi morale organizacije prepoved uporabe dolgoročnih skrivnosti v CI/CD pipelinesin jih nadomestite s časovnimi poverilnicami. V prejšnjem primeru s ključi AWS v dejanjih GitHuba je varneje uporabiti Ponudnik OpenID Connect (OIDC) za pridobitev kratkotrajnih poverilnic, potrebnih za dejanja.

Močvirska jezaImel si tako srečo! Puščanje skriptov s trdo kodiranimi ključi je bila v starih časih običajna praksa, celo na javno dostopnih vedrih S3. Vse, kar si moral storiti, je bilo, da si prečkal objekte v vedru in naredil nekaj greppinga, da bi našel zanimive stvari.

Včasih je bilo območje, uporabljeno za uvajanje (v tem primeru vedro AWS S3), odprto za branje zunanjim osebam zaradi konfiguracijske napake (ki ni bila odkrita). Kaj Močvirska jeza uporabljeno je bilo nekaj takega:

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

Vedro je bilo verjetno ustvarjeno v predlogi za oskrbovanje, ki bi jo bilo mogoče samodejno pregledati glede varnostnih pomanjkljivosti.

Privzeta konfiguracija orodja je bila za nas igrača

Da bi navedli konkretne primere, se pogovorimo o Jenkins, eno najbolj priljubljenih orodij za CI.

Močvirska jezaSe spomniš tistega potrditvenega polja »Omogoči varnost« v Jenkinsu in koliko organizacij se je odločilo, da ga zaradi udobja ne aktivira? In tistih »Vsakdo lahko naredi karkoli"kombinacije dovoljenj kot privzete?" In tisti nadležni Jenkinsovi vtičniki, kot je Vtičnik GitHub OAuthTip, ki ga je konfiguriral, je izbral tako »Dodeli dovoljenja za branje vsem overjenim uporabnikom« kot »Uporabi dovoljenja repozitorija GitHub«, kar nam je omogočilo dostop do vseh njihovih projektov.

(Oprosti, Jenkins, ker sem te postavil za primer 😉

Bodite vešči (celo odvisni) od varnostnih načel. Eno je Privzeto varno načelo: kontrole bi morale imeti privzeto najvarnejše možne nastavitve. Varnost bi morala biti vgrajena v CI/CD orodja in pipelineod temeljev navzgor, namesto da bi bili naknadna misel. Vendar pa sta uporabniku prijazna in priročna oprema pogosto v nasprotju z varnostjo.

V primeru Jenkinsa je vgrajena avtentikacija preveč krhka: Nikoli ne uporabljajte vgrajenih mehanizmov za preverjanje pristnosti v JenkinsuBolje je izbrati mehanizem tretje osebe (SAML, LDAP, Google ...) z vtičnikom Role-based Authorization Strategy (»RBAC«). In bodite izjemno previdni pri admin račun.

Poskrbite za delo in pipeline datoteke v Jenkinsu so obdelane. Enako velja za Vtičnik Konfiguracija kot koda in njegove konfiguracijske datoteke, ki veljajo za konfiguracijo Jenkinsa.

Selitev iz samostojnega gostovanja CI/CD Prehod na oblačne SaaS sisteme odpravlja nekatera potencialna tveganja, ki omogočajo lateralno gibanje znotraj organizacijskega omrežja, dodaja pa še druga, kot je na primer odpiranje zunanjih povezav med obstoječimi notranjimi sistemi in eksternaliziranimi sistemi. CI/CD orodje.

Organizacije bi se morale potruditicispotrebna skrbnost pri utrjevanju CI/CD sistem, začenši z najbolj restriktivnimi nastavitvami in postopoma odpirajoč se z minimalnimi potrebnimi dovoljenji za pipeline koraki.

Konfiguriranje varnosti v CI/CD orodja so lahko zapleten podvig. Mnoga imajo vtičnike ali razširitve, ki imajo večino ranljivosti in jih je treba posodobiti.

V pomoč so lahko skenerji napačnih konfiguracij varnosti za tako kompleksna orodja ali primerjalne meritve.

Vstavljanje kode v pipeline ukazi za zabavo in dobiček

M3M3N70Ste že kdaj uporabili Nezanesljive Preverjanja Kode, ki so ranljiva dejanja in skripti, ranljivi za vbrizgavanje ukazov?

Ta razdelek kaže, da pipeline sam po sebi bi lahko imel napake v kodi, ki zlonamernim akterjem omogočajo vstavljanje poljubnega izvajanja kode v pipeline brez spreminjanja pipeline sam virNa primer z uporabo odnosov z javnostmi

Prvi primer nesrečen potek dela na GitHubu:

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

Združevanje pull_request_target Sprožilec poteka dela z eksplicitnim prevzemom nezaupanja vrednega PR je nevarna praksa, ki lahko privede do kompromitacije repozitorija. V primeru je nesrečna kombinacija:

• pull_request_target dogodek, ki ima privzeto dovoljenje za pisanje v ciljni repozitorij in skrivnosti ciljnega repozitorija, tudi iz zunanjih forkov, in se izvaja v kontekstu ciljnega repozitorija PR,
• preverite PR kodo iz izvorne kode, nezaupanja vrednega repozitorija,
• sprožiti kateri koli skript, ki lahko deluje na vsebinah, nadzorovanih s strani PR, kot v primeru npm installin
• brez uporabe pogoja za sprožitev pull_request_target dogodek se izvede le, če je zahtevi za spremembo dodeljena nekakšna oznaka »ta zahteva za spremembo je bila preverjena« (zunanji uporabniki zahtevi za spremembo ne morejo dodeliti oznak).

Drugi primer upošteva nezanesljive vnose (iz težave, komentarja ali pull request) kot vir za argumente, posredovane pipeline ukaz prek izrazov. To je pipeline različica ranljivosti vbrizgavanja ukazov operacijskega sistema.

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

Operacija zagona ustvari začasni skript lupine na podlagi predloge z $ zamenjan, zaradi česar je ranljiv za vbrizgavanje ukazov lupine. Napadalec z lažnim računom GitHub bi lahko povzročil težavo z naslovom a"; bad_code_goes_here;#, in bum! 

Močvirska jezaOh, ti fantje so odpirali vrata za vbrizgavanje ukazov preprosto z odpiranjem težave ...

V dejanjih GitHuba so bile ranljivosti pri izvajanju kode, kot so gajira-komentar, zdaj popravljeno. Prosimo, preberite »Nezanesljiv vnos v delovne poteke GitHuba« za vse podrobnosti.

Moral zgodbe: Nikoli ne preverjajte in ne sestavljajte PR-jev iz nezanesljivih virov, ne da bi jih prej pregledali. »Nezaupanja vredno« tukaj, razen če gre za drakonsko preverjanje izvora, lahko pomeni kateri koli potencialno ugrabljen račun razvijalca.

 

Nenamerna namestitev zlonamerne programske opreme tukaj!

Neprekinjeno uvajanje je vrhunec avtomatizacije, vendar bi ta vrhunec lahko bil onemogočen zaradi pomanjkanja ustreznih kontrol odobritve na pipeline pretok.

Tveganja popolnoma avtomatizirane uvedbe iz vira commit v produkcijske sisteme vključujejo možnost, da se zlonamerna koda namesti v produkcijska okolja, ne da bi bila zaznana, pa tudi možnost, da napake v procesu uvajanja povzročijo motnje ali izpade.

Da bi ublažili ta tveganja, se organizacijam pogosto priporoča, da v svojem procesu uvajanja uvedejo »trdo prekinitev«, ki zahteva človeško odobravanje preden so izdaje nameščene v končna okolja.

Zapirajo vrata

Močvirska jezaTista vesela privzeta gesla v CI/CD orodja se brišejo. Dostop do /var/lib/jenkins/secrets/initialAdminPassword je zdaj slepa pot. Številna orodja zdaj ponujajo 2FA, ki ga je Covid pritegnil, in celo najbolj leni programerji ga uporabljajo!

M3M3N70Borimo se proti dvofaktorski avtorizaciji (2FA), vendar ni tako enostavno. Težko je te fante pretentati s spear phishingom, saj "Scatter Swine" je naredil s TwiliomS ključi WebAuthn je veliko težje. Vsaj poskusimo lahko kradejo piškotke za obhod MFA, ampak moram vdreti v razvijalčevo polje.

Večfaktorska avtentikacija je dober korak v pravo smer za omejevanje tveganja uhajanja skrivnosti za avtentikacijo. Večina sodobnih orodij DevOps podpira MFA. Ključi za avtentikacijo pa so pod WebAuthn / U2F (glejte Projekt FIDO2) so morda najboljša možnost za MFA v DevOps, če so pravilno upravljani.

Močvirska jezaDevOps fantje se prebujajo. V krvi imajo prekleto stvar z "najmanjšimi privilegiji". In niso več kodniški opice. Zdaj nas recenzenti ujamejo pri delu.

Pravzaprav, pipelineso zdaj nekoliko bolj robustni kot pred nekaj leti, saj so bila odstranjena šibka dejanja in skripti, poleg tega pa so bili uvedeni dodatni koraki varnostnega testiranja, ki so celo zaznali naše skrivalne skripte. commitin paketi, ki smo jih ugrabili.

Vprašanje za bralca: ali je postopek gradnje programske opreme iz izvorne kode in uvajanja v produkcijo tvegan posel? Si lahko predstavljate svoj DevOps v fazi dobri časi za slabe fante?

Končna priporočila

Kje začeti CI/CD pipelines?

Prvo priporočilo je tukaj preprosto: Previdno pregleda pipelines (so kritično viri) za varnostne težave. Pregledi so dragi, vendar potrebni in jih je treba opraviti pravilno. Pregledovalci se morajo zavedati, na kaj morajo biti pozorni. Vsak korak je treba preveriti glede pomanjkljivosti.

Morda bi lahko pomagala kombinacija strokovnih ocenjevalcev, oboroženih z avtomatiziranimi skenerji zlonamerne kode.

Drugo priporočilo je, da usposabljanje razvijalcev, ki pišejo pipelinein jih vzdrževati na varnemStvari, ki jih je treba upoštevati:

• Kako pravilno upravljati preverjanje pristnosti z internimi in oblačnimi storitvami, pri čemer se izogniti nadlogam pri upravljanju dolgoročnih poverilnic.
• Kako omejiti pipelinedo natančnega nabora virov, do katerih potrebuje dostop. Načelo najmanjših privilegijev znova zasije.
• Kako napisati korake za izdelavo pipelineje ponovljiva, kot je pripenjanje različic, in izogibanje ranljivostim pri vbrizgavanju ukazov.
• Kako odobriti uvedbe z varnostnega vidika (to so drugi!): katera varnost standards se morajo ujemati in kako dodati ustrezna preverjanja/vrata v pipelines.

Tretje priporočilo je, da konfigurirajte CI/CD sistem s potrebno skrbnostjoMočna avtentikacija, brez privzetih gesel ali nezaščitenih nastavitev, minimalni privilegiji ... Poskrbite za ranljivosti v nameščenih vtičnikih in razširitvah. To bi lahko bila osrednja tema naslednjih objav, spremljajte nas.

Četrto priporočilo je, da izkoristite CI/CD pipelineza varnostno avtomatizacijoAnaliza izvorne kode (SAST), analiza sestave vira (SCA), skeniranje puščanja skrivnosti, orodja za zaščito pred zlonamerno programsko opremo, skenerji varnosti vsebnikov ali avtomatizirani detektorji med izvajanjem (DAST in zlonamerna programska oprema) se lahko rutinsko izvajajo na pipelineIn vaša organizacija lahko uveljavi standardo pokritosti varnostnega skeniranja v CI/CD.

Ne pozabite, da ta orodja ne izključujejo strokovnega pregleda, sicer bi lahko imeli lažen občutek varnosti.

Če ste vešči lestvice najboljših desetih na OWASP-u, je lep nedavni projekt 10 najboljših OWASP CI/CD Varnostno tveganje.

Opomba o omejitvi odgovornosti

(1) Primeri v tej objavi uporabljajo GitHub kot SCM, AWS kot ponudnik storitev v oblaku in GitHub Actions ali Jenkins kot CI/CD orodje. Niso šibkejša/varnejša od svojih alternativ. Brez slabega namena za medije! Ta orodja so močna in jih je treba uporabljati ustrezno.

(2) M3M3N70 in Močvirska jeza so izmišljeni liki. Vsaka podobnost z osebami ali skupinami, živimi ali mrtvimi, je zgolj naključna ... ali pač?

Za branje več

• Haymore, A. et al. "10 resničnih zgodb o tem, kako smo sklepali kompromise" CI/CD pipelines "Skupina NCC, januar 2022.
• configure-aws-credentials Dejanje GitHuba in Konfiguriranje OpenID Connect v storitvah Amazon Web Services za podrobnosti o tem, kako izvajati ukaze AWS za uvajanje v delovnih tokovih GitHub.
• Lobačevski J. »Zaščita vaših dejanj in delovnih procesov na GitHubu 1. del: Preprečevanje zahtevkov pwn«Varnostni laboratorij GitLab, december 2020.
• Lobačevski J. »Zaščita dejanj in delovnih procesov na GitHubu – 2. del: Nezaupanja vreden vnos«Varnostni laboratorij GitLab, januar 2021.
• OWASP. "OWASP Top 10" CI/CD Varnostna tveganja””Julij 2022.
• Saltzer J. in Schroeder M. "Varstvo informacij v računalniških sistemih"April 1975. Varnostna načela so se razvijala skupaj s tehnologijo, vendar 47 let pozneje večina idej varnosti in varnosti ostaja v veljavi.
• NCSC Združenega kraljestva. "Zavarujte gradnjo in uvajanje" pipeline"Nacionalni center za kibernetsko varnost Združenega kraljestva, februar 2019.