LFI2RCE via Eternal waiting
PreviousLFI2RCE Via temp file uploadsNextLFI2RCE Via compress.zlib + PHP_STREAM_PREFER_STUDIO + Path Disclosure
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)
डिफ़ॉल्ट रूप से जब एक फ़ाइल PHP में अपलोड की जाती है (भले ही इसकी अपेक्षा न की जा रही हो), तो यह /tmp में php[a-zA-Z0-9]{6} जैसे नाम के साथ एक अस्थायी फ़ाइल उत्पन्न करेगी, हालाँकि मैंने कुछ डॉकर इमेज देखी हैं जहाँ उत्पन्न फ़ाइलों में अंक नहीं होते हैं।
एक स्थानीय फ़ाइल समावेशन में, यदि आप उस अपलोड की गई फ़ाइल को शामिल करने में सफल होते हैं, तो आपको RCE मिलेगा।
ध्यान दें कि डिफ़ॉल्ट रूप से PHP केवल एकल अनुरोध में 20 फ़ाइलें अपलोड करने की अनुमति देता है (जो /etc/php/<version>/apache2/php.ini में सेट है):
Also, the संभावित फ़ाइल नामों की संख्या 62*62*62*62*62*62 = 56800235584 है।
अन्य तकनीकें PHP प्रोटोकॉल पर हमले पर निर्भर करती हैं (आप केवल पथ के अंतिम भाग को नियंत्रित करने पर सक्षम नहीं होंगे), फ़ाइल के पथ का खुलासा करना, अपेक्षित फ़ाइलों का दुरुपयोग करना, या PHP को विभाजन दोष का सामना करने के लिए मजबूर करना ताकि अपलोड की गई अस्थायी फ़ाइलें हटाई न जाएं। यह तकनीक पिछली तकनीक के समान है लेकिन शून्य दिन खोजने की आवश्यकता नहीं है।
इस तकनीक में हमें केवल एक सापेक्ष पथ को नियंत्रित करने की आवश्यकता है। यदि हम फ़ाइलें अपलोड करने और LFI को कभी समाप्त न होने में सक्षम होते हैं, तो हमारे पास अपलोड की गई फ़ाइलों को ब्रूट-फोर्स करने और खोजने के लिए "पर्याप्त समय" होगा।
इस तकनीक के लाभ:
आपको केवल एक शामिल में एक सापेक्ष पथ को नियंत्रित करने की आवश्यकता है
लॉग फ़ाइलों तक पहुँच के लिए nginx या अप्रत्याशित स्तर की आवश्यकता नहीं है
विभाजन दोष उत्पन्न करने के लिए 0 दिन की आवश्यकता नहीं है
पथ का खुलासा करने की आवश्यकता नहीं है
इस तकनीक की मुख्य समस्याएँ हैं:
एक विशिष्ट फ़ाइल(फाइलें) का होना आवश्यक है (और भी हो सकती हैं)
संभावित फ़ाइल नामों की असाधारण मात्रा: 56800235584
यदि सर्वर अंक का उपयोग नहीं कर रहा है तो कुल संभावित मात्रा: 19770609664
डिफ़ॉल्ट रूप से केवल 20 फ़ाइलें एक एकल अनुरोध में अपलोड की जा सकती हैं।
उपयोग किए गए सर्वर के समानांतर कार्यकर्ताओं की अधिकतम संख्या।
पिछले सीमाओं के साथ यह सीमा इस हमले को बहुत लंबा बना सकती है
PHP अनुरोध के लिए टाइमआउट। आदर्श रूप से, यह शाश्वत होना चाहिए या अस्थायी अपलोड की गई फ़ाइलों को हटाए बिना PHP प्रक्रिया को समाप्त करना चाहिए, यदि नहीं, तो यह भी एक समस्या होगी
तो, आप PHP शामिल को कभी समाप्त नहीं करने के लिए कैसे कर सकते हैं? बस फ़ाइल /sys/kernel/security/apparmor/revision को शामिल करके (दुर्भाग्यवश, यह डॉकर कंटेनरों में उपलब्ध नहीं है...)।
बस इसे कॉल करके आजमाएँ:
डिफ़ॉल्ट रूप से, Apache 150 समवर्ती कनेक्शन का समर्थन करता है, https://ubiq.co/tech-blog/increase-max-connections-apache/ के अनुसार, इस संख्या को 8000 तक बढ़ाना संभव है। उस मॉड्यूल के साथ PHP का उपयोग करने के लिए इसका पालन करें: https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04।
डिफ़ॉल्ट रूप से, (जैसा कि मैं अपने परीक्षणों में देख सकता हूँ), एक PHP प्रक्रिया अनंतकाल तक चल सकती है।
चलो कुछ गणित करते हैं:
हम 149 कनेक्शन का उपयोग करके 149 * 20 = 2980 अस्थायी फ़ाइलें उत्पन्न कर सकते हैं।
फिर, अंतिम कनेक्शन का उपयोग करके संभावित फ़ाइलों को ब्रूट-फोर्स करें।
10 अनुरोध/सेकंड की गति पर समय हैं:
56800235584 / 2980 / 10 / 3600 ~= 530 घंटे (265 घंटे में 50% संभावना)
(अंक के बिना) 19770609664 / 2980 / 10 / 3600 ~= 185 घंटे (93 घंटे में 50% संभावना)
ध्यान दें कि पिछले उदाहरण में हम अन्य ग्राहकों को पूरी तरह से DoSing कर रहे हैं!
यदि Apache सर्वर को बेहतर बनाया गया है और हम 4000 कनेक्शन का दुरुपयोग कर सकते हैं (अधिकतम संख्या के आधे रास्ते)। हम 3999*20 = 79980 फ़ाइलें बना सकते हैं और संख्या लगभग 19.7 घंटे या 6.9 घंटे (10 घंटे, 3.5 घंटे 50% संभावना) तक कम हो जाएगी।
यदि Apache के लिए नियमित php मोड का उपयोग करने के बजाय वेब पृष्ठ PHP-FMP का उपयोग कर रहा है (यह वेब पृष्ठ की दक्षता में सुधार करता है, इसलिए इसे पाना सामान्य है), तो तकनीक में सुधार करने के लिए कुछ और किया जा सकता है।
PHP-FMP request_terminate_timeout पैरामीटर को /etc/php/<php-version>/fpm/pool.d/www.conf में कॉन्फ़िगर करने की अनुमति देता है।
यह पैरामीटर अधिकतम सेकंड की मात्रा को इंगित करता है जब PHP को अनुरोध समाप्त करना चाहिए (डिफ़ॉल्ट रूप से अनंत, लेकिन यदि पैरामीटर को अनकमेंट किया गया है तो 30 सेकंड)। जब PHP द्वारा एक अनुरोध को संसाधित किया जा रहा है, तो निर्दिष्ट संख्या के सेकंड में, इसे मार दिया जाता है। इसका मतलब है, कि यदि अनुरोध अस्थायी फ़ाइलें अपलोड कर रहा था, क्योंकि PHP प्रोसेसिंग रोक दी गई थी, तो उन फ़ाइलों को हटाया नहीं जाएगा। इसलिए, यदि आप उस समय तक एक अनुरोध को बनाए रख सकते हैं, तो आप हजारों अस्थायी फ़ाइलें उत्पन्न कर सकते हैं जो नहीं हटेंगी, जो उन्हें खोजने की प्रक्रिया को तेज़ करती है और सभी कनेक्शनों का उपभोग करके प्लेटफ़ॉर्म पर DoS की संभावना को कम करती है।
तो, DoS से बचने के लिए मान लीजिए कि एक हमलावर केवल 100 कनेक्शन का उपयोग कर रहा होगा और php अधिकतम प्रोसेसिंग समय php-fmp (request_terminate_timeout**) 30 सेकंड है। इसलिए, प्रति सेकंड उत्पन्न होने वाली अस्थायी फ़ाइलों की संख्या है 100*20/30 = 66.67।
फिर, 10000 फ़ाइलें उत्पन्न करने के लिए एक हमलावर को आवश्यकता होगी: 10000/66.67 = 150 सेकंड ( 100000 फ़ाइलें उत्पन्न करने के लिए समय 25 मिनट होगा)।
फिर, हमलावर उन 100 कनेक्शनों का उपयोग करके ब्रूट-फोर्स खोज कर सकता है। **** 300 req/s की गति मानते हुए, इसे शोषण करने के लिए आवश्यक समय निम्नलिखित है:
56800235584 / 10000 / 300 / 3600 ~= 5.25 घंटे (2.63 घंटे में 50% संभावना)
(100000 फ़ाइलों के साथ) 56800235584 / 100000 / 300 / 3600 ~= 0.525 घंटे (0.263 घंटे में 50% संभावना)
हाँ, एक EC2 मध्यम आकार के उदाहरण में 100000 अस्थायी फ़ाइलें उत्पन्न करना संभव है:
ध्यान दें कि टाइमआउट को ट्रिगर करने के लिए कमजोर LFI पृष्ठ को शामिल करना पर्याप्त होगा, ताकि यह अनंत शामिल लूप में प्रवेश कर सके।
ऐसा लगता है कि डिफ़ॉल्ट रूप से Nginx 512 समानांतर कनेक्शन का समर्थन करता है (और इस संख्या को बेहतर बनाया जा सकता है)।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
