Docker Breakout / Privilege Escalation
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks प्रशिक्षण AWS रेड टीम विशेषज्ञ (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण GCP रेड टीम विशेषज्ञ (GRTE)
Trickest का उपयोग करें और आसानी से बिल्ड और स्वचालित कार्यप्रणालियाँ बनाएं जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित हों। आज ही पहुंच प्राप्त करें:
linpeas: यह कंटेनरों की गणना भी कर सकता है
CDK: यह उपकरण खास रूप से उस कंटेनर की गणना करने के लिए उपयोगी है जिसमें आप हैं और स्वचालित रूप से भागने की कोशिश कर सकते हैं
amicontained: कंटेनर के द्वारा दी गई प्रिविलेज को प्राप्त करने के लिए उपयोगी उपकरण ताकि इससे भागने के तरीके ढूंढ़ सकें
deepce: कंटेनरों से गणना और भागने के लिए उपकरण
grype: छवि में स्थापित सॉफ्टवेयर में शामिल CVEs प्राप्त करें
यदि किसी प्रकार से आपको लगता है कि डॉकर सॉकेट डॉकर कंटेनर के अंदर माउंट किया गया है, तो आप इससे भाग सकेंगे। यह आम तौर पर उन डॉकर कंटेनरों में होता है जो किसी कारणवश डॉकर डेमन से कनेक्ट करने की आवश्यकता होती है ताकि कार्रवाई कर सकें।
इस मामले में आप सामान्य docker कमांड्स का उपयोग करके docker डेमन के साथ संचार कर सकते हैं:
यदि डॉकर सॉकेट अपेक्षित स्थान पर है तो आप इसके साथ अभी भी docker
कमांड का उपयोग करके संवाद कर सकते हैं पैरामीटर के साथ -H unix:///path/to/docker.sock
डॉकर डेमन एक पोर्ट में भी हो सकता है (डिफ़ॉल्ट रूप से 2375, 2376) या सिस्टमडी-आधारित सिस्टमों पर, डॉकर डेमन के साथ संवाद fd://
के माध्यम से हो सकता है।
इसके अतिरिक्त, अन्य उच्च स्तरीय रनटाइम के सॉकेट की रनटाइम सूची पर ध्यान दें:
dockershim: unix:///var/run/dockershim.sock
containerd: unix:///run/containerd/containerd.sock
cri-o: unix:///var/run/crio/crio.sock
frakti: unix:///var/run/frakti.sock
rktlet: unix:///var/run/rktlet.sock
...
आपको कंटेनर की क्षमताओं की जांच करनी चाहिए, यदि इसमें निम्नलिखित में से कोई है, तो आप इससे बचने के लिए सक्षम हो सकते हैं: CAP_SYS_ADMIN
, CAP_SYS_PTRACE
, CAP_SYS_MODULE
, DAC_READ_SEARCH
, DAC_OVERRIDE, CAP_SYS_RAWIO
, CAP_SYSLOG
, CAP_NET_RAW
, CAP_NET_ADMIN
आप पहले से उल्लिखित स्वचालित उपकरणों या का उपयोग करके वर्तमान में कंटेनर क्षमताएँ जांच सकते हैं:
एक विशेषाधिकृत कंटेनर --privileged
फ्लैग के साथ बनाया जा सकता है या विशेष रक्षाओं को अक्षम करके:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
/dev
माउंट करें
--privileged
फ्लैग कंटेनर सुरक्षा को काफी कम कर देता है, असीमित डिवाइस एक्सेस प्रदान करता है और कई सुरक्षा उपायों को छलने देता है। विस्तृत विश्लेषण के लिए, --privileged
के पूरे प्रभाव पर दस्तावेज़ीकरण देखें।
केवल विशेषाधिकार ध्वज के साथ आप होस्ट की डिस्क तक पहुंचने की कोशिश कर सकते हैं या रिलीज़_एजेंट या अन्य भागों का दुरुपयोग करके बच निकलने की कोशिश कर सकते हैं।
निम्नलिखित उल्टियों का परीक्षण करें जो एक कंटेनर में निष्पादित हो रहा है:
अच्छी तरह से कॉन्फ़िगर किए गए डॉकर कंटेनर fdisk -l जैसे कमांड को नहीं चलने देगा। हालांकि, जब --privileged
या --device=/dev/sda1
फ्लैग के साथ बूट किया जाता है, तो यह संभावना है कि आपको मेज़बान ड्राइव देखने के लिए विशेषाधिकार मिल सकते हैं।
इसलिए मेज़बान मशीन पर कब्ज़ा करना बहुत आसान है:
और देखो! अब आप मेज़बान के फ़ाइल सिस्टम तक पहुँच सकते हैं क्योंकि यह /mnt/hola
फ़ोल्डर माउंट किया गया है।
कंटेनर के भीतर, एक हमलावर होस्ट ओएस तक और पहुँच प्राप्त करने का प्रयास कर सकता है जिसे क्लस्टर द्वारा बनाए गए एक लिखने योग्य होस्टपैथ वॉल्यूम माउंट किया गया है। नीचे कुछ सामान्य चीजें हैं जिन्हें आप कंटेनर के भीतर जांच सकते हैं ताकि आप इस हमलावर वेक्टर का उपयोग कर सकें:
तकनीक की व्याख्या खोजें:
Docker release_agent cgroups escapeपिछले उत्पीड़नों में मेज़बान फ़ाइल सिस्टम में कंटेनर का पूर्ण पथ उजागर किया गया है। हालांकि, यह हमेशा ऐसा नहीं होता। उन मामलों में जहां आप मेज़बान में कंटेनर का पूर्ण पथ नहीं जानते हैं, आप इस तकनीक का उपयोग कर सकते हैं:
release_agent exploit - Relative Paths to PIDsकिसी विशेषाधिकार वाले कंटेनर के भीतर PoC को क्रियान्वित करने से निम्नलिखित के समान आउटपुट प्राप्त होना चाहिए:
कई फ़ाइलें हो सकती हैं जो माउंट की गई हों जो मेज़बान होस्ट के बारे में जानकारी देती हैं। इनमें से कुछ ऐसी भी हो सकती हैं जो कुछ होने पर मेज़बान द्वारा कुछ निष्पादित करने की संकेत देती हैं (जिससे हमलावर को कंटेनर से बाहर निकलने की अनुमति मिल सकती है)। इन फ़ाइलों का दुरुपयोग यह संभव बना सकता है कि:
release_agent (पहले से ही शामिल किया गया है)
हालांकि, आप इस पृष्ठ में अन्य संवेदनशील फ़ाइलें भी जांचने के लिए खोज सकते हैं:
Sensitive Mountsकई अवसरों में आपको यह मिलेगा कि कंटेनर में मेज़बान होस्ट से कुछ वॉल्यूम माउंट किया गया है। यदि यह वॉल्यूम सही ढंग से कॉन्फ़िगर नहीं किया गया है तो आप संवेदनशील डेटा तक पहुंचने/संशोधित करने की सक्षम हो सकते हैं: रहस्य पढ़ें, एसएसएच अधिकृत_कुंजियाँ बदलें...
यदि आपके पास कंटेनर के अंदर रूट के रूप में पहुंच है जिसमें होस्ट से कुछ फोल्डर माउंट किया गया है और आपने गैर-विशेषाधिकृत उपयोगकर्ता के रूप में होस्ट पर बच निकला है और माउंट किए गए फोल्डर पर पढ़ने की पहुंच है। आप कंटेनर के अंदर माउंट किए गए फोल्डर में एक बैश suid फ़ाइल बना सकते हैं और होस्ट से इसे निषेधाधिकार के लिए निष्पादित कर सकते हैं।
यदि आपके पास कंटेनर के अंदर रूट के रूप में पहुंच है और आप गैर-विशेषाधिकृत उपयोगकर्ता के रूप में होस्ट में बाहर निकल गए हैं, तो आप दोनों शैल्स का दुरुपयोग करके होस्ट के अंदर विशेषाधिकार उन्नति कर सकते हैं यदि आपके पास कंटेनर के अंदर MKNOD क्षमता है (यह डिफ़ॉल्ट रूप से है) जैसा कि इस पोस्ट में स्पष्ट किया गया है। इस प्रकार की क्षमता के साथ, कंटेनर के अंदर रूट उपयोगकर्ता को ब्लॉक उपकरण फ़ाइलें बनाने की अनुमति है। उपकरण फ़ाइलें विशेष फ़ाइलें हैं जो अंतर्निहित हार्डवेयर और कर्नेल मॉड्यूल तक पहुंचने के लिए उपयोग की जाती हैं। उदाहरण के लिए, /dev/sda ब्लॉक उपकरण फ़ाइल सिस्टम डिस्क पर रॉ डेटा पढ़ने की पहुंच प्रदान करती है।
डॉकर कंटेनर किसी भी ब्लॉक उपकरण के दुरुपयोग के खिलाफ सुरक्षित रखने के लिए एक cgroup नीति को लागू करके ब्लॉक उपकरण पढ़ने/लिखने के कार्यों को रोकता है। फिर भी, यदि कंटेनर के अंदर एक ब्लॉक उपकरण बनाया जाता है, तो यह कंटेनर के बाहर से /proc/PID/root/ निर्देशिका के माध्यम से पहुंचने योग्य हो जाता है। इस पहुंच के लिए आवश्यक है कि प्रक्रिया के मालिक दोनों कंटेनर के अंदर और बाहर समान हों।
इस लेखन से शोषण उदाहरण:
यदि आप मेज़बान के प्रक्रियाओं तक पहुंच सकते हैं तो आप उन प्रक्रियाओं में संग्रहित कई संवेदनशील जानकारी तक पहुंच सकेंगे। टेस्ट लैब चलाएँ:
उदाहरण के लिए, आप कुछ इस प्रकार से ps auxn
का उपयोग करके प्रक्रियाएँ सूचीबद्ध कर सकेंगे और कमांड में संवेदनशील विवरणों की खोज कर सकते हैं।
फिर, जैसे ही आप /proc/ में मेजबान की प्रत्येक प्रक्रिया तक पहुंच सकते हैं, आप उनके env गुप्त चीजें चुरा सकते हैं चलाकर:
आप भी अन्य प्रक्रियाओं के फ़ाइल डिस्क्रिप्टर्स तक पहुँच सकते हैं और उनकी ओपन फ़ाइल्स को पढ़ सकते हैं:
आप भी प्रक्रियाओं को मार सकते हैं और डीओएस का कारण बना सकते हैं।
यदि आपके पास किसी कंटेनर के बाहर की प्रक्रिया पर विशेषाधिकार है, तो आप nsenter --target <pid> --all
या nsenter --target <pid> --mount --net --pid --cgroup
जैसी कुछ चला सकते हैं ताकि आप उस प्रक्रिया के साथ समान ns प्रतिबंधों (आशा है कोई नहीं) वाला शैल चला सकें।
यदि एक कंटेनर को डॉकर होस्ट नेटवर्किंग ड्राइवर (--network=host
) के साथ कॉन्फ़िगर किया गया था, तो उस कंटेनर का नेटवर्क स्टैक डॉकर होस्ट से अलग नहीं है (कंटेनर होस्ट के नेटवर्किंग नेमस्पेस को साझा करता है), और कंटेनर को अपना आईपी-पता आवंटित नहीं किया जाता है। दूसरे शब्दों में, कंटेनर सभी सेवाएं सीधे होस्ट के आईपी पर बाइंड करता है। इसके अतिरिक्त, कंटेनर होस्ट द्वारा भेजे और प्राप्त कर रहा है सभी नेटवर्क ट्रैफ़िक को **अंतर्ग्रहण कर सकता है जो साझा इंटरफेस पर है tcpdump -i eth0
।
उदाहरण के रूप में, आप इसका उपयोग करके होस्ट और मेटाडेटा इंस्टेंस के बीच ट्रैफ़िक को स्निफ़ और स्पूफ़ कर सकते हैं।
जैसे निम्नलिखित उदाहरणों में:
आपको यहां तक पहुंचने की अनुमति भी होगी होस्ट के अंदर लोकलहोस्ट पर बाइंड नेटवर्क सेवाओं तक या फिर नोड की मेटाडेटा अनुमतियों तक (जो एक कंटेनर तक पहुंच सकती है)।
जब hostIPC=true
होता है, तो आपको मेज़बान के इंटर-प्रोसेस कम्यूनिकेशन (IPC) संसाधनों तक पहुंच मिलती है, जैसे कि साझा स्मृति /dev/shm
में। इससे यह संभव हो जाता है कि आप उन्हीं IPC संसाधनों पर पढ़ने/लिखने की अनुमति प्राप्त करें जो अन्य मेज़बान या पॉड प्रक्रियाओं द्वारा उपयोग किए जा रहे हों। ipcs
का उपयोग करके इन IPC तंत्रों की अध्ययन करें।
/dev/shm की जांच - इस साझा स्मृति स्थान में किसी भी फ़ाइल की खोज करें: ls -la /dev/shm
मौजूदा IPC सुविधाओं की जांच - आप /usr/bin/ipcs
का उपयोग करके देख सकते हैं कि क्या कोई IPC सुविधाएँ उपयोग की जा रही हैं। इसे इस प्रकार जांचें: ipcs -a
यदि सिस्कॉल unshare
को निषेधित नहीं किया गया है तो आप सभी क्षमताएँ पुनः प्राप्त कर सकते हैं:
पोस्ट https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/ में स्पष्ट किया गया दूसरा तकनीकी तरीका दिखाता है कि आप यूजर नेमस्पेस के साथ बाइंड माउंट का दुरुपयोग कैसे कर सकते हैं, ताकि मेजबान के अंदर के फ़ाइलों पर प्रभाव डाल सकें (उस विशिष्ट मामले में, फ़ाइलें हटा सकते हैं)।
Trickest का उपयोग करें और आसानी से वर्कफ़्लो को बनाएं और स्वचालित करें जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित होता है। आज ही पहुंच प्राप्त करें:
यदि आप docker exec
को रूट के रूप में निष्पादित कर सकते हैं (संभावित रूप से sudo के साथ), तो आप CVE-2019-5736 का दुरुपयोग करके निकल सकते हैं (यहां दुरुपयोग यहां है)। यह तकनीक बुनियादी रूप से /bin/sh बाइनरी को मेजबान से कंटेनर में अधिलेखित कर देगी, ताकि कोई भी docker exec को चलाने वाला पेलोड ट्रिगर कर सके।
पेलोड को अनुसार बदलें और go build main.go
के साथ main.go को बनाएं। परिणामी बाइनरी को कंटेनर में निष्पादन के लिए रखा जाना चाहिए।
निष्पादन के दौरान, जैसे ही यह [+] Overwritten /bin/sh successfully
प्रदर्शित करता है, आपको मेजबान मशीन से निम्नलिखित को निष्पादित करना होगा:
docker exec -it <container-name> /bin/sh
यह पेलोड को ट्रिगर करेगा जो मुख्य.go फ़ाइल में मौजूद है।
अधिक जानकारी के लिए: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
कंटेनर को अनुरक्षित करने वाली अन्य CVEs हो सकती हैं, आप https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list में सूची पा सकते हैं।
नेमस्पेस: प्रक्रिया को नेमस्पेस के माध्यम से पूरी तरह से अलग रखा जाना चाहिए, ताकि हम नेमस्पेस के कारण अन्य प्रक्रियाओं के साथ बातचीत से बच सकें (डिफ़ॉल्ट रूप से IPCs, यूनिक्स सॉकेट, नेटवर्क सेवाएं, D-Bus, अन्य प्रक्रियाओं के /proc
के माध्यम से संवाद नहीं कर सकते)।
रूट उपयोगकर्ता: डिफ़ॉल्ट रूप से प्रक्रिया चलाने वाला उपयोगकर्ता रूट उपयोगकर्ता है (हालांकि इसकी विशेषाधिकारिता सीमित है)।
क्षमताएँ: Docker निम्नलिखित क्षमताएँ छोड़ता है: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
सिसकॉल्स: ये सिसकॉल्स हैं जिन्हें रूट उपयोगकर्ता कॉल नहीं कर सकेगा (क्षमताओं की कमी + Seccomp के कारण)। बचे हुए सिसकॉल्स का प्रयास करने के लिए उपयोग किया जा सकता है।
{% टैब शीर्षक="arm64 सिसकॉल्स" %}
{% टैब शीर्षक="syscall_bf.c" %}
If you are in userspace (no kernel exploit involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
Find the path of the containers filesystem inside the host
You can do this via mount, or via brute-force PIDs as explained in the second release_agent exploit
Find some functionality where you can indicate the path of a script to be executed by a host process (helper) if something happens
You should be able to execute the trigger from inside the host
You need to know where the containers files are located inside the host to indicate a script you write inside the host
Have enough capabilities and disabled protections to be able to abuse that functionality
You might need to mount things o perform special privileged actions you cannot do in a default docker container
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)