يحتوي هذا المشروع على نصوص برمجية لاختبار ما إذا كانت الأجهزة العميلة أو نقاط الوصول (APs) متأثرة بهجوم KRACK ضد WPA2. للحصول على تفاصيل هذا الهجوم راجع موقعنا وورقة البحث.

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

ديسمبر 2024: تم إصلاح خطأ في الاختبار السابع ./krack-test-client.py --gtkinit. قبل هذا الإصلاح، كان يُذكر أن (مخرجات) هذا الاختبار غير موثوقة، لكن الآن يجب أن تكون المخرجات جديرة بالثقة عند اتباع التعليمات الجديدة. أي عندما يشير هذا الاختبار الآن إلى أن الجهاز معرّض للخطر، فمن المرجح بالفعل أنه معرّض.

يناير 2021: تم جعل النصوص البرمجية متوافقة مع Python3 وتم تحديثها لدعم توزيعات لينكس الأحدث بشكل أفضل. إذا أردت الرجوع إلى الإصدار القديم، نفّذ git fetch --tags && git checkout v1 بعد استنساخ المستودع (ثم عُد إلى الإصدار الأحدث باستخدام git checkout research).

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

تم اختبار نصوصنا البرمجية على Kali Linux. لتثبيت التبعيات المطلوبة على Kali، نفّذ:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

الآن قم بتجميع نسخة hostapd المعدلة لدينا وإنشاء بيئة افتراضية للبايثون. يضمن هذا استخدام مكتبات بايثون متوافقة (تلك المدرجة في krackattack/requirements.txt):

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

ثم عطّل التشفير العتادي (Hardware Encryption) للحصول على أفضل النتائج:

cd krackattack
sudo ./disable-hwcrypto.sh

لاحظ أنه يمكنك لاحقًا إعادة تمكين التشفير العتادي إذا لزم الأمر باستخدام النص البرمجي sudo ./reenable-hwcrypto.sh. يُنصح بإعادة التشغيل بعد تعطيل التشفير العتادي. لقد اختبرنا نصوصنا البرمجية باستخدام Intel Dual Band Wireless-AC 7260 وTP-Link TL-WN722N v1 على Kali Linux.

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

في كل مرة قبل استخدام النصوص البرمجية، يجب عليك تعطيل Wi-Fi في مدير الشبكة لديك. ثم نفّذ:

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

بعد القيام بذلك، يمكنك تنفيذ النصوص البرمجية عدة مرات طالما لم تغلق الطرفية.

إذا أردت التراجع عن تأثيرات disable-hwcrypto.sh فاحذف الملف /etc/modprobe.d/nohwcrypt.conf.

اختبار الأجهزة العميلة

أولاً عدّل hostapd/hostapd.conf وحرّر السطر interface= لتحديد واجهة Wi-Fi التي ستُستخدم لتنفيذ الاختبارات. لاحظ أنه في جميع الاختبارات، بمجرد تشغيل النص البرمجي، يجب عليك ترك الجهاز الذي يتم اختباره يتصل بشبكة SSID باسم testnetwork باستخدام كلمة المرور abcdefgh. يمكنك تغيير إعدادات نقطة الوصول عن طريق تعديل hostapd/hostapd.conf. في جميع الاختبارات، يجب على العميل استخدام DHCP للحصول على عنوان IP بعد الاتصال بشبكة Wi-Fi. وذلك لأن بعض الاختبارات تبدأ فقط بعد أن يطلب العميل عنوان IP باستخدام DHCP!

يجب الآن تشغيل الاختبارات التالية الموجودة في مجلد krackattacks/:

1. ./krack-test-client.py --replay-broadcast. يختبر هذا ما إذا كان العميل يقبل إطارات البث المعاد تشغيلها (Replayed Broadcast Frames). إذا قبل العميل إطارات البث المعاد تشغيلها، فيجب تصحيح هذا أولاً. إذا لم تقم بتصحيح العميل، فلن يتمكن نصنا البرمجي من تحديد ما إذا كان المفتاح الجماعي (Group Key) يعاد تثبيته (لأن النص البرمجي سيقول دائمًا إن المفتاح الجماعي يعاد تثبيته).

2. ./krack-test-client.py --group --gtkinit. يختبر ما إذا كان العميل يثبّت المفتاح الجماعي في مصافحة المفتاح الجماعي (Group Key Handshake) مع عدّاد تسلسل الاستقبال (RSC) المحدد. راجع القسم 6.4 من ورقة البحث اللاحقة للاطلاع على تفاصيل هذه الثغرة.

3. ./krack-test-client.py --group. يختبر ما إذا كان العميل يعيد تثبيت المفتاح الجماعي في مصافحة المفتاح الجماعي. بعبارة أخرى، يختبر ما إذا كان العميل معرضًا لـ CVE-2017-13080. يختبر النص البرمجي عمليات إعادة تثبيت المفتاح الجماعي عن طريق إرسال طلبات ARP بثية إلى العميل باستخدام رقم حزمة مستخدم سابقًا (معاد تشغيله) (هنا رقم الحزمة = nonce = IV). لاحظ أنه إذا كان العميل يقبل دائمًا إطارات البث المعاد تشغيلها (انظر --replay-broadcast)، فقد يستنتج هذا الاختبار بشكل غير صحيح أن المفتاح الجماعي يعاد تثبيته.

4. ./krack-test-client.py. يختبر إعادة تثبيت المفاتيح في المصافحة الرباعية (4-way handshake) عن طريق إرسال الرسائل الثالثة المشفرة بشكل متكرر إلى العميل. بمعنى آخر، يختبر CVE-2017-13077 (الثغرة ذات التأثير الأعلى) وCVE-2017-13078. يراقب النص البرمجي حركة المرور المرسلة من العميل لمعرفة ما إذا كان المفتاح الثنائي (Pairwise Key) يعاد تثبيته. لاحظ أن هذا ينفذ فعليًا اختبارين: ما إذا كان المفتاح الثنائي يعاد تثبيته، وما إذا كان المفتاح الجماعي يعاد تثبيته. تأكد من أن العميل يطلب عنوان IP باستخدام DHCP لبدء اختبار إعادة تثبيت المفتاح الجماعي. وللتأكد من أن العميل يرسل عددًا كافيًا من الإطارات الأحادية (Unicast Frames)، يمكنك اختياريًا إرسال أمر ping إلى نقطة الوصول: ping 192.168.100.254.

5. ./krack-test-client.py --tptk. مطابق للاختبار 4، باستثناء أنه يتم حقن رسالة أولى مزورة قبل إرسال الرسالة الثالثة المشفرة. هذا الاختلاف في الاختبار مهم لأن بعض الأجهزة العميلة (مثل wpa_supplicant v2.6) تكون معرضة فقط لإعادة تثبيت المفتاح الثنائي في المصافحة الرباعية عند حقن رسالة أولى مزورة قبل إرسال رسالة ثالثة معاد إرسالها.

6. ./krack-test-client.py --tptk-rand. نفس الاختبار أعلاه، باستثناء أن الرسالة الأولى المزورة تحتوي على ANonce عشوائي.

7. ./krack-test-client.py --gtkinit. يختبر ما إذا كان العميل يثبّت المفتاح الجماعي في المصافحة الرباعية مع عدّاد تسلسل الاستقبال (RSC) المحدد. يتم ذلك عن طريق إعادة إرسال Msg3/4 من المصافحة الرباعية، وفي كل مرة بمفتاح جماعي جديد وعدّاد إعادة تشغيل مرتفع جدًا. نعلم أنه معرض للخطر إذا قبل العميل الذي يتم اختباره لاحقًا إطارات بث بعدّاد إعادة تشغيل أقل. لسوء الحظ، بعض الأجهزة العميلة لا تقبل Msg3/4 المعاد إرسالها على الإطلاق، مما يعني أنه لا يمكن اختبار هذه الأجهزة بهذا الأمر. الأجهزة العميلة التي تقبل Msg3/4 المعاد إرسالها، وبالتالي يمكن اختبارها بهذا الأمر، سترد برسالة Msg4/4 يمكن اكتشافها بناءً على المخرجات التالية:

   [09:24:11] 02:20:2a:22:a8:30: received a new message 4
   

نوصي أيضًا بتنفيذ هذا الاختبار في بيئات ذات ضوضاء خلفية قليلة وتنفيذه عدة مرات.

بعض الملاحظات الإضافية:

• الاختبار الأكثر أهمية هو ./krack-test-client، الذي يختبر عمليات إعادة التثبيت العادية للمفاتيح في المصافحة الرباعية.

• نفّذ هذه الاختبارات في غرفة ذات تداخل قليل. كمية كبيرة من فقدان الحزم ستجعل هذا النص البرمجي أقل موثوقية!

• يمكنك اختياريًا فحص حركة مرور الشبكة يدويًا لتأكيد مخرجات النص البرمجي (قد تتداخل بعض بطاقات شبكة Wi-Fi مع نصوصنا البرمجية):

  • استخدم بطاقة Wi-Fi إضافية في وضع المراقبة (Monitor Mode) للتأكد من أن نصنا البرمجي (نقطة الوصول) يرسل الإطارات باستخدام أرقام الحزم الصحيحة (IVs). على وجه الخصوص، تحقق مما إذا كانت إطارات البث المعاد تشغيلها تُرسل بالفعل باستخدام رقم حزمة مستخدم سابقًا (IV).

  • استخدم بطاقة Wi-Fi إضافية في وضع المراقبة للتحقق من عمليات إعادة تثبيت المفتاح الثنائي عن طريق مراقبة IVs للإطارات المرسلة من العميل.

  • التقط حركة المرور على العميل لمعرفة ما إذا كانت طلبات ARP البثية المعاد تشغيلها مقبولة أم لا.

• إذا كان بإمكان العميل استخدام عدة راديوهات/بطاقات Wi-Fi، فنفّذ الاختبار باستخدام عدة بطاقات Wi-Fi.

• يمكنك إضافة المعامل --debug لمزيد من مخرجات التصحيح.

• يتم تمرير جميع المعاملات غير المعروفة إلى hostapd، لذا يمكنك تضمين شيء مثل -dd -K لجعل hostapd يُخرج جميع معلومات التصحيح.

التوافق مع اختبارات Wi-Fi Alliance

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

• 4.1.1 (إعادة إرسال رسالة EAPOL 3 بالنص الصريح). لا ندعم حاليًا هذا الاختبار. هذا الاختبار غير ضروري على أي حال. تأكد من أن الجهاز الذي يتم اختباره يجتاز الاختبار 4.1.3، وعندها سيجتاز هذا الاختبار أيضًا.

• 4.1.2 (إعادة إرسال فورية لـ EAPOL M3 بالنص الصريح). لا ندعم حاليًا هذا الاختبار. مرة أخرى، تأكد من أن الجهاز الذي يتم اختباره يجتاز الاختبار 4.1.3، وعندها سيجتاز هذا الاختبار أيضًا.