## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-XIAOBAILOVESSTIRRING-CVE-2026-0013-POC
# CVE-2026-0013
ثغرة الوكيل المربك (Confused Deputy) في DocumentsUI على أندرويد - مشروع تحقّق للبحث الأمني
## بيان مهم
هذا المستودع هو مستودع بناء مُشتقّ، ويرتبط بالمستودع الرئيسي الأصلي بعلاقة تابعة.
الدور| المستودع| الوصف
---|---|---
المستودع الرئيسي| inforcqb/cve-2026-0013-exploit| البحث الأصلي للثغرة
هذا المستودع| XiaoBaiLovesStirring/cve-2026-0013-poc| توزيع نواتج البناء السحابية
## البروتوكول الأمني
قبل الوصول إلى هذا المستودع، تأكّد من قراءة وفهم SECURITY_PROTOCOL.md.
النقاط الرئيسية:
* لا يوفّر هذا المستودع الكود المصدري أو أدوات الهجوم أو أُطر استغلال الثغرات
* نواتج البناء هي عيّنات تحقّق للبحث الأمني، تُستخدم للأغراض الأكاديمية فقط
* أي خسائر مالية أو عواقب قانونية لا علاقة لها بمنشئ المستودع
* المستخدم يتحمّل المسؤولية الكاملة بنفسه
## البدء السريع
GitHub Pages: https://XiaoBaiLovesStirring.github.io/cve-2026-0013-poc/
تشغيل البناء: https://github.com/XiaoBaiLovesStirring/cve-2026-0013-poc/actions
الحصول على النواتج: git clone --branch artifacts https://github.com/XiaoBaiLovesStirring/cve-2026-0013-poc.git
## نشرة التحديثات
### v1.0.4 (2026-08-23) - تشغيل مكوّن مخصص بالوكالة عبر EXTRA_INTENT
**التغيير** : أصبح `targetIntent` الذي يُطلقه DocumentsUI بالوكالة يشير إلى المكوّن المخصص الجديد `IdTestActivity`. يتولّى هذا المكوّن تنفيذ `id` وكتابة هوية التشغيل والنتيجة في logcat وشريط الإشعارات، للتحقق الفعلي من حقيقتين أساسيتين:
1. هل يستهلك PickActivity في OPPO فعليًا `Intent.EXTRA_INTENT` ويُطلق المكوّن الهدف بالوكالة؟
2. في أي UID/عملية يعمل المكوّن المُطلَق بالوكالة فعليًا؟
**شرح الآلية (مهم)** : وفقًا لنموذج العزل في أندرويد، فإن أي مكوّن من تطبيق طرف ثالث - بغضّ النظر عمّن أطلقه - يعمل فقط داخل العملية/UID المُعلَن عنها ذاتيًا. بالاعتماد على تشغيل DocumentsUI بالوكالة فقط، سيظل `IdTestActivity` يعمل بمعرّف UID الخاص بـ `com.example.cve20260013exploit` (مثل `u0_a702`/10702)، ولن يتحوّل **تلقائيًا** إلى `uid=10054` الخاص بـ DocumentsUI. للحصول على 10054 لكامل ملف APK، يلزم `sharedUserId="android.uid.documentsui"` (يتطلب توقيع النظام، وهو غير متاح لأطراف ثالثة) أو بيئة root. تكمن قيمة v1.0.4 في التحقق مما إذا كان EXTRA_INTENT مستهلكًا وتحديد الهوية الحقيقية للتشغيل بالوكالة.
### v1.0.3 (2026-08-23) - إصلاح سلسلة التشغيل (تجريد EXTRA_INTENT)
**المشكلة** : على OPPO/ColorOS، لم يعد `PickActivity` في DocumentsUI يستهلك `Intent.EXTRA_INTENT` المُمرَّر من المُستدعي. في الاختبار الفعلي، ظلّ `mCallingUid` هو معرّف المُستدعي `u0_a702`، واكتفى PickActivity بعرض واجهة التحديد الخاصة به ثم توقف، دون أي إطلاق بالوكالة للإجراء الهدف بهوية DocumentsUI (uid=10054)، وبذلك انقطعت سلسلة الوكيل المربك الأصلية فعليًا.
**الإصلاح (إعادة تصميم سلسلة التشغيل)** :
* التخلّي عن أسلوب «اسم الفئة المرمّز بشكل ثابت + EXTRA_INTENT»، والتحوّل إلى جعل Activity Resolver في النظام يحلّ DocumentsUI ضمن Intent شرعي (`ACTION_OPEN_DOCUMENT` / `ACTION_GET_CONTENT` \+ `CATEGORY_OPENABLE` \+ `*/*`)
* الإبقاء على التسمية الصريحة الاحتياطية لمدخل OPPO المعدَّل `picker.PickActivity` والمدخل الأصلي `PickActivity`، لمنع الانهيار عند عدم العثور على المدخل
* التحقق العكسي من هوية مضيف التفويض عبر URI التفويض المؤقت `content://` الذي يعيده DocumentsUI (`probeUriGrant`)، للتحقق من قيام الوكيل المربك من منظور المُفوِّض
* تسجيل نقاط تتبّع لكل مرحلة من سلسلة التشغيل (نتيجة تحليل resolver + المكوّن المُطلق نهائيًا) في logcat وشريط الإشعارات، لتسهيل التأكد من مسار السلسلة مباشرة على الهاتف
**شرح الآلية** : لا يمكن للتطبيق نفسه أن يجعل عملية DocumentsUI تنفّذ أوامر عشوائية بالوكالة؛ فـ«رفع الامتياز» في الوكيل المربك يتجسّد في جعله يحتفظ/يعيد توجيه نيابةً عنك موارد التفويض التي لا يمكن الحصول عليها إلا بمعرّف uid الخاص به. لذلك تحوّل v1.0.3 إلى التحقق من «من حصل على إذن URI الممنوح من DocumentsUI»، بدلًا من تنفيذ `id` داخل عملية التطبيق نفسها.
**سجل إصلاح البناء** : فشل البناء الأول، إذ كان النوع المُرجَع من `getPackageManager().resolveActivity()` هو `ResolveInfo` وليس `ComponentName`، مع الخطأ `error: incompatible types: ResolveInfo cannot be converted to ComponentName`. تم الإصلاح باستخراج `packageName`/`name` من `ResolveInfo.activityInfo` لإنشاء `ComponentName`، ثم نجح البناء.
### v1.0.2 (2026-08-23) - تنفيذ أمر id وعرضه في شريط الإشعارات
**التغيير** : تغيّر إجراء إثبات المفهوم من «تشغيل Termux» إلى «تنفيذ أمر `id` بعد تشغيل سلسلة الوكيل المربك، وعرض النتيجة في شريط إشعارات النظام».
* بعد تشغيل سلسلة الوكيل المربك في DocumentsUI، يتم تنفيذ أمر `id` داخل التطبيق (محاولة مسارات متعددة: `sh -c id` و`id` و`/system/bin/id` و`/system/xbin/id`)
* عرض نتائج التنفيذ مثل `uid/gid/groups` في شريط الإشعارات
* الإبقاء على منطق المدخل الاحتياطي لمداخل المصنّعين المعدَّلة (`picker.PickActivity` → `.PickActivity` الأصلي)
* إضافة إذن `POST_NOTIFICATIONS` لأندرويد 13+ لإرسال الإشعارات
### v1.0.1 (2026-08-23) - التكيُّف مع مداخل المصنّعين المعدَّلة
**المشكلة** : عدّلت عدة شركات مصنّعة (مثل OPPO) مسار فئات DocumentsUI، إذ انتقل المدخل الأصلي `com.android.documentsui.PickActivity` إلى `com.android.documentsui.picker.PickActivity`، ما جعل نواتج البناء القديمة غير قادرة على تحديد مدخل استغلال الثغرة على الجهاز المستهدف.
**الإصلاح** :
* تحديث مدخل الاستغلال الافتراضي إلى `com.android.documentsui.picker.PickActivity`
* إضافة فحص لتوفر المدخل؛ فإذا لم يكن مدخل الحزمة الفرعية موجودًا، يتم التراجع تلقائيًا إلى المسار الأصلي `.PickActivity`
* منطق الحكم على التراجع: عند اكتشاف أن المدخل المعدَّل غير متاح، يتم تسجيل سجل (log) ثم محاولة المسار الأصلي
**دليل استكشاف فشل البناء (مهم)** :
* إذا فشل البناء السحابي، اطّلع أولًا على سجلات تشغيل GitHub Actions لتحديد الخطأ المحدد
* إذا كان الخطأ من نوع «تعذّر العثور على المدخل / Activity not found»، فهذا يعني أن المصنّع المستهدف قد عدّل مسار فئات DocumentsUI
* تأكّد بنفسك من اسم فئة المدخل الحقيقي بعد تعديل المصنّع عبر `dumpsys package com.android.documentsui` أو جدول Activity Resolver Table، ثم عدّل معامل `setClassName` في `ExploitActivity.java` وادفع التغيير لبدء إعادة البناء
## معلومات الثغرة
CVE-2026-0013 | HIGH (CVSS 8.4) | CWE-441 | Android 14-16 | DocumentsUI PickActivity
نشرة الإصلاح: Android Security Bulletin 2026-03-01