Concourse Enumeration & Attacks
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)
Concourse में पांच भूमिकाएँ होती हैं:
Concourse Admin: यह भूमिका केवल मुख्य टीम (डिफ़ॉल्ट प्रारंभिक concourse टीम) के मालिकों को दी जाती है। एडमिन अन्य टीमों को कॉन्फ़िगर कर सकते हैं (जैसे: 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 टीमों के भीतर पाइपलाइनों को समूहित करता है। इसलिए, एक टीम से संबंधित उपयोगकर्ता उन पाइपलाइनों का प्रबंधन कर सकेंगे और कई टीमें हो सकती हैं। एक उपयोगकर्ता कई टीमों से संबंधित हो सकता है और प्रत्येक में विभिन्न अनुमतियाँ हो सकती हैं।
YAML कॉन्फ़िग में आप मानों को ((_source-name_:_secret-path_._secret-field_))
सिंटैक्स का उपयोग करके कॉन्फ़िगर कर सकते हैं।
दस्तावेज़ से: source-name वैकल्पिक है, और यदि छोड़ा गया है, तो क्लस्टर-व्यापी क्रेडेंशियल प्रबंधक का उपयोग किया जाएगा, या मान स्थैतिक रूप से प्रदान किया जा सकता है।
वैकल्पिक _secret-field_ उस फ़ील्ड को निर्दिष्ट करता है जिसे प्राप्त किए गए रहस्य से पढ़ा जाना है। यदि छोड़ा गया है, तो क्रेडेंशियल प्रबंधक प्राप्त किए गए क्रेडेंशियल से 'डिफ़ॉल्ट फ़ील्ड' पढ़ने का विकल्प चुन सकता है यदि फ़ील्ड मौजूद है।
इसके अलावा, secret-path और secret-field को डबल उद्धरणों "..."
से घेर सकते हैं यदि वे विशेष वर्ण जैसे .
और :
शामिल करते हैं। उदाहरण के लिए, ((source:"my.secret"."field:1"))
secret-path को my.secret
और secret-field को field:1
पर सेट करेगा।
Static vars को tasks steps में निर्दिष्ट किया जा सकता है:
Or using the following fly
arguments:
-v
or --var
NAME=VALUE
स्ट्रिंग VALUE
को var NAME
के लिए मान के रूप में सेट करता है।
-y
or --yaml-var
NAME=VALUE
VALUE
को YAML के रूप में पार्स करता है और इसे var NAME
के लिए मान के रूप में सेट करता है।
-i
or --instance-var
NAME=VALUE
VALUE
को YAML के रूप में पार्स करता है और इसे instance var NAME
के लिए मान के रूप में सेट करता है। instance vars के बारे में अधिक जानने के लिए Grouping Pipelines देखें।
-l
or --load-vars-from
FILE
FILE
को लोड करता है, जो मानों के लिए var नामों को मैप करने वाला एक YAML दस्तावेज़ है, और इन्हें सभी सेट करता है।
एक पाइपलाइन में Credential Manager को निर्दिष्ट करने के विभिन्न तरीके हैं, इसके बारे में पढ़ें https://concourse-ci.org/creds.html। इसके अलावा, Concourse विभिन्न क्रेडेंशियल प्रबंधकों का समर्थन करता है:
ध्यान दें कि यदि आपके पास Concourse पर कुछ प्रकार की लिखने की पहुंच है, तो आप उन रहस्यों को निकालने के लिए नौकरियां बना सकते हैं क्योंकि Concourse को उन्हें एक्सेस करने में सक्षम होना चाहिए।
एक concourse वातावरण को सूचीबद्ध करने के लिए, आपको पहले मान्य क्रेडेंशियल्स इकट्ठा करने की आवश्यकता है या एक प्रमाणित टोकन खोजने की आवश्यकता है, जो शायद एक .flyrc
कॉन्फ़िग फ़ाइल में हो।
लॉगिन करने के लिए आपको endpoint, team name (डिफ़ॉल्ट main
है) और टीम जिसका उपयोगकर्ता सदस्य है जानना होगा:
fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]
कॉन्फ़िगर किए गए targets प्राप्त करें:
fly targets
जांचें कि कॉन्फ़िगर किया गया target connection अभी भी मान्य है:
fly -t <target> status
निर्दिष्ट लक्ष्य के खिलाफ उपयोगकर्ता की भूमिका प्राप्त करें:
fly -t <target> userinfo
ध्यान दें कि API token डिफ़ॉल्ट रूप से $HOME/.flyrc
में सहेजा जाता है, आप मशीनों को लूटते समय वहां क्रेडेंशियल्स पा सकते हैं।
टीमों की सूची प्राप्त करें
fly -t <target> teams
टीम के अंदर भूमिकाएँ प्राप्त करें
fly -t <target> get-team -n <team-name>
उपयोगकर्ताओं की सूची प्राप्त करें
fly -t <target> active-users
सूची पाइपलाइनों की:
fly -t <target> pipelines -a
पाइपलाइन yaml प्राप्त करें (संवेदनशील जानकारी परिभाषा में मिल सकती है):
fly -t <target> get-pipeline -p <pipeline-name>
सभी पाइपलाइन config घोषित vars प्राप्त करें
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
सभी पाइपलाइनों के रहस्य नाम प्राप्त करें (यदि आप एक नौकरी बना/संशोधित कर सकते हैं या एक कंटेनर को हाईजैक कर सकते हैं तो आप उन्हें निकाल सकते हैं):
List workers:
fly -t <target> workers
List containers:
fly -t <target> containers
List builds (to see what is running):
fly -t <target> builds
admin:admin
test:test
पिछले अनुभाग में हमने देखा कि आप पाइपलाइन द्वारा उपयोग किए जाने वाले सभी रहस्यों के नाम और वेरिएबल्स प्राप्त कर सकते हैं। वेरिएबल्स में संवेदनशील जानकारी हो सकती है और रहस्यों के नाम बाद में उन्हें चुराने की कोशिश करने के लिए उपयोगी होंगे।
यदि आपके पास पर्याप्त विशेषाधिकार (सदस्य भूमिका या अधिक) हैं, तो आप पाइपलाइनों और भूमिकाओं की सूची बना सकेंगे और बस <pipeline>/<job>
कंटेनर के अंदर एक सत्र प्राप्त कर सकेंगे:
इन अनुमतियों के साथ आप सक्षम हो सकते हैं:
कंटेनर के अंदर गुप्त जानकारी चुराना
नोड पर भागने की कोशिश करना
क्लाउड मेटाडेटा एंडपॉइंट को सूचीबद्ध/दुरुपयोग करना (पॉड से और यदि संभव हो तो नोड से)
यदि आपके पास पर्याप्त विशेषाधिकार हैं (सदस्य भूमिका या अधिक) तो आप नई पाइपलाइनों को बनाने/संशोधित करने में सक्षम होंगे। इस उदाहरण को देखें:
With the modification/creation of a new pipeline you will be able to:
चुराना the गुप्त (via echoing them out or getting inside the container and running env
)
भागना to the नोड (by giving you enough privileges - privileged: true
)
Enumerate/Abuse क्लाउड मेटाडेटा endpoint (from the pod and from the node)
हटाना created pipeline
This is similar to the previous method but instead of modifying/creating a whole new pipeline you can just execute a custom task (which will probably be much more गुप्त):
In the previous sections we saw how to execute a privileged task with concourse. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex".
In the following PoC we are going to use the release_agent to escape with some small modifications:
जैसा कि आपने देखा होगा, यह बस एक सामान्य release_agent escape है, बस नोड में cmd के पथ को संशोधित करना
इसके लिए एक सामान्य release_agent escape में एक छोटा संशोधन पर्याप्त है:
भले ही वेब कंटेनर में कुछ सुरक्षा उपाय निष्क्रिय हैं, यह एक सामान्य विशेषाधिकार प्राप्त कंटेनर के रूप में नहीं चल रहा है (उदाहरण के लिए, आप माउंट नहीं कर सकते और क्षमताएँ बहुत सीमित हैं, इसलिए कंटेनर से भागने के सभी आसान तरीके बेकार हैं)।
हालांकि, यह स्थानीय क्रेडेंशियल्स को स्पष्ट पाठ में स्टोर करता है:
आप उन क्रेडेंशियल्स का उपयोग वेब सर्वर के खिलाफ लॉगिन करने और एक विशेषाधिकार प्राप्त कंटेनर बनाने और नोड पर भागने के लिए कर सकते हैं।
पर्यावरण में आप पोस्टग्रेसक्यूएल उदाहरण तक पहुँचने के लिए जानकारी भी पा सकते हैं जो concourse उपयोग करता है (पता, उपयोगकर्ता नाम, पासवर्ड और डेटाबेस सहित अन्य जानकारी):
यह सेवा के बारे में कुछ दिलचस्प नोट्स हैं, लेकिन क्योंकि यह केवल लोकलहोस्ट पर सुन रही है, ये नोट्स कोई प्रभाव नहीं डालेंगे जिसे हमने पहले ही शोषण किया है
डिफ़ॉल्ट रूप से, प्रत्येक concourse कार्यकर्ता गार्डन सेवा को पोर्ट 7777 पर चलाएगा। इस सेवा का उपयोग वेब मास्टर द्वारा कार्यकर्ता को यह बताने के लिए किया जाता है कि उसे क्या निष्पादित करना है (इमेज डाउनलोड करना और प्रत्येक कार्य चलाना)। यह एक हमलावर के लिए काफी अच्छा लगता है, लेकिन कुछ अच्छे सुरक्षा उपाय हैं:
यह केवल स्थानीय रूप से (127..0.0.1) प्रदर्शित है और मुझे लगता है कि जब कार्यकर्ता विशेष SSH सेवा के साथ वेब के खिलाफ प्रमाणीकरण करता है, तो एक सुरंग बनाई जाती है ताकि वेब सर्वर प्रत्येक कार्यकर्ता के अंदर प्रत्येक गार्डन सेवा से बात कर सके।
वेब सर्वर हर कुछ सेकंड में चल रहे कंटेनरों की निगरानी कर रहा है, और अप्रत्याशित कंटेनरों को हटाया जाता है। इसलिए यदि आप एक कस्टम कंटेनर चलाना चाहते हैं तो आपको वेब सर्वर और गार्डन सेवा के बीच संवाद के साथ छेड़छाड़ करनी होगी।
Concourse कार्यकर्ता उच्च कंटेनर विशेषाधिकारों के साथ चलते हैं:
हालांकि, तकनीकें जैसे mounting /dev डिवाइस नोड या release_agent काम नहीं करेंगी (क्योंकि नोड के फाइल सिस्टम के साथ असली डिवाइस उपलब्ध नहीं है, केवल एक वर्चुअल है)। हम नोड की प्रक्रियाओं तक पहुँच नहीं सकते, इसलिए कर्नेल एक्सप्लॉइट्स के बिना नोड से भागना जटिल हो जाता है।
पिछले अनुभाग में हमने देखा कि कैसे एक विशेषाधिकार प्राप्त कंटेनर से भागना है, इसलिए यदि हम privileged container में commands execute कर सकते हैं जो current worker द्वारा बनाया गया है, तो हम node पर escape कर सकते हैं।
ध्यान दें कि concourse के साथ खेलते समय मैंने देखा कि जब कुछ चलाने के लिए एक नया कंटेनर उत्पन्न होता है, तो कंटेनर प्रक्रियाएँ वर्कर कंटेनर से सुलभ होती हैं, इसलिए यह एक कंटेनर के अंदर एक नया कंटेनर बनाने जैसा है।
एक चल रहे विशेषाधिकार प्राप्त कंटेनर के अंदर जाना
नया विशेषाधिकार प्राप्त कंटेनर बनाना
आप बहुत आसानी से एक नया कंटेनर बना सकते हैं (बस एक यादृच्छिक UID चलाएँ) और उस पर कुछ निष्पादित कर सकते हैं:
हालांकि, वेब सर्वर हर कुछ सेकंड में चल रहे कंटेनरों की जांच कर रहा है, और यदि कोई अप्रत्याशित कंटेनर पाया जाता है, तो उसे हटा दिया जाएगा। चूंकि संचार HTTP में हो रहा है, आप अप्रत्याशित कंटेनरों के हटाने से बचने के लिए संचार में छेड़छाड़ कर सकते हैं:
https://concourse-ci.org/vars.html
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)