ثغرة OAuth خطيرة فى أندرويد وسيطرة كاملة

مع إني مش بحب أنزل Duplicate، بس الثغرة دي من أكتر الحاجات اللي كنت مقهور عليها 😅
المهم… حضّر كوباية الشاي وتعالى نفهم الموضوع لأن فيه تفاصيل مهمة جدًا لأي حد شغال Bug Bounty أو Mobile Application Security ☕
الثغرة كانت عبارة عن شوية مشاكل أمنية مترابطة جوه Android Mobile Application أثناء تنفيذ OAuth Authorization Code Flow، والنتيجة؟ 😶

المهاجم يقدر يسرق: Access Token - Refresh Token
وبالتالي يحصل على سيطرة كاملة على حساب الضحية (Full Account Takeover).

السبب الأول: عدم استخدام PKCE فى OAuth 🔓​

التطبيق كان بيستخدم OAuth Authorization Code Flow لكن من غير تفعيل PKCE.
طلب الـ Authorization كان ناقص حاجات أساسية جدًا زى:

code_challenge
code_verifier

وده معناه إن Authorization Code مكنش مربوط بالتطبيق الأصلي.

طيب يعني إيه PKCE وليه مهم؟ 🤔
ببساطة، PKCE عبارة عن طبقة حماية إضافية معمولـة مخصوص لتطبيقات الموبايل والـ Public Clients.
الـ Flow الطبيعي بيكون كده:

1. التطبيق يعمل Generate لقيمة عشوائية اسمها: code_verifier

1. يطلع منها قيمة تانية اسمها: code_challenge

1. يبعت الـ code_challenge مع طلب تسجيل الدخول.
2. بعد نجاح الـ Login، السيرفر يرجع Authorization Code.
3. التطبيق لازم يبعت الـ code_verifier الحقيقي علشان السيرفر يتأكد إن نفس التطبيق اللي بدأ العملية هو اللي بيطلب الـ Tokens.

مثال بسيط للتوضيح:

GET /authorize?
client_id=mobile_app
&response_type=code
&code_challenge=abc123
&code_challenge_method=S256

وبعدها:

POST /token
code=AUTH_CODE
code_verifier=real_secret_value

الميزة هنا إن حتى لو حد سرق الـ Authorization Code، مش هيعرف يستخدمه من غير الـ code_verifier ✅
لكن فى الحالة دي ؟ مفيش PKCE أصلًا 😶

وده خلّى أي شخص يقدر يسرق الـ Code ويستبدله بسهولة بـ:

access_token
refresh_token

---

السبب التانى: تخزين client_secret داخل ملف APK 🚨​

واحدة من المشاكل الخطيرة كمان إن OAuth client_secret كان متخزن بشكل ثابت جوه ملف الـ APK.
وبعد فك التطبيق (Reverse Engineering) كان سهل جدًا الوصول له.
وده يعتبر Design غلط أصلًا.
ليه؟

لأن تطبيقات الموبايل تعتبر: Public Clients
يعني أي Secret يتحط جوه التطبيق غالبًا هيكون قابل للاستخراج بسهولة باستخدام أدوات زى:

• jadx
• apktool
• MobSF

مثال سريع: jadx app.apk
بعد فك الملفات ممكن تلاقي بيانات حساسة بالشكل ده:

client_secret = "super_secret_key";

وده كارثة أمنية حقيقية 😅

---

السبب التالت: استخدام Custom URI Scheme بشكل غير آمن ⚠️​

التطبيق كان بيستخدم Redirect URI بالشكل ده:

myapp://oauth-callback

المشكلة إن أي تطبيق أندرويد تانى يقدر يسجل نفس الـ Custom Scheme.
وده معناه إن تطبيق خبيث ممكن يعمل: Intercept للـ OAuth Callback
كمان التطبيق الأصلي كان عنده Activity مفتوحة للتعامل مع Android Intents، وبالتالي التطبيقات التانية كانت تقدر تتفاعل معاها بسهولة.

---

سيناريو الاستغلال الكامل للثغرة 🎯​

طريقة الاستغلال كانت ماشية بالشكل ده:

1- الضحية تثبت تطبيق خبيث​

المهاجم يخلي الضحية تثبت Malicious Application.

2- التطبيق الخبيث يسجل نفس الـ Redirect Scheme​

التطبيق يعمل Register لنفس: myapp://oauth-callback

3- الضحية تبدأ تسجيل الدخول​

الضحية تعمل Login داخل التطبيق الأصلي.

4- أندرويد يعرض رسالة "Open With"​

بعد انتهاء تسجيل الدخول، النظام يسأل المستخدم: Open with

5- الضحية تختار التطبيق الخبيث​

وهنا تبدأ الكارثة 💀 التطبيق الخبيث يستقبل: Authorization Code

6- تنفيذ Exchange للكود​

المهاجم يستخدم:

client_id
client_secret

اللي تم استخراجه من التطبيق.
بعدها السيرفر يرجع:

access_token
refresh_token

---

النتيجة النهائية: Full Account Takeover 💥​

بمجرد الحصول على الـ Tokens، المهاجم يقدر:

• الدخول على حساب الضحية
• الحفاظ على Session لفترة طويلة
• تجديد التوكن باستخدام Refresh Token
• تنفيذ سيطرة كاملة على الحساب

وده يعتبر واحد من أخطر سيناريوهات OAuth Misconfiguration فى تطبيقات الموبايل.

---

ازاى تمنع النوع ده من الثغرات؟ 🛡️​

لو شغال على تطوير تطبيقات أندرويد أو Mobile Security، ركز على النقاط دي:

✅ فعّل PKCE Mandatory
✅ متحطش client_secret جوه تطبيقات الموبايل
✅ استخدم App Links / Universal Links بدل Custom URI Schemes
✅ اقفل الـ Activities الحساسة باستخدام صلاحيات صحيحة
✅ اختبر الـ OAuth Flow بشكل دورى أثناء الـ Security Assessment​

فى النهاية… ثغرات الـ OAuth ساعات بتبان بسيطة، لكن لما كذا مشكلة صغيرة تتربط ببعض، النتيجة ممكن تكون سيطرة كاملة على الحسابات 🔥