FragAttacks: هجمات التجزئة والتجميع

1. مقدمة

يحتوي هذا المستودع على أداة FragAttacks. يمكنها اختبار عملاء ونقاط وصول Wi-Fi بحثًا عن هجمات التجزئة (fragmentation) والتجميع (aggregation). تؤثر هذه الثغرات على جميع شبكات Wi-Fi المحمية. لمزيد من المعلومات حول هذه الثغرات، انظر fragattacks.com.

الموارد الإضافية التالية متاحة:

• عرض USENIX Security يقدّم ملخصًا للثغرات المكتشفة.
• نظرة عامة على جميع CVEs المخصصة متاحة.
• شرائح تلخص السبب الجذري والأثر لكل ثغرة.
• ملخص من صفحتين للهجمات الناتجة والشروط المسبقة.
• نشرات تقدم خلفية إضافية وتشرح الثغرات بمزيد من التفصيل.
• عرض توضيحي لثلاثة هجمات مثال.
• الورقة البحثية المنشورة في USENIX Security.
• التقاطات شبكة مثال توضح بعض الثغرات.
• صورة USB حية مع هذه الأداة وبرامج تشغيل معدّلة مثبتة مسبقًا.
• قائمة بالنشرات الاستشارية المعروفة من الشركات

انظر سجل التغييرات للحصول على نظرة عامة مفصلة حول التحديثات التي أجريت على الأداة منذ 11 أغسطس 2020. يحتوي سجل التغييرات هذا أيضًا على معلومات حول إصدار hostap الذي تستند إليه أداة FragAttacks.

لاحظ أن الهجمات متطابقة ضد WPA2 وWPA3 لأن خوارزميات التشفير CCMP وGCMP الخاصة بهما متطابقة. شبكات WPA الأقدم تستخدم افتراضيًا TKIP للتشفير، وإمكانية تطبيق الهجمات ضد TKIP تتم مناقشتها في الورقة وعلى الموقع الإلكتروني. لتوضيح أن Wi-Fi كانت عرضة للثغرات منذ إنشائها، تناقش الورقة والموقع أيضًا بإيجاز إمكانية تطبيق الهجمات ضد WEP.

2. بطاقات الشبكة المدعومة

يتم دعم بطاقات شبكة لاسلكية محددة فقط. وذلك لأن بعض بطاقات الشبكة قد تستبدل رقم التسلسل أو رقم الجزء (fragment) للإطارات المحقونة، أو قد تعيد ترتيب إطارات ذات أولويات مختلفة، وهذا يتعارض مع أداة الاختبار (أي قد تقول الأداة إن الجهاز آمن رغم أنه ليس كذلك). لقد تأكدت من أن بطاقات الشبكة التالية تعمل بشكل صحيح:

العمودان الأخيران يعنيان:

1. الوضع المختلط: ما إذا كان يمكن استخدام بطاقة الشبكة في الوضع المختلط الموصى به.

2. وضع الحقن: ما إذا كان يمكن استخدام بطاقة الشبكة كواجهة ثانية لحقن الإطارات في وضع الحقن.

نعم تشير إلى أن البطاقة تعمل فورًا في الوضع المعطى. برنامج تشغيل/برنامج ثابت معدّل يعني أن البطاقة متوافقة عند استخدامها مع برامج تشغيل و/أو برامج ثابتة معدّلة. لا تعني أن هذا الوضع غير مدعوم من بطاقة الشبكة. أوصي باستخدام أداة الاختبار في الوضع المختلط.

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

تجربتي مع بطاقات الشبكة المذكورة أعلاه موجودة هنا. باختصار:

• AWUS036ACM في الوضع المختلط يبدو موثوقًا مع أحدث برامج التشغيل لدينا وهو الذي أوصي به. جهاز أرخص ولكن شبه متطابق هو جهاز بشرائح MT7612U. انظر مزيدًا من المعلومات هنا.

• كنت أوصي سابقًا بـ Technoethical N150 HGA في الوضع المختلط. هذا الدونجل مطابق لـ TP-Link TL-WN722N v1.x ويتطلب استخدام برامج تشغيل وبرامج ثابتة معدّلة. هذا واحد من أكثر الدونجل اختبارًا، لكنه صعب الحصول عليه. لهذا أوصي الآن بـ AWUS036ACM بدلاً منه.

• Intel 3160 و8265 مدعومان ومختبران على نطاق واسع. أحيانًا يتعطل برنامجهما الثابت ولكن إعادة التشغيل تجعل بطاقة الشبكة قابلة للاستخدام مرة أخرى. Intel AX200 غير متوافقة مع أداة الاختبار.

• WN111v2 يبدو أنه يعمل جيدًا، على الرغم من أنني لم أختبره على نطاق واسع.

• برنامج تشغيل AWUS036ACH ليس جزءًا من نواة Linux ويتطلب تثبيت برنامج تشغيل منفصل. على Kali يمكنك تثبيت هذا البرنامج عبر مدير الحزم. لم يتم اختبار هذه البطاقة على نطاق واسع.

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

3. المتطلبات الأساسية

تم اختبار أداة الاختبار على Ubuntu 20.04 باستخدام نواة 5.8. إذا كنت تستخدم توزيعة Linux أخرى، يرجى ملاحظة أن إصدارات النواة الأقل من أو تساوي 5.12 فقط هي المدعومة.

خاص بـ Ubuntu 20.04

عند استخدام Ubuntu 20.04 ستحتاج أولاً إلى تثبيت النواة 5.8 كما يلي. لاحظ أن النواة الحالية ستبقى مثبتة وستبقى أيضًا مستخدمة افتراضيًا:

sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
	linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic

الآن أعد تشغيل Ubuntu، واضغط مع الاستمرار على مفتاح Shift أثناء الإقلاع، واختر "Advanced options for Ubuntu"، ثم ابدأ النواة 5.8 باختيار "Ubuntu, with Linux 5.8.0-63-generic". يمكنك تعديل إعدادات GRUB حتى يستخدم Ubuntu إصدار النواة هذا افتراضيًا. تابع التعليمات التالية تحت هذه النواة التي تعمل الآن.

تعليمات عامة

ثبّت التبعيات المطلوبة:

sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
	libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
	aircrack-ng rfkill firmware-ath9k-htc
# ملاحظة: على Kali Linux استخدم الحزمة firmware-atheros بدلاً من firmware-ath9k-htc

الآن استنسخ هذا المستودع، وابنِ الأدوات، وهيئ بيئة python3 افتراضية:

git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh

التعليمات أعلاه تُنفذ مرة واحدة فقط. بعد سحب كود جديد باستخدام git، يجب تنفيذ ./build.sh و./pysetup.sh مرة أخرى.

4. برامج التشغيل المعدّلة

ثبّت برامج التشغيل المعدّلة باستخدام:

sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install

يقوم هذا بترجمة برامج التشغيل لمعظم بطاقات الشبكة المدعومة من Linux. إذا كنت تريد فقط ترجمة برامج التشغيل لبطاقات الشبكة التي اختبرتها صراحةً، استخدم make defconfig-experiments بدلاً من ذلك. قد تحصل على التحذيرات التالية:

• عند تنفيذ make defconfig-wifi قد تحصل على تحذيرات متعلقة بـ -Wyacc و-Wformat-overflow. يمكنك تجاهل هذه التحذيرات طالما تم تجميع برامج التشغيل بنجاح.
• أثناء أمر التثبيت، قد تحصل أيضًا على التحذيرات التالية:
  • عدة تحذيرات تحتوي على .. needs unknown symbol ... يمكنك تجاهل هذه التحذيرات طالما أنها لا تحتوي على المسار /lib/modules/*/updates/ وأن برامج التشغيل المترجمة تعمل.
  • تحذيرات متكررة تحتوي على SSL error وأمر sign-file. هذا يعني أن التوقيع الرقمي لوحدات النواة قد فشل. يمكنك عادةً تجاهل هذا.
• يمكنك التحقق من تثبيت برامج التشغيل المعدّلة بتنفيذ cat /sys/module/mac80211/parameters/fragattack_version بعد إعادة التشغيل. إذا كان هذا الملف موجودًا، فقد تم تثبيت برامج التشغيل المعدّلة بنجاح.

الآن ثبّت البرنامج الثابت المعدّل ath9k_htc:

cd research/ath9k-firmware/
./install.sh
# الآن أعد التشغيل

يفترض سكربت ./install.sh أن صور البرنامج الثابت ath9k_htc موجودة في الدليل /lib/firmware/ath9k_htc. إذا لم يكن الأمر كذلك على نظامك، يجب نسخ htc_7010.fw وhtc_9271.fw يدويًا إلى الدليل المناسب.

بعد تثبيت برامج التشغيل والبرنامج الثابت المعدّلين، يجب فصل دونجل Wi-Fi وإعادة تشغيل نظامك. يجب تنفيذ التعليمات أعلاه مرة أخرى إذا تم تحديث نواة Linux الخاصة بك أو إذا تم تحديث برامج التشغيل المعدّلة.

لاحظ أنه حتى عندما يعمل جهازك فورًا، ما زلت أوصي بتثبيت برامج التشغيل المعدّلة، لأن ذلك يضمن عدم وجود تراجعات غير متوقعة في كود النواة وبرامج التشغيل.

في حال لم تتمكن من تثبيت برامج التشغيل/البرنامج الثابت المعدّلين بشكل أصلي، يمكنك تنزيل صورة USB حية تحتوي على برامج التشغيل/البرنامج الثابت المعدّلين مع أداة الاختبار الخاصة بنا. بدلاً من ذلك، يمكنك استخدام جهاز افتراضي مع بطاقات شبكة USB، على الرغم من أنني وجدت أن استخدام جهاز افتراضي أقل موثوقية عمليًا.

5. قبل كل استخدام

في كل مرة تريد استخدام أداة الاختبار، يجب أولاً تحميل بيئة python الافتراضية كجذر (root). يمكن القيام بذلك باستخدام:

cd research
sudo su
source venv/bin/activate

يجب الآن تعطيل Wi-Fi في مدير الشبكة حتى لا يتعارض مع أداة الاختبار. تأكد أيضًا من عدم وجود خدمات شبكة أخرى تسبب حركة مرور صادرة. يمكنك التأكد من ذلك باستخدام iptables لحظر حركة المرور بتنفيذ ./droptraffic.sh (يمكنك التراجع عن ذلك بإعادة التشغيل). اختياريًا، تحقق باستخدام sudo airmon-ng check لمعرفة العمليات الأخرى التي قد تستخدم بطاقة الشبكة اللاسلكية وقد تتعارض مع أداتنا.

يمكن لأداة الاختبار اختبار كل من العملاء ونقاط الوصول:

• اختبار نقاط الوصول: قم بإعداد نقطة الوصول التي تريد اختبارها بتحرير research/client.conf. هذا ملف إعداد قياسي لـ wpa_supplicant. انظر توثيق hostap للحصول على نظرة عامة على جميع الخيارات التي يدعمها.

• اختبار العملاء: يجب تنفيذ أداة الاختبار مع المعامل --ap (انظر أدناه). هذا يوجه الأداة إلى إنشاء نقطة وصول باسم testnetwork وكلمة مرور abcdefgh. اتصل بهذه الشبكة باستخدام العميل الذي تريد اختباره. افتراضيًا، يجب أن يطلب العميل عنوان IP باستخدام DHCP. لتعديل خصائص نقطة الوصول المنشأة، مثل القناة التي تُنشأ عليها، يمكنك تحرير research/hostapd.conf.

6. أوضاع الواجهة

6.1. الوضع المختلط

يتطلب هذا الوضع بطاقة شبكة لاسلكية واحدة فقط، ولكنه يتطلب عمومًا برنامج تشغيل و/أو برنامجًا ثابتًا معدّلًا. انظر برامج التشغيل المعدّلة حول كيفية تثبيت برامج التشغيل/البرامج الثابتة المعدّلة، و بطاقات الشبكة المدعومة لبطاقات الشبكة المتوافقة. نفّذ أداة الاختبار في هذا الوضع باستخدام:

./fragattack.py wlan0 [--ap] $COMMAND

القيم الممكنة لـ $COMMAND مذكورة في اختبار الثغرات واختبارات الثغرات الموسعة.

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

6.2. وضع الحقن

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

./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND

هنا ستعمل الواجهة wlan0 كعميل أو نقطة وصول شرعية، وستُستخدم wlan1 لحقن الإطارات. بالنسبة لـ wlan0، يمكن استخدام أي بطاقة تدعم وضع العميل أو نقطة الوصول العادي على Linux. بالنسبة لـ wlan1، يجب استخدام بطاقة تدعم وضع الحقن وفقًا لـ بطاقات الشبكة المدعومة.

عند اختبار العملاء في هذا الوضع، قد يتم إرسال الإطارات المحقونة عندما يكون العميل في حالة سكون. هذا يتسبب في فشل الهجمات، لذلك يجب التأكد من أن العميل لن يدخل في حالة سكون.

6.3. وضع Hwsim

هذا الوضع تجريبي ولأغراض البحث فقط. انظر تفاصيل وضع hwsim لمزيد من المعلومات.

7. اختبار الثغرات

يمكنك اختبار الأجهزة بتشغيل أداة الاختبار كما هو موضح في أوضاع الواجهة واستبدال $COMMAND بأحد الأوامر في الجدول أدناه. نفترض أن العملاء سيطلبون عنوان IP باستخدام DHCP (إذا لم يكن الأمر كذلك، انظر إعداد IP الثابت). جميع الأوامر تعمل ضد كل من العملاء ونقاط الوصول ما لم يُذكر خلاف ذلك.

تخرج الأداة TEST COMPLETED SUCCESSFULLY إذا كان الجهاز عرضة للهجوم المقابل لـ $COMMAND المعطى، وتخرج Test timed out! Retry to be sure, or manually check result إذا كان الجهاز غير عرضة للثغرة. بعد اكتمال الاختبار، يمكنك إغلاق أداة الاختبار باستخدام CTRL+C. معظم الهجمات لها عدة أشكال مختلفة قليلاً تمثلها قيم مختلفة لـ $COMMAND.

يتطلب التحقق من نتيجة بعض الاختبارات تشغيل tcpdump أو wireshark على الجهاز قيد الاختبار (يوضح الجدول أدناه ما إذا كان يجب استخدام tcpdump). يجب أن يتضمن التقاط tcpdump هذا فقط الحزم التي اجتازت معالجة الطبقة المادية وطبقة MAC. على سبيل المثال، على Linux يجب إجراء هذا الالتقاط بينما الواجهة اللاسلكية في وضع "managed" أو "ap"، وليس في وضع المراقبة (monitor)، مما يعني أن الالتقاط سيحتوي فقط على الحزم التي اجتازت المعالجة في طبقة Wi-Fi. انظر تجنب tcpdump على نقاط الوصول لمناقشة حول كيفية إجراء بعض الاختبارات مع ذلك دون الحاجة إلى تشغيل tcpdump على نقاط الوصول.

للتحقق من إعداد الاختبار الخاص بك، يقوم الأمر الأول في الجدول أدناه بإجراء ping عادي يجب أن ينجح. الأمر الثاني يرسل الـ ping كإطارَي Wi-Fi مجزأين، ويجب أن يفشل فقط في الحالة النادرة التي لا يدعم فيها الجهاز الذي تم اختباره التجزئة. إذا لم يعمل أحد هذين الاختبارين، فاتبع التعليمات في اختبار حقن بطاقة الشبكة للتأكد من أن بطاقة الشبكة تحقن الإطارات بشكل صحيح. إذا كان العميل الذي يتم اختباره قد يدخل وضع السكون، فانظر التعامل مع وضع السكون.

الأوامر الثالث والرابع والخامس ليست هجمات ولكنها تتحقق من سلوك إعادة التجميع الأساسي للجهاز ويتم مناقشتها بشكل أكبر أسفل الجدول.

كيفية تطابق الأوامر مع CVEs مذكورة أدناه. لاحظ أنه بالنسبة لعيوب التنفيذ، نذكر معرف CVE مرجعيًا، ومع ذلك، قد يستخدم البائعون CVEs مختلفة لأن ثغرة تنفيذية عادةً تحصل على CVE فريد لكل قاعدة كود متأثرة. ومع ذلك، نوصي دائمًا بالإشارة إلى هذه الـ CVEs المرجعية كطريقة سهلة للإشارة إلى كل نوع من عيوب التنفيذ المكتشفة.

7.1. فحوصات السلامة

• ping: يجب أن ينجح هذا الاختبار دائمًا. إذا فشل، فهناك خطأ ما في إعداد الاختبار.- ping I,E,E: يجب أن ينجح هذا الاختبار مع جميع أجهزة الكمبيوتر المحمولة والهواتف الذكية ونقاط الوصول الحديثة. إذا فشل، فمن المرجح أن هناك خطأ ما في إعداد الاختبار. جرّب إضافة المعامل --icmp-size 100 كإصلاح. إذا نجح مع هذا المعامل الإضافي، فيجب عليك تنفيذ جميع الاختبارات الأخرى مع هذا المعامل الإضافي أيضًا. المرة الوحيدة التي واجهت فيها فشل هذا الاختبار لأسباب وجيهة هي عندما لا يدعم الجهاز الذي تم اختباره استقبال الإطارات المجزأة، وهو ما يمكن أن يحدث في أجهزة إنترنت الأشياء خفيفة الوزن وعلى سبيل المثال OpenBSD.

7.2. سلوك الجهاز الأساسي

• ping I,E,E --delay 5: يُستخدم هذا الاختبار للتحقق من أقصى تأخير مقبول بين جزأين. إذا لم يعمل هذا الاختبار، فجرّبه مرة أخرى مع --delay 1.5 أو أقل. على سبيل المثال، يزيل Linux الأجزاء من الذاكرة بعد ثانيتين، مما يعني أن تأخيرًا قدره 1.8 سيعمل بينما 2.2 سيؤدي إلى عدم وجود رد. في حال كان الحد الأقصى للتأخير المقبول منخفضًا، يجب إرسال جميع الأجزاء المرسلة في الاختبارات الأخرى ضمن هذا الحد الأقصى للتأخير المقبول. وإلا، فستفشل الاختبارات بشكل تافه وقد تستنتج أن الجهاز ليس عرضة لهجوم على الرغم من أنه كذلك فعلاً.

• ping-frag-sep: يرسل هذا الاختبار إطار Wi-Fi مجزأً مفصولاً بإطار غير مرتبط. أي أنه يرسل الجزء الأول، ثم إطار Wi-Fi عادي (غير مرتبط)، وأخيرًا الجزء الثاني. في حال فشل هذا الاختبار، فمن المرجح أن يفشل أيضًا هجوم المفتاح المختلط (الافتراضي) وهجوم ذاكرة التخزين المؤقت (لأنهما يتطلبان إرسال إطارات أخرى بين جزأين). سيفشل هذا الاختبار أيضًا في حال تحقق جهاز الاستقبال من أن الأجزاء لها أرقام حزم متتالية (انظر الاختبار التالي ping-frag-sep --pn-per-qos).

• ping-frag-sep --pn-per-qos: نفس ما سبق، لكن إضافة المعامل --pn-per-qos تضمن أن كلا جزأي طلب ping لهما رقم حزم (Packet Number) متتالٍ. هذا شيء ينبغي على جهاز الاستقبال التحقق منه ليكون آمنًا. لسوء الحظ، قبل الإفصاح عن نتائجنا، لا تتحقق العديد من التطبيقات من أن أرقام الحزم متتالية. قد يفشل هذا الاختبار في حال عدم تتبع جهاز الاستقبال لأحدث عداد حزم مستلم لكل QoS TID، وفي هذه الحالة يمكنك تجاهل الاختبارات الأخرى التي تحتوي على المعامل --pn-per-qos.

7.3. اختبارات هجوم A-MSDU (§3 -- CVE-2020-24588)

الاختبار ping I,E --amsdu يتحقق مما إذا كان التطبيق يدعم A-MSDU غير SPP (لا يتحقق مما إذا كان الجهاز عرضة لـ CVE-2020-24588). لمنع الهجمات، يجب على الشبكة من الناحية المثالية أن تفرض استخدام SPP A-MSDU وأن تسقط جميع A-MSDU غير SPP. ومع ذلك، فإن معظم البائعين ينفذون حاليًا تخفيفات مخصصة بدلاً من ذلك (انظر القسم 7.2 من الورقة). لهذا السبب، يجب عليك استخدام الاختبارين التاليين للتحقق مما إذا كان الجهاز عرضة لهجمات التجميع (A-MSDU) (CVE-2020-24588):

• amsdu-inject: يحاكي هذا الاختبار هجوم حقن A-MSDU الموضح في القسم 3.2 من الورقة. على وجه الخصوص، يرسل إطار A-MSDU تكون بدايته أيضًا ترويسة LLC/SNAP صالحة (لأن هذا هو ما يحدث أيضًا في هجومنا المرجعي). إذا نجح هذا الاختبار، يكون الجهاز عرضة لـ CVE-2020-24588.

• amsdu-inject-bad: تحلل بعض الأجهزة بشكل غير صحيح إطارات A-MSDU التي تبدأ بترويسة LLC/SNAP صالحة مما يتسبب في فشل الاختبار أعلاه. في هذه الحالة جرّب amsdu-inject-bad بدلاً من ذلك (انظر القسم 3.6 في الورقة). لاحظ أنه إذا نجح هذا الاختبار، فإن تأثير الهجوم مطابق فعليًا للتطبيقات التي تحلل هذه الإطارات بشكل صحيح، مما يعني أن الجهاز عرضة لـ CVE-2020-24588.

7.4. اختبارات هجوم المفتاح المختلط (§4 -- CVE-2020-24587)

• عند تشغيل اختبار المفتاح المختلط ضد نقطة وصول، يجب تكوين نقطة الوصول لتجديد مفتاح الجلسة (PTK) بانتظام (مثلاً كل دقيقة) عن طريق تنفيذ مصافحة رباعية جديدة. ستعرض الأداة Client cannot force rekey. Waiting on AP to start PTK rekey أثناء انتظار مصافحة إعادة المفتاح PTK هذه. ضد عدد قليل من نقاط الوصول، يمكن لأداة الاختبار أيضًا طلب تجديد PTK بإضافة المعامل --rekey-req ، مما يعني عدم الحاجة إلى تكوين نقطة الوصول لتجديد المفتاح بشكل دوري.

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

• ping I,F,BE,AE --pn-per-qos: يضمن المعامل الإضافي --pn-per-qos أن يكون لكلا الجزأين المحقونين أرقام حزم متتالية، وهو أمر مطلوب لنجاح هجوم المفتاح المختلط ضد أجهزة معينة (مثل Linux).

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

7.5. اختبارات هجوم ذاكرة التخزين المؤقت (§5 -- CVE-2020-24586)

• عند اختبار نقطة وصول، ترسل الأداة جزءًا أولاً، ثم تحاول إعادة الارتباط بنقطة الوصول، وأخيرًا ترسل الجزء الثاني. ومع ذلك، لا تدعم جميع نقاط الوصول عملية إعادة الارتباط بشكل صحيح. في هذه الحالة، أضف الخيار --full-reconnect كما هو موضح في الجدول، مما يجعل أداة الاختبار تقوم بإلغاء المصادقة بعد إرسال الجزء الأول.

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

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

• ping I,E,R,AE [--full-recon]: هنا يتم إرسال الجزء الثاني مباشرة بعد إعادة الاتصال بالجهاز قيد الاختبار ، وهو أمر مهم في حال قيام الجهاز بمسح الأجزاء من الذاكرة بعد وقت قصير. لاحظ أن full-recon هو اختصار لـ full-reconnect.

• ping I,E,R,E [--full-recon]: هنا يتم إرسال الجزء الثاني بعد ثانية واحدة من إعادة الاتصال بالجهاز قيد الاختبار، وهو ما قد يكون مفيدًا في حال وجود تأخير صغير بين اكتمال المصافحة وتثبيت المفتاح المتفاوض عليه.

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

7.6. هجوم أرقام الحزم غير المتتالية (§6.2 -- CVE-2020-26146)

في تجاربنا، فشل هذا الاختبار فقط ضد Linux وضد الأجهزة التي لا تدعم التجزئة.

7.7. هجوم الخلط بين النص الصريح والمشفر (§6.3 -- CVE-2020-26147/26140/26143)

• ping I,E,P و linux-plain: إذا نجح هذا الاختبار، فإن الهجمات الناتجة موصوفة في القسم 6.3 من الورقة. باختصار، عند دمجه مع ثغرة A-MSDU أو ثغرة ذاكرة التخزين المؤقت، يمكن استغلاله لحقن الحزم. وعند عدم دمجه مع أي ثغرات أخرى، يكون التأثير خاصًا بالتطبيق (CVE-2020-26147).

• ping I,P,E: إذا نجح هذا الاختبار، فمن التافه حقن إطارات نص صريح نحو الجهاز إذا كانت الشبكة تستخدم التجزئة (CVE-2020-26147).

• ping I,P: إذا نجح هذا الاختبار، يقبل التطبيق إطارات النص الصريح في شبكة Wi-Fi محمية، مما يسمح بحقن حزم بشكل تافه (CVE-2020-26140).

• ping I,P,P: إذا نجح هذا الاختبار، يقبل التطبيق إطارات النص الصريح المجزأة في شبكة Wi-Fi محمية، مما يسمح بحقن حزم بشكل تافه (CVE-2020-26143).

7.8. اختبارات هجوم إطارات البث المجزأة (§6.4 -- CVE-2020-26145)

يرسل الاختباران التاليان إطارات بث، والتي لا يُعاد إرسالها تلقائيًا، ولذلك يُنصح بتنفيذهما عدة مرات. وذلك لأن الضوضاء الخلفية قد تمنع الأجهزة التي يتم اختبارها من استقبال إطار البث المحقون. في تجاربي، تأثر بشكل أساسي العملاء (من بين نقاط الوصول التي تم اختبارها تأثرت فقط أجهزة Free/NetBSD).

• ping I,D,P --bcast-ra: أرسل ping أحادي الإرسال داخل جزء ثانٍ نص صريح مُبث بعد الاتصال. يتم التحقق من نتيجة هذا الشكل من الهجوم تلقائيًا بواسطة أداة الاختبار.

• ping D,BP --bcast-ra: هنا يتم إرسال الإطار أعلاه أثناء الاتصال بالشبكة (أي أثناء المصافحة الرباعية). هذا مهم لأن العديد من العملاء ونقاط الوصول يكونون عرضة فقط قبل إكمال المصافحة الرباعية. لتأكيد نتيجة هذا الاختبار، عليك تشغيل wireshark أو tcpdump على الضحية ومراقبة ما إذا كان طلب ping المحقون قد استُقبل من قبل الضحية. في tcpdump يمكنك استخدام الفلتر icmp وفي wireshark يمكنك أيضًا استخدام الفلتر frame contains "test_ping_icmp" لتسهيل اكتشاف طلب ping هذا. في تجاربي تأثر العملاء بشكل أساسي.

7.9. اختبارات هجوم A-MSDU EAPOL (§6.5 -- CVE-2020-26144)

• eapol-amsdu I,P: هذا هو الاختبار القياسي للثغرة الخاصة بالتطبيق التي تمت مناقشتها في القسم 6.5 من الورقة. يمكن أن يكون كل من العملاء ونقاط الوصول عرضة لها. يتم التحقق من نتيجتها تلقائيًا بواسطة أداة الاختبار.

• الاختبارات المنتهية بـ BP (eapol-amsdu BP و eapol-amsdu-bad BP): تحقن هذه الاختبارات الإطار الخبيث أثناء تنفيذ المصافحة الرباعية. لتأكيد نتيجة هذا الاختبار، عليك تشغيل wireshark أو tcpdump على الضحية ومراقبة ما إذا كان طلب ping المحقون قد استُقبل من قبل الضحية. في tcpdump يمكنك استخدام الفلتر icmp وفي wireshark يمكنك أيضًا استخدام الفلتر frame contains "test_ping_icmp" لتسهيل اكتشاف طلب ping هذا.

• الاختبارات التي تبدأ بـ eapol-amsdu-bad (eapol-amsdu-bad BP و eapol-amsdu-bad I,P): تعالج عدة تطبيقات بشكل غير صحيح إطارات A-MSDU التي تساوي أول 6 بايتات منها أيضًا ترويسة RFC1042 صالحة لـ EAPOL. لاختبار هذه التطبيقات، يجب عليك استخدام شكل الاختبار eapol-amsdu-bad. لاحظ أنه إذا نجح هذا الاختبار، فإن تأثير الهجوم مطابق للتطبيقات التي تحلل هذه الإطارات بشكل صحيح (للتفاصيل انظر القسمين 3.6 و6.6 في الورقة).

7.10. قائمة التحقق لاستكشاف الأخطاء وإصلاحها

في حال بدت أداة الاختبار غير عاملة، تحقق مما يلي:

1. تأكد من عدم وجود عملية أخرى تستخدم بطاقة الشبكة (مثلاً قم بإنهاء مدير الشبكة لديك).

2. إذا كان كل شيء يعمل سابقًا، فجرّب فصل دونجل Wi-Fi وإعادة تشغيل جهاز الكمبيوتر أو الجهاز الافتراضي ثم حاول مرة أخرى. حاول أيضًا تعطيل التشفير عبر العتاد باستخدام سكربت disable-hwcrypto.sh (أعد تشغيل جهاز الكمبيوتر بعد تنفيذ هذا السكربت).

3. تأكد من أن الجهاز الذي تختبره لا يدخل في حالة سكون (مما يجعله يفوت الإطارات المحقونة). أوصي بتشغيل أداة الاختبار في الوضع المختلط لأنه يتعامل بشكل أفضل مع العملاء الذين قد يدخلون في حالة سكون.

4. شغّل اختبارات الحقن للتأكد من أن الحقن يعمل بشكل صحيح. تأكد أيضًا من استخدام قناة 20 ميجاهرتز، فالحقن على القنوات الأخرى غير مُختبَر.

5. تحقق من أن جهازك لا يولد حركة مرور خلفية تتعارض مع الاختبارات. على وجه الخصوص، عطّل الشبكات في نظام التشغيل لديك، وأنهِ عميل/خادم DHCP يدويًا، وما إلى ذلك. انظر أيضًا قبل كل استخدام.

6. تأكد من أنك تتصل بالشبكة الصحيحة. تحقق مرة أخرى من client.conf.

7. تأكد من أن نقطة الوصول التي يتم اختبارها تستخدم (AES-)CCMP كخوارزمية تشفير. خوارزميات التشفير الأخرى مثل TKIP أو GCMP غير مدعومة.

8. إذا قمت بتحديث الكود باستخدام git، فنفّذ ./build.sh و ./pysetup.sh مرة أخرى (انظر المتطلبات الأساسية). في حال تحديث برامج التشغيل المعدّلة، تذكر إعادة تجميعها أيضًا.

9. إذا كنت تستخدم جهازًا افتراضيًا، فجرّب تشغيل أداة الاختبار من صورة USB حية بدلاً من ذلك.

10. تحقق من أن الجهاز الذي تم اختباره لا يحظر طلبات ICMP ping. في حال لم يرد على طلبات ping، يمكنك تشغيل tcpdump أو wireshark على الجهاز، أو يمكنك تجربة أي من الطرق الأخرى المدرجة في عدم دعم ICMP.

11. شغّل الأداة مع المعامل الإضافي --debug 2 للحصول على مخرجات تصحيح إضافية من wpa_supplicant أو hostapd ومن أداة الاختبار نفسها.

8. اختبارات الثغرات الموسعة

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

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

8.1. اختبارات هجوم A-MSDU (§3 -- CVE-2020-24588)

من المفيد فقط تنفيذ هذين الاختبارين إذا فشل الاختبار الرئيسي ping I,E --amsdu وأردت فهمًا أفضل لكيفية تعامل الجهاز المختبر مع إطارات A-MSDU:

• ping I,E --amsdu-fake: إذا نجح هذا الاختبار، يعامل جهاز الاستقبال جميع الإطارات كإطارات عادية (بمعنى أنه لا يدعم إطارات A-MSDU). هذا السلوك ليس مثاليًا، على الرغم من أنه من غير المرجح أن يتمكن المهاجم من إساءة استخدام هذا عمليًا (انظر القسم 3.5 في الورقة).

• ping I,E --amsdu-fake --amsdu-spp: إذا نجح هذا الاختبار، يصادق جهاز الاستقبال على علامة QoS A-MSDU لكل إطار مستلم (أي أنه لن يقوم بتقنيعها إلى صفر عند الاستقبال) ولكنه بعد ذلك يعامل جميع الإطارات المستلمة كإطارات عادية (بمعنى أنه لا يدعم استقبال إطارات A-MSDU حقيقية). هذا السلوك ليس مثاليًا، على الرغم من أنه من غير المرجح أن يتمكن المهاجم من إساءة استخدام هذا عمليًا (انظر القسم 3.5 في الورقة).

8.2. اختبارات هجوم المفتاح المختلط (§4 -- CVE-2020-24587)

معظم الأجهزة التي اختبرتها عرضة لهجمات المفتاح المختلط. في حال أشارت اختبارات هجوم المفتاح المختلط العادية إلى أن الجهاز غير عرضة، لكن الاختبار ping-frag-sep نجح، فمن المستحسن بشدة تجربة اختبارات هجوم المفتاح المختلط البديلة هذه.كملاحظة عامة، عند اختبار نقطة وصول (AP)، يمكنك إضافة المعامل --rekey-req إلى أيٍّ من اختبارات هجوم المفتاح المختلط لطلب مصافحة إعادة المفتاح (rekey handshake) بشكل فعّال. سيقوم عدد قليل من نقاط الوصول عندها بتنفيذ مصافحة إعادة المفتاح. لكن معظم نقاط الوصول ستتجاهل هذا الطلب، ويجب تهيئتها صراحةً لتجديد مفتاح الجلسة (PTK) بانتظام.

بعض الملاحظات بخصوص الاختبارات:

• ping I,F,BE,E و ping I,E,F,AE: هذان اختباران مباشران إلى حدٍّ ما لهجوم المفتاح المختلط حيث يتم حقن الجزأين في أوقات مختلفة.

• ping I,E,F,AE --rekey-plain: بعض البرامج التشغيلية (مثل MediaTek) ستقوم بمصافحة إعادة المفتاح كنص صريح. لاختبار الأجهزة التي تستخدم مثل هذا البرنامج التشغيلي، يجب إضافة المعامل --rekey-plain.

• ping I,E,F,AE --rekey-plain --rekey-req: هذا المزيج بالذات مفيد لاختبار الموجّهات التي تستخدم برنامجًا تشغيليًا من MediaTek. تقوم هذه الموجّهات بمصافحة إعادة المفتاح كنص صريح، ويمكن للعميل طلب مصافحة إعادة المفتاح بشكل فعّال.

• ping I,E,F,AE --rekey-early-install: عدد قليل من العملاء يقوم (بشكل غير صحيح) بتثبيت المفتاح في وقت مبكر جدًا أثناء إعادة مفاتيح الجلسة الثنائية. لاختبار هؤلاء العملاء بشكل موثوق، أضف المعامل --rekey-early-install. هذا الاختبار غير ذي معنى ضد نقاط الوصول.

• ping I,E,F,E [--rekey-pl] [--rekey-req]: هذا النوع من الاختبارات هو نفسه اختبارات ping I,E,F,AE * السابقة، باستثناء أن الجزء الثاني يتم إرساله بعد ثانية واحدة من مصافحة 4-way. قد يكون هذا مهمًا لأنه في عدد قليل من الأجهزة يوجد تأخير بسيط قبل تثبيت المفتاح الجديد. لاحظ أن --rekey-pl هي اختصار لـ .

أخيرًا، في حال لم ينجح اختبار ping-frag-sep، يجب أن تجرّب اختبار هجوم المفتاح المختلط التالي:

• ping I,F,BE,AE --freebsd: يقوم هذا الاختبار أساسًا بتنفيذ مصافحة إعادة المفتاح ضد تطبيق FreeBSD، أو برنامج تشغيلي يستعير كودًا من FreeBSD، دون التأثير على عملية إعادة تجميع الأجزاء لإطارات البيانات. راجع الملحق E في الورقة للحصول على التفاصيل.

8.3. اختبارات هجوم ذاكرة التخزين المؤقت (§5 -- CVE-2020-24586)

• ping I,E,R,AE --freebsd --full-reconnect: يمكن استخدام هذا الاختبار للتحقق مما إذا كانت نقطة وصول FreeBSD، أو برنامج تشغيلي يستعير كودًا من FreeBSD، عرضة لهجوم ذاكرة التخزين المؤقت. راجع الملحق E في الورقة للحصول على تفاصيل حول كيفية عمل هذا الاختبار. يجب أيضًا تجربة هذا الاختبار بدون المعامل --full-reconnect. يعمل الاختبار أيضًا ضد العملاء، لكن من غير المرجح أن يتأثروا.

• ping I,E,R,AP --freebsd --full-reconnect: هذا الاختبار هو نوع مختلف ضد نقاط وصول FreeBSD، أو ضد برنامج تشغيلي يستعير كودًا من FreeBSD، حيث يتم إرسال الجزء الثاني كنص صريح بعد إعادة الاتصال بنقطة الوصول. ضد بعض الدونغلات على FreeBSD كان هذا الاختبار أكثر موثوقية ولا يزال يُثبت أن الأجزاء القديمة تبقى في ذاكرة نقطة الوصول بعد إعادة الاتصال. يجب أيضًا تجربة هذا الاختبار بدون المعامل --full-reconnect. يعمل الاختبار أيضًا ضد العملاء، لكن من غير المرجح أن يتأثروا.

• ping I,E,R,AP [--full-reconnect]: في هذا الاختبار، يتم إرسال الجزء الثاني كنص صريح. قد يكون هذا مفيدًا إذا كان الجهاز الذي يتم اختباره لا يثبّت المفتاح فورًا بعد مصافحة 4-way. إذا نجح هذا الاختبار، فإنه يُظهر أن الجهاز يحتفظ بالأجزاء في الذاكرة بعد (إعادة) الاتصال بشبكة، مما يعني أنه عرضة لهجمات ذاكرة التخزين المؤقت. على عكس الأمرين أعلاه، هذا الاختبار مفيد أيضًا لتنفيذه ضد العملاء (بالإضافة إلى نقاط الوصول).

8.4. هجوم النص الصريح/المشفّر المختلط (§6.3 -- CVE-2020-26147)

• ping I,E,E --amsdu: يرسل هذا الاختبار إطار A-MSDU مجزأً، وهو ما لا يمكن لجميع الأجهزة استقباله بشكل صحيح. لا يختبر هذا الاختبار وجود ثغرة أمنية. بدلاً من ذلك، هذا الاختبار مفيد لتحديد قابلية الاستغلال العملي لهجوم "النص الصريح/المشفّر المختلط". وتحديدًا، إذا نجح هذا الاختبار، يصبح من الأسهل مهاجمة الجهاز إذا كان يمكن إرسال الجزء الثاني كنص صريح (اختبار ping I,E,P). راجع القسم 6.3 من الورقة للحصول على التفاصيل.

• ping I,E,P,E و linux-plain 3: إذا لم تنجح جميع اختبارات هجوم النص الصريح/المشفّر المختلط الأخرى، يمكنك أيضًا تجربة هذين الاختبارين الإضافيين. أعتقد أنه من غير المرجح إلى حدٍّ كبير أن يكشف هذا عن ثغرة أمنية جديدة.

8.5. اختبارات هجوم البث المجزأ (امتدادات §6.4)

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

• ping I,P --bcast-ra: يرسل طلب ping ICMP أحادي الإرسال داخل إطار بث Wi-Fi بنص صريح (CVE-2020-26145). يمكن تنفيذ هذا الاختبار ضد كل من العملاء ونقاط الوصول.

• ping BP --bcast-ra: مشابه للاختبار أعلاه ping I,P --bcast-ra، لكن يتم إرسال ping قبل أن يوثّق العميل اتصاله بالشبكة، أي أثناء تنفيذ مصافحة 4-way (CVE-2020-26145). يجب تشغيل tcpdump أو wireshark للتحقق مما إذا كان العميل يقبل الإطار. في tcpdump يمكنك استخدام عامل التصفية icmp، وفي wireshark يمكنك أيضًا استخدام عامل التصفية frame contains "test_ping_icmp" لاكتشاف طلب ping هذا بسهولة أكبر.

• ping BP --bcast-ra --bcast-dst: هذا الاختبار هو نفسه السابق، لكنه مفيد إذا لم تتمكن من تشغيل tcpdump على نقطة الوصول المستهدفة. لاحظ أن هذا الاختبار ذو معنى فقط ضد نقاط الوصول. المعامل الإضافي --bcast-dst في هذا الاختبار يجعل نقطة الوصول الضعيفة تبث طلب ping المحقون إلى جميع العملاء المتصلين. بعبارة أخرى، للتحقق مما إذا كانت نقطة الوصول ضعيفة، نفّذ هذا الأمر، واستمع لإطارات بث Wi-Fi على جهاز ثانٍ متصل بنقطة الوصول باستخدام عامل التصفية icmp أو frame contains "test_ping_icmp".

• ping BP [--bcast-dst]: هذا نوع مختلف من الاختبارين أعلاه ping BP --bcast-ra [--bcast-dst]، باستثناء أن طلب ping يتم إرساله الآن في إطار أحادي الإرسال بنص صريح بدلاً من إطار بث (لا يوجد CVE مخصص له بعد - إنه مرتبط بـ CVE-2020-26145). يجب تنفيذ هذا الاختبار ضد كل من العملاء ونقاط الوصول. يتم إرسال ping قبل أن يوثّق العميل اتصاله بالشبكة (أي أثناء تنفيذ مصافحة 4-way)، مما يعني أنه يجب تشغيل tcpdump أو wireshark للتحقق مما إذا كان الجهاز يقبل هذا الإطار. بدلاً من ذلك، عند اختبار نقاط الوصول، يمكنك إضافة المعامل --bcast-dst كما في الاختبار أعلاه، ثم استخدام tcpdump أو wireshark على جهاز ثانٍ متصل بنقطة الوصول باستخدام عامل التصفية icmp أو frame contains "test_ping_icmp".

• eapfrag BP,BP: هذا تخصيص لاختبارات البث المجزأ أعلاه يتم تنفيذه قبل أن يوثّق العميل اتصاله. إنه هجوم تجريبي للغاية يعتمد على تحليل كود مُسرَّب. يرسل أولاً جزءًا بنص صريح يبدأ بترويسة EAPOL، والتي يتم قبولها لأن مصافحة 4-way ما تزال قيد التنفيذ. ثم يرسل جزء بث ثانيًا بنفس رقم التسلسل. استنادًا إلى تحليل الكود المُسرَّب، قد تقبل بعض الأجهزة الآن هذا الجزء (لأن الجزء السابق كان مسموحًا به)، لكن الكود اللاحق سيعالجه كإطار عادي (لأن الجزء يُبَث). يجب استخدام tcpdump أو wireshark على الضحية لتحديد ما إذا كان الإطار قد استُقبل بشكل صحيح، على سبيل المثال باستخدام عامل التصفية icmp أو frame contains "test_ping_icmp". البديل الممكن هو eapfrag BP,AE في حال لم يعمل النوع العادي.

8.6. اختبارات هجوم A-MSDU EAPOL (§6.5 -- CVE-2020-26144)

يمكن استخدام هذا الاختبار في حال رغبت في تنفيذ اختبارات eapol-amsdu[-bad] BP ولكن لا يمكنك تشغيل tcpdump أو wireshark على نقطة الوصول. هذا الاختبار ذو معنى فقط ضد نقاط الوصول: الأمر eapol-amsdu[-bad] BP --bcast-dst يجعل نقطة الوصول الضعيفة تبث طلب ping المحقون إلى جميع العملاء المتصلين. بعبارة أخرى، للتحقق مما إذا كانت نقطة الوصول ضعيفة، نفّذ هذا الأمر، واستمع لإطارات بث Wi-Fi على جهاز ثانٍ متصل بنقطة الوصول باستخدام عامل التصفية icmp أو frame contains "test_ping_icmp".

8.7. اختبارات هجوم إعادة توجيه نقطة الوصول لإطارات EAPOL (§6.6 -- CVE-2020-26139)

• eapol-inject 00:11:22:33:44:55: هذا الاختبار ذو معنى فقط ضد نقاط الوصول. لتنفيذ هذا الاختبار، يجب عليك الاتصال بالشبكة باستخدام جهاز ثانٍ واستبدال عنوان MAC 00:11:22:33:44:55 بعنوان MAC الخاص بهذا الجهاز الثاني. قبل المصادقة، سترسل أداة الاختبار إطار EAPOL إلى نقطة الوصول بوجهته النهائية هذا الجهاز الثاني. إذا قامت نقطة الوصول بإعادة توجيه إطار EAPOL إلى الجهاز الثاني، تُعتبر نقطة الوصول ضعيفة. للتأكد مما إذا كانت نقطة الوصول تعيد توجيه إطار EAPOL، يجب تشغيل tcpdump أو wireshark على الجهاز الثاني. يمكنك استخدام عامل تصفية wireshark frame contains "forwarded_data" عند مراقبة حركة المرور المفكوكة تشفيرها على الواجهة اللاسلكية للجهاز الثاني (أو عامل تصفية tcpdump ether proto 0x888e لمراقبة جميع إطارات EAPOL). راجع القسم 6.6 من الورقة للحصول على التفاصيل والتأثير.

• eapol-inject-lage 00:11:22:33:44:55: في حال نجح اختبار eapol-inject أعلاه، يمكنك أيضًا تجربة eapol-inject-large لمعرفة ما إذا كان يمكن استغلال هذه الثغرة لإجبار إرسال أجزاء مشفّرة. سيتعين عليك مرة أخرى استخدام tcpdump أو wireshark للتحقق من ذلك. استخدم عامل تصفية wireshark أو tshark (wlan.fc.frag == 1) || (wlan.frag > 0) لكشف الإطارات المجزأة. وجدت أنه من النادر جدًا أن ينجح هذا الهجوم.

8.8. اختبار هجوم عدم دعم التجزئة (§6.8 -- CVE-2020-26142)

• ping I,D,E: إذا نجح هذا الاختبار، فإن العميل أو نقطة الوصول لا يدعم (إعادة) التجزئة، لكنه ما يزال عرضة للهجمات. المشكلة هي أن المستقبِل يتعامل مع الجزء الأخير كإطار كامل. راجع القسم 6.8 في الورقة للحصول على التفاصيل وكيف يمكن استغلال ذلك.

• ping I,E,D: إذا نجح هذا الاختبار، فإن العميل أو نقطة الوصول يتعامل مع الجزء الأول كإطار كامل. على الرغم من أن هذا السلوك ليس مثاليًا، إلا أنه من غير المعروف حاليًا ما إذا كان يمكن استغلال هذا الأمر بمفرده عمليًا.

9. الاستخدام المتقدم

9.1. اختبارات حقن بطاقة الشبكة

وضع الحقن

يمكن استخدام السكربت test-injection.py لاختبار ما إذا كانت الإطارات تُحقن بشكل صحيح عند استخدام وضع الحقن:

./test-injection.py wlan0 wlan1

هنا نختبر ما إذا كانت بطاقة الشبكة wlan0 تحقن الإطارات بشكل صحيح، ونستخدم بطاقة الشبكة wlan1 لمراقبة ما إذا كانت الإطارات تُحقن بشكل صحيح. لاحظ أن كلا الواجهتين يجب أن تدعم وضع المراقبة لكي يعمل سكربت الاختبار.

في حال لم يكن لديك بطاقة شبكة ثانية، يمكنك تنفيذ اختبار حقن جزئي باستخدام:

./test-injection.py wlan0

لسوء الحظ، يمكن للاختبار أعلاه فقط اختبار ما إذا كانت النواة تستبدل حقول الإطارات المحقونة، ولا يمكنه اختبار ما إذا كانت البرامج الثابتة أو شريحة اللاسلكي نفسها تستبدل الحقول.

الوضع المختلط

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

./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap

هنا نختبر ما إذا كانت wlan0 تحقن الإطارات بشكل صحيح من خلال مراقبة الإطارات المحقونة باستخدام بطاقة الشبكة الثانية wlan1. يختبر الأمر الأول ما إذا كانت الإطارات تُحقن بشكل صحيح عند استخدام الوضع المختلط أثناء العمل كعميل، والأمر الثاني عند استخدام الوضع المختلط أثناء العمل كنقطة وصول. لبدء الاختبار، يجب أن يكون العميل قادرًا على الاتصال بشبكة، وتنتظر نقطة الوصول حتى يتصل عميل قبل بدء اختبارات الحقن (راجع قبل كل استخدام لتهيئة إعداد الاتصال للعميل ونقطة الوصول).

إذا أردت أيضًا اختبار سلوك إعادة الإرسال لـ wlan0 في الوضع المختلط، يمكنك تنفيذ:

./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap

في حال لم يكن لديك بطاقة شبكة ثانية، يمكنك تنفيذ اختبار حقن جزئي في الوضع المختلط باستخدام:

./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap

لسوء الحظ، يمكن للاختبارات أعلاه فقط اختبار ما إذا كانت النواة تستبدل حقول الإطارات المحقونة، ولا يمكنها اختبار ما إذا كانت البرامج الثابتة أو شريحة اللاسلكي نفسها تستبدل الحقول.

تفسير نتائج الاختبار

سيقدم سكربت الاختبار مخرجات مفصّلة حول الاختبارات التي نجحت أو فشلت، وسيختتم بإخراج إما ==> The most important tests have been passed successfully أو رسالة تشير إلى أن اختبارات مهمة فشلت أو أنه لم يتمكن من التقاط بعض الإطارات المحقونة.

لاحظ أن سكربتات الحقن تختبر فقط السلوك الأكثر أهمية. أفضل طريقة لتأكيد أن الحقن يعمل بشكل صحيح هي تنفيذ اختبارات الثغرات ضد أجهزة معروفة بأنها ضعيفة، والتأكد من أن الأداة تحدّد الجهاز (الأجهزة) بشكل صحيح على أنها ضعيفة.

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

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

ملاحظات الفحوصات اليدوية

عند استخدام wireshark لفحص سلوك الحقن لجهاز ما، يُنصح باستخدام جهاز ثانٍ في وضع المراقبة لمعرفة كيفية حقن الإطارات.

في حال فتحت الواجهة المستخدمة لحقن الإطارات، يجب أن ترى الإطارات المحقونة مرتين: (1) أولاً ترى الإطار كما حقنته الأداة التي ترسله، ثم (2) مرة ثانية كما حقنه برنامج التشغيل. قد يختلف هذان الإطاران قليلاً إذا كانت النواة قد استبدلت بعض الحقول. إذا رأيت إطارًا محقونًا مرة واحدة فقط، فقد يكون قد أُسقط بواسطة النواة.

9.2. إعداد عنوان IP الثابت

في حال كان الجهاز الذي تختبره لا يدعم DHCP، يمكنك تحديد عناوين IP يدويًا التي يجب أن تستخدمها أداة الاختبار. على سبيل المثال:

./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1

هنا ستستخدم أداة الاختبار عنوان IP 192.168.100.10، وستحقن طلب ping إلى عنوان IP النظير 192.168.100.1.

عندما يرسل اختبار حزم IP قبل الحصول على عناوين IP باستخدام DHCP، سيستخدم عنوان IP الافتراضي 127.0.0.1. لاستخدام عناوين IP (افتراضية) مختلفة، يمكنك أيضًا استخدام المعاملين --ip و -peerip.

9.3. عدم دعم ICMP

تعمل معظم اختبارات الهجوم عن طريق إرسال طلبات ping ICMP بطرق خاصة، ومعرفة ما إذا كنا نتلقى استجابة ping ICMP. في حال كان الجهاز الذي يتم اختباره لا يدعم ping ICMP، يمكنك بدلاً من ذلك استخدام طلبات ARP بإضافة المعامل --arp إلى جميع الاختبارات. في حال كان أحد الاختبارات لا يدعم إرسال طلبات ARP، ستظهر الأداة الخطأ Cannot override request type of the selected test، وفي هذه الحالة لا يمكن تنفيذ هذا الاختبار المحدد إلا باستخدام طلبات ping ICMP.

TODO: عند العمل كعميل، يمكننا أيضًا حقن طلبات DHCP بدلاً من ذلك.

1. بطاقات الشبكة التي تستخدم ath9k_htc

2. بطاقات الشبكة التي تستخدم carl9170

3. بطاقات الشبكة التي تستخدم iwlmvm.

أوصي بالبطاقات القائمة على ath9k_htc. لن تكون جميع البطاقات التي تستخدم iwlmvm متوافقة. عند استخدام بطاقة شبكة بديلة، أوصي بشدة بتشغيل اختبارات الحقن أولاً للتأكد من أن بطاقة الشبكة متوافقة.

9.5. دعم 5 جيجاهرتز

من أجل استخدام أداة الاختبار على قنوات 5 جيجاهرتز، يجب أن تسمح بطاقة الشبكة المستخدمة بحقن الإطارات في قناة 5 جيجاهرتز. لسوء الحظ، هذا ليس ممكنًا دائمًا بسبب القيود التنظيمية. لمعرفة القنوات التي يمكنك حقن الإطارات فيها، يمكنك تنفيذ iw list والبحث ضمن Frequencies عن القنوات التي ليست موسومة بأنها معطلة أو no IR أو كشف الرادار. لاحظ أن هذه الشروط قد تعتمد على بطاقة الشبكة، والدولة المكوّنة حاليًا، ونقطة الوصول التي أنت متصل بها. لمزيد من المعلومات، راجع على سبيل المثال وثائق Arch Linux.

لاحظ أن الجهاز قد يستخدم برامج تشغيل مختلفة للتعامل مع نطاقي 2.4 و5 جيجاهرتز. نتيجة لذلك، من المهم اختبار الأجهزة في كلا النطاقين، لأن الجهاز قد يتصرف بشكل مختلف اعتمادًا على نطاق التردد المستخدم.

لاحظ أنه في الوضع المختلط، قد لا تسمح نواة Linux بحقن الإطارات حتى لو كان مسموحًا إرسال الإطارات العادية. وذلك لأن النواة في الدالة ieee80211_monitor_start_xmit ترفض حقن الإطارات عندما تُرجع cfg80211_reg_can_beacon القيمة false. نتيجة لذلك، قد يرفض Linux حقن الإطارات حتى لو كان ذلك مسموحًا به بالفعل. جعل cfg80211_reg_can_beacon تُرجع true في الظروف الصحيحة يمنع هذا الخطأ.

عمليًا، وجد بعض الأشخاص أنه يجب عليك أولاً ضبط بطاقة الشبكة اللاسلكية يدويًا على قناة 5 جيجاهرتز التي تعمل عليها نقطة الوصول. راجع هذه المسألة على GitHub للحصول على التفاصيل.

9.6. التعامل مع وضع السكون

قد تضع الأجهزة مثل الهواتف المحمولة أو أجهزة إنترنت الأشياء راديو Wi-Fi في وضع السكون لتقليل استهلاك الطاقة. عند وجودها في وضع السكون، تكون هذه الأجهزة غير قادرة على استقبال إطارات Wi-Fi، مما قد يتعارض مع اختباراتنا. هناك بعض الخيارات لمحاولة تخفيف هذه المشكلة:

1. حاول تعطيل وضع السكون على الجهاز الذي يتم اختباره. هذا هو الحل الأكثر موثوقية، لكنه للأسف ليس ممكنًا دائمًا.

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

3. جرّب بطاقة شبكة مختلفة لتنفيذ الاختبارات. وجدت أن بطاقات الشبكة المختلفة ستحقن الإطارات في أوقات مختلفة قليلاً، وقد يكون هذا هو الفرق بين وصول الإطار المحقون بشكل صحيح أو تفويته. على سبيل المثال، ضد Pixel 4 XL كانت أداة الاختبار غير موثوقة عند استخدام TL-WN722N لكنها عملت بشكل موثوق مع Intel 8265.

4. خصّص عناوين IP ثابتة للجهاز قيد الاختبار ودع أداة الاختبار تستخدم عناوين IP ثابتة (راجع إعداد عنوان IP الثابت). مع العديد من الاختبارات، يمكن أن يكون هذا أكثر موثوقية لأن أداة الاختبار يمكنها عندها إرسال إطار الاختبار فورًا بدلاً من الاضطرار أولاً إلى استخدام/الانتظار على DHCP.

9.7. تجنب استخدام tcpdump على نقاط الوصوليمكن استغلال بعض الثغرات فقط أثناء اتصال الجهاز قيد الاختبار بالشبكة،

أي عند تنفيذ المصافحة الرباعية. وهذا يجعل اختبارها آليًا أكثر صعوبة، ويعني عادةً أنه يجب استخدام tcpdump أو أداة مشابهة على الجهاز قيد الاختبار. ومع ذلك، يمكن اختبار نقاط الوصول دون تشغيل tcpdump عليها. على وجه الخصوص، يمكن إجراء اختبارات هجوم تجزئة البث (CVE-2020-26145) واختبارات هجوم A-MSDU EAPOL (CVE-2020-26144) دون تشغيل tcpdump على الجهاز قيد الاختبار. بدلاً من ذلك، يجب تشغيل tcpdump على عميل آخر متصل بنقطة الوصول. عمليًا، يمكن استخدام الأوامر التالية:

• ping I,P --bcast-ra --bcast-dst و ping BP --bcast-ra --bcast-dst

• eapol-amsdu BP --bcast-dst و eapol-amsdu-bad BP --bcast-dst

باستخدام هذه الأوامر، يمكنك مراقبة طلب ping على عميل آخر متصل بنقطة الوصول. في حالة استلام طلب ping على هذا العميل المستقل، تكون نقطة الوصول قيد الاختبار ضعيفة. لسوء الحظ، يبدو حاليًا أن اختبار العملاء ضد هذه المتغيرات من الهجمات أمر صعب دون تشغيل tcpdump على العميل.

9.8. ملاحظات حول دعم الأجهزة

AWUS036ACM

إذا لم يتعرف Linux تلقائيًا على هذا الدونغل لسبب ما، فنفّذ الأمر sudo modprobe mt76x2u لتحميل برنامج التشغيل يدويًا. يبدو هذا الدونغل موثوقًا مع أحدث برامج التشغيل لدينا. إذا كان الدونغل غير موثوق، فأنشئ الملف /etc/modprobe.d/mt76.conf بالمحتوى التالي:``` options mt76_usb disable_usb_sg=1

ثم أعد تشغيل جهازك. وتأكد أيضًا من استخدام كبل USB جيد مع هذا الدونغل! في السابق واجهت سلوكًا غير موثوق مع هذا الدونغل، وكان سببه كبل USB 3.0 رديء. لذا إذا واجهت مشكلات، فقد يساعدك توصيل الدونغل مباشرة دون استخدام كبل.

عند استخدام VirtualBox، تأكد من تمكين USB3.0 حتى يتم التعرف على الدونغل. راجع [هذه المشكلة](https://github.com/vanhoefm/fragattacks/issues/22) للتفاصيل.

يستخدم AWUS036ACM داخليًا مجموعة شرائح MT7612U. توجد الآن أيضًا دونغلات بمجموعة شرائح MT7612UN وهي موثوقة أيضًا مع أداة الاختبار الخاصة بنا. مثال على ذلك [محول الشبكة اللاسلكية CSL](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).

### ath9k_htc

أجهزة Technoethical N150 HGA، وTP-Link TL-WN722N v1.x، وAlfa AWUS036NHA، جميعها تستخدم برنامج التشغيل `ath9k_htc`.

بالنسبة لي عملت هذه الأجهزة بشكل جيد إلى حد ما في جهاز افتراضي، ومع أنها مثل جميع الأجهزة تكون أكثر موثوقية عند استخدامها بشكل أصلي. عند استخدام جهاز افتراضي (VM)، أنصح بتكوينه لاستخدام وحدة تحكم USB2.0، لأن ذلك بدا أكثر استقرارًا (على الأقل مع VirtualBox).

في الأنوية الحديثة كانت هناك انتكاسة ([تم إصلاحها الآن](https://www.spinics.net/lists/linux-wireless/msg200825.html)) مع برنامج تشغيل `ath9k_htc` تسببت في عدم عمله. ببساطة استخدم نواة محدّثة أو برامج التشغيل المعدّلة لدينا لتجنب هذه المشكلة.

#### AWUS036ACH

هذا الجهاز غير مدعوم افتراضيًا في معظم توزيعات Linux ويتطلب تثبيت برامج التشغيل يدويًا. في Kali Linux يمكنك تثبيت برنامج التشغيل باستخدام `sudo apt install realtek-rtl88xxau-dkms`. لتثبيت برنامج التشغيل على التوزيعات الأخرى، تحقق من مدير الحزم لديك أو اتبع تعليمات التثبيت على [GitHub](https://github.com/aircrack-ng/rtl8812au). قبل توصيل الجهاز، يُنصح بتنفيذ `modprobe 88XXau rtw_monitor_retransmit=1`.

لسوء الحظ، لا يعمل هذا الجهاز في الوضع المختلط، وهو الوضع الموصى به، ومن الصعب استخدامه مع برامج التشغيل المعدّلة لدينا. عمليًا، سيتعين عليك إلغاء تثبيت برامج التشغيل المعدّلة ثم تشغيل أداة الاختبار باستخدام المعاملات `--no-drivercheck` وباستخدام `--inject wlan0` حيث يشير wlan0 إلى بطاقة AWUS036ACH. بسبب هذه القيود، لا يُنصح بهذا الجهاز.

### Intel AX200

لقد اختبرت Intel AX200 ووجدت أنه _غير_ متوافق مع أداة الاختبار: يتعطل برنامجه الثابت (firmware) بعد حقن إطار مع تعيين علامة More Fragments. إذا كان مطوّر Intel يقرأ هذا، فيرجى تحديث البرنامج الثابت وجعل من الممكن حقن الإطارات المجزأة.

### شرائح RT5572

اختبرت مجموعة الشرائح هذه باستخدام [محول CSL USB 2.0 WLAN 300Mbit](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20). بعد تعطيل فك التشفير العتادي بتنفيذ سكربت `disable-hwcrypto.sh`، تمكنت من إجراء اختبار ping أساسي (`ping`). كان اختبار ping المجزأ (`ping I,E,E`) غير موثوق جدًا لكنه نجح أحيانًا.

الاستنتاج الحالي هو أن شرائح RT5572 _ربما_ تعمل مع أداة الاختبار بعد تعطيل تشفير العتاد. لكن هناك حاجة إلى تجارب إضافية لتأكيد ذلك (الملاحظات مرحّب بها).

<a id="id-hwsim-details"></a>
## 9.9. تفاصيل وضع Hwsim

**تحذير**: *هذا الوضع تجريبي حاليًا، استخدمه فقط لأغراض البحث.*

يتطلب هذا الوضع بطاقة شبكة واحدة فقط تدعم وضع المراقبة (monitor mode)، وعلى عكس الوضع المختلط، لا يتعين على بطاقة الشبكة دعم الواجهات الافتراضية. العيب هو أنه في هذا الوضع تتم معالجة الإطارات بشكل أبطأ قليلاً، كما أنه غير موثوق عندما لا تؤكد بطاقة الشبكة استلام الإطارات:

- بسبب commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") ستنتهي مهلة المصادقة كعميل فورًا، مما يعني أننا لا نستطيع استخدام وضع hwsim كعميل حاليًا.
  _TODO: نحتاج إلى تعديل النواة لتجنب انتهاء المهلة هذه._

- إذا اختبرنا عميلًا يستخدم commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") فيتعين علينا (كنقطة وصول) تأكيد استلام الإطارات المرسلة إلينا. وإلا فلن يتمكن العميل الذي يتم اختباره من الاتصال.
  _TODO: اختبار الأجهزة التي تؤكد الإطارات في وضع المراقبة، واختبار `iw set wlanX monitor active`._

- تتطلب بعض نقاط الوصول أيضًا أن يؤكد العميل استلام إطارات المصادقة والاقتران (association). وهذا يعني أنه يتعين علينا (كعميل) مرة أخرى تأكيد استلام الإطارات المرسلة إلينا.
  _TODO: اختبار الأجهزة التي تؤكد الإطارات في وضع المراقبة، واختبار `iw set wlanX monitor active`._

- لسبب غريب، لا يمكن لـ Intel/mvm استقبال إطارات البيانات من Android/iPhone/iPad بعد المصافحة الرباعية (4-way HS)؟ هذه مشكلة غريبة جدًا. _TODO: التحقيق في هذا الأمر أكثر._

قبل استخدام هذا الوضع، أنشئ بطاقتي شبكة افتراضيتين:

	./hwsim.sh

سيؤدي هذا إلى إخراج الواجهتين الافتراضيتين "hwsim" اللتين تم إنشاؤهما، على سبيل المثال wlan1 وwlan2. عند اختبار نقطة وصول في هذا الوضع، يجب عليك أولاً البحث عن قناة نقطة الوصول، ووضع بطاقة الشبكة الحقيقية على هذه القناة:

	./scan.sh wlan0
	ifconfig wlan0 down
	iw wlan0 set type monitor
	ifconfig wlan0 up
	# Pick the channel that the AP is on (in this example 11)
	iw wlan0 set channel 11

هنا يشير wlan0 إلى بطاقة الشبكة _الحقيقية_ (وليس واجهة تم إنشاؤها بواسطة `hwsim.sh`). عند اختبار عميل، لا يتعين عليك أولاً تكوين القناة (يتم أخذها من `hostapd.conf`). يمكنك الآن تشغيل أداة الاختبار كما يلي:

	./fragattack.py	 wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND

بعد تنفيذ الأداة، يمكنك تشغيلها مباشرة مرة أخرى بأمر `$COMMAND` جديد.

<a id="id-wpa3-sae"></a>
## 9.10. اختبار أجهزة WPA3 وSAE

يمكنك اختبار نقطة وصول WPA3/SAE بإدراج السطرين التاليين في `client.conf`:

	key_mgmt=SAE
	ieee80211w=1

لاختبار عملاء WPA3/SAE يمكنك تعديل `hostapd.conf` وتعيين المعاملات:

	wpa_key_mgmt=SAE
	ieee80211w=2

اختبرنا ما سبق مع Intel 8265 وIntel 3160 وNetgear WN111v2 (`carl9170`) وTP-Link TL-WN722N (`ath9k_htc`) وWNDA3200 (`ath9k_htc`). مع هذه الأجهزة تمكنت من الاتصال بنقطة الوصول وتشغيل بعض الاختبارات. لذلك يبدو أن هذا يجب أن يعمل مع جميع الدونغلات المدعومة بالفعل. لاحظ أنني لم أختبر هذا بالتفصيل: كان افتراضي أن ما إذا كان الجهاز يعمل في وضع WPA2 أو WPA3 لن يؤثر على نتائج الاختبار.

يقوم ملف `client.conf` المرفق افتراضيًا بتمكين كل من طريقة hunting-and-pecking وطريقة hash-to-element. لإعداد نقطة وصول تدعم hash-to-element (وبالتالي اختبار أحدث عملاء WPA3/SAE) يمكنك تعديل `hostapd.conf` وتعيين المعامل:

	sae_pwe=2

بتعيين هذه القيمة، ستقبل نقطة الوصول كلًا من طريقة hunting-and-pecking وطريقة hash-to-element.

<a id="id-live-image"></a>
## 9.11. صورة USB الحية

نزّل [صورة USB الحية](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso) واكتبها على USB باستخدام:

	# Unmount in case there's an old partition on the USB
	sudo umount /dev/sdb*
	# Copy the image
	sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress

قيمة sha256sum للصورة هي `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. استبدل `/dev/sdb` بذاكرتك USB. إذا كنت لا تستخدم Linux، فابحث عبر الإنترنت عن كيفية كتابة صورة ISO على ذاكرة USB.

عند بدء تشغيل الصورة الحية، انقر على "Try Ubuntu" أثناء الإقلاع. ابدأ الطرفية بالنقر بزر الماوس الأيمن على سطح المكتب واختيار "Open in Terminal" ثم نفّذ:

	cd ~/fragattacks/research
	sudo su
	nmcli radio wifi off
	source venv/bin/activate

يمكنك الآن تشغيل `./fragattacks.py` واتباع التعليمات العادية في هذا README. تذكر تعطيل Wi-Fi باستخدام `nmcli radio wifi off` كما هو موضح أعلاه، وإلا سيتداخل مدير الشبكة في Ubuntu مع أداة الاختبار. هذا README موجود أيضًا على الصورة الحية في `~/fragattacks/README.md`.

لاحظ أن airmon-ng قد يكون غير موثوق على الصورة الحية ومن الأفضل استخدام [iw](https://github.com/vanhoefm/fragattacks/issues/36).

<a id="id-design-notes"></a>
# 10. ملاحظات التصميم

تحدد الوسائط المعطاة لأمر ping الإجراءات التي ستنفذها أداة الاختبار ومتى يتم تنفيذ هذه الإجراءات. يتم فصل كل إجراء بفاصلة (`,`). افتراضيًا، يتم تنفيذ إجراء بعد اتصال العميل، وفي هذه الحالة يمثل حرف واحد الإجراء الذي يتم تنفيذه. لاحظ أن هذا منفذ في دالة [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23). الإجراءات الممكنة هي:

- `I`: الحصول على عنوان IP. افتراضيًا يتم ذلك باستخدام DHCP، إلا إذا تم توفير عنوان IP صراحةً باستخدام الوسيطتين `--ip` و`--peerip`، وفي هذه الحالة لا يتم تنفيذ أي شيء.
- `E`: حقن حزمة/جزء مشفّر من طلب ping.
- `P`: حقن حزمة/جزء نصي واضح من طلب ping.
- `F`: تحديث مفتاح الجلسة عن طريق بدء المصافحة الرباعية (كنقطة وصول) أو انتظار المصافحة الرباعية (كعميل).
- `R`: السماح للعميل بإعادة الاتصال بالشبكة.
- `D`: هذا "إجراء فوقي" (meta action) خاص. تعامل معه كجزء فارغ من طلب ping لا يتم إرساله فعليًا.

إذا كان هناك إجراء `E` أو `P` واحد فقط، فسيتم حقن طلب ping كإطار واحد. إذا كانت هناك إجراءات `E` أو `P` متعددة، فسيتم تجزئة طلب ping، حيث يكون عدد الأجزاء مساويًا لعدد إجراءات `E` أو `P`. إذا كان هناك الإجراء الخاص `D`، فسيتم تجزئة طلب ping عبر إجراءات `E` أو `P` المتبقية (انظر الأمثلة في الجدول). سلوك التجزئة هذا منفذ في فئة [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).

يمكن وضع حرف أمام الإجراءات أعلاه لتغيير وقت تنفيذ الإجراء:

- `S`: يتم تنفيذ الإجراء على الرسالة الأولى أو الثانية من المصافحة الرباعية.
- `B`: يتم تنفيذ الإجراء على الرسالة الثالثة أو الرابعة من المصافحة الرباعية.
- `A`: يتم تنفيذ الإجراء مباشرة بعد اكتمال المصافحة الرباعية.
- `C`: يتم تنفيذ الإجراء بعد ثانية واحدة من اكتمال المصافحة الرباعية. يمكن تغيير عدد الثواني التي يتم الانتظارها باستخدام المعامل `--connected-delay`.

على سبيل المثال، انظر الجدولين أعلاه مع الأوامر.

<a id="id-change-log"></a>
# 11. سجل التغييرات

**الإصدار 1.3.4 (قيد التقدم):**:

- قم دائمًا بتشفير إطارات طلب EAPOL (Rekey)، حتى عند استخدام --rekey-plaintext.

- يقبل العميل الآن إطارات EAPOL المعاد تشغيلها (replayed). يضمن هذا أن عمليات إعادة المفاتيح تعمل حتى عندما تنفذ نقطة الوصول التي يتم اختبارها عمليات إعادة المفاتيح بشكل غير صحيح.

- تم تحديث wpa_supplicant لإعادة تمكين الاتصال بشبكات Enterprise التي تستخدم MS-CHAPv2. سابقًا، عندما يستخدم نظام التشغيل OpenSSL 3.0 أو أعلى، كان MD4 معطلاً افتراضيًا، مما يعني عدم إمكانية استخدام MS-CHAPv2.

- تمت إضافة المعامل `--pre-test-delay`. يضيف هذا تأخيرًا بين الحصول على عنوان IP وإرسال أول أجزاء/إطارات. راجع [طلب السحب](https://github.com/vanhoefm/fragattacks/pull/44) من Michael Trimarchi وAngelo Compagnucci.
	
- تم تحديث برامج التشغيل المعدّلة حتى يمكن ترجمتها على Linux kernel 5.13 أيضًا. هذا تجريبي.

- جعل اختبار الحقن أكثر موثوقية بالانتظار لفترة أطول للإطارات في اختبار إعادة الترتيب.

- تم إجراء العديد من التغييرات الطفيفة لتسهيل ترجمة الكود على الأنظمة القديمة (التي تحتوي على إصدارات أقدم من Python ومكتبات OpenSSL).

- تم تحديث README بمثال حول كيفية تثبيت نواة قديمة مدعومة على Ubuntu 20.04. تمت إضافة ملاحظات التصميم. أصبحنا الآن نوصي بـ AWUS036ACM.

**الإصدار 1.3.3 (11 مايو 2021)**:

- تم تحديث برامج التشغيل المعدّلة حتى يمكن ترجمتها على Linux kernel 5.10 و5.11 و5.12.

- تم تحديث البرنامج الثابت لأجهزة `ath9k_htc` (يجب ألا يكون له تأثير على الاختبارات).

- تمت إعادة هيكلة المستودع للإصدار العام. تمت إزالة المستندات والشرائح الداخلية للرجوع بدلاً من ذلك إلى النسخ العامة من هذه المستندات.

- دعم أساسي لقنوات 40 ميجاهرتز عند استخدام المعامل `--inject-test[-postauth]` لاختبار الحقن. في اختبارات الثغرات الفعلية، استخدام قنوات 40 ميجاهرتز غير مختبر (استخدم `disable_ht40` في `client.conf` إذا لزم الأمر).

**الإصدار 1.3.2 (8 مارس 2021)**:

- تمت إضافة [النشرات](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) الخاصة بالعرض التقديمي و[ملخص](https://papers.mathyvanhoef.com/fragattacks-overview.pdf) للسبب الجذري وتأثير كل ثغرة.

- تم تحديث هذا README لـ[شرح](#id-test-sanity) أنه يمكن إضافة المعامل `--icmp-size 100` أو ما شابه إلى جميع الاختبارات التي ترسل إطارات مجزأة إذا كان الجهاز قيد الاختبار يقبل فقط الأجزاء ذات حد أدنى معين للحجم.

- تم إصلاح أخطاء إملائية طفيفة في هذا README.

**الإصدار 1.3.1 (1 مارس 2021)**:

- تمت إضافة اختبار [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) إلى هذا README. يقوم بحقن ping نصي واضح أثناء الاتصال (أي خلال المصافحة الرباعية). يمكن أن يكون كل من العملاء ونقاط الوصول عرضة لهذا الهجوم.

- تم تحديث [نظرة عامة على الهجمات](#id-paper-clarifications) بأمثلة جديدة حول كيفية إساءة استخدام ثغرات حقن الحزم عمليًا. يتضمن ذلك تقنيات لخداع العملاء الذين يدعمون IPv4 فقط لاستخدام خادم DNS خبيث، وتقنيات للتواصل مباشرة مع الأجهزة خلف NAT/جدار حماية (لاستغلال الخدمات المحلية على سبيل المثال).

- تم توضيح أنه يمكن تنفيذ [اختبارات البث المجزأ](#id-extended-bcast-check) ضد كل من العملاء ونقاط الوصول.

- ستتحقق أداة الاختبار الآن مما إذا كان الإصدار المتوقع من مكتبة Python Scapy قد تم تحميله.

- تم إصلاح بعض الإشارات إلى الورقة البحثية في هذا README (تشير الآن بشكل صحيح إلى الأقسام 6.4 و6.6 و6.8).

- تم التحديث إلى النسخة الثالثة من مسودة الورقة البحثية. لا توجد تغييرات كبيرة مقارنة بالمسودة الثانية، فقط تعديلات نصية وهيكلية طفيفة. من حيث المحتوى، هذه الآن النسخة النهائية من الورقة.

**الإصدار 1.3 (20 يناير 2021)**:

- يعتمد هذا الإصدار على commit `a337c1d7c` من hostap ("New TWT operations and attributes to TWT Setup and Nudge").

- تمت إضافة [نظرة عامة](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) على الهجمات وشروطها المسبقة، وتم إنشاء [هذه الشرائح](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf) لتوضيح كيفية عمل هجوم التجميع (CVE-2020-24588) عمليًا بشكل أفضل.

- تمت إضافة <a href="#id-wpa3-sae">تعليمات</a> حول كيفية اختبار أجهزة WPA3/SAE باستخدام إما طريقة hunting-and-pecking أو hash-to-element. هذا يعني أيضًا أن حماية إطارات الإدارة (MFP) مدعومة بواسطة أداة الاختبار.

- تمت إضافة توضيح إلى هذا README حول كيفية استخدام tcpdump للتحقق من نتيجة بعض الاختبارات.

- تمت إضافة الاختبار الإضافي `ping BP --bcast-ra --bcast-dst` إلى هذا README لتمكين اختبار CVE-2020-26145 ضد نقاط الوصول التي لا يمكنها تشغيل tcpdump (مع هذا الاختبار يجب تشغيل tcpdump على عميل متصل مستقل).

- تمت إضافة الاختبارات الإضافية `ping I,E,F,E [--rekey-pl] [--rekey-req]` إلى هذا README لاكتشاف هجمات المفاتيح المختلطة (CVE-2020-24587) بشكل أفضل في بعض الأجهزة.

- تم إصلاح حقن الإطارات المجزأة عند استخدام دونغلات ath9k_htc مع 802.11n.

- تمت إضافة سكربت `pysetup.sh` لإنشاء البيئة الافتراضية لـ Python. يقوم هذا السكربت أيضًا بإصلاح [خطأ](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) في مكتبة scapy عند استخدامها مع Python 3.9.

- تم تحديث برامج التشغيل المعدّلة لتترجم بشكل صحيح على Linux 5.9.0.

- تم إصلاح اختبار `ping-frag-sep`. سابقًا كان يتصرف مثل `ping-frag-sep --pn-per-qos`. لاحظ أن هذا الاختبار لا يستخدم لاكتشاف الثغرات بل فقط لفهم التطبيقات بشكل أفضل.

**الإصدار 1.2 (15 نوفمبر 2020)**:

- يعتمد هذا الإصدار (والإصدارات الأقدم) على commit `1c67a0760` من hostap ("tests: Add basic power saving tests for ap_open").

- ستخرج الأداة تلقائيًا بعد اكتمال الاختبار أو انتهاء مهلته.

- تكتشف الأداة ما إذا كانت المصافحة الرباعية في حلقة تكرار أو إذا لم يكن هناك رد على طلب إعادة مفاتيح (`--rekey-req`).

- عند استخدام خادم DHCP خارجي، سترسل الأداة الآن دائمًا إطارات EAPOL بعنوان وجهة هو نقطة الوصول (بدلاً من خادم DHCP). هذا مهم في اختبارات المفاتيح المختلطة وهجمات ذاكرة التخزين المؤقت عند استخدام خادم DHCP خارجي.

- عند اختبار نقطة وصول باستخدام `--rekey-req`، سترسل الأداة الآن طلب إعادة مفاتيح EAPOL بعداد إعادة تشغيل (Replay Counter) بقيمة واحد بدلاً من صفر.

- يعرض إخراج التصحيح الآن المفتاح (المجموعة) الصحيح عند تشفير إطارات البث/البث المتعدد. لا يؤثر هذا على أي نتائج اختبار، بل يغير فقط ناتج أداة الاختبار.

- تم توضيح أن جميع الأوامر في هذا README يمكنها اختبار كل من العملاء ونقاط الوصول ما لم يُذكر خلاف ذلك.

- تم توضيح وصف هجمات ذاكرة التخزين المؤقت، والبث المجزأ، واختبارات هجوم A-MSDU EAPOL في هذا README.

- تم توضيح أنه من المهم اختبار كل من نطاقي 2.4 و5 جيجاهرتز في هذا README.

**الإصدار 1.1 (20 أكتوبر 2020)**:

- تم إصلاح خطأ حيث كان الأمر `ping I,E,D` يرسل طلب ping مشفرًا عاديًا. الآن يرسل طلب ping مشفرًا مع تعيين علامة More Fragments في الترويسة.

- تم نقل أوامر `amsdu-inject-[bad]` إلى القسم 7 من هذا README. تحاكي هذه هجمات حقيقية ويمكن استخدامها للتحقق مما إذا كانت التخفيفات المؤقتة تعمل (انظر القسم 7.2 في الورقة البحثية).

- تم إصلاح تهجئة A-MSDU SPPs في هذا README وأداة الاختبار. الوسيطة الجديدة `--amsdu-spp` أصبحت الآن مرادفة للوسيطة القديمة `--amsdu-ssp`.

**الإصدار 1.0 (11 أغسطس 2020)**:

- تم تجهيز الإصدار الأولي للاستخدام أثناء فترة الحظر.