bishopfox/imperva_gzip_waf_bypassاستغلال لتجاوز جدار حماية الويب السحابي Imperva باستخدام ترويسة Content-Encoding بنوع gzip للالتفاف على قواعد WAF في طلبات HTTP POST. يتضمن سكريبت اكتشاف وخطوات اختبار يدوي.
كان جدار حماية 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 في سطر الأوامر لتفعيل الوضع المرن. الوضع المرن معطّل افتراضيًا، وهو ما يعني أن طلب 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. تحتوي ملاحظات إصدار SecureSphere الإصدار 12.6 على هذه الفقرة:
SPHR-58185: عندما يفشل SecureSphere في فك ضغط جسم POST في الطلبات التي تحمل ترويسة "Content-Encoding: gzip/deflate"، فإنه لا يصدر أي تنبيه ويسمح بمرور الطلب.
أنا شبه متأكد من أن هذا هو نفس الخطأ، ربما بنفس الجذور البرمجية لـ Cloud WAF... إنه خطأ محدد جدًا بحيث يصعب وجوده في منتجين. تم حل المشكلة في SecureSphere في فبراير 2021، لكننا لا نعرف متى ظهرت لأول مرة. من المحتمل أن الثغرة كانت موجودة منذ سنوات!
دعم عملاء Imperva: https://www.imperva.com/support/technical-support/