ماذا حدث عندما كسرنا المعرض؟

Q RC OD E من خلال تطبيق محمول لمسح شارات العارضين لمشاريع أمن المعلومات.

قمنا في العام الماضي بزيارة معرض كبير لمشاريع أمن المعلومات في لندن. في التحضير ، تم إرسال بطاقاتنا على شكل ملفات PDF "اطبعها بنفسك".


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

{"CJe";"BHEEZST","DO";"Cvmmfuqsppg","G";"upn","KU";"Qfofusbujpo uftufs","T";"xzbuu"} 

اتضح أنه JSON تقريبًا ولكن ليس تمامًا. واحدة من مزايا هذا الاسم القصير مثل لي هو أنه يلفت انتباهك في مثل هذه المواقف. لذلك ، لاحظت على الفور أن اسمي تم ترميزه في ROT-25 ("توم" تحول إلى "upn"). يُعرف أيضًا باسم تشفير قيصر ، حيث يتم استبدال كل حرف بحرف آخر بإزاحة ثابتة (في هذه الحالة ، تم استخدام الحرف في الأبجدية بدلاً من كل حرف). بعد تشغيل الخط من خلال وحدة فك الترميز (مع مراعاة ترميز JSON) ، حصلنا على:

 {"BId";"AGDDYRS","CN";"Bulletproof","F";"tom","JT";"Penetration tester","S";"wyatt"} 

هذا أكثر قابلية للقراءة.

كسرها؟

الغريب أن كود QR يخزن المعلومات التي يبدو أنها تتعلق بحقل BId في قاعدة البيانات. لماذا؟ حسنًا ، هذا بسيط جدًا. قدم المنظمون تطبيقًا للجوّال للبائعين يساعدهم في جمع جهات اتصال المشاركين أثناء المعرض. افترضنا أن البيانات مشفرة في رمز الاستجابة السريعة في حالة عدم استقرار شبكة Wi-Fi أو الإشارة الخلوية.

حتى الآن ، لا يمكننا فعل الكثير بهذه المعلومات ، باستثناء تغيير بياناتنا لتجنب البريد العشوائي من البائعين من الحدث. سيكون الأمر مضحكًا ، ولكن بالكاد يستحق إرسال بريد إلكتروني إلى مطور النظام. لذلك ، ذهبنا إلى Play Market وقمنا بتثبيت التطبيق المناسب لمعرفة ما يفعله.


وهنا واجهنا مشكلة: لم يكن لدينا البيانات اللازمة من منظمي الحدث. اعتقدنا أنه يمكننا تزوير استجابة الخادم باستخدام وكيل MiTM ، وسيسمح لنا التطبيق بالذهاب. أنشأنا Burpsuite وسجلنا بعض محاولات تسجيل الدخول غير الناجحة ، على أمل اعتراض حركة المرور واللعب بها.

للأسف ، لم ننجح. وجه التطبيق جميع الطلبات باستخدام SOAP ، ولم تكن الردود واضحة. ومع ذلك ، ينشر الخادم وثائق WSDL للتطبيق.

هذه ليست النهاية

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


قمنا بمسح شارات ضوئية ، ويبدو أن كل شيء يعمل بشكل صحيح. تقدم! بعد التجول في التطبيق لبعض الوقت ، أصبح من الواضح أنه كان يستخدم نوعًا من إطار عمل يستند إلى WebView. حفر قليلاً في APK ، وجدنا عددًا من الإشارات إلى Sencha و Ext.js ، والتي أكدت افتراضنا.

والآن - الأكثر إثارة للاهتمام. إذا كان التطبيق يتكون من خليط منتظم من HTML و JavaScript ، فهل يمكن أن يكون عرضة لهجمات الويب القياسية؟ لقد قمنا بلف بعض XSS'es في "not-تماما-JSON" التي يتوقعها التطبيق وفحصها و ...

كسرناه

عظيم! أظهر حقن HTML في حقل "JT" الصورة. يمكننا إضافة السمة "onerror" إلى هذه العلامة لتحقيق تنفيذ البرنامج النصي ، ولكننا مقيدون بالقيود على الحد الأقصى لطول رمز الاستجابة السريعة. ونتيجة لذلك ، قمنا بإنشاء حمولة تقوم بتنزيل ملف JS من الخادم وتشغيله على الجهاز. هنا ، على سبيل المثال ، هو اختبار التنبيه القياسي ():


يؤدي مسح الرمز الشريطي إلى تشغيل XSS وتنفيذ الرمز:


قمنا بتدوينه بحيث يتناسب تمامًا مع الحجم الأقصى لرمز QR القابل للقراءة ، وليس كثيفًا جدًا للطباعة على بطاقة. بعد قراءة وثائق واجهة برمجة التطبيقات Ext.js ومقارنتها بشفرة APK المترجمة ، تمكنا من إنشاء رمز شريطي:

1. قم بتنزيل ملف JS من خادم بعيد
2. يقرأ مفاتيح الجلسة من هاتف ذكي ويرسلها إلى خادمنا
3. قراءة محتويات قاعدة بيانات جهات الاتصال المخزنة مؤقتًا من التطبيق ، بما في ذلك أسماء وعناوين البريد الإلكتروني لجميع الذين تم مسح بطاقاتهم ضوئيًا بواسطة هذا الجهاز
4. حذف التسجيل الخاص بك من الهاتف الذكي

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

الحمولة:



الطلبات إلى خادم الويب:

كل شيء على ما يرام ينتهي بشكل جيد

لفتنا انتباه البائعين في المعرض ، وبعد بعض المناقشات ، قرروا عدم استخدام التطبيق هذا العام. استفاد عدد قليل من الأشخاص في الحدث من التطبيق ، بينما يفضل معظم ماسحات الباركود الصغيرة البسيطة عليه. تم تنزيل التطبيق من السوق حوالي 500 مرة فقط. ومع ذلك ، يعد هذا متجهًا مثيرًا للاهتمام لـ XSS ، والذي يوضح أنك تحتاج حقًا إلى تصفية البيانات قبل الاستخدام ، بغض النظر عن مصدرها.

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