:::info المؤلفون:
(1) دانييلي كابوني، SecSI srl، نابولي، إيطاليا (daniele.capone@secsi.io)؛
(2) فرانشيسكو كاتورانو، قسم الهندسة الكهربائية والمعلومات، جامعة نابولي فيديريكو الثاني للتكنولوجيا، نابولي، إيطاليا (francesco.caturano@unina.i)
(3) أنجيلو ديليكاتو، SecSI srl، نابولي، إيطاليا (angelo.delicato@secsi.io)؛
(4) غايتانو بيروني، قسم الهندسة الكهربائية وتكنولوجيا المعلومات، جامعة نابولي فيديريكو الثاني، نابولي، إيطاليا (gaetano.perrone@unina.it)
(5) سيمون بييترو رومانو، قسم الهندسة الكهربائية وتكنولوجيا المعلومات، جامعة نابولي فيديريكو الثاني، نابولي، إيطاليا (spromano@unina.it).
:::
الملخص والمقدمة الأولى
II. الأعمال ذات الصلة
III. تصميم نظام أندرويد المحوسب
IV. بنية نظام أندرويد المحوسب
V. التقييم
VI. الخاتمة والتطورات المستقبلية، والمراجع
يقيم هذا القسم منصة أندرويد المحوسب من خلال فحص عدة جوانب. أولاً، نؤكد على الاختلافات بين مكونات النواة للمحاكي والنواة للجهاز الحقيقي من حيث الميزات ونسلط الضوء على التوافق مع أنظمة التشغيل الثلاثة الأكثر استخدامًا. ثم نقدم أمثلة عملية لاستخدام أندرويد المحوسب ونناقش تغطية المتطلبات المحددة في القسم الثالث.
\
\ أ. الاختلافات بين النواة للمحاكي والنواة للجهاز الحقيقي
\ حتى مع بذل جهد كبير لإنشاء نظام يحتوي على نفس الميزات لكلا نوعي الأجهزة، هناك قيود عند استخدام المحاكاة:
\ • ميزة إرسال/استقبال الرسائل القصيرة عبر ADB: في الأجهزة المحاكاة، من الممكن أتمتة إرسال واستقبال الرسائل القصيرة من خلال برنامج ADB. من الواضح أن هذا غير ممكن بشكل أصلي للأجهزة الحقيقية. لذلك، يجب على المستخدم إرسال واستقبال الرسائل القصيرة يدويًا لتنفيذ سيناريوهات هجوم الرسائل القصيرة. يمكن أن يكون الحل لمعالجة هذه المشكلة هو إنشاء تطبيق أندرويد مخصص يمكن تثبيته على جهاز حقيقي ويمكن برمجته لإرسال واستقبال الرسائل تلقائيًا.
\ • الشبكات: تختلف الشبكات بشكل كبير بين إصدارات المحاكي والجهاز الحقيقي. في إصدار المحاكي، يتم إنشاء AVD داخل حاوية Docker، وبالتالي فهو يشارك عنوان IP الخاص بالحاوية. بدلاً من ذلك، يتم توصيل الجهاز الحقيقي فعليًا بالجهاز الذي يشغل الحاوية ويحتفظ بعنوان IP الخاص به.
\ • المحاكاة الافتراضية للأجهزة: بالنسبة لمكونات الأجهزة، الوضع مختلف تمامًا أيضًا: يمكن محاكاة بعض أجهزة الأجهزة مثل نظام تحديد المواقع العالمي (GPS) والميكروفون. على وجه الخصوص، يمكن تعيين موقع GPS للجهاز من خلال ADB، ويمكن مشاركة ميكروفون الجهاز المضيف مع المحاكي. هناك مكونات أجهزة أخرى لا يمكن محاكاتها حاليًا، مثل البلوتوث.
\ ب. تقييم المضيف للتوافق عبر المنصات
\ ينص المتطلب غير الوظيفي NF04 (التوافق عبر المنصات) على أن النظام الناتج يجب أن يكون قابلاً للاستخدام من داخل أي نظام تشغيل مضيف. يشير هذا إلى نظام التشغيل للجهاز الذي يشغل حاويات Docker. يقدم الجدول الثالث ملخصًا للتوافق مع Linux و Windows و OS X.
\
\ المشكلة مع Windows هي أنه حاليًا، أفضل طريقة لاستخدام Docker هي من خلال إطار عمل نظام Windows الفرعي لـ Linux (WSL). لسوء الحظ، لا يدعم WSL المحاكاة المتداخلة بعد، وهذه الميزة مطلوبة لتشغيل محاكي Android داخل حاوية Docker. ومع ذلك، ستكون الميزة متاحة في إصدارات WSL القادمة. قد يكون من الممكن تشغيل إصدار النواة للمحاكي على Windows باستخدام جهاز افتراضي، على الرغم من فقدان جميع فوائد الأداء المرتبطة بالحوسبة. توجد مشكلة مماثلة مع OS X، حيث لا توجد حاليًا طريقة لتشغيل النواة للمحاكي. بالإضافة إلى ذلك، لا يسمح OS X بمشاركة جهاز USB مع حاوية Docker. لهذا السبب، فإن الطرق الوحيدة لاستخدام إصدار النواة للجهاز الحقيقي هي إما تشغيل ADB عبر Wi-Fi أو الاتصال بـ ADB المضيف من داخل حاوية Docker.
\ في بقية هذا القسم، نوضح فعالية أندرويد المحوسب في إعادة إنتاج سلاسل القتل الأمنية باستخدام كل من النواة للمحاكي والنواة للجهاز الحقيقي.
\ ج. إعادة إنتاج هجوم أمني على المحاكي
\ نركز هنا على سيناريو ثغرة أمنية مرتبط بـ CVE-2018-7661[1]. يرتبط هذا CVE بالإصدار المجاني من تطبيق "Wi-Fi Baby Monitor". يجب تثبيت هذا التطبيق على جهازين ليعمل كما يسمى مراقب الأطفال (نظام راديو يستخدم للاستماع عن بعد إلى الأصوات الصادرة عن الرضيع). كما ورد في قاعدة بيانات الثغرات الوطنية، "Wi-Fi Baby Monitor Free & Lite" قبل الإصدار 2.02.2 يسمح للمهاجمين عن بعد بالحصول على بيانات صوتية عبر طلبات محددة إلى أرقام منافذ TCP 8258 و 8257".
\
\ يوفر الإصدار المميز من هذا التطبيق للمستخدمين القدرة على تحديد كلمة مرور لاستخدامها في عملية الاقتران. من خلال مراقبة حركة الشبكة، من الممكن ملاحظة ما يلي:
\ • يتم الاتصال الأولي على المنفذ 8257؛
\ • يتم دائمًا إرسال نفس التسلسل لبدء عملية الاقتران؛
\ • في نهاية عملية الاقتران، يتم بدء اتصال جديد على المنفذ 8258. يستخدم هذا المنفذ لنقل البيانات الصوتية؛
\ • بعد الاتصال بالمنفذ 8258، يظل الاتصال الآخر على المنفذ 8257 مفتوحًا ويستخدم كنبض للجلسة؛
\ • على اتصال النبض، يرسل العميل دوريًا البايت السداسي العشري 0x01 (حوالي مرة واحدة في الثانية)؛
\ إثبات المفهوم الذي يسمح للمهاجم بالحصول على البيانات الصوتية موجود في [21]. يمكن إعادة إنتاج إثبات المفهوم (PoC) هذا بسهولة على أندرويد المحوسب من خلال إنشاء بنية تحتية تتكون من ثلاث خدمات:
\ • core-emulator: نسخة من مكون النواة مع تطبيق Baby Monitor مثبت مسبقًا يعمل كمرسل؛
\ • ui: مكون واجهة المستخدم للتحكم فيما يحدث؛
\ • attacker: نسخة مخصصة من Kali Linux تقوم تلقائيًا بتثبيت جميع التبعيات اللازمة لتنفيذ PoC.
\ هذا أيضًا مثال مثالي لإظهار ميزة إعادة توجيه المنفذ المستخدمة لتمكين الاتصالات.
\ د. إعادة إنتاج هجوم أمني على الجهاز الحقيقي
\ مع الجهاز الحقيقي، نفحص ثغرة أخرى، تعرف باسم BlueBorne. يشير مصطلح "BlueBorne" إلى ثغرات أمنية متعددة تتعلق بتنفيذ البلوتوث. تم اكتشاف هذه الثغرات من قبل مجموعة من الباحثين من Armis Security، وهي شركة أمن إنترنت الأشياء، في سبتمبر 2017. وفقًا لـ Armis، في وقت الاكتشاف، كان حوالي 8.2 مليار جهاز محتملاً تأثره بمتجه هجوم BlueBorne، الذي يؤثر على تنفيذات البلوتوث في Android و iOS و Microsoft و Linux، وبالتالي يؤثر على جميع أنواع أجهزة البلوتوث تقريبًا مثل الهواتف الذكية وأجهزة الكمبيوتر المحمولة والساعات الذكية. تم تحليل BlueBorne بالتفصيل في ورقة نُشرت في 12 سب