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 पर जाएं और डाउनलोड करें जो आपके लिए उपयुक्त हो।
अपने github उपयोगकर्ता का व्यक्तिगत टोकन (repo एक्सेस के साथ) बनाएं।
./atlantis testdrive
निष्पादित करें और यह एक डेमो repo बनाएगा जिसका आप atlantis से बात करने के लिए उपयोग कर सकते हैं।
आप 127.0.0.1:4141 में वेब पृष्ठ तक पहुँच सकते हैं।
Atlantis कई git होस्ट जैसे Github, Gitlab, Bitbucket और Azure DevOps का समर्थन करता है। हालांकि, इन प्लेटफार्मों में repos तक पहुँचने और क्रियाएँ करने के लिए, इसे कुछ विशेषाधिकार प्राप्त एक्सेस की आवश्यकता होती है (कम से कम लिखने की अनुमति)। The docs इन प्लेटफार्मों में Atlantis के लिए विशेष रूप से एक उपयोगकर्ता बनाने की सिफारिश करते हैं, लेकिन कुछ लोग व्यक्तिगत खातों का उपयोग कर सकते हैं।
किसी भी मामले में, एक हमलावर के दृष्टिकोण से, Atlantis खाता एक बहुत ही दिलचस्प हैक करने के लिए होगा।
Atlantis वैकल्पिक रूप से Webhook secrets का उपयोग करता है ताकि यह सत्यापित किया जा सके कि आपके Git होस्ट से प्राप्त webhooks वैध हैं।
इसकी पुष्टि करने का एक तरीका यह होगा कि केवल आपके Git होस्ट के IPs से आने के लिए अनुरोधों को अनुमति दें, लेकिन एक आसान तरीका Webhook Secret का उपयोग करना है।
ध्यान दें कि जब तक आप एक निजी github या bitbucket सर्वर का उपयोग नहीं करते, आपको वेबहुक एंडपॉइंट्स को इंटरनेट पर उजागर करने की आवश्यकता होगी।
Atlantis webhooks को expose करने जा रहा है ताकि git सर्वर इसे जानकारी भेज सके। एक हमलावर के दृष्टिकोण से यह जानना दिलचस्प होगा कि क्या आप इसे संदेश भेज सकते हैं।
Atlantis Terraform को बस terraform plan
और apply
कमांड्स को सर्वर पर निष्पादित करके चलाता है जिस पर Atlantis होस्ट किया गया है। ठीक उसी तरह जैसे आप स्थानीय रूप से Terraform चलाते हैं, Atlantis को आपके विशेष प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता होती है।
यह आपके ऊपर है कि आप Atlantis के लिए अपने विशेष प्रदाता के लिए क्रेडेंशियल्स कैसे प्रदान करते हैं:
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 सर्वर द्वारा समर्थित हैं।
मान मानने का यह क्रम है:
फ्लैग
पर्यावरण चर
कॉन्फ़िग फ़ाइल
ध्यान दें कि कॉन्फ़िगरेशन में आप tokens और passwords जैसे दिलचस्प मान पा सकते हैं।
कुछ कॉन्फ़िगरेशन repos के प्रबंधन के तरीके को प्रभावित करते हैं। हालाँकि, यह संभव है कि प्रत्येक repo को विभिन्न सेटिंग्स की आवश्यकता हो, इसलिए प्रत्येक repo को निर्दिष्ट करने के तरीके हैं। यह प्राथमिकता क्रम है:
Repo /atlantis.yml
फ़ाइल। इस फ़ाइल का उपयोग यह निर्दिष्ट करने के लिए किया जा सकता है कि atlantis को repo के साथ कैसे व्यवहार करना चाहिए। हालाँकि, डिफ़ॉल्ट रूप से कुछ कुंजियाँ यहाँ निर्दिष्ट नहीं की जा सकती हैं बिना कुछ फ्लैग्स की अनुमति के।
शायद allowed_overrides
या allow_custom_workflows
जैसे फ्लैग्स द्वारा अनुमति दी जानी चाहिए।
Server Side Config: आप इसे फ्लैग --repo-config
के साथ पास कर सकते हैं और यह प्रत्येक repo के लिए नई सेटिंग्स को कॉन्फ़िगर करने वाला yaml है (regexes समर्थित)।
डिफ़ॉल्ट मान
PR Protections
Atlantis यह संकेत करने की अनुमति देता है कि क्या आप चाहते हैं कि PR को किसी और द्वारा approved
किया जाए (यहां तक कि यदि वह शाखा सुरक्षा में सेट नहीं है) और/या mergeable
(शाखा सुरक्षा पास की गई) apply चलाने से पहले। सुरक्षा के दृष्टिकोण से, दोनों विकल्प सेट करना अनुशंसित है।
यदि allowed_overrides
सत्य है, तो ये सेटिंग्स प्रत्येक प्रोजेक्ट पर /atlantis.yml
फ़ाइल द्वारा ओवरराइट की जा सकती हैं।
Scripts
Repo कॉन्फ़िगरेशन स्क्रिप्ट्स को निर्दिष्ट कर सकता है पहले (pre workflow hooks) और बाद में एक workflow के निष्पादन के लिए।
इन स्क्रिप्ट्स को repo /atlantis.yml
फ़ाइल में निर्दिष्ट करने की कोई विकल्प नहीं है।
Workflow
Repo कॉन्फ़िगरेशन (सर्वर साइड कॉन्फ़िगरेशन) में आप एक नया डिफ़ॉल्ट workflow निर्दिष्ट कर सकते हैं, या नए कस्टम workflows बना सकते हैं। आप यह भी निर्दिष्ट कर सकते हैं कि कौन से repos नए उत्पन्न किए गए ones तक पहुँच सकते हैं। फिर, आप प्रत्येक repo के atlantis.yaml फ़ाइल को workflow का उपयोग करने के लिए निर्दिष्ट करने की अनुमति दे सकते हैं।
यदि server side config फ्लैग allow_custom_workflows
को True पर सेट किया गया है, तो workflows को प्रत्येक repo के atlantis.yaml
फ़ाइल में निर्दिष्ट किया जा सकता है। यह भी संभावित रूप से आवश्यक है कि allowed_overrides
भी workflow
को override करने के लिए निर्दिष्ट करे जो उपयोग किया जाने वाला है।
यह मूल रूप से Atlantis सर्वर में RCE किसी भी उपयोगकर्ता को देगा जो उस repo तक पहुँच सकता है।
Conftest नीति जांच
Atlantis सर्वर-साइड 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 और शाखाओं को हटा दें।
आप atlantis plan (terraform plan
) चलाकर उपयोग किए गए सीक्रेट्स को डंप कर सकते हैं, जैसे कि terraform फ़ाइल में कुछ इस तरह डालकर:
यदि आपके पास एक रिपॉजिटरी पर लिखने की अनुमति है, तो आप उस पर एक नई शाखा बना सकते हैं और एक PR उत्पन्न कर सकते हैं। यदि आप atlantis apply
निष्पादित कर सकते हैं, तो आप Atlantis सर्वर के अंदर RCE कर सकेंगे।
हालांकि, आपको आमतौर पर कुछ सुरक्षा उपायों को बायपास करने की आवश्यकता होगी:
Mergeable: यदि यह सुरक्षा Atlantis में सेट है, तो आप केवल atlantis apply
चला सकते हैं यदि PR मर्ज करने योग्य है (जिसका अर्थ है कि शाखा सुरक्षा को बायपास करना होगा)।
संभावित शाखा सुरक्षा बायपास की जांच करें
Approved: यदि यह सुरक्षा Atlantis में सेट है, तो कुछ अन्य उपयोगकर्ता को PR को स्वीकृत करना होगा इससे पहले कि आप atlantis apply
चला सकें
डिफ़ॉल्ट रूप से, आप Gitbot टोकन का दुरुपयोग करके इस सुरक्षा को बायपास कर सकते हैं
एक दुर्भावनापूर्ण Terraform फ़ाइल पर terraform apply
चलाना 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 में सेटिंग है:
यदि आप webhook secret चुराने में सफल होते हैं या यदि कोई webhook secret उपयोग नहीं किया जा रहा है, तो आप Atlantis webhook को call कर सकते हैं और atlatis commands सीधे invoke कर सकते हैं।
Bitbucket Cloud webhook secrets का समर्थन नहीं करता। यह हमलावरों को Bitbucket से अनुरोधों की नकल करने की अनुमति दे सकता है। सुनिश्चित करें कि आप केवल Bitbucket IPs की अनुमति दे रहे हैं।
इसका मतलब है कि एक हमलावर Atlantis के लिए नकली अनुरोध कर सकता है जो ऐसा दिखता है जैसे कि वे Bitbucket से आ रहे हैं।
यदि आप --repo-allowlist
निर्दिष्ट कर रहे हैं तो वे केवल उन repos से संबंधित नकली अनुरोध कर सकते हैं, इसलिए वे जो सबसे अधिक नुकसान कर सकते हैं वह आपके अपने repos पर plan/apply करना होगा।
इसे रोकने के लिए, Bitbucket के IP पते को allowlist करें (Outbound IPv4 addresses देखें)।
यदि आप सर्वर तक पहुँचने में सफल हो गए हैं या कम से कम आपके पास 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 (संवेदनशील डेटा हो सकता है)
क्योंकि कोई भी सार्वजनिक पुल अनुरोधों पर टिप्पणी कर सकता है, सभी सुरक्षा उपायों के साथ भी, सार्वजनिक repos पर Atlantis चलाना उचित कॉन्फ़िगरेशन के बिना अभी भी खतरनाक है।
--allow-fork-prs
यदि आप एक सार्वजनिक repo पर चल रहे हैं (जो अनुशंसित नहीं है, ऊपर देखें) तो आपको --allow-fork-prs
सेट नहीं करना चाहिए (डिफ़ॉल्ट रूप से false) क्योंकि कोई भी अपने fork से आपके repo के लिए एक पुल अनुरोध खोल सकता है।
--repo-allowlist
Atlantis को आपको --repo-allowlist
ध्वज के माध्यम से वेबहुक स्वीकार करने के लिए repos की एक 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
देखें।
यदि हमलावर दुष्ट Terraform कोड के साथ पुल अनुरोध प्रस्तुत कर रहे हैं तो यह आपके खतरे के मॉडल में है, तो आपको यह जानना चाहिए कि terraform apply
अनुमतियाँ पर्याप्त नहीं हैं। यह external
data source का उपयोग करके या एक दुष्ट प्रदाता निर्दिष्ट करके terraform plan
में दुष्ट कोड चलाना संभव है। यह कोड फिर आपके क्रेडेंशियल्स को एक्सफिल्ट्रेट कर सकता है।
इसे रोकने के लिए, आप कर सकते हैं:
प्रदाताओं को Atlantis छवि में बेक करें या होस्ट करें और उत्पादन में ईग्रेस को अस्वीकार करें।
आंतरिक रूप से प्रदाता रजिस्ट्री प्रोटोकॉल लागू करें और सार्वजनिक ईग्रेस को अस्वीकार करें, इस तरह आप नियंत्रित करते हैं कि किसके पास रजिस्ट्री में लिखने का अधिकार है।
अपने server-side repo configuration के plan
चरण को संशोधित करें ताकि अवैध प्रदाताओं या डेटा स्रोतों या अनुमति न दिए गए उपयोगकर्ताओं से PRs के उपयोग के खिलाफ मान्य किया जा सके। आप इस बिंदु पर अतिरिक्त मान्यता भी जोड़ सकते हैं, जैसे कि plan
को जारी रखने की अनुमति देने से पहले PR पर "thumbs-up" की आवश्यकता। Conftest यहाँ उपयोगी हो सकता है।
Atlantis को $ATLANTIS_GH_WEBHOOK_SECRET
/$ATLANTIS_GITLAB_WEBHOOK_SECRET
पर्यावरण वेरिएबल के माध्यम से सेट किए गए Webhook secrets के साथ चलाना चाहिए। --repo-allowlist
ध्वज सेट होने के बावजूद, बिना webhook secret के, हमलावर Atlantis को एक अनुमति प्राप्त रिपॉजिटरी के रूप में अनुरोध कर सकते हैं। Webhook secrets यह सुनिश्चित करते हैं कि वेबहुक अनुरोध वास्तव में आपके VCS प्रदाता (GitHub या GitLab) से आ रहे हैं।
यदि आप Azure DevOps का उपयोग कर रहे हैं, तो webhook secrets के बजाय एक बुनियादी उपयोगकर्ता नाम और पासवर्ड जोड़ें।
Azure DevOps सभी वेबहुक घटनाओं में एक बुनियादी प्रमाणीकरण हेडर भेजने का समर्थन करता है। इसके लिए आपके वेबहुक स्थान के लिए HTTPS URL का उपयोग करना आवश्यक है।
यदि आप webhook secrets का उपयोग कर रहे हैं लेकिन आपका ट्रैफ़िक HTTP पर है, तो webhook secrets चुराए जा सकते हैं। --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)