StrandHogg 2.0 هي ثغرة أمنية جديدة وخطيرة في نظام Android. وإليك كيف يمكن أن يؤثر ذلك على المستخدمين وكيف يمكن للمطورين حماية تطبيقاتهم ضده.
إنها الساعة 10:00 مساءً. هل تعرف أين أنشطتك؟ هناك ثغرة أمنية جديدة يمكن استغلالها على ملايين أجهزة Android، وهي ثغرة سيئة جدًا أيضًا. باختصار، يسمح هذا الخلل في التصميم للمهاجم بعرض نشاطه (صفحة) الخاصة به فوق تطبيق آخر، مما قد يؤدي إلى إرباك المستخدم ودفعه إلى الكشف عن بياناته الخاصة. وقد أطلق على الثغرة الأمنية اسم StrandHogg 2.0 وتم الكشف عنها مؤخرًا بواسطة برومون، شركة أمنية نرويجية.
تؤثر ثغرة StrandHogg 2.0 نظريًا على جميع أجهزة Android التي تعمل بإصدارات Android القديمة مثل Honeycomb (3.0) وحتى Android 9 Pie (9.0). على أساس أحدث إحصائيات توزيع إصدارات أندرويد، هذا يعني أن ما يقرب من 91.8٪ من جميع أجهزة Android معرضة لـ StrandHogg 2.0. تم تعيين الثغرة الأمنية CVE-2020-0096 وأعطي أ مستوى خطورة "حرجة". لا يتطلب أي أذونات خاصة للعمل ويمكن أن يعمل بشكل كامل تقريبًا دون تدخل المستخدم. كل ما يتعين على المستخدم فعله هو فتح تطبيق يحتوي على تعليمات برمجية ضارة مخبأة فيه، ومن ثم يصبح عرضة للاستغلال.
لقد كان Promon لطيفًا بما يكفي ليرسل إلينا إثباتًا لتطبيق المفهوم وكود المصدر الخاص به حتى نتمكن من تحقيق الأفضل اشرح كيفية عمل الاستغلال، وسبب أهميته للمستخدمين، وكيف يمكن للمطورين حماية تطبيقاتهم ضدها.
كيف تعمل
لنفترض أنك تستخدم Gmail وقمت بالنقر فوق رابط ويب. إذا انتقلت إلى شاشة التطبيقات الحديثة، فقد تلاحظ أن صفحة الويب تبدو "داخل" Gmail. تعرض المعاينة موقع الويب، لكن رمز التطبيق واسمه لا يزالان من Gmail. يحدث هذا عندما يقوم تطبيق/نشاط بتشغيل تطبيق/نشاط آخر في نفس المهمة. تخيل الآن أنك لم تفتح هذا الرابط عمدًا. بالنسبة لك، يبدو أنه مجرد جزء من تطبيق Gmail. هذا هو السلوك الذي يستغله StrandHogg 2.0.
سيتعين علينا أن نترك بعض التفاصيل هنا، ولكن إليك كيفية عمل هذا الاستغلال تقريبًا. بالنسبة لما يلي، لنفترض أن المهاجم يريد الحصول على تسجيل دخول المستخدم إلى Gmail.
- يقوم المستخدم بتنزيل تطبيق ضار (بالطبع، دون أن يعرف أنه ضار) ويفتحه.
- في الخلفية، يفتح التطبيق Gmail، ويضع فوقه نشاط تسجيل دخول مشابهًا، ثم يقوم بتشغيل نشاط آخر.
- يفتح المستخدم Gmail ويرى ما يشبه شاشة تسجيل الدخول إلى Gmail ولكنه في الواقع نشاط تصيد احتيالي للمهاجم.
النشاط النهائي الذي تم إطلاقه في الخطوة 2 يمكن أن يكون أي شيء يتجنب الشك. يمكن أن يتظاهر التطبيق بالتعطل ويعود إلى الشاشة الرئيسية، أو يمكن أن يفتح فقط لنشاطه الرئيسي كما لو لم يحدث شيء. الشيء الوحيد المريب الذي قد يراه المستخدم هو مجموعة من الرسوم المتحركة الافتتاحية عند بدء جميع الأنشطة. أسوأ ما في الأمر: لن يبدو الأمر وكأن Gmail قد تم فتحه.
وبطبيعة الحال، يمكن للمهاجم أن يفعل أكثر من مجرد إظهار شاشة تسجيل دخول مزيفة. يمكن أن يقدم تطبيق ضار مطالبة بالأذونات بدلاً من ذلك، مما يخدع المستخدم لمنح أذونات غير مرغوب فيها. على الرغم من أن طلب أي أذونات خاصة مثل إمكانية الوصول قد يثير شكوك المستخدم، فمن الممكن أن يحدث الكثير من الضرر باستخدام شيء مثل الوصول إلى التخزين.
البتات التقنية
هذا القسم التالي عبارة عن نظرة عامة عالية المستوى حول كيفية عمل StrandHogg 2.0. لن يقوم Promon بنشر التفاصيل الكاملة لبضعة أشهر أخرى، لذلك لا يمكننا مشاركة كيفية تنفيذ هذا الاستغلال بالضبط. ومع ذلك، هناك بعض التفاصيل الفنية التي يمكننا التحدث عنها.
باختصار، StrandHogg 2.0 يخطف نظام Android Context.startActivities() طريقة API، باستخدام ثلاثة نوايا.
- الهدف الأول هو الذي يطلق Gmail، في حالة مثالنا. تم وضع علامة عليها
Intent.FLAG_ACTIVITY_NEW_TASK. - النية الثانية هي الخبيثة. في مثالنا، يتعلق الأمر بنشاط تسجيل الدخول المشابه. هذه النية لا تحتوي على علامات.
- المقصد الثالث هو الهاء. إنه يتأكد من أن المستخدم لا يشك في أن Gmail يفتح بشكل عشوائي بدلاً من التطبيق الذي نقر عليه (أي التطبيق الذي يشن الهجوم). تم وضع علامة عليها
Intent.FLAG_ACTIVITY_NEW_TASK.
يتم بعد ذلك تمرير كل هذه النوايا في مصفوفة إلى ملف startActivities() طريقة.
إن افتقار النية الثانية إلى الأعلام هو المفتاح هنا. ومن خلال القيام بذلك، نكون قد قمنا بتكرار مثال Gmail المذكور أعلاه. المهمة من الناحية الفنية تخص Gmail، لكن النشاط الأعلى هو للمهاجم. عندما ينقر المستخدم بعد ذلك على أيقونة شاشة Gmail الرئيسية، يتم عرض نشاط المهاجم بدلاً من نشاط Gmail.
إثبات المفهوم
بفضل المعلومات التي أرسلها إلينا برومون، تمكنا من تكرار إثبات المفهوم الخاص بهم. إليك تسجيل شاشة من هاتف Samsung Galaxy Note8 الذي يعمل بنظام التشغيل Android 9 Pie ويظهر ذلك أثناء العمل.
تقنيات وقضايا التخفيف
الآن، مجرد تكرار ما ورد أعلاه في التعليمات البرمجية لن ينجح فعليًا. إنه ليس مثالًا كاملاً، وهناك بعض الأشياء الأخرى التي يجب على المهاجم القيام بها لإنجاح الأمر، والتي لا يمكننا مشاركتها. لكن ليس من الصعب تخمينها بنفسك، وهذا جزء مما يجعل هذا الهجوم خطيرًا للغاية. يعد StrandHogg 2.0 استغلالًا سهل التنفيذ نسبيًا، ويصعب التخفيف منه.
لا يمكن أن يشمل التخفيف فقط إدراج جميع التطبيقات التي تستخدمها في القائمة السوداء startActivities()، نظرًا لوجود الكثير من الاستخدامات المشروعة له. من الصعب أيضًا أتمتة خوارزمية الكشف عنها. يمكن لمطوري البرامج الضارة استخدام جميع أنواع الحيل لجعل تطبيق StrandHogg 2.0 غير مرئي بشكل فعال لخدمات مثل Google Play Protect. تطلب StrandHogg 1.0 من المهاجم إضافة سمة في ملف AndroidManifest.xml الخاص بالتطبيق الضار، والذي كان من السهل نسبيًا اكتشافه. من ناحية أخرى، يعمل StrandHogg 2.0 بالكامل في Java/Kotlin.
مع الأخذ في الاعتبار التشويش والانعكاس وحتى أنماط الترميز المختلفة، يبدو من غير العملي اكتشاف تطبيق يستخدم هذا الاستغلال بشكل صحيح تلقائيًا. والأكثر من ذلك هو أنه إذا كان المستخدم موضوعًا لهجوم StrandHogg 2.0، فقد لا يعرف حتى ذلك. إذا قمت بفتح Gmail ورأيت شاشة تسجيل الدخول الخاصة به، فقد تعتقد أن جلستك قد انتهت وأدخل تفاصيل تسجيل الدخول الخاصة بك دون تفكير آخر.
عندما اتصلنا بشركة Google للحصول على رد، قدم المتحدث الرسمي البيان التالي:
"نحن نقدر عمل الباحثين، وأصدرنا حلاً للمشكلة التي حددوها. بالإضافة إلى ذلك، يكتشف Google Play Protect التطبيقات الضارة ويحظرها، بما في ذلك التطبيقات التي تستخدم هذه التقنية."
يبدو هذا جيدًا، ونأمل أن يكون له بعض التأثير على الأقل ضد هجمات StrandHogg 2.0. ومع ذلك، تجدر الإشارة إلى أن Google Play Protect لم اكتشاف دليل إثبات المفهوم الخاص بنا باعتباره تطبيقًا ضارًا، حتى بعد إجراء فحص يدوي.
يقول برومون أنهم "لم ألاحظ أي برامج ضارة حقيقية تستخدم ثغرة StrandHogg 2.0"، ولكن ليس هناك ما يضمن أن هذه هي المرة الأولى التي يتم فيها اكتشاف برمجية إكسبلويت. لهذا السبب، يوصي Promon المطورين بالمضي قدمًا وحماية تطبيقاتهم من خلال تعيين نشاط المشغل الخاص بهم launchMode العلم إما singleTask أو singleInstance. ستمنع أي من هذه العلامات إدخال المهام، وهو ما يعتمد عليه StrandHogg 2.0. ومع ذلك، فإن استخدام نشاطك لإحدى هذه العلامات يمكن أن يسبب مشكلات في تدفقات تطبيقات معينة، لذلك ليس من المرغوب فيه دائمًا.
تقوم Promon أيضًا بالترويج لمنتج "In-App Protection by Promon SHIELD" الخاص بها والذي يبدو وكأنه مكتبة التي يمكن لمطوري التطبيقات تنفيذها لمراقبة المهام في عملية تطبيقك للتحقق من عدم انتظامها الإدراج. ونظرًا لعدم وجود إستراتيجية فعالة للمطورين أو المستخدمين لتخفيف المشكلة، فمن المهم جدًا أن تقوم الشركات المصنعة بتنفيذ التصحيح لإصلاح هذه المشكلة في أسرع وقت ممكن.
ولحسن الحظ، اتبع Promon إرشادات الكشف المسؤول قبل نشر هذا الاستغلال للعامة (و لا يزال الأمر غير متاح للعامة بالكامل، حيث ينتظر Promon 90 يومًا قبل الكشف الكامل عن كيفية استخدام StrandHogg 2.0 يعمل). قامت Google منذ ذلك الحين بإعادة تصحيحات هذا الاستغلال إلى Android 8.0 Oreo وAndroid 8.1 Oreo وAndroid 9 Pie مع مستوى تصحيح أمان Android (SPL) لشهر مايو 2020. المستخدمون على نظام التشغيل Android 10 والإصدارات الأحدث ليسوا عرضة للخطر، على الرغم من أننا لسنا متأكدين تمامًا من سبب ذلك. من المحتمل أن يكون له علاقة بالقيود الجديدة التي فرضها نظام Android 10 فيما يتعلق بإطلاق الأنشطة وكيفية دمج Google لذلك في حزمة المهام. يقول برومون: "في نظام Android 10، يكون الهجوم غير فعال تمامًا، ويتم تقسيم الأنشطة إلى مهام مختلفة وإلى مجموعات مهام منفصلة وفقًا لـ adb shell dumpsys activity activities."
إذا كانت الشركة المصنعة لجهازك لا تزال توفر تحديثات الأمان (يمكنك قراءة المزيد حول كيف تعمل عملية التصحيح الأمني هنا)، يجب عليك مضايقتهم للحصول على تحديث في أقرب وقت ممكن. بخلاف ذلك، ستحتاج فقط إلى توخي الحذر بشأن التطبيقات التي تقوم بتنزيلها وتشغيلها (على الرغم من أنه يجب عليك القيام بذلك على أي حال).
لمزيد من التفاصيل وحالات استخدام StrandHogg 2.0، قم بمراجعة الإعلان الرسمي على موقع Promon. بالنسبة لمطوري ROM المخصص، يمكنك العثور على التزامات AOSP ذات الصلة لمنع هجمات StrandHogg 2.0 هنا و هنا.
الجدول الزمني للإفصاح
فيما يلي الجدول الزمني للإفصاح الذي شاركته Promon في مستند StandHogg 2.0 الخاص بها:
- 4 ديسمبر 2019 - تم الإبلاغ عن مشكلة إلى Google
- 4 ديسمبر 2019 - مشاركة "تطبيق ضار" وفيديو لـ PoC مع Google
- 4 ديسمبر 2019 – أكدت جوجل استلام التقرير
- 9 ديسمبر 2019 - جوجل تحدد مدى خطورة النتيجة على أنها «حرجة»
- 9 ديسمبر 2019 – تؤكد Google أنها قادرة على إعادة إنتاج المشكلة
- 14 فبراير 2020 – نبلغ Google بأن الإفصاح لمدة 90 يومًا يقترب في بداية شهر مارس، ونطلب الحالة من جانبهم
- 14 فبراير 2020 – ردت Google بأن شهر أبريل هو أقرب وقت يمكنها فيه طرح الإصلاح
- 14 فبراير 2020 – نبلغ Google بأننا نعمل على إجراءات التخفيف
- 14 فبراير 2020 – جوجل تستجيب. إنهم يعملون على العلاجات، ويسألون عما إذا كان بإمكاننا مشاركة وسائل التخفيف التي نوصي بها
- 17 فبراير 2020 – نبلغ جوجل أنه يمكننا تأجيل الكشف حتى أبريل. نطلب رقم CVE
- 17 فبراير 2020 – نحن نشارك إستراتيجيات التخفيف الخاصة بنا، بالإضافة إلى كيفية تصورنا لتخفيف المنصة
- 23 مارس 2020 – تستجيب Google بمعرف CVE (CVE-2020-0096)
- 23 مارس 2020 - تجيب Google بأن التوفر العام للإصلاح لنظام Android سيكون متاحًا في شهر مايو
- 23 مارس 2020 – تسأل Google عما إذا كنا سنفكر في تأخير الكشف إلى شهر مايو
- 27 مارس 2020 – نرد بأننا سنؤجل الكشف حتى شهر مايو
- 22 أبريل 2020 – أبلغتنا Google أنه من المقرر أن تحتوي النشرة الأمنية لشهر مايو على تصحيح للثغرة الأمنية