Last updated
Atlantis help jou basies om terraform vanaf Pull Requests van jou git-bediener te hardloop.
Gaan na die atlantis vrystellingsbladsy by https://github.com/runatlantis/atlantis/releases en laai af die een wat by jou pas.
Skep 'n persoonlike token (met repo-toegang) van jou github gebruiker
Voer ./atlantis testdrive uit en dit sal 'n demonstrasie-repo skep wat jy kan gebruik om met atlantis te praat
Jy kan die webbladsy besoek by 127.0.0.1:4141
Atlantis ondersteun verskeie git-gashere soos Github, Gitlab, Bitbucket en Azure DevOps. Nietemin, om toegang tot die repositories op daardie platforms te verkry en aksies uit te voer, moet daar aan hulle 'n sekere bevoorregte toegang verleen word (ten minste skryftoestemmings). Die dokumente moedig aan om 'n gebruiker in hierdie platforms spesifiek vir Atlantis te skep, maar sommige mense mag persoonlike rekeninge gebruik.
In enige geval, vanuit 'n aanvaller se perspektief, gaan die Atlantis-rekening een wees wat baie interessant is om te kompromiteer.
Atlantis gebruik opsioneel Webhook-geheime om te valideer dat die webhooks wat dit van jou Git-bediener ontvang, wettig is.
Een manier om dit te bevestig sou wees om versoeke slegs vanaf die IP-adresse van jou Git-bediener toe te laat, maar 'n makliker manier is om 'n Webhook-geheim te gebruik.
Let daarop dat tensy jy 'n privaat github- of bitbucket-bediener gebruik, sal jy die webhook-eindpunte aan die internet moet blootstel.
Atlantis gaan webhooks blootstel sodat die git-bediener dit inligting kan stuur. Vanuit 'n aanvaller se perspektief sou dit interessant wees om te weet of jy dit kan gebruik om boodskappe te stuur.
Atlantis hardloop Terraform deur eenvoudigweg terraform plan en apply-opdragte op die bediener waarop Atlantis gehuisves is uit te voer. Net soos wanneer jy Terraform plaaslik hardloop, benodig Atlantis gelde vir jou spesifieke verskaffer.
Dit is aan jou hoe jy gelde voorsien vir jou spesifieke verskaffer aan Atlantis:
Die Atlantis Helm Grafiek en AWS Fargate Module het hul eie meganismes vir verskaffer gelde. Lees hul dokumente.
As jy Atlantis in 'n wolk hardloop, het baie wolke maniere om wolk-API-toegang te gee aan programme wat op hulle hardloop, bv:
AWS EC2 Rolle (Soek na "EC2 Rol")
Baie gebruikers stel omgewingsveranderlikes in, bv. AWS_ACCESS_KEY, waar Atlantis hardloop.
Ander skep die nodige konfigurasie lêers, bv. ~/.aws/credentials, waar Atlantis hardloop.
Gebruik die HashiCorp Vault Verskaffer om verskaffer gelde te verkry.
Die houer waar Atlantis op hardloop sal hoogstwaarskynlik bevoorregte gelde vir die verskaffers (AWS, GCP, Github...) wat Atlantis via Terraform bestuur, bevat.
Standaard sal Atlantis 'n webbladsy in poort 4141 in plaaslike host hardloop. Hierdie bladsy laat jou net toe om atlantis apply aan en af te skakel en die planstatus van die repositories te kontroleer en hulle te ontgrendel (dit laat nie toe om dinge te wysig nie, so dit is nie baie nuttig nie).
Jy sal dit waarskynlik nie aan die internet blootgestel vind nie, maar dit lyk asof standaard geen gelde nodig is om dit te benader (en as dit wel is, is atlantis:atlantis die standaard een).
Konfigurasie vir atlantis bediener kan gespesifiseer word deur middel van opdraglynvlaggies, omgewingsveranderlikes, 'n konfig-lêer of 'n mengsel van die drie.
Jy kan hier die lys van vlaggies vind wat deur Atlantis-bedieners ondersteun word
Waardes word in hierdie volgorde gekies:
Vlaggies
Omgewingsveranderlikes
Konfig-lêer
Let daarop dat in die konfigurasie jy moontlik interessante waardes soos tokkens en wagwoorde kan vind.
Sommige konfigurasies beïnvloed hoe die repositories bestuur word. Dit is egter moontlik dat elke repo verskillende instellings benodig, dus is daar maniere om elke repo te spesifiseer. Dit is die prioriteitsvolgorde:
Repo /atlantis.yml lêer. Hierdie lêer kan gebruik word om te spesifiseer hoe atlantis die repo moet hanteer. Tog kan sommige sleutels nie hier gespesifiseer word sonder sekere vlaggies wat dit toelaat nie.
Waarskynlik nodig om toegelaat te word deur vlaggies soos allowed_overrides of allow_custom_workflows
Bedienerkant Konfig: Jy kan dit deurgee met die vlag --repo-config en dit is 'n yaml wat nuwe instellings vir elke repo konfigureer (regexes ondersteun)
Verstek waardes
Atlantis maak dit moontlik om aan te dui of jy wil hê dat die PR deur iemand anders goedgekeur moet word (selfs al is dit nie ingestel in die takbeskerming nie) en/of saamvoegbaar moet wees (takbeskerming geslaag) voordat die toepassing uitgevoer word. Vanuit 'n veiligheidsoogpunt word dit aanbeveel om beide opsies in te stel.
In die geval dat allowed_overrides Waar is, kan hierdie instellings oor geskryf word op elke projek deur die /atlantis.yml lêer.
Die repo-konfigurasie kan skripte spesifiseer om uit te voer voor (voor werkstroom hakies) en na (na werkstroom hakies) 'n werkstroom uitgevoer word.
Daar is nie 'n opsie om toe te laat om hierdie skripte in die repo /atlantis.yml lêer te spesifiseer nie.
In die repo-konfigurasie (bedienerkant-konfigurasie) kan jy 'n nuwe verstek-werkvloei spesifiseer, of nuwe aangepaste werkvloei skep. Jy kan ook spesifiseer watter repos kan toegang hê tot die nuwe gegenereerdes. Daarna kan jy die atlantis.yaml lêer van elke repo toelaat om die werkvloei te spesifiseer wat gebruik moet word.
Indien die bedienerkant-konfigurasie vlag allow_custom_workflows op Waar ingestel is, kan werkvloei in die atlantis.yaml lêer van elke repo gespesifiseer word. Dit is ook moontlik dat allowed_overrides ook werkvloei moet spesifiseer om die werkvloei wat gebruik gaan word, te oorheers.
Dit sal basies RCE in die Atlantis-bediener aan enige gebruiker wat toegang tot daardie repo het, gee.
Atlantis ondersteun die hardloop van bedienerkant conftest beleide teen die plan uitset. Algemene gevalle vir die gebruik van hierdie stap sluit in:
Weiering van die gebruik van 'n lys modules
Bevestiging van eienskappe van 'n hulpbron tydens skepping
Vang van onbedoelde hulpbronverwyderings
Voorkoming van sekuriteitsrisiko's (d.w.s. blootstelling van veilige poorte aan die publiek)
Jy kan sien hoe om dit te konfigureer in die dokumentasie.
In die dokumentasie kan jy die opsies vind wat jy kan gebruik om Atlantis te hardloop:
Indien jy tydens die uitbuiting hierdie fout vind: Fout: Fout met die verkryging van die toestandsluiting
Jy kan dit regmaak deur die volgende uit te voer:
Indien jy skryftoegang het tot 'n bewaarplek, sal jy in staat wees om 'n nuwe tak daarop te skep en 'n PR te genereer. As jy atlantis plan kan uitvoer (of dit word dalk outomaties uitgevoer) sal jy binne die Atlantis-bediener kan RCE.
Jy kan dit doen deur Atlantis om 'n eksterne data-bron te laat laai. Plaas net 'n lading soos die volgende in die main.tf lêer:
Jy kan hierdie aanval selfs op 'n stiller manier uitvoer deur hierdie voorstelle te volg:
In plaas daarvan om die rev shell direk in die terraform-lêer by te voeg, kan jy 'n eksterne bron laai wat die rev shell bevat:
Jy kan die rev shell-kode vind in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules
In die eksterne bron, gebruik die ref funksie om die terraform rev shell-kode in 'n tak binne die repo te verberg, iets soos: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
In plaas daarvan om 'n PR na meester te skep om Atlantis te trigger, skep 2 takke (test1 en test2) en skep 'n PR van een na die ander. Wanneer jy die aanval voltooi het, verwyder net die PR en die takke.
Jy kan geheime wat deur terraform gebruik word uitlek deur atlantis plan (terraform plan) uit te voer deur iets soos hierdie in die terraform-lêer te plaas:
Indien jy skryftoegang het tot 'n bewaarplek, sal jy in staat wees om 'n nuwe tak daarop te skep en 'n PR te genereer. As jy atlantis apply kan uitvoer, sal jy binne die Atlantis-bediener RCE kan uitvoer.
Gewoonlik sal jy egter sekere beskermings moet omseil:
Mergeable: As hierdie beskerming in Atlantis ingestel is, kan jy slegs atlantis apply hardloop as die PR mergeable is (wat beteken dat die takbeskerming omseil moet word).
Kontroleer potensiële takbeskermingsomseilings
Goedgekeur: As hierdie beskerming in Atlantis ingestel is, moet 'n ander gebruiker die PR goedkeur voordat jy atlantis apply kan hardloop
Standaard kan jy die Gitbot-token misbruik om hierdie beskerming te omseil
Hardloop terraform apply op 'n skadelike Terraform-lêer met local-exec.
Jy hoef net te verseker dat 'n sekere lading soos die volgende in die main.tf-lêer eindig:
Volg die aanbevelings van die vorige tegniek om hierdie aanval op 'n meer onopvallende manier uit te voer.
Wanneer atlantis plan of atlantis apply uitgevoer word, word terraform agter-die-skerm uitgevoer, jy kan bevele na terraform deurgee vanaf atlantis deur iets soos te kommentarieer:
Iets wat jy kan deurgee is omgewingsveranderlikes wat nuttig kan wees om sekere beskermings te omseil. Kyk na terraform omgewingsveranderlikes in https://www.terraform.io/cli/config/environment-variables
Die uitvoer van skadelike aangepaste bou-opdragte wat gespesifiseer is in 'n atlantis.yaml lêer. Atlantis gebruik die atlantis.yaml lêer van die trekversoek-tak, nie van master.
Hierdie moontlikheid is genoem in 'n vorige afdeling:
As die bedienerkant konfig vlag allow_custom_workflows op True ingestel is, kan werkvloei in die atlantis.yaml lêer van elke repo gespesifiseer word. Dit is ook moontlik nodig dat allowed_overrides ook workflow spesifiseer om die werkvloei wat gebruik gaan word, te oorheers.
Dit sal basies RCE in die Atlantis-bedieners aan enige gebruiker wat daardie repo kan bereik, gee.
Indien die bedienerkant-konfig vlag allowed_overrides het apply_requirements geconfigureer, is dit moontlik vir 'n repo om die plan/apply beskerming te bypass.
Indien iemand atlantis plan/apply kommentaar op jou geldige pull-aanvrae stuur, sal dit veroorsaak dat terraform loop wanneer jy dit nie wil nie.
Verder, indien jy nie gekonfigureer het in die takbeskerming om te vra om te heroorweeg elke PR wanneer 'n nuwe commit daarna gedruk word, kan iemand boosaardige opsette (kyk na vorige scenario's) in die terraform opstel, atlantis plan/apply hardloop en RCE verkry.
Dit is die instelling in Github takbeskerming:
As jy daarin slaag om die webhook-geheim te steel wat gebruik word of as daar geen webhook-geheim gebruik word nie, kan jy die Atlantis webhook oproep en atlantis-opdragte direk aanroep.
Bitbucket Cloud ondersteun nie webhook-geheime nie. Dit kan aanvallers toelaat om versoek van Bitbucket te vervalste. Maak seker dat jy slegs Bitbucket IP-adresse toelaat.
Dit beteken dat 'n aanvaller vals versoek aan Atlantis kan maak wat lyk asof dit van Bitbucket afkomstig is.
As jy --repo-allowlist spesifiseer, kan hulle slegs vals versoek maak wat betrekking het op daardie repos, sodat die meeste skade wat hulle kan aanrig, is om plan/apply op jou eie repos te doen.
Om dit te voorkom, lys Bitbucket se IP-adresse op (sien Uitgaande IPv4-adresse).
As jy daarin geslaag het om toegang tot die bediener te kry of ten minste 'n LFI daar het, is daar 'n paar interessante dinge wat jy moet probeer lees:
/home/atlantis/.git-credentials Bevat vcs-toegangskrediete
/atlantis-data/atlantis.db Bevat vcs-toegangskrediete met meer inligting
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform staatlêer
Voorbeeld: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Omgewingsveranderlikes
/proc/[2-20]/cmdline Cmd-lyn van atlantis server (kan sensitiewe data bevat)
Omdat enigiemand kommentaar kan lewer op openbare pull-aanvrae, selfs met al die beskikbare sekuriteitsversagtings, is dit steeds gevaarlik om Atlantis op openbare repos te hardloop sonder behoorlike konfigurasie van die sekuriteitsinstellings.
--allow-fork-prs Gebruik NieAs jy op 'n openbare repo hardloop (wat nie aanbeveel word nie, sien hierbo) moet jy nie --allow-fork-prs instel (verstek na vals) omdat enigiemand 'n pull-aanvraag van hul vurk na jou repo kan oopmaak.
--repo-allowlistAtlantis vereis dat jy 'n lys van toegelate repositoriums spesifiseer waarvan dit webhooks sal aanvaar via die --repo-allowlist vlag. Byvoorbeeld:
Spesifieke repositoriums: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Jou hele organisasie: --repo-allowlist=github.com/runatlantis/*
Elke repositorium in jou GitHub Enterprise-installasie: --repo-allowlist=github.yourcompany.com/*
Alle repositoriums: --repo-allowlist=*. Nuttig wanneer jy in 'n beskermde netwerk is, maar gevaarlik sonder om ook 'n webhook-geheim in te stel.
Hierdie vlag verseker dat jou Atlantis-installasie nie met repositoriums gebruik word wat jy nie beheer nie. Sien atlantis server --help vir meer inligting.
As aanvallers pull-aanvrae indien met boosaardige Terraform-kode in jou dreigingsmodel is, moet jy bewus wees dat terraform apply goedkeurings nie genoeg is nie. Dit is moontlik om boosaardige kode in 'n terraform plan te hardloop deur die external data bron te gebruik of deur 'n boosaardige verskaffer te spesifiseer. Hierdie kode kan dan jou geloofsbriewe uitlees.
Om dit te voorkom, kan jy:
Verskaffers in die Atlantis-beeld baklei of gasheer en uitgaande in produksie ontken.
Implementeer die verskafferregisterprotokol intern en ontken openbare uitgaande verkeer, sodat jy beheer wie skryftoegang tot die register het.
Wysig jou bedienerkant-repo-konfigurasie's plan-stap om te valideer teen die gebruik van verbode verskaffers of data-bronne of PR's van nie toegelate gebruikers nie. Jy kan ook op hierdie punt ekstra validering byvoeg, bv. 'n "duim-op" op die PR vereis voordat die plan kan voortgaan. Conftest kan hier nuttig wees.
Atlantis moet met Webhook-geheime hardloop word wat ingestel is via die $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET omgewingsveranderlikes. Selfs met die --repo-allowlist vlag ingestel, sonder 'n webhook-geheim, kan aanvallers versoek aan Atlantis maak wat voordoen as 'n repositorium wat toegelaat is. Webhook-geheime verseker dat die webhook-versoeke werklik van jou VCS-leweransier (GitHub of GitLab) afkomstig is.
Indien jy Azure DevOps gebruik, voeg in plaas van webhook-geheime 'n basiese gebruikersnaam en wagwoord by.
Azure DevOps ondersteun die stuur van 'n basiese verifikasie-kop in alle webhook-gebeure. Dit vereis dat jy 'n HTTPS-URL vir jou webhook-plek gebruik.
As jy webhook-geheime gebruik, maar jou verkeer is oor HTTP, kan die webhook-geheime gesteel word. Skakel SSL/HTTPS in deur die --ssl-cert-file en --ssl-key-file vlae te gebruik.
Dit word sterk aanbeveel om verifikasie in die webdiens in te skakel. Skakel Basiese Verifisering in deur die --web-basic-auth=true te gebruik en stel 'n gebruikersnaam en wagwoord in met die --web-username=yourUsername en --web-password=yourPassword vlae.
Jy kan dit ook as omgewingsveranderlikes deurgee ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername en ATLANTIS_WEB_PASSWORD=yourPassword.
