CVE-2026-0073-Android-client-TLS-auth-bypass

CVE‑2026‑0073 هو خطأ منطقي في برنامج adbd الخفي في أندرويد (ADB daemon) يسمح للمهاجم بتجاوز المصادقة المتبادلة عبر TLS وفتح صدفة بعيدة على جهاز مفعّل فيه تصحيح الأخطاء اللاسلكي وتم إقرانه بأي حاسوب مرة واحدة على الأقل. السبب الجذري هو إساءة استخدام استدعاء برمجي واحد: قيمة الإرجاع من دالة EVP_PKEY_cmp() الخاصة بـ OpenSSL تُعامل كقيمة منطقية (Boolean) بدلاً من نتيجة ثلاثية القيم.

تدفق المصادقة الطبيعي مع تصحيح الأخطاء اللاسلكي ADB

عندما نقوم بتمكين تصحيح الأخطاء اللاسلكي من إعدادات المطور في أندرويد، يبدأ الجهاز مثيل adbd يستمع على منفذ TCP عشوائي. ملاحظة: تم تقديم هذه الميزة بدءاً من أندرويد 11.

البروتوكول له مرحلتان:

1. مفاوضات النص الصريح: يتصل المضيف عبر TCP ويتبادل مصافحة CNXN/STLS للاتفاق على الترقية إلى TLS.
2. مصادقة TLS 1.3 المتبادلة:
   • الخادم adbd يتطلب من العميل تقديم شهادة
   • adbd يستخرج المفتاح العام من تلك الشهادة
   • ثم يقارن المفتاح مع جميع مفاتيح RSA المخزنة في /data/misc/adb/adb_keys. يتم وضع المفاتيح هناك خلال عمليات الإقران السابقة (يتطلب الاستغلال وجود مفتاح واحد على الأقل هنا)
   • إذا تطابقت المفاتيح، تنجح المصافحة ويمكن للمضيف إرسال أوامر الصدفة كمستخدم shell تتم مقارنة المفاتيح باستخدام دالة OpenSSL EVP_PKEY_cmp(key1, key2)، والتي ترجع:

• 1 --> المفاتيح متساوية
• 0 --> المفاتيح غير متساوية
• -1 --> أنواع المفاتيح مختلفة، أو حدث خطأ

الخلل

في الملف daemon/auth.cpp، الدالة القابلة للاستغلال adb_tls_verify_cert() تبدو شيئاً مثل هذا:

int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {     
    authorised = true;
}

بما أن if(cmp) ترجع true طالما أن cmp غير صفرية، فإن قيمة الإرجاع -1 من EVP_PKEY_cmp() تؤدي إلى التصريح. هذا يعني أنه بما أن المفتاح المخزن هو RSA، فعندما يقدم العميل شهادة EC أو ed25519، ترجع الدالة -1 ويحصل المهاجم على وصول مصرح به.

تسلسل الهجوم

1. الهدف: جهاز أندرويد مفعّل عليه تصحيح الأخطاء اللاسلكي ويحتوي على مفتاح RSA واحد على الأقل في مخزن المفاتيح الخاص به (تم إقرانه مرة واحدة من قبل أي شخص).
2. المصافحة الصريحة: يتصل المهاجم بمنفذ TCP الخاص بـ adbd ويتبادل CNXN/STLS.
3. مصافحة TLS بشهادة EC: يولد المهاجم مفتاح EC P‑256 مؤقتاً وشهادة موقعة ذاتياً. هذا المفتاح ليس RSA عمداً.
4. المقارنة المعيبة: EVP_PKEY_cmp(RSA, EC) ترجع ‑1 ← if (cmp) تكون true ← adbd يعلن أن الناقل مصرح به.
5. بعد TLS: يتجنب المهاجم إرسال CNXN من المضيف (الذي قد يعيد تعيين الناقل) ويفتح مباشرة دفق shell: مع نافذة delayed_ack كبيرة.

النتيجة: صدفة بعيدة كمستخدم shell، دون أي تفاعل من المستخدم، دون إشعار، ودون الحاجة إلى امتلاك أي مفتاح خاص شرعي.

لماذا ترجمته إلى C؟

يتطلب سكربت Python وجود مترجم Python 3 ومكتبة cryptography مثبتة على جهاز المهاجم. أما تنفيذ بلغة C فيُترجم إلى ملف ثنائي مستقل لا توجد له تبعيات خارجية بخلاف OpenSSL/libssl الخاص بالنظام، وهو موجود افتراضياً في كل نظام لينكس تقريباً. هذا يقلل بشكل كبير من حاجز النشر. علاوة على ذلك، يمكن تجميع برنامج C بشكل متقاطع لأي بنية معمارية مستهدفة (x86_64, ARM, MIPS). هذا يعني أنه يمكن تجميع الاستغلال وتشغيله مباشرة على الأجهزة المدمجة مثل أجهزة التوجيه، أو Raspberry Pi، أو حتى جهاز أندرويد آخر يعمل كمهاجم، دون الحاجة إلى بيئة Python. كما أن ملف C ثنائي المترجم يمكن تجريده من الرموز، وضغطه (UPX)، ويكون معتماً بدون مفكك شفرات مما يجعله أكثر تمويهاً من سكربت Python.

تجربة

تشغيل الاستغلال: قم بتوفير عنوان IP ورقم PORT لواجهة تصحيح الأخطاء اللاسلكية وستحصل على صدفة على الجهاز.

docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>

فتح الآلة الحاسبة:

am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator

ملاحظة حول استخدام LLM

تم استخدام LLM لترجمة الاستغلال من Python إلى C، والاستغلال الأصلي موجود هنا. لم تكن الترجمة صحيحة بنسبة 1:1 وواجهنا الكثير من المشاكل، لذلك كانت هناك حاجة إلى حلقة من تحليل الكود والذهاب والإياب في الدردشة لإصلاح الأخطاء في الترجمة والوصول إلى استغلال كامل يعمل.