LFI2RCE via Eternal waiting

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

मौलिक जानकारी

डिफ़ॉल्ट रूप से जब एक फ़ाइल PHP में अपलोड की जाती है (यह उम्मीद नहीं थी भी), तो यह /tmp में एक अस्थायी फ़ाइल उत्पन्न करेगा जिसका नाम php[a-zA-Z0-9]{6} जैसा होगा, हालांकि मैंने कुछ डॉकर छवियाँ देखी हैं जहां उत्पन्न फ़ाइलें अंक नहीं समायुक्त होती हैं।

स्थानीय फ़ाइल समावेश में, यदि आप उस अपलोड की गई फ़ाइल को समावेशित करने में सफल होते हैं, तो आपको RCE मिलेगा

ध्यान दें कि डिफ़ॉल्ट रूप से PHP केवल एक ही अनुरोध में 20 फ़ाइलें अपलोड करने की अनुमति देता है ( /etc/php/<version>/apache2/php.ini में सेट किया गया है):

; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20

इसके अलावा, संभावित फ़ाइल नामों की संख्या 62*62*62*62*62*62 = 56800235584 है

अन्य तकनीकें

अन्य तकनीकें PHP प्रोटोकॉल पर हमला करने पर निर्भर हैं (यदि आपके पास केवल पथ के अंतिम हिस्से का नियंत्रण है तो आप यह नहीं कर पाएंगे), फ़ाइल के पथ को उजागर करना, अपेक्षित फ़ाइलों का दुरुपयोग करना, या PHP को विभाजन त्रुटि का सामना कराना ताकि अपलोड की गई अस्थायी फ़ाइलें हटाई न जाएं। यह तकनीक पिछले तकनीक के बहुत ही समान है लेकिन किसी ज़ीरो दिन को खोजने की आवश्यकता नहीं है

शाश्वत प्रतीक्षा तकनीक

इस तकनीक में हमें केवल एक संबंधित पथ को नियंत्रित करने की आवश्यकता है। यदि हम फ़ाइलें अपलोड करने और LFI को कभी समाप्त नहीं होने देने में कामयाब होते हैं, तो हमें "पर्याप्त समय" होगा अपलोड की गई फ़ाइलों को ब्रूट-फ़ोर्स करने और अपलोड की गई किसी भी फ़ाइल को खोजने के लिए।

इस तकनीक के लाभ:

  • आपको केवल एक संबंधित पथ को नियंत्रित करने की आवश्यकता है

  • एनजिन्क्स या अपेक्षित स्तर के एक्सेस की आवश्यकता नहीं है ताकि लॉग फ़ाइलें

  • विभाजन त्रुटि का कारण बनाने के लिए एक ज़ीरो दिन की आवश्यकता नहीं है

  • पथ उजागर करने की आवश्यकता नहीं है

इस तकनीक की मुख्य समस्याएं हैं:

  • निश्चित फ़ाइल(ओं) की उपस्थिति की आवश्यकता है (अधिक हो सकती हैं)

  • संभावित फ़ाइल नामों की अत्यधिक संख्या: 56800235584

  • यदि सर्वर अंक उपयोग नहीं कर रहा है तो कुल संभावित मात्रा है: 19770609664

  • डिफ़ॉल्ट रूप से केवल 20 फ़ाइलें एक एकल अनुरोध में अपलोड की जा सकती हैं।

  • उपयोग किए गए सर्वर की पारलेल कर्मचारियों की अधिकतम संख्या

  • यह सीमा पिछले वालों के साथ इस हमले को बहुत अधिक चलने के लिए बना सकती है

  • PHP अनुरोध के लिए समय सीमा। आदर्श रूप से यह शाश्वत होना चाहिए या यदि नहीं, तो PHP प्रक्रिया को हटाए बिना अस्थायी अपलोड की गई फ़ाइलें हटा देना भी एक पीड़ा होगी।

तो, आप PHP इनक्लूड को कभी समाप्त कैसे कर सकते हैं? बस फ़ाइल /sys/kernel/security/apparmor/revision को शामिल करके। (डॉकर कंटेनर में उपलब्ध नहीं है, दुःख की बात...).

बस इसे बुलाकर कोशिश करें:

php -a # open php cli
include("/sys/kernel/security/apparmor/revision");

Apache2

डिफ़ॉल्ट रूप से, 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 घंटे (50% की संभावना 265 घंटे में)

  • (बिना अंक) 19770609664 / 2980 / 10 / 3600 ~= 185 घंटे (50% की संभावना 93 घंटे में)

पिछले उदाहरण में ध्यान दें कि हम अन्य ग्राहकों को पूरी तरह से DoS कर रहे हैं!

यदि Apache सर्वर में सुधार किया गया है और हम 4000 कनेक्शन (अधिकतम संख्या की ओर आधा) का उपयोग कर सकते हैं। हम 3999*20 = 79980 फ़ाइलें बना सकते हैं और संख्या को लगभग 19.7 घंटे या 6.9 घंटे (10 घंटे, 3.5 घंटे 50% की संभावना) तक कम किया जा सकता है।

PHP-FMP

यदि Apache के लिए नियमित php मॉड का उपयोग करने की बजाय वेब पृष्ठ PHP-FMP का उपयोग कर रहा है (यह वेब पृष्ठ की कुशलता में सुधार करता है, इसलिए इसे पाना सामान्य है), तो तकनीक को सुधारने के लिए कुछ और किया जा सकता है।

PHP-FMP को /etc/php/<php-version>/fpm/pool.d/www.conf में request_terminate_timeout पैरामीटर को कॉन्फ़िगर करने की अनुमति है। यह पैरामीटर सेकंड की अधिकतम मात्रा को दर्शाता है जब PHP को अनुरोध समाप्त होना चाहिए (डिफ़ॉल्ट रूप से अनंत, लेकिन 30 सेकंड अगर पैरामीटर को अनकमेंट किया गया है। जब एक अनुरोध PHP द्वारा प्रसंस्कृत किया जा रहा होता है तो निर्दिष्ट सेकंड की संख्या, तो वह मार दिया जाता है। इसका मतलब है, कि यदि अनुरोध अस्थायी फ़ाइलें अपलोड कर रहा था, क्योंकि php प्रसंस्करण रोक दिया गया था, तो वह फ़ाइलें हटाई नहीं जाएंगी। इसलिए, यदि आप एक अनुरोध को उस समय तक चला सकते हैं, तो आप हजारों अस्थायी फ़ाइलें उत्पन्न कर सकते हैं जो हटाई नहीं जाएंगी, जो उन्हें खोजने की प्रक्रिया को तेज करेगी और सभी कनेक्शन का उपयोग करके प्लेटफ़ॉर्म को DoS करने की संभावना को कम करेगी।

इसलिए, DoS से बचने के लिए मान लें कि एक हमलावर केवल 100 कनेक्शन का उपयोग कर रहा होगा और php द्वारा अधिकतम प्रसंस्करण समय (request_terminate_timeout) 30 सेकंड है। इसलिए, प्रति सेकंड उत्पन्न की जा सकने वाली अस्थायी फ़ाइलों की संख्या है 100*20/30 = 66.67

फिर, 10000 फ़ाइलें उत्पन्न करने के लिए एक हमलावर को चाहिए होगा: 10000/66.67 = 150 सेकंड (यदि 100000 फ़ाइलें उत्पन्न करने के लिए समय होगा 25 मिनट)।

फिर, हमलावर उन 100 कनेक्शनों का उपयोग करके एक खोज ब्रूट-फ़ोर्स कर सकता है। **** 300 अनुरोध/सेकंड की गति के साथ इसे उत्पन्न करने के लिए आवश्यक समय निम्नलिखित है:

  • 56800235584 / 10000 / 300 / 3600 ~= 5.25 घंटे (50% की संभावना 2.63 घंटे में)

  • (100000 फ़ाइलों के साथ) 56800235584 / 100000 / 300 / 3600 ~= 0.525 घंटे (50% की संभावना 0.263 घंटे में)

हाँ, एक EC2 मध्यम आकार के इंस्टेंस में 100000 अस्थायी फ़ाइलें उत्पन्न करना संभव है:

ध्यान दें कि टाइमआउट को ट्रिगर करने के लिए विकल्पनीय LFI पृष्ठ को शामिल करना पर्याप्त होगा, ताकि यह एक शाश्वत समावेश लूप में प्रवेश करे।

Nginx

डिफ़ॉल्ट रूप से लगता है कि Nginx एक साथ 512 समभावित कनेक्शन का समर्थन करता है (और यह संख्या सुधारी जा सकती है)।

Last updated