Atlantis Security
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis help jou basies om terraform vanaf Pull Requests van jou git bediener te laat loop.
Gaan na die atlantis vrylating bladsy in https://github.com/runatlantis/atlantis/releases en aflaai die een wat vir jou geskik is.
Skep 'n persoonlike token (met repo toegang) van jou github gebruiker.
Voer ./atlantis testdrive uit en dit sal 'n demo repo skep wat jy kan gebruik om met atlantis te praat.
Jy kan die webblad in 127.0.0.1:4141 toegang.
Atlantis ondersteun verskeie git gashere soos Github, Gitlab, Bitbucket en Azure DevOps. Echter, om toegang tot die repos in daardie platforms te verkry en aksies uit te voer, moet dit 'n paar privilegierte toegang gegee word (ten minste skrywe toestemmings). Die dokumentasie moedig aan om 'n gebruiker in hierdie platforms spesifiek vir Atlantis te skep, maar sommige mense mag persoonlike rekeninge gebruik.
In elk geval, vanuit 'n aanvaller se perspektief, gaan die Atlantis rekening een baie interessante te kompromitteer wees.
Atlantis gebruik opsioneel Webhook geheime om te verifieer dat die webhooks wat dit van jou Git gasheer ontvang legitiem is.
Een manier om dit te bevestig, sou wees om toestemming te gee dat versoeke slegs van die IP's van jou Git gasheer kom, maar 'n makliker manier is om 'n Webhook Geheim te gebruik.
Let daarop dat tensy jy 'n private github of bitbucket bediener gebruik, jy webhooks eindpunte aan die internet moet blootstel.
Atlantis gaan webhooks blootstel sodat die git bediener dit inligting kan stuur. Vanuit 'n aanvaller se perspektief sal dit interessant wees om te weet of jy dit boodskappe kan stuur.
Atlantis loop Terraform deur eenvoudig terraform plan en apply op die bediener waarop Atlantis gehost word. Net soos wanneer jy Terraform plaaslik loop, het Atlantis kredensiale vir jou spesifieke verskaffer nodig.
Dit is aan jou hoe jy kredensiale verskaf vir jou spesifieke verskaffer aan Atlantis:
Die Atlantis Helm Chart en AWS Fargate Module het hul eie meganismes vir verskaffer kredensiale. Lees hul dokumentasie.
As jy Atlantis in 'n wolk loop, het baie wolke maniere om wolk API toegang aan toepassings wat daarop loop te gee, bv:
AWS EC2 Rolle (Soek vir "EC2 Rol")
Baie gebruikers stel omgewing veranderlikes in, bv. AWS_ACCESS_KEY, waar Atlantis loop.
Ander skep die nodige konfigurasie lêers, bv. ~/.aws/credentials, waar Atlantis loop.
Gebruik die HashiCorp Vault Provider om verskaffer kredensiale te verkry.
Die houer waar Atlantis loop sal hoogs waarskynlik privilegierte kredensiale vir die verskaffers (AWS, GCP, Github...) wat Atlantis via Terraform bestuur, bevat.
Standaard sal Atlantis 'n webblad in poort 4141 op localhost loop. Hierdie bladsy laat jou net toe om atlantis toep te laat of te verwyder en die planstatus van die repos te kontroleer en hulle te ontgrendel (dit laat nie toe om dinge te verander nie, so dit is nie so nuttig nie).
Jy sal waarskynlik nie vind dat dit aan die internet blootgestel is nie, maar dit lyk asof standaard geen kredensiale benodig word om toegang te verkry nie (en as hulle is, is atlantis:atlantis die standaard een).
Konfigurasie vir atlantis server kan gespesifiseer word via opdraglyn vlae, omgewing veranderlikes, 'n konfigurasie lêer of 'n mengsel van die drie.
Jy kan hier die lys van vlae wat deur Atlantis bediener ondersteun word, vind.
Waardes word in hierdie volgorde gekies:
Vlae
Omgewing Veranderlikes
Konfigurasie Lêer
Let daarop dat jy in die konfigurasie dalk interessante waardes soos tokens en wagwoorde kan vind.
Sommige konfigurasies beïnvloed hoe die repos bestuur word. Dit is egter moontlik dat elke repo verskillende instellings vereis, so daar is maniere om elke repo spesifiek te spesifiseer. Dit is die prioriteitsorde:
Repo /atlantis.yml lêer. Hierdie lêer kan gebruik word om te spesifiseer hoe atlantis die repo moet hanteer. Echter, standaard kan sommige sleutels nie hier gespesifiseer word nie sonder sommige vlae wat dit toelaat.
Waarskynlik vereis om deur vlae soos allowed_overrides of allow_custom_workflows toegelaat te word.
Bediener Kante Konfigurasie: Jy kan dit met die vlag --repo-config deurgee en dit is 'n yaml wat nuwe instellings vir elke repo konfigureer (regexes ondersteun).
Standaard waardes.
PR Beskermings
Atlantis laat toe om aan te dui of jy wil hê die PR moet goedgekeur word deur iemand anders (selfs al is dit nie in die tak beskerming ingestel nie) en/of mergable wees (tak beskermings geslaag) voor die toep van toepassing is. Vanuit 'n sekuriteitsoogpunt is dit aanbeveel om albei opsies in te stel.
In die geval dat allowed_overrides waar is, kan hierdie instelling op elke projek oorgeskryf word deur die /atlantis.yml lêer.
Skripte
Die repo konfigurasie kan skripte spesifiseer om voor (pre workflow hooks) en na (post workflow hooks) 'n workflow uitgevoer word.
Daar is geen opsie om **hierdie skripte in die repo /atlantis.yml lêer te spesifiseer nie.
Workflow
In die repo konfigurasie (bediener kant konfigurasie) kan jy 'n nuwe standaard workflow spesifiseer, of nuwe pasgemaakte workflows skep. Jy kan ook spesifiseer watter repos toegang kan hê tot die nuwe wat gegenereer is. Dan kan jy die atlantis.yaml lêer van elke repo toelaat om die workflow te spesifiseer wat gebruik moet word.
As die bediener kant konfigurasie vlag allow_custom_workflows op Waar gestel is, kan workflows in die atlantis.yaml lêer van elke repo gespesifiseer word. Dit is ook potensieel nodig dat allowed_overrides ook workflow spesifiseer om die workflow te oorgeskryf wat gaan gebruik word.
Dit sal basies RCE in die Atlantis bediener aan enige gebruiker wat toegang tot daardie repo kan kry, gee.
Conftest Beleid Kontrole
Atlantis ondersteun die uitvoering van server-side conftest beleide teen die plan-uitset. Algemene gebruiksgevalle vir hierdie stap sluit in:
Weiering van die gebruik van 'n lys van modules
Bevestiging van eienskappe van 'n hulpbron tydens die skepping
Vang van onbedoelde hulpbronverwyderings
Voorkoming van sekuriteitsrisiko's (bv. blootstelling van veilige poorte aan die publiek)
Jy kan kyk hoe om dit te konfigureer in die dokumentasie.
In die dokumentasie kan jy die opsies vind wat jy kan gebruik om Atlantis te laat loop:
As jy tydens die ontginning hierdie fout vind: Error: Error acquiring the state lock
Jy kan dit regmaak deur te hardloop:
As jy skryfrechten oor 'n repository het, sal jy in staat wees om 'n nuwe tak daarop te skep en 'n PR te genereer. As jy atlantis plan kan uitvoer (of dalk word dit outomaties uitgevoer), sal jy in staat wees om RCE binne die Atlantis bediener te hê.
Jy kan dit doen deur Atlantis 'n eksterne databron te laat laai. Sit net 'n payload soos die volgende in die main.tf-lêer:
Stealthier Aanval
Jy kan hierdie aanval selfs op 'n stealthier manier uitvoer deur hierdie voorstelle te volg:
In plaas daarvan om die rev shell direk in die terraform-lêer te voeg, kan jy 'n eksterne hulpbron laai wat die rev shell bevat:
You can find the rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules
In die eksterne hulpbron, gebruik die ref kenmerk 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 master te skep om Atlantis te aktiveer, 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 secrets wat deur terraform gebruik word dump deur atlantis plan (terraform plan) te loop deur iets soos dit in die terraform-lêer te plaas:
As jy skrywe toegang oor 'n repository het, 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 in staat wees om RCE binne die Atlantis bediener te hê.
Jy sal egter gewoonlik sommige beskermings moet omseil:
Mergeable: As hierdie beskerming in Atlantis gestel is, kan jy slegs atlantis apply uitvoer as die PR mergeable is (wat beteken dat die tak beskerming omseil moet word).
Kontroleer potensiële tak beskerming omseilings
Goedgekeurd: As hierdie beskerming in Atlantis gestel is, moet 'n ander gebruiker die PR goedkeur voordat jy atlantis apply kan uitvoer.
Standaard kan jy die Gitbot token misbruik om hierdie beskerming om te seil
Voer terraform apply uit op 'n kwaadwillige Terraform-lêer met local-exec.
Jy moet net seker maak dat 'n payload soos die volgende in die main.tf lêer eindig:
Volg die voorstelle van die vorige tegniek om hierdie aanval op 'n stealthier manier uit te voer.
Wanneer jy atlantis plan of atlantis apply uitvoer, word terraform onder-needs uitgevoer, jy kan opdragte aan terraform deur atlantis deur iets soos te kommentaar:
Something you can pass are env variables which might be helpful to bypass some protections. Check terraform env vars in https://www.terraform.io/cli/config/environment-variables
Running malicious custom build commands specified in an atlantis.yaml file. Atlantis uses the atlantis.yaml file from the pull request branch, not of master.
This possibility was mentioned in a previous section:
As die server side config vlag allow_custom_workflows op True gestel is, kan workflows gespesifiseer word in die atlantis.yaml lêer van elke repo. Dit is ook moontlik nodig dat allowed_overrides ook workflow spesifiseer om die workflow wat gebruik gaan word te oorheers.
This will basically give RCE in the Atlantis server to any user that can access that repo.
As die server side config vlag allowed_overrides gekonfigureer is met apply_requirements, is dit moontlik vir 'n repo om die plan/apply beskermings te wysig om hulle te omseil.
As iemand atlantis plan/apply kommentaar op jou geldige pull requests stuur, sal dit veroorsaak dat terraform loop wanneer jy dit nie wil hê nie.
Boonop, as jy nie in die branch protection gekonfigureer het om te vra om elke PR te herwaardeer wanneer 'n nuwe commit gestuur word nie, kan iemand kwaadwillige konfigurasies (kyk vorige scenario's) in die terraform konfigurasie skryf, atlantis plan/apply uitvoer en RCE verkry.
Dit is die instelling in Github branch protections:
As jy daarin slaag om die webhook secret te steel of as daar geen webhook secret gebruik word nie, kan jy die Atlantis webhook aanroep en atlatis opdragte direk aanroep.
Bitbucket Cloud ondersteun nie webhook secrets nie. Dit kan aanvallers toelaat om versoeke van Bitbucket te spoof. Verseker dat jy slegs Bitbucket IP's toelaat.
Dit beteken dat 'n aanvaller valse versoeke aan Atlantis kan maak wat lyk asof dit van Bitbucket kom.
As jy --repo-allowlist spesifiseer, kan hulle slegs valse versoeke rakende daardie repos maak, so die meeste skade wat hulle kan aanrig, sal wees om te plan/apply op jou eie repos.
Om dit te voorkom, laat Bitbucket se IP adresse toe (sien Uitgaande IPv4 adresse).
As jy daarin geslaag het om toegang tot die bediener te verkry of ten minste 'n LFI daar het, is daar 'n paar interessante dinge wat jy moet probeer lees:
/home/atlantis/.git-credentials Bevat vcs toegang akkrediteer
/atlantis-data/atlantis.db Bevat vcs toegang akkrediteer met meer inligting
/atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform state file
Voorbeeld: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ Omgewings veranderlikes
/proc/[2-20]/cmdline Cmd lyn van atlantis server (kan sensitiewe data bevat)
Omdat enigiemand op publieke pull requests kan kommentaar lewer, selfs met al die sekuriteitsmitigaties beskikbaar, is dit steeds gevaarlik om Atlantis op publieke repos te laat loop sonder behoorlike konfigurasie van die sekuriteitsinstellings.
--allow-fork-prs Gebruik nieAs jy op 'n publieke repo loop (wat nie aanbeveel word nie, sien hierbo) moet jy nie --allow-fork-prs stel nie (standaard is vals) omdat enigiemand 'n pull request van hul fork na jou repo kan oopmaak.
--repo-allowlistAtlantis vereis dat jy 'n allowlist van repositories spesifiseer waarvan dit webhooks sal aanvaar via die --repo-allowlist vlag. Byvoorbeeld:
Spesifieke repositories: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
Jou hele organisasie: --repo-allowlist=github.com/runatlantis/*
Elke repository in jou GitHub Enterprise installasie: --repo-allowlist=github.yourcompany.com/*
Alle repositories: --repo-allowlist=*. Nuttig wanneer jy in 'n beskermde netwerk is, maar gevaarlik sonder om ook 'n webhook secret in te stel.
Hierdie vlag verseker dat jou Atlantis installasie nie gebruik word met repositories wat jy nie beheer nie. Sien atlantis server --help vir meer besonderhede.
As aanvallers pull requests met kwaadwillige Terraform kode indien in jou bedreigingsmodel, moet jy bewus wees dat terraform apply goedkeuringe nie genoeg is nie. Dit is moontlik om kwaadwillige kode in 'n terraform plan te loop deur die external data source of deur 'n kwaadwillige verskaffer te spesifiseer. Hierdie kode kan dan jou akkrediteer uitvreet.
Om dit te voorkom, kan jy:
Verskaffers in die Atlantis beeld bak of gasheer en egress in produksie ontken.
Die verskaffer registrasie protokol intern implementeer en publieke egress ontken, sodat jy beheer wie skrywe toegang tot die registrasie het.
Jou server-side repo konfigurasie's plan stap aanpas om te valideer teen die gebruik van verbode verskaffers of data bronne of PRs van nie-toegelate gebruikers. Jy kan ook ekstra validasie by hierdie punt voeg, bv. 'n "duim-op" op die PR vereis voordat jy die plan toelaat om voort te gaan. Conftest kan hier nuttig wees.
Atlantis moet met Webhook secrets gedraai word wat via die $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET omgewingsveranderlikes ingestel is. Selfs met die --repo-allowlist vlag ingestel, kan aanvallers versoeke aan Atlantis maak wat as 'n repository wat toegelaat is, voorgee. Webhook secrets verseker dat die webhook versoeke werklik van jou VCS verskaffer (GitHub of GitLab) kom.
As jy Azure DevOps gebruik, voeg in plaas van webhook secrets 'n basiese gebruikersnaam en wagwoord by.
Azure DevOps ondersteun die stuur van 'n basiese verifikasie kop in alle webhook gebeurtenisse. Dit vereis die gebruik van 'n HTTPS URL vir jou webhook ligging.
As jy webhook secrets gebruik, maar jou verkeer is oor HTTP, kan die webhook secrets gesteel word. Aktiveer SSL/HTTPS met die --ssl-cert-file en --ssl-key-file vlaggies.
Dit word sterk aanbeveel om verifikasie in die webdiens te aktiveer. Aktiveer BasicAuth met die --web-basic-auth=true en stel 'n gebruikersnaam en 'n wagwoord op met die --web-username=yourUsername en --web-password=yourPassword vlaggies.
Jy kan ook hierdie as omgewingsveranderlikes deurgee ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername en ATLANTIS_WEB_PASSWORD=yourPassword.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
