Concourse Enumeration & Attacks
Concourse सूचना संग्रहण और हमले
उपयोगकर्ता भूमिकाएँ और अनुमतियाँ
Concourse में पाँच भूमिकाएँ होती हैं:
Concourse Admin: यह भूमिका केवल मुख्य टीम के मालिकों को दी जाती है (डिफ़ॉल्ट प्रारंभिक concourse टीम). Admins अन्य टीमों को कॉन्फ़िगर कर सकते हैं (उदाहरण:
fly set-team
,fly destroy-team
...). इस भूमिका की अनुमतियाँ RBAC द्वारा प्रभावित नहीं की जा सकती हैं.owner: टीम के मालिक टीम के भीतर सब कुछ संशोधित कर सकते हैं.
member: टीम के सदस्य टीम की संपत्तियों के भीतर पढ़ और लिख सकते हैं लेकिन टीम की सेटिंग्स में परिवर्तन नहीं कर सकते.
pipeline-operator: पाइपलाइन ऑपरेटर पाइपलाइन ऑपरेशन्स जैसे कि बिल्ड्स ट्रिगर करना और संसाधनों को पिन करना कर सकते हैं, हालांकि वे पाइपलाइन कॉन्फ़िगरेशन्स को अपडेट नहीं कर सकते.
viewer: टीम के दर्शकों के पास टीम और उसकी पाइपलाइनों के लिए "केवल-पढ़ने की" पहुँच होती है.
इसके अलावा, भूमिकाओं owner, member, pipeline-operator और viewer की अनुमतियाँ संशोधित की जा सकती हैं RBAC को कॉन्फ़िगर करके (इसकी क्रियाओं को अधिक विशेष रूप से कॉन्फ़िगर करके). इसके बारे में और पढ़ें: https://concourse-ci.org/user-roles.html
ध्यान दें कि Concourse पाइपलाइनों को टीमों के भीतर समूहित करता है. इसलिए एक टीम के सदस्य उन पाइपलाइनों को प्रबंधित कर सकते हैं और कई टीमें मौजूद हो सकती हैं. एक उपयोगकर्ता कई टीमों का सदस्य हो सकता है और उनमें से प्रत्येक में विभिन्न अनुमतियाँ रख सकता है.
Vars & Credential Manager
YAML कॉन्फ़िग्स में आप ((_source-name_:_secret-path_._secret-field_))
सिंटैक्स का उपयोग करके मानों को कॉन्फ़िगर कर सकते हैं।
source-name वैकल्पिक है, और यदि छोड़ दिया जाता है, तो cluster-wide credential manager का उपयोग किया जाएगा, या मान statically प्रदान किया जा सकता है।
secret-field वैकल्पिक है और यह एक फील्ड को निर्दिष्ट करता है जिसे प्राप्त सीक्रेट से पढ़ा जाएगा। यदि छोड़ दिया जाता है, तो क्रेडेंशियल मैनेजर एक 'डिफ़ॉल्ट फील्ड' को प्राप्त क्रेडेंशियल से पढ़ सकता है यदि फील्ड मौजूद है।
इसके अलावा, secret-path और secret-field को डबल कोट्स "..."
से घेरा जा सकता है यदि वे विशेष अक्षर जैसे कि .
और :
को समाहित करते हैं। उदाहरण के लिए, ((source:"my.secret"."field:1"))
secret-path को my.secret
और secret-field को field:1
सेट करेगा।
Static Vars
Static vars को tasks steps में निर्दिष्ट किया जा सकता है:
निम्नलिखित fly
तर्क का उपयोग करते हुए:
-v
या--var
NAME=VALUE
वरNAME
के लिए स्ट्रिंगVALUE
को मान के रूप में सेट करता है।-y
या--yaml-var
NAME=VALUE
VALUE
को YAML के रूप में पार्स करता है और इसे वरNAME
के मान के रूप में सेट करता है।-i
या--instance-var
NAME=VALUE
VALUE
को YAML के रूप में पार्स करता है और इसे इंस्टेंस वरNAME
के मान के रूप में सेट करता है। Grouping Pipelines में इंस्टेंस वर्स के बारे में और जानें।-l
या--load-vars-from
FILE
FILE
को लोड करता है, जो एक YAML दस्तावेज़ है जिसमें वर नामों को मानों के साथ मैपिंग होती है, और उन सभी को सेट करता है।
Credential Management
पाइपलाइन में एक Credential Manager को निर्दिष्ट करने के विभिन्न तरीके हैं, https://concourse-ci.org/creds.html में पढ़ें। इसके अलावा, Concourse विभिन्न प्रकार के क्रेडेंशियल मैनेजर्स का समर्थन करता है:
ध्यान दें कि यदि आपके पास Concourse के लिए किसी प्रकार का लिखने का अधिकार है तो आप उन रहस्यों को निकालने के लिए जॉब्स बना सकते हैं क्योंकि Concourse को उन तक पहुँचने में सक्षम होना चाहिए।
Concourse Enumeration
Concourse पर्यावरण का अनुक्रमण करने के लिए आपको पहले मान्य क्रेडेंशियल एकत्रित करने की आवश्यकता होती है या एक प्रमाणित टोकन खोजने की, जो शायद एक .flyrc
कॉन्फ़िग फ़ाइल में हो।
Login and Current User enum
लॉगिन करने के लिए आपको एंडपॉइंट, टीम का नाम (डिफ़ॉल्ट है
main
) और एक टीम जिसके उपयोगकर्ता सदस्य हैं की जानकारी होनी चाहिए:fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]
कॉन्फ़िगर किए गए टारगेट्स प्राप्त करें:
fly targets
यह जांचें कि कॉन्फ़िगर किया गया टारगेट कनेक्शन अभी भी मान्य है:
fly -t <target> status
इंगित किए गए टारगेट के खिलाफ उपयोगकर्ता की भूमिका प्राप्त करें:
fly -t <target> userinfo
ध्यान दें कि API टोकन डिफ़ॉल्ट रूप से $HOME/.flyrc
में सहेजा जाता है, आप मशीनों को लूटते समय वहां क्रेडेंशियल पा सकते हैं।
Teams & Users
टीमों की सूची प्राप्त करें
fly -t <target> teams
टीम के अंदर भूमिकाएँ प्राप्त करें
fly -t <target> get-team -n <team-name>
उपयोगकर्ताओं की सूची प्राप्त करें
fly -t <target> active-users
Pipelines
पाइपलाइनों की सूची:
fly -t <target> pipelines -a
पाइपलाइन yaml प्राप्त करें (संवेदनशील जानकारी परिभाषा में पाई जा सकती है):
fly -t <target> get-pipeline -p <pipeline-name>
सभी पाइपलाइन कॉन्फ़िग घोषित वर्स प्राप्त करें
for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done
सभी पाइपलाइनों के गुप्त नामों का उपयोग किया जाता है (यदि आप एक जॉब बना सकते हैं/संशोधित कर सकते हैं या एक कंटेनर को हाइजैक कर सकते हैं तो आप उन्हें निकाल सकते हैं):
कंटेनर्स और वर्कर्स
वर्कर्स की सूची:
fly -t <target> workers
कंटेनर्स की सूची:
fly -t <target> containers
बिल्ड्स की सूची (यह देखने के लिए कि क्या चल रहा है):
fly -t <target> builds
Concourse हमले
क्रेडेंशियल्स ब्रूट-फोर्स
admin:admin
test:test
सीक्रेट्स और पैराम्स एन्युमेरेशन
पिछले अनुभाग में हमने देखा कि कैसे आप सभी सीक्रेट्स नाम और वर्स को प्राप्त कर सकते हैं जो पाइपलाइन द्वारा इस्तेमाल किए जाते हैं। वर्स में संवेदनशील जानकारी हो सकती है और सीक्रेट्स के नाम बाद में उन्हें चुराने की कोशिश करने के लिए उपयोगी होंगे।
चल रहे या हाल ही में चले गए कंटेनर के अंदर सेशन
यदि आपके पास पर्याप्त अधिकार हैं (मेंबर रोल या अधिक) तो आप पाइपलाइन्स और रोल्स की सूची बना सकते हैं और बस <pipeline>/<job>
कंटेनर के अंदर एक सेशन प्राप्त कर सकते हैं इसका उपयोग करके:
इन अनुमतियों के साथ आप संभवतः निम्नलिखित कर सकते हैं:
कंटेनर के अंदर के secrets चुराना
नोड की ओर भागने का प्रयास करना
cloud metadata endpoint का संग्रहण/दुरुपयोग करना (पॉड से और यदि संभव हो तो नोड से)
Pipeline Creation/Modification
यदि आपके पास पर्याप्त विशेषाधिकार हैं (member role या अधिक) तो आप नए pipelines बनाने/संशोधित करने में सक्षम होंगे। इस उदाहरण को देखें:
नई पाइपलाइन के संशोधन/निर्माण के साथ आप सक्षम होंगे:
चुराना गुप्त सूचनाएं (उन्हें बाहर निकालने या कंटेनर के अंदर जाकर
env
चलाने के द्वारा)नोड पर भाग निकलना (आपको पर्याप्त अधिकार देकर -
privileged: true
)क्लाउड मेटाडेटा एंडपॉइंट का सूचीकरण/दुरुपयोग (पॉड और नोड से)
बनाई गई पाइपलाइन को हटाना
कस्टम टास्क निष्पादित करें
यह पिछली विधि के समान है लेकिन पूरी नई पाइपलाइन को संशोधित/निर्मित करने के बजाय आप केवल एक कस्टम टास्क निष्पादित कर सकते हैं (जो शायद बहुत अधिक गुप्त होगा):
प्रिविलेज्ड टास्क से नोड में एस्केपिंग
पिछले खंडों में हमने देखा कि कैसे concourse के साथ प्रिविलेज्ड टास्क को निष्पादित किया जाए। यह कंटेनर को docker कंटेनर में प्रिविलेज्ड फ्लैग के समान एक्सेस नहीं देगा। उदाहरण के लिए, आप /dev में नोड फाइलसिस्टम डिवाइस नहीं देखेंगे, इसलिए एस्केप अधिक "जटिल" हो सकता है।
निम्नलिखित PoC में हम कुछ छोटे संशोधनों के साथ release_agent का उपयोग करके एस्केप करने जा रहे हैं:
जैसा कि आपने देखा होगा यह सिर्फ एक सामान्य release_agent escape है जो केवल node में cmd के पथ को संशोधित करता है
Worker container से node में भागना
इसके लिए एक सामान्य release_agent escape के साथ एक मामूली संशोधन पर्याप्त है:
वेब कंटेनर से नोड में भागना
यदि वेब कंटेनर में कुछ रक्षा निष्क्रिय है, तब भी यह सामान्य विशेषाधिकार प्राप्त कंटेनर के रूप में नहीं चल रहा है (उदाहरण के लिए, आप नहीं माउंट कर सकते और क्षमताएं बहुत सीमित हैं, इसलिए कंटेनर से भागने के सभी आसान तरीके बेकार हैं)।
हालांकि, यह स्थानीय क्रेडेंशियल्स को स्पष्ट पाठ में संग्रहीत करता है:
आप उन क्रेडेंशियल्स का उपयोग कर सकते हैं वेब सर्वर में लॉगिन करने के लिए और एक विशेषाधिकार प्राप्त कंटेनर बनाने और नोड में एस्केप करने के लिए।
पर्यावरण में आपको concourse द्वारा उपयोग किए जाने वाले postgresql इंस्टेंस तक पहुँचने के लिए जानकारी भी मिल सकती है (पता, उपयोगकर्ता नाम, पासवर्ड और डेटाबेस सहित अन्य जानकारी):
गार्डन सर्विस का दुरुपयोग - वास्तविक हमला नहीं
ये कुछ दिलचस्प नोट्स हैं जो सर्विस के बारे में हैं, लेकिन चूंकि यह केवल लोकलहोस्ट पर सुन रहा है, इसलिए इन नोट्स का कोई प्रभाव नहीं होगा जिसे हम पहले ही शोषित नहीं कर चुके हैं
डिफ़ॉल्ट रूप से प्रत्येक कॉनकोर्स वर्कर पोर्ट 7777 पर एक गार्डन सर्विस चला रहा होगा। यह सर्विस वेब मास्टर द्वारा वर्कर को क्या क्रियान्वित करना है (इमेज डाउनलोड करना और प्रत्येक टास्क चलाना) यह इंगित करने के लिए उपयोग की जाती है। यह हमलावर के लिए काफी अच्छा लगता है, लेकिन कुछ अच्छी सुरक्षा हैं:
यह केवल स्थानीय रूप से प्रकट होता है (127.0.0.1) और मुझे लगता है जब वर्कर वेब के साथ विशेष SSH सर्विस के माध्यम से प्रमाणित होता है, एक टनल बनाई जाती है ताकि वेब सर्वर प्रत्येक वर्कर के अंदर प्रत्येक गार्डन सर्विस से बात कर सके।
वेब सर्वर हर कुछ सेकंड में चल रहे कंटेनरों की निगरानी कर रहा है, और अप्रत्याशित कंटेनरों को हटा दिया जाता है। इसलिए अगर आप कस्टम कंटेनर चलाना चाहते हैं तो आपको वेब सर्वर और गार्डन सर्विस के बीच संचार में छेड़छाड़ करनी होगी।
कॉनकोर्स वर्कर्स उच्च कंटेनर विशेषाधिकारों के साथ चलते हैं:
हालांकि, माउंटिंग /dev डिवाइस ऑफ द नोड या release_agent काम नहीं करेगा (क्योंकि असली डिवाइस जिसमें नोड की फाइल सिस्टम है, वह सुलभ नहीं है, केवल एक वर्चुअल डिवाइस है)। हम नोड की प्रक्रियाओं तक पहुँच नहीं सकते, इसलिए बिना कर्नेल एक्सप्लॉइट्स के नोड से बाहर निकलना जटिल हो जाता है।
पिछले अनुभाग में हमने देखा कि कैसे एक विशेषाधिकार प्राप्त कंटेनर से बच निकलना है, इसलिए अगर हम कमांड्स एक्जीक्यूट कर सकते हैं एक विशेषाधिकार प्राप्त कंटेनर में जो कि वर्तमान वर्कर द्वारा बनाया गया है, हम नोड में बच निकल सकते हैं।
ध्यान दें कि concourse के साथ खेलते समय मैंने देखा कि जब एक नया कंटेनर कुछ चलाने के लिए उत्पन्न होता है, तो कंटेनर की प्रक्रियाएं वर्कर कंटेनर से सुलभ होती हैं, इसलिए यह एक कंटेनर की तरह है जो उसके अंदर एक नया कंटेनर बना रहा है।
एक चल रहे विशेषाधिकार प्राप्त कंटेनर के अंदर प्रवेश करना
एक नया विशेषाधिकार प्राप्त कंटेनर बनाना
आप बहुत आसानी से एक नया कंटेनर बना सकते हैं (बस एक यादृच्छिक UID चलाएं) और उस पर कुछ निष्पादित करें:
हालांकि, वेब सर्वर हर कुछ सेकंड में चल रहे कंटेनरों की जांच कर रहा है, और यदि कोई अप्रत्याशित कंटेनर पाया जाता है, तो उसे हटा दिया जाएगा। चूंकि संचार HTTP में हो रहा है, आप संचार में हेरफेर करके अप्रत्याशित कंटेनरों के विलोपन से बच सकते हैं:
संदर्भ
https://concourse-ci.org/vars.html
Last updated