Exploit for CVE-2019-5736-PoC

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-FRICHETTEN-CVE-2019-5736-POC
# CVE-2019-5736-PoC

CVE-2019-5736 के लिए PoC

की सहायता से बनाया गया @singe, @_cablethief, और @feexd

Ubuntu 18.04, Debian 9, और Arch Linux पर परीक्षण किया गया। Docker संस्करण 18.09.1-ce और 18.03.1-ce। यह PoC वर्तमान में Ubuntu 16.04 और CentOS के साथ काम नहीं करता है।

Dragon Sector (जिन्होंने कमजोरी की खोज की) से एक्सप्लॉइट कोड देखें यहाँ।

### यह क्या है?

यह CVE-2019-5736 का Go कार्यान्वयन है, जो Docker के लिए एक कंटेनर एस्केप है। एक्सप्लॉइट कंटेनर के अंदर से होस्ट सिस्टम के runc बाइनरी को ओवरराइट और निष्पादित करके काम करता है।

## एक्सप्लॉइट कैसे काम करता है?

एक्सप्लॉइट के **2** उपयोग मामले हैं। पहला (जो इस रिपॉजिटरी में है), मूलतः एक जाल है। हमलावर को कंटेनर के अंदर कमांड निष्पादन प्राप्त करना होगा और एक दुर्भावनापूर्ण बाइनरी शुरू करनी होगी जो सुनेगी। जब कोई (हमलावर या पीड़ित) कंटेनर में प्रवेश करने के लिए `docker exec` का उपयोग करता है, तो यह एक्सप्लॉइट को ट्रिगर करेगा जो रूट के रूप में कोड निष्पादन की अनुमति देगा।

![](https://assets.kitploit.com/production/public/readmes/36124/453946e0d0d9db21ee8607e84d8f76f643cf2e842186f25f044d134ba64411c4.gif)

दूसरा (जो **नहीं** है यह रिपॉजिटरी), एक दुर्भावनापूर्ण Docker इमेज बनाता है। जब वह इमेज चलाई जाती है, एक्सप्लॉइट सक्रिय हो जाता है। कंटेनर में exec करने की आवश्यकता नहीं है। gif उदाहरण के लिए इस रीडमी के नीचे देखें।

### आपको क्या चाहिए?

इस कमजोरी का शोषण करने के लिए आपको कंटेनर के अंदर रूट (uid 0) होना आवश्यक है।

### क्या कोई दुष्प्रभाव हैं?

**हाँ, आप अपने runc के कार्यान्वयन को ओवरराइट कर देंगे जिससे आपका सिस्टम Docker कंटेनर चलाने में असमर्थ हो जाएगा। कृपया /usr/bin/docker-runc या /usr/bin/runc (इस पर निर्भर करता है कि आपके पास कौन सा है; /usr/sbin भी जांचें) का बैकअप लें।**

### मैं इसे कैसे चलाऊं?

कोड को अपनी इच्छानुसार संशोधित करें और `go build main.go` से संकलित करें। उस बाइनरी को उस कंटेनर में ले जाएं जिससे आप बचना चाहते हैं। बाइनरी निष्पादित करें, और फिर अगली बार जब कोई इससे जुड़ता है और `/bin/sh` कॉल करता है, तो आपका पेलोड सक्रिय हो जाएगा।

### चरण दर चरण स्पष्टीकरण

यह PoC lxc प्रोजेक्ट की इस कमिट (और दूसरों से कुछ सहायक सलाह) के उत्कृष्ट स्पष्टीकरण का उपयोग करके बनाया गया था।

> उदाहरण के तौर पर, यदि लक्ष्य बाइनरी /bin/bash था, तो इसे एक निष्पादन योग्य स्क्रिप्ट से बदला जा सकता है जो इंटरप्रेटर पथ #!/proc/self/exe निर्दिष्ट करती है (/proc/self/exec कर्नेल द्वारा प्रत्येक प्रक्रिया के लिए बनाया गया एक प्रतीकात्मक लिंक है जो उस प्रक्रिया के लिए निष्पादित बाइनरी की ओर इशारा करता है)। इस प्रकार जब /bin/bash कंटेनर के अंदर निष्पादित होता है, तो इसके बजाय /proc/self/exe का लक्ष्य निष्पादित होगा - जो होस्ट पर runc बाइनरी की ओर इशारा करेगा।

हम इसे कंटेनर में `/bin/sh` को `#!/proc/self/exe` से ओवरराइट करके लागू करते हैं जो इस प्रक्रिया को शुरू करने वाली बाइनरी (Docker exec) की ओर इशारा करेगा।

![](https://assets.kitploit.com/production/public/readmes/36124/76e26db4db3a4a2d7f2a72a3e5110103cee73ec900c306176bbf207b8cead1cc.png)

> हमलावर तब /proc/self/exe के लक्ष्य पर लिखने का प्रयास कर सकता है ताकि होस्ट पर runc बाइनरी को ओवरराइट कर सके। हालांकि, सामान्यतः यह सफल नहीं होगा क्योंकि कर्नेल इसे तब ओवरराइट होने की अनुमति नहीं देगा जब runC निष्पादित हो रहा है। इसे दूर करने के लिए, हमलावर इसके बजाय O_PATH फ्लैग का उपयोग करके /proc/self/exe के लिए फ़ाइल डिस्क्रिप्टर खोल सकता है और फिर /proc/self/fd/ के माध्यम से बाइनरी को O_WRONLY के रूप में फिर से खोल सकता है और एक अलग प्रक्रिया से बिजी लूप में उस पर लिखने का प्रयास कर सकता है।

नोट: पिछले अनुभाग के कुछ भाग पूरी तरह से सटीक नहीं हैं। runcinit के लिए फ़ाइल डिस्क्रिप्टर प्राप्त करते समय आपको O_PATH फ्लैग का उपयोग करने की आवश्यकता नहीं है। इसके अतिरिक्त आपको दूसरी प्रक्रिया में राइट लूप बनाने की आवश्यकता नहीं है। हम `/proc/PID/exe` के लिए फ़ाइल हैंडल प्राप्त करके `runcinit` के लिए फ़ाइल डिस्क्रिप्टर प्राप्त करते हैं। वहां से, हम फिर उस हैंडल का उपयोग करके `/proc/self/fd/FILEDESCRIPTOR` के लिए फ़ाइल हैंडल प्राप्त करते हैं। यह फ़ाइल हैंडल है जिसका उपयोग हम लिखने के लिए करेंगे।

![](https://assets.kitploit.com/production/public/readmes/36124/4872af1531d14c111d96214b2ae206dd728788bdbe96b92cb198ffc444c67e15.png)

> अंततः यह तब सफल होगा जब runC बाइनरी बाहर निकलती है। इसके बाद runC बाइनरी से समझौता हो जाता है और इसका उपयोग अन्य कंटेनरों या होस्ट पर हमला करने के लिए किया जा सकता है।

यदि हम उस फ़ाइल हैंडल पर लिखने में सक्षम हैं तो हमने होस्ट पर `runc` बाइनरी को ओवरराइट कर दिया है। हम रूट के रूप में मनमाने कमांड निष्पादित करने में सक्षम हैं।

### दुर्भावनापूर्ण Docker इमेज का उदाहरण

इस रिपॉजिटरी में यह उदाहरण शामिल नहीं है लेकिन आप इसे यहाँ पा सकते हैं। मेरी राय में, यह कहीं अधिक खतरनाक परिदृश्य है। बस दुर्भावनापूर्ण कंटेनर इमेज चलाएं और आपको रूट के रूप में कोड निष्पादन मिलता है। विस्तृत स्पष्टीकरण के लिए कृपया यह देखें।

![](https://assets.kitploit.com/production/public/readmes/36124/eb862d3a0756624a3dc3ec52cc477f28d8579320575c4fe055be10ab3fde57ac.gif)