Atlantis Security
मौलिक जानकारी
अटलांटिस आम तौर पर आपको आपके गिट सर्वर से पुल रिक्वेस्ट्स से टेराफ़ॉर्म चलाने में मदद करता है।
स्थानीय लैब
https://github.com/runatlantis/atlantis/releases पर अटलांटिस रिलीज़ पेज पर जाएं और उसे डाउनलोड करें जो आपके लिए उपयुक्त है।
अपने गिटहब उपयोगकर्ता का व्यक्तिगत टोकन (रेपो एक्सेस के साथ) बनाएं
./atlantis testdrive
चलाएं और यह एक डेमो रेपो बनाएगा जिसका आप अटलांटिस से बात करने के लिए उपयोग कर सकते हैं।आप 127.0.0.1:4141 में वेब पेज तक पहुंच सकते हैं
अटलांटिस एक्सेस
गिट सर्वर क्रेडेंशियल्स
अटलांटिस कई गिट होस्ट्स का समर्थन करता है जैसे गिटहब, गिटलैब, बिटबकेट और एज़्यूर डेवऑप्स। हालांकि, इन प्लेटफॉर्मों में रेपो में पहुंचने और कार्रवाई करने के लिए, उन्हें कुछ विशेषाधिकार पहुंच दिए जाने की आवश्यकता है (कम से कम लेखन अनुमतियाँ)। दस्तावेज़ इन प्लेटफॉर्मों में एक उपयोगकर्ता बनाने की प्रोत्साहना करते हैं, लेकिन कुछ लोग व्यक्तिगत खाते का उपयोग कर सकते हैं।
किसी भी स्थिति में, हमलावर की दृष्टि से, अटलांटिस खाता बहुत रोचक होगा कंप्रोमाइज करने के लिए।
वेबहुक्स
अटलांटिस वैकल्पिक रूप से वेबहुक सीक्रेट्स का उपयोग करता है ताकि वह आपके गिट होस्ट से प्राप्त वेबहुक्स को वैध मान सके।
इसे पुष्टि करने का एक तरीका यह हो सकता है कि आप अपने गिट होस्ट के आईपी से केवल अनुरोधों को अनुमति दें लेकिन एक आसान तरीका एक वेबहुक सीक्रेट का उपयोग करना है।
ध्यान दें कि यदि आप निजी गिटहब या बिटबकेट सर्वर का उपयोग नहीं करते हैं, तो आपको वेबहुक एंडपॉइंट को इंटरनेट पर उजागर करने की आवश्यकता होगी।
अटलांटिस वेबहुक्स को उजागर करेगा ताकि गिट सर्वर उसे सूचनाएं भेज सके। हमलावर की दृष्टि से यह रोचक होगा जानना कि क्या आप संदेश भेज सकते हैं।
प्रदाता क्रेडेंशियल्स
अटलांटिस टेराफ़ॉर्म चलाता है बस terraform plan
और apply
कमांड्स को सर्वर पर अटलांटिस होस्ट किया जाता है। जिस तरह से जब आप स्थानीय रूप से टेराफ़ॉर्म चलाते हैं, अटलांटिस को आपके विशिष्ट प्रदाता के लिए क्रेडेंशियल्स की आवश्यकता है।
यह आप पर निर्भर करता है कि आप अपने विशिष्ट प्रदाता के लिए क्रेडेंशियल्स प्रदान कैसे करते हैं अटलांटिस के लिए:
अटलांटिस हेल्म चार्ट और AWS फारगेट मॉड्यूल के लिए उनके खुद के तरीके हैं प्रदाता क्रेडेंशियल्स के लिए। उनके दस्तावेज़ पढ़ें।
यदि आप अटलांटिस को एक क्लाउड में चला रहे हैं तो कई क्लाउड्स के पास उन पर चल रहे एप्लिकेशन्स को क्लाउड एपीआई एक्सेस देने के तरीके होते हैं, जैसे:
AWS EC2 रोल्स (खोजें "EC2 रोल")
बहुत से उपयोगकर्ता पर्यावरण चर निर्मित करते हैं, जैसे
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 को किसी भी उपयोगकर्ता को देगा जो उस रेपो तक पहुंच सकता है।
Conftest नीति जांच
एटलांटिस सर्वर-साइड conftest नीतियों को प्लान आउटपुट के खिलाफ चलाने का समर्थन करता है। इस स्टेप का उपयोग करने के सामान्य मामले शामिल हैं:
मॉड्यूल की सूची का उपयोग नकारना
संसाधन की विशेषताओं की प्रमाणित करना निर्माण समय पर
अनजाने में संसाधन हटाने को पकड़ना
सुरक्षा जोखिमों को रोकना (जैसे कि सुरक्षित पोर्ट्स को सार्वजनिक करना)
आप यह कैसे कॉन्फ़िगर कर सकते हैं, दस्तावेज़ में देख सकते हैं।
एटलांटिस कमांड
दस्तावेज़ में आप उन विकल्पों को खोज सकते हैं जिन्हें आप एटलांटिस चलाने के लिए उपयोग कर सकते हैं:
हमले
यदि आप उत्पीड़न के दौरान इस त्रुटि को पाते हैं: Error: Error acquiring the state lock
तो आप इसे ठीक कर सकते हैं द्वारा निम्नलिखित को चला कर:
एटलांटिस योजना RCE - कॉन्फ़िग संशोधन नए पीआर में
यदि आपके पास किसी रिपॉजिटरी पर लेखन एक्सेस है तो आप उस पर एक नयी शाखा बना सकते हैं और एक पीआर उत्पन्न कर सकते हैं। यदि आप atlantis plan
का निष्पादन कर सकते हैं (या शायद यह स्वचालित रूप से निष्पादित होता है) तो आप एटलांटिस सर्वर के अंदर RCE कर सकते हैं।
आप इसे एटलांटिस को एक बाह्य डेटा स्रोत लोड करने के द्वारा कर सकते हैं। बस main.tf
फ़ाइल में निम्नलिखित पेलोड डालें:
गुप्ततर हमला
आप इस हमला को एक गुप्ततर तरीके से भी कर सकते हैं, इन सुझावों का पालन करके:
टेराफ़ॉर्म फ़ाइल में सीधे रेव शैल जोड़ने की बजाय, आप एक बाह्य संसाधन को लोड कर सकते हैं जिसमें रेव शैल हो:
आप यहाँ 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
) चलाकर, जैसे कि टेराफ़ॉर्म फ़ाइल में कुछ इस प्रकार डालकर:
एटलांटिस एप्लाई RCE - कॉन्फ़िग मॉडिफ़िकेशन न्यू पीआर में
यदि आपके पास रिपॉजिटरी पर राइट एक्सेस है तो आप उस पर एक नयी ब्रांच बना सकते हैं और एक पीआर जेनरेट कर सकते हैं। यदि आप atlantis apply
को एक्सीक्यूट कर सकते हैं तो आप एटलांटिस सर्वर के अंदर RCE कर सकते हैं।
हालांकि, आपको आम तौर पर कुछ सुरक्षा उपायों को दाखिल करने की आवश्यकता होगी:
मर्जेबल: यदि यह सुरक्षा एटलांटिस में सेट की गई है, तो आपको केवल
atlantis apply
चला सकते हैं अगर पीआर मर्जेबल है (जिसका मतलब है कि ब्रांच सुरक्षा को दाखिल करने की आवश्यकता है)।मंजूर: यदि यह सुरक्षा एटलांटिस में सेट की गई है, तो कुछ अन्य उपयोगकर्ता को पीआर को मंजूरी देनी होगी इससे पहले कि आप
atlantis apply
चला सकेंडिफ़ॉल्ट रूप से आप इस सुरक्षा को दाखिल करने के लिए गिटबॉट टोकन का दुरुपयोग कर सकते हैं
terraform apply
को एक दुरुपयोगी टेराफ़ॉर्म फ़ाइल पर चलाना local-exec।
आपको बस यह सुनिश्चित करना है कि कुछ पेलोड जैसे निम्नलिखित वाले main.tf
फ़ाइल में समाप्त हो जाएं:
टेराफ़ॉर्म पैरामीटर इंजेक्शन
जब atlantis plan
या atlantis apply
चलाया जा रहा है तो टेराफ़ॉर्म अंदर-जरूरत होता है, आप टेराफ़ॉर्म को एटलांटिस से कमेंट करके कमांड पास कर सकते हैं:
कस्टम वर्कफ़्लो
atlantis.yaml
फ़ाइल में निर्दिष्ट हानिकारक कस्टम बिल्ड कमांड चलाना। एटलांटिस पुल अनुरोध शाखा से atlantis.yaml
फ़ाइल का उपयोग करता है, नहीं master
का।
इस संभावना का उल्लेख पिछले खंड में किया गया था:
यदि सर्वर साइड कॉन्फ़िग ध्वज allow_custom_workflows
को सही पर सेट किया गया है, तो प्रक्रियाएँ प्रत्येक रेपो के atlantis.yaml
फ़ाइल में निर्दिष्ट की जा सकती हैं। यह भी संभावना है कि allowed_overrides
वास्तव में workflow
को भी निर्दिष्ट करता है ताकि उस वर्कफ़्लो को ओवरराइड किया जा सके।
यह मुख्य रूप से एटलांटिस सर्वर में RCE को किसी भी उपयोगकर्ता को देगा जो उस रेपो तक पहुंच सकता है।
बायपास प्लान/लागू सुरक्षा
यदि सर्वर साइड कॉन्फ़िग ध्वज allowed_overrides
को 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
का उपयोग न करेंयदि आप सार्वजनिक रेपो पर चला रहे हैं (जिसे सिफारिश नहीं किया गया है, ऊपर देखें) तो आपको --allow-fork-prs
(डिफ़ॉल्ट रूप से अस्वीकृत) सेट नहीं करना चाहिए क्योंकि कोई भी अपने फोर्क से आपके रेपो में पुल अनुरोध खोल सकता है।
--repo-allowlist
--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
फ्लैग सेट किए बिना, वेबहुक सीक्र
Last updated