Atlantis Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantis मूल रूप से आपको आपके git सर्वर से Pull Requests से terraform चलाने में मदद करता है।
https://github.com/runatlantis/atlantis/releases पर atlantis releases page पर जाएं और download करें जो आपके लिए उपयुक्त हो।
अपने github उपयोगकर्ता का personal token (repo access के साथ) बनाएं।
./atlantis testdrive चलाएं और यह एक demo repo बनाएगा जिसका आप atlantis से बात करने के लिए उपयोग कर सकते हैं।
आप 127.0.0.1:4141 में वेब पृष्ठ तक पहुँच सकते हैं।
Atlantis कई git होस्ट जैसे Github, Gitlab, Bitbucket और Azure DevOps का समर्थन करता है। हालांकि, इन प्लेटफार्मों में repos तक पहुँचने और क्रियाएँ करने के लिए, इसे कुछ privileged access granted to them (कम से कम लिखने की अनुमति) की आवश्यकता होती है। The docs इन प्लेटफार्मों में Atlantis के लिए विशेष रूप से एक उपयोगकर्ता बनाने की सिफारिश करते हैं, लेकिन कुछ लोग व्यक्तिगत खातों का उपयोग कर सकते हैं।
किसी भी मामले में, एक हमलावर के दृष्टिकोण से, Atlantis account एक बहुत ही दिलचस्प हैक करने के लिए होगा।
Atlantis वैकल्पिक रूप से Webhook secrets का उपयोग करता है ताकि यह सत्यापित किया जा सके कि webhooks जो इसे आपके Git होस्ट से मिलते हैं, वे वैध हैं।
इसकी पुष्टि करने का एक तरीका यह होगा कि केवल आपके Git होस्ट के IPs से आने के लिए अनुरोधों को allowlist करें, लेकिन एक आसान तरीका Webhook Secret का उपयोग करना है।
ध्यान दें कि जब तक आप एक निजी github या bitbucket सर्वर का उपयोग नहीं करते, आपको वेबहुक एंडपॉइंट्स को इंटरनेट पर उजागर करने की आवश्यकता होगी।
Atlantis webhooks को expose करने जा रहा है ताकि git सर्वर इसे जानकारी भेज सके। एक हमलावर के दृष्टिकोण से यह जानना दिलचस्प होगा कि क्या आप इसे संदेश भेज सकते हैं।
Atlantis Terraform को बस terraform plan और apply कमांड्स को सर्वर पर चलाकर चलाता है जिस पर Atlantis होस्ट किया गया है। ठीक उसी तरह जैसे आप स्थानीय रूप से Terraform चलाते हैं, Atlantis को आपके विशेष प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता होती है।
यह आपके ऊपर है कि आप Atlantis के लिए अपने विशेष प्रदाता के लिए credentials कैसे प्रदान करते हैं:
Atlantis Helm Chart और AWS Fargate Module के पास प्रदाता क्रेडेंशियल्स के लिए अपने स्वयं के तंत्र हैं। उनके दस्तावेज़ पढ़ें।
यदि आप Atlantis को एक क्लाउड में चला रहे हैं तो कई क्लाउड में उन पर चलने वाले अनुप्रयोगों को क्लाउड API एक्सेस देने के तरीके होते हैं, जैसे:
AWS EC2 Roles ( "EC2 Role" के लिए खोजें)
कई उपयोगकर्ता पर्यावरण चर सेट करते हैं, जैसे AWS_ACCESS_KEY, जहां Atlantis चल रहा है।
अन्य आवश्यक कॉन्फ़िग फ़ाइलें बनाते हैं, जैसे ~/.aws/credentials, जहां Atlantis चल रहा है।
प्रदाता क्रेडेंशियल्स प्राप्त करने के लिए HashiCorp Vault Provider का उपयोग करें।
Container जहां Atlantis चल रहा है में उच्च संभावना है कि privileged credentials प्रदाताओं (AWS, GCP, Github...) के लिए होंगे जिन्हें Atlantis Terraform के माध्यम से प्रबंधित कर रहा है।
डिफ़ॉल्ट रूप से Atlantis एक वेब पृष्ठ को localhost में पोर्ट 4141 पर चलाएगा। यह पृष्ठ आपको atlantis apply को सक्षम/अक्षम करने और repos की योजना की स्थिति की जांच करने और उन्हें अनलॉक करने की अनुमति देता है (यह चीजों को संशोधित करने की अनुमति नहीं देता, इसलिए यह इतना उपयोगी नहीं है)।
आप शायद इसे इंटरनेट पर उजागर नहीं पाएंगे, लेकिन ऐसा लगता है कि डिफ़ॉल्ट रूप से इस तक पहुँचने के लिए कोई क्रेडेंशियल्स की आवश्यकता नहीं है (और यदि हैं तो atlantis:atlantis डिफ़ॉल्ट हैं)।
atlantis server के लिए कॉन्फ़िगरेशन को कमांड लाइन फ्लैग, पर्यावरण चर, एक कॉन्फ़िग फ़ाइल या तीनों के मिश्रण के माध्यम से निर्दिष्ट किया जा सकता है।
आप यहां फ्लैग की सूची पा सकते हैं जो Atlantis सर्वर द्वारा समर्थित हैं।
मान मानने का यह क्रम है:
Flags
Environment Variables
Config File
ध्यान दें कि कॉन्फ़िगरेशन में आप tokens और passwords जैसे दिलचस्प मान पा सकते हैं।
कुछ कॉन्फ़िगरेशन repos के प्रबंधन के तरीके को प्रभावित करते हैं। हालाँकि, यह संभव है कि प्रत्येक repo को विभिन्न सेटिंग्स की आवश्यकता हो, इसलिए प्रत्येक repo को निर्दिष्ट करने के तरीके हैं। यह प्राथमिकता क्रम है:
Repo /atlantis.yml फ़ाइल। इस फ़ाइल का उपयोग यह निर्दिष्ट करने के लिए किया जा सकता है कि atlantis को repo के साथ कैसे व्यवहार करना चाहिए। हालाँकि, डिफ़ॉल्ट रूप से कुछ कुंजियाँ यहाँ निर्दिष्ट नहीं की जा सकती हैं बिना कुछ फ्लैग्स की अनुमति के।
शायद allowed_overrides या allow_custom_workflows जैसे फ्लैग्स द्वारा अनुमति दी जानी चाहिए।
Server Side Config: आप इसे फ्लैग --repo-config के साथ पास कर सकते हैं और यह प्रत्येक repo के लिए नई सेटिंग्स को कॉन्फ़िगर करने वाला yaml है (regexes समर्थित)।
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 का उपयोग करने के लिए specify करने की अनुमति दे सकते हैं।
यदि server side config फ्लैग allow_custom_workflows को True पर सेट किया गया है, तो workflows को प्रत्येक repo के atlantis.yaml फ़ाइल में specify किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि allowed_overrides workflow को override करने के लिए भी specify करे जो उपयोग किया जाने वाला है।
यह मूल रूप से Atlantis सर्वर में RCE किसी भी उपयोगकर्ता को देगा जो उस repo तक पहुँच सकता है।
Conftest नीति जांचना
Atlantis server-side conftest नीतियों को योजना आउटपुट के खिलाफ चलाने का समर्थन करता है। इस चरण का उपयोग करने के सामान्य मामले शामिल हैं:
मॉड्यूल की एक सूची का उपयोग अस्वीकार करना
निर्माण के समय एक संसाधन के गुणों का सत्यापन करना
अनजाने में संसाधन हटाने को पकड़ना
सुरक्षा जोखिमों को रोकना (जैसे, सुरक्षित पोर्ट को सार्वजनिक रूप से उजागर करना)
आप इसे कॉन्फ़िगर करने के तरीके की जांच कर सकते हैं दस्तावेज़ों में.
दस्तावेज़ों में आप उन विकल्पों को पा सकते हैं जिनका उपयोग आप Atlantis चलाने के लिए कर सकते हैं:
यदि शोषण के दौरान आपको यह त्रुटि मिलती है: Error: Error acquiring the state lock
आप इसे चलाकर ठीक कर सकते हैं:
यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis plan को निष्पादित कर सकते हैं (या शायद यह स्वचालित रूप से निष्पादित होता है), तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे।
आप ऐसा Atlantis को एक बाहरी डेटा स्रोत लोड करने के द्वारा कर सकते हैं। बस main.tf फ़ाइल में निम्नलिखित की तरह एक पेलोड डालें:
स्टेल्थियर अटैक
आप इस अटैक को एक स्टेल्थियर तरीके से भी कर सकते हैं, इन सुझावों का पालन करके:
टेराफॉर्म फ़ाइल में सीधे रेव शेल जोड़ने के बजाय, आप एक बाहरी संसाधन लोड कर सकते हैं जिसमें रेव शेल हो:
आप रिव शेल कोड 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 को मास्टर में बनाने के बजाय Atlantis को ट्रिगर करने के लिए, 2 शाखाएँ (test1 और test2) बनाएं और एक से दूसरी के लिए PR बनाएं। जब आप हमले को पूरा कर लें, तो बस PR और शाखाओं को हटा दें।
आप terraform द्वारा उपयोग किए गए सीक्रेट्स को डंप कर सकते हैं atlantis plan (terraform plan) चलाकर, terraform फ़ाइल में कुछ इस तरह डालकर:
यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis apply निष्पादित कर सकते हैं, तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे।
हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करने की आवश्यकता होगी:
Mergeable: यदि यह सुरक्षा Atlantis में सेट की गई है, तो आप केवल atlantis apply चला सकते हैं यदि PR मर्ज करने योग्य है (जिसका मतलब है कि शाखा सुरक्षा को बायपास करना होगा)।
संभावित शाखा सुरक्षा बायपास की जांच करें
Approved: यदि यह सुरक्षा Atlantis में सेट की गई है, तो कुछ अन्य उपयोगकर्ता को PR को स्वीकृत करना होगा इससे पहले कि आप atlantis apply चला सकें
डिफ़ॉल्ट रूप से, आप Gitbot टोकन का दुरुपयोग करके इस सुरक्षा को बायपास कर सकते हैं
terraform apply को एक दुर्भावनापूर्ण Terraform फ़ाइल पर चलाना local-exec।
आपको बस यह सुनिश्चित करने की आवश्यकता है कि निम्नलिखित जैसे कुछ पेलोड main.tf फ़ाइल में समाप्त हो जाएं:
पिछली तकनीक से सुझावों का पालन करें ताकि इस हमले को छिपे हुए तरीके से किया जा सके।
जब atlantis plan या atlantis apply चलाया जाता है, तो terraform नीचे चल रहा होता है, आप atlantis से terraform को कमांड पास कर सकते हैं, कुछ इस तरह टिप्पणी करके:
कुछ चीजें जो आप पास कर सकते हैं वे env variables हैं जो कुछ सुरक्षा उपायों को बायपास करने में सहायक हो सकते हैं। terraform env vars की जांच करें https://www.terraform.io/cli/config/environment-variables
atlantis.yaml फ़ाइल में निर्दिष्ट दुष्ट कस्टम बिल्ड कमांड चलाना। Atlantis पुल अनुरोध शाखा से atlantis.yaml फ़ाइल का उपयोग करता है, master की नहीं।
इस संभावना का उल्लेख पिछले अनुभाग में किया गया था:
यदि सर्वर साइड कॉन्फ़िग ध्वज allow_custom_workflows को True पर सेट किया गया है, तो वर्कफ़्लो को प्रत्येक रेपो की atlantis.yaml फ़ाइल में निर्दिष्ट किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि allowed_overrides workflow को ओवरराइड करने के लिए भी निर्दिष्ट करता है जो उपयोग किया जाने वाला है।
यह मूल रूप से Atlantis सर्वर में किसी भी उपयोगकर्ता को RCE देगा जो उस रेपो तक पहुंच सकता है।
यदि सर्वर साइड कॉन्फ़िग ध्वज allowed_overrides में apply_requirements कॉन्फ़िगर किया गया है, तो एक रिपॉजिटरी योजना/लागू सुरक्षा को बायपास करने के लिए संशोधित कर सकती है।
यदि कोई आपके मान्य पुल अनुरोधों पर atlantis plan/apply टिप्पणियाँ भेजता है, तो यह terraform को चलाने का कारण बनेगा जब आप नहीं चाहते।
इसके अलावा, यदि आपने branch protection में यह कॉन्फ़िगर नहीं किया है कि जब एक नया कमिट इसे धकेला जाता है तो हर PR को फिर से मूल्यांकन करने के लिए कहा जाए, तो कोई दुष्ट कॉन्फ़िग्स (पिछले परिदृश्यों की जांच करें) terraform कॉन्फ़िग में लिख सकता है, atlantis plan/apply चला सकता है और RCE प्राप्त कर सकता है।
यह Github branch protections में सेटिंग है:
यदि आप वेबहुक सीक्रेट चुराने में सफल होते हैं या यदि कोई वेबहुक सीक्रेट उपयोग नहीं किया जा रहा है, तो आप Atlantis वेबहुक को कॉल कर सकते हैं और atlatis कमांड सीधे निष्पादित कर सकते हैं।
Bitbucket Cloud वेबहुक सीक्रेट्स का समर्थन नहीं करता है। यह हमलावरों को Bitbucket से अनुरोधों की नकल करने की अनुमति दे सकता है। सुनिश्चित करें कि आप केवल Bitbucket IPs की अनुमति दे रहे हैं।
इसका मतलब है कि एक हमलावर Atlantis के लिए नकली अनुरोध कर सकता है जो ऐसा दिखता है जैसे कि वे Bitbucket से आ रहे हैं।
यदि आप --repo-allowlist निर्दिष्ट कर रहे हैं तो वे केवल उन रिपोजिटरी से संबंधित नकली अनुरोध कर सकते हैं, इसलिए वे जो सबसे अधिक नुकसान कर सकते हैं वह आपके अपने रिपोजिटरी पर plan/apply करना होगा।
इसे रोकने के लिए, Bitbucket के IP पते को allowlist करें (आउटबाउंड IPv4 पते देखें)।
यदि आप सर्वर तक पहुँचने में सफल हो गए हैं या कम से कम आपके पास 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 (संवेदनशील डेटा हो सकता है)
क्योंकि कोई भी सार्वजनिक पुल अनुरोधों पर टिप्पणी कर सकता है, सभी सुरक्षा उपायों के साथ भी, सार्वजनिक रिपोजिटरी पर Atlantis चलाना उचित कॉन्फ़िगरेशन के बिना अभी भी खतरनाक है।
--allow-fork-prsयदि आप एक सार्वजनिक रिपोजिटरी पर चल रहे हैं (जो अनुशंसित नहीं है, ऊपर देखें) तो आपको --allow-fork-prs सेट नहीं करना चाहिए (डिफ़ॉल्ट रूप से false) क्योंकि कोई भी अपने फोर्क से आपके रिपोजिटरी के लिए एक पुल अनुरोध खोल सकता है।
--repo-allowlistAtlantis को आपको --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=*। जब आप एक सुरक्षित नेटवर्क में होते हैं तो यह उपयोगी है लेकिन बिना वेबहुक सीक्रेट सेट किए खतरनाक है।
यह ध्वज सुनिश्चित करता है कि आपकी Atlantis इंस्टॉलेशन उन रिपोजिटरी के साथ उपयोग नहीं की जा रही है जिन्हें आप नियंत्रित नहीं करते। अधिक विवरण के लिए atlantis server --help देखें।
यदि हमलावर दुष्ट Terraform कोड के साथ पुल अनुरोध प्रस्तुत कर रहे हैं तो यह आपके खतरे के मॉडल में है, तो आपको यह जानना चाहिए कि terraform apply अनुमतियाँ पर्याप्त नहीं हैं। यह external डेटा स्रोत का उपयोग करके या एक दुष्ट प्रदाता निर्दिष्ट करके terraform plan में दुष्ट कोड चलाना संभव है। यह कोड फिर आपके क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।
इसे रोकने के लिए, आप कर सकते हैं:
प्रदाताओं को Atlantis छवि में बेक करें या होस्ट करें और उत्पादन में निकासी को अस्वीकार करें।
आंतरिक रूप से प्रदाता रजिस्ट्री प्रोटोकॉल लागू करें और सार्वजनिक निकासी को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि किसके पास रजिस्ट्री में लिखने का अधिकार है।
अपने सर्वर-साइड रिपो कॉन्फ़िगरेशन के plan चरण को संशोधित करें ताकि अवैध प्रदाताओं या डेटा स्रोतों या अनुमति न दिए गए उपयोगकर्ताओं से PRs के उपयोग के खिलाफ मान्य किया जा सके। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे PR पर "थंब्स-अप" की आवश्यकता करना इससे पहले कि plan जारी रखने की अनुमति दी जाए। Conftest यहाँ उपयोगी हो सकता है।
Atlantis को $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET पर्यावरण वेरिएबल के माध्यम से सेट किए गए वेबहुक सीक्रेट्स के साथ चलाना चाहिए। --repo-allowlist ध्वज सेट होने के बावजूद, बिना वेबहुक सीक्रेट के, हमलावर Atlantis को एक ऐसे रिपोजिटरी के रूप में अनुरोध कर सकते हैं जो allowlisted है। वेबहुक सीक्रेट्स सुनिश्चित करते हैं कि वेबहुक अनुरोध वास्तव में आपके VCS प्रदाता (GitHub या GitLab) से आ रहे हैं।
यदि आप Azure DevOps का उपयोग कर रहे हैं, तो वेबहुक सीक्रेट्स के बजाय एक बुनियादी उपयोगकर्ता नाम और पासवर्ड जोड़ें।
Azure DevOps सभी वेबहुक घटनाओं में एक बुनियादी प्रमाणीकरण हेडर भेजने का समर्थन करता है। इसके लिए आपके वेबहुक स्थान के लिए HTTPS URL का उपयोग करना आवश्यक है।
यदि आप वेबहुक सीक्रेट्स का उपयोग कर रहे हैं लेकिन आपका ट्रैफ़िक HTTP पर है, तो वेबहुक सीक्रेट्स चुराए जा सकते हैं। --ssl-cert-file और --ssl-key-file ध्वजों का उपयोग करके SSL/HTTPS सक्षम करें।
वेब सेवा में प्रमाणीकरण सक्षम करना अत्यधिक अनुशंसित है। --web-basic-auth=true का उपयोग करके BasicAuth सक्षम करें और --web-username=yourUsername और --web-password=yourPassword ध्वजों का उपयोग करके एक उपयोगकर्ता नाम और पासवर्ड सेट करें।
आप इन्हें पर्यावरण वेरिएबल के रूप में भी पास कर सकते हैं ATLANTIS_WEB_BASIC_AUTH=true ATLANTIS_WEB_USERNAME=yourUsername और 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)
