CVE-2018-7747

CalderaForms 1.5.9.1 XSS (إضافة ووردبريس) - برنامج تعليمي

CalderaForm هي إضافة لـ WordPress تتيح إنشاء النماذج بسهولة عبر السحب والإفلات. خلال نشاط حديث، صادف أن اختبرت بعض البوابات، وكانت إحداها تستضيف نموذج اتصال تم إنشاؤه بهذه الإضافة. الإعداد المخصص للمثيل المعني سمح لي باكتشاف ثغرة فيه: ونظرًا لطبيعتها البسيطة، التي تشبه ما يُشرَح في الكتيبات، أعتقد أنها ذريعة جيدة لشرح بعض الآليات للمبتدئين.

لأغراض تعليمية فقط - لا تستخدم هذه المعلومات لاختبار أي هدف دون إذن صريح ولا لأغراض غير قانونية - لا تغطس في الماء البارد أثناء الهضم - ارتدِ طبقات من الملابس عندما يكون الجو حارًا

للاستغلال الكامل:
https://www.exploit-db.com/exploits/44489/
بالنسبة إلى CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7747

الإعداد

في الإعداد محل التحليل، كان النموذج مضبوطًا على الرد برسالة شكر موجهة إلى المستخدم، تخاطبه بالاسم الذي أدخله للتو.

لتكرار بيئة الاختبار، قم بتثبيت نسخة من WordPress محليًا وتثبيت إضافة CalderaForms الإصدار 1.5.9.1 (متوفرة هنا أو هنا).

بعد التثبيت، من لوحة تحكم WordPress الإدارية > العمود الأيسر > "Caldera Forms" > الأزرار العلوية > "New Form" > حدد Contact Form، وأعد تسميته ثم "Create Form"

بمجرد إنشائه، يمكن تعديل إعداده: الأزرار العلوية > "Form Settings" > عدّل Success Message بحيث يشمل أحد البيانات التي أدخلها المستخدم. انقر على المربع فتظهر قائمة منسدلة من الاقتراحات.
أضف %first_name%

الأزرار العلوية > "Save Form"

لإدراج النموذج في صفحة: العمود الأيسر > "Pages" > "Sample Page" > "Edit" > "Caldera Form" > حدد النموذج الذي أنشأته للتو > "Insert Form" > العمود الأيمن > "Update"

تم.

الاستطلاع وتحديد ناقل الهجوم

سنتناول خطوة بخطوة الخطوات اللازمة لبناء هذا النوع من الهجوم، وفقًا لمنهج فرّق تسد.

في مرحلة الاختبار، عند التفاعل مع مكوّن ما، يجب دائمًا الانتباه إلى ردود أفعاله استجابةً للمحفزات المُدخلة؛ على وجه الخصوص، نركّز على "مسار" البيانات التي أدخلناها وأي تحويلات تطرأ عليها.

مثال محدد لحالتنا هو التالي:

0. نزور الصفحة التي تحتوي النموذج: http://127.0.0.1/wordpress/sample-page/

1. نملأ النموذج بالبيانات التالية
   "First Name": myName
   "Last Name": myLast
   "Email Address": my@e.mail
   "Comments": myComm

2. تتم معالجة البيانات وفقًا لمنطق الإضافة

3. رسالة الشكر المستلمة تحتوي على السلسلة التي أدخلناها في حقل First Name
   "Thank you myName, form has been successfully submitted."

السلسلة التي أدخلناها في حقل "First Name" تُعاد إلينا في رسالة الشكر.
على وجه الخصوص، تكون السلسلة محتواة داخل وسم div في HTML.
مدخلاتنا تنتهي في HTML الصفحة.
ملاحظة: "نحب هذا. لدينا نقطة تماس."

لنتقدم خطوة إلى الأمام. كيف تتم معالجة مدخلاتنا خلال المرحلة التي سميناها "المعالجة" (النقطة 2)؟ تحديدًا، ما نريد معرفته هو: هل توجد قيود على الأحرف (وتوليفاتها) التي يمكننا استخدامها؟ من الواضح أن الهدف هو النجاح في حقن "أشياء". عند محاولة تنفيذ حقن (injection)، يجب أن نضع في الاعتبار أين تنتهي مدخلاتنا وأن نستخدم "اللغة" المناسبة.

هل تتم معالجة مدخلاتنا بواسطة مترجم SQL؟ يجب أن نتحدث لغته
هل تتم معالجة مدخلاتنا بواسطة سكربت PHP؟ يجب أن نتحدث لغته
هل تنتهي مدخلاتنا في صفحة HTML؟ ...

إذن ما يهمنا هو معرفة ما إذا كان بإمكاننا استخدام الأحرف والتراكيب النمطية الخاصة بـ HTML، وبشكل خاص، نظرًا لقدرة هذه اللغة على احتواء/تفسير كود JavaScript، معرفة ما إذا كنا سنجد استراتيجية لإدخال كودنا في "منطقة الهبوط"، أي وسم div الذي لاحظناه سابقًا.

للقيام بذلك، نُدخل في حقل "First Name" وسم HTML بسيط ونرى ما إذا كان يتم "تعقيمه" (من sanitized)، أي ما إذا كان يُعدَّل بحيث يصبح غير ضار/غير قابل للتفسير، أو ما إذا كان يُعاد إلينا كما هو. نستخدم لهذا الغرض وسم <br>، الذي يُستخدم لإدراج فاصل أسطر في النص.

باتباع الترقيم السابق:

1. نملأ النموذج بالبيانات التالية
   "First Name": m<br>yName
   "Last Name": myLast
   "Email Address": my@e.mail
   "Comments": myComm

2. رسالة الشكر تحتوي على وسم HTML الخاص بنا، والذي لم يتم تعديله، ويتم تفسيره بشكل صحيح، حيث يُدخل فاصل أسطر في منتصف الرسالة

"Thank you m  
yName, form has been successfully submitted."

ملاحظة: "نحب هذا. يمكننا استخدام رمزي أصغر من وأكبر من، ويمكننا إدراج وسوم HTML لا يتم تعقيمها ويتم تفسيرها."

خطوة للأمام. نستبدل وسم التنسيق بشيء أكثر فائدة، مثل وسم <script>، الذي يتيح لنا إدراج كود JavaScript داخل الصفحة وتنفيذه.

1. نملأ النموذج بالبيانات التالية
   "First Name": m<script>alert(1);</script>yName
   "Last Name": myLast
   "Email Address": my@e.mail
   "Comments": myComm

2. رسالة الشكر تحتوي على وسم HTML الخاص بنا، والذي لم يتم تعديله، ويتم تفسيره بشكل صحيح، مع عرض تنبيه لنا.

ملاحظة 1: "نحب هذا. يمكننا تنفيذ كود JavaScript عشوائي في سياق متصفح المستخدم."
ملاحظة 2: "لا يعجبنا هذا. المستخدم الذي ينفذ JavaScript هو نحن أنفسنا."

التخزين والاستدعاء

الوضع هو كما يلي: يمكننا تنفيذ JavaScript عبر موقع لا نتحكم فيه في سياق متصفح أحد المستخدمين، لكن هذا المستخدم، حاليًا، هو نفسه من يُدخل القيم في النموذج. كل هذا غير مفيد إلى حد كبير.
الفكرة هي: هل توجد طريقة لاستدعاء رسالة الشكر التي تحتوي على الكود الذي نريد تنفيذه؟

لنعد إلى أول إرسال لنا، وهو إرسال "الاستطلاع" (أو لنعد تنفيذ الخطوات الأولى).

من خلال تحليل حركة مرور الشبكة أو مصدر الصفحة، ندرك أن النموذج ينفذ طلب POST إلى العنوان

http://127.0.0.1/wordpress/cf-api/CF5ad9b3176c0f4

(الجزء الأخير قد يختلف؛ عدّله كما يناسب في جميع الأمثلة التالية)
أي إلى العنوان

http://<target>/cf-api/<form-id>

وأن استجابة هذا الطلب هي JSON يحتوي على بعض البيانات، من بينها رسالة الشكر، وله البنية التالية:

{
      "data":
          {"cf_id":"48"},
      "html":"<div class=\" alert alert-success\">Thank you myName, form has been successfully submitted.<\/div>",
      "type":"complete",
      "form_id":"CF5ad9b3176c0f4",
      "form_name":"MyContactForm",
      "status":"complete"
}

نحتفظ بهذه المعلومة جانبًا، وسنعود إليها قريبًا؛ ونلاحظ بشكل خاص الحقلين "form_id" و "cf_id".

ماذا يوجد في العنوان الذي يُنفَّذ إليه طلب POST؟ دون كثير من التخمين، لنرَ ما يحدث إذا نفذنا طلب GET، أي إذا زرنا الصفحة على العنوان http://127.0.0.1/wordpress/cf-api/CF5ad9b3176c0f4، فسنجد، لا أكثر ولا أقل، HTML النموذج المعني.

1. نملأ النموذج بالبيانات التالية
   "First Name": myRedirectedName
   "Last Name": myLast
   "Email Address": my@e.mail
   "Comments": myComm

ونفحص حركة مرور الشبكة الناتجة عن الإرسال

هذه المرة نتلقى رمز HTTP 302 (إعادة توجيه) إلى الموقع /wordpress/cf-api/CF5ad9b3176c0f4/?cf_su=1&cf_id=49 الذي يعيد إلينا، لا أكثر ولا أقل، HTML الذي يحتوي على وسم div لرسالة الشكر.

لاحظ تنسيق هذا العنوان:

http://<target>/cf-api/<form-id>/?cf_su=1&cf_id=<cf-id>

حيث تكون قيمتا <form-id> و <cf-id> هما بالضبط القيمتان الموجودتان في JSON الذي حللناه سابقًا، وهما "form_id" و "cf_id" على التوالي.

هل أجبنا على السؤال الأول؟ نعم. لقد وجدنا طريقة لاستدعاء محتوى رسالة الشكر.
ملاحظة: "نحب هذا. يمكننا استدعاء الرسالة التي تحتوي على بياناتنا عند الحاجة."

بناء الهجوم

لنلخّص الأمور، ونربط كل المعلومات التي جمعناها حتى الآن، ولنصنع هجومًا.
1) نحفظ الكود الخبيث الخاص بنا على الهدف
2) نجمع البيانات اللازمة لاستعادة هذا الكود
3) نبني عنوان URL المناسب "لإطلاق" (من "to trigger") هجومنا

1. نملأ النموذج (من أي من الصفحتين، لا فرق) بالبيانات التالية
   "First Name": m<script>document.body.innerHTML=String.fromCodePoint(128046);</script>yName
   "Last Name": myLast
   "Email Address": my@e.mail
   "Comments": myComm

2. من خلال تحليل الحركة الناتجة، سواء بقراءة JSON المستلم في حالة صفحة sample-page أو قراءة إعادة التوجيه في حالة الصفحة التي تحتوي النموذج فقط، نستعيد المعرفين form_id و cf_id

{  
      "data":  
          {"cf_id":"69"},  
      "html":"...",  
      "type":"...",  
      "form_id":"CF5ad9b3176c0f4",  
      "form_name":"...",  
      "status":"..."  
}

3. نبني عنوان URL ونستخدمه لتنفيذ هجومنا

http://127.0.0.1/wordpress/cf-api/CF5ad9b3176c0f4/?cf_su=1&cf_id=69

بعض الملاحظات:

• لاحظ أن محتوى (أو بشكل أعم، سلوك) آخر صفحة تمت زيارتها يتحكم فيه نحن؛ استخدم خيالك
• تأمل في أن تعديل الصفحة الذي ينفذه كود JavaScript الخاص بنا يحدث داخل متصفح المستخدم: XSS هو نوع من الهجمات يُعرَّف بأنه هجوم من جانب العميل (client-side)
• لماذا كان من الضروري إيجاد طريقة لاستدعاء السكربت؟
  لأن الفكرة وراء هجوم XSS هي تنفيذ كود في سياق متصفح الضحية؛ خلال الاختبارات الأولى، نفذنا كود JS، لكن بشكل مؤقت وفي سياق متصفحنا نحن.
• لماذا استُخدمت بقرة؟ لأنها لطيفة
• معامل طلب GET "cf_id" هو معرّف (تتابعي) لمجموعة البيانات المُدخلة في النموذج؛ لذا، بإنقاص هذه القيمة يمكن المضي "عكسيًا في الزمن" واستعادة المعلومات التي أرسلها الآخرون سابقًا. لو كان المشتري في برج العقرب، وكان الزهرة ليس ضد زحل، وكان النموذج مضبوطًا على تضمين عنوان البريد الإلكتروني للمستخدم في رسالة الشكر أيضًا، لكان من الممكن افتراضيًا استعادة عناوين الزوار السابقين

يُقترح على القارئ، إذا كان مهتمًا، أن:

• يعيد تنفيذ الهجوم ويبني حمولة مناسبة بحيث يرى الضحية تنبيهًا يحتوي على السلسلة "MUCCA"
• يعيد التمرين السابق دون استخدام الحرف ' (الفاصلة العلوية، single quote)، أو الحرف " (علامة الاقتباس المزدوجة، double quotes)، أو الحرف ` (اللكنة المعكوسة، backtick أو backquote أو grave accent)، وهو غير موجود في تخطيط لوحات المفاتيح الإيطالية
• يطوّر سكربت، باللغة التي يفضلها، بحيث، عند إعطائه عنوان الصفحة على بوابة المستخدم التي تحتوي النموذج، ينفذ العمليات التالية:
  • ملء النموذج وإرساله
  • التحقق من إرجاع أحد الحقول المُدخلة
  • بناء وإرسال حمولة خبيثة داخل الحقل المستهدف
  • إرجاع عنوان الصفحة التي يمكن استدعاء الهجوم بها
• تغيير الإعداد الذي تم في بداية النموذج (تعديل رسالة الشكر) وإعادة اختبار السكربت من النقطة السابقة