يحتوي هذا المشروع على نصوص برمجية لاختبار ما إذا كانت الأجهزة العميلة أو نقاط الوصول (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 إلى نقطة الوصول: .

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

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

• الاختبار الأكثر أهمية هو ./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، وعندها سيجتاز هذا الاختبار أيضًا.

• 4.1.3 (إعادة إرسال فورية لـ EAPOL M3 المشفرة أثناء مصافحة إعادة المفتاح الثنائي). يتوافق هذا مع ./krack-test-client.py، باستثناء أن EAPOL M3 المشفرة تُرسل دوريًا بدلاً من فورًا.

• 4.1.5 (إعادة تثبيت PTK في المصافحة الرباعية عندما تستخدم المحطة STA بناء PTK المؤقت، مع نفس ANonce). نفّذ هذا الاختبار باستخدام ./krack-test-client.py --tptk.

• 4.1.6 (إعادة تثبيت PTK في المصافحة الرباعية عندما تستخدم المحطة STA بناء PTK المؤقت، مع ANonce عشوائي). نفّذ هذا الاختبار باستخدام ./krack-test-client.py --tptk-rand.

• 4.2.1 (اختبار ثغرة مصافحة المفتاح الجماعي على المحطة STA). نفّذ هذا الاختبار باستخدام ./krack-test-client.py --group.

• 4.3.1 (إعادة تثبيت GTK وIGTK على محطة STA تدعم وضع السكون WNM). لا ندعم حاليًا هذا الاختبار (ولا يدعمه Wi-Fi Alliance في الواقع!).

اختبار نقاط الوصول: اكتشاف مصافحة FT المعرضة للخطر (802.11r)

1. أنشئ ملف إعدادات wpa_supplicant يمكن استخدامه للاتصال بالشبكة. مثال أساسي هو:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

   لاحظ استخدام "FT-PSK". احفظه باسم network.conf أو ما شابه. لمزيد من المعلومات راجع wpa_supplicant.conf.

2. حاول الاتصال بالشبكة باستخدام wpa_supplicant الخاص بمنصتك. سيتطلب هذا غالبًا أمرًا مثل:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   إذا فشل ذلك، فإما أن نقطة الوصول لا تدعم FT، أو أنك قدمت خيارات إعدادات شبكة خاطئة في الخطوة 1. لاحظ أنه إذا كانت نقطة الوصول لا تدعم FT، فهي غير متأثرة بهذه الثغرة.

3. استخدم هذا النص البرمجي كغلاف (Wrapper) لأمر wpa_supplicant السابق:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   سينفّذ هذا أمر wpa_supplicant باستخدام المعاملات المقدمة، وسيضيف واجهة مراقبة افتراضية لتنفيذ اختبارات الهجوم. من المهم أولاً أن تصبح root ثم تحميل البيئة الافتراضية للبايثون (انظر أعلاه لمعرفة كيفية إنشاء هذه البيئة الافتراضية).

4. استخدم wpa_cli للتجوال إلى نقطة وصول مختلفة على نفس الشبكة. على سبيل المثال:

   root@kitploit:~

    wpa_cli -i wlan0
    > status
    bssid=c4:e9:84:db:fb:7b
    ssid=testnet
    ...
    > scan_results 
    bssid / frequency / signal level / flags / ssid
    c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    ...
    > roam c4:e9:84:1d:a5:bc
    ...
   

   في هذا المثال، كنا متصلين بنقطة الوصول c4:e9:84:db:fb:7b الخاصة بشبكة testnet (انظر أمر status). يُظهر أمر scan_results أن هذه الشبكة تحتوي أيضًا على نقطة وصول ثانية بعنوان MAC هو c4:e9:84:1d:a5:bc. ثم نقوم بالتجوال إلى نقطة الوصول الثانية هذه.

تأكد أيضًا من فحص آثار الشبكة يدويًا، للتأكد من أن هذا النص البرمجي يعيد تشغيل طلب إعادة الارتباط (Reassociation Request) بشكل صحيح، وللتأكد يدويًا مما إذا كان هناك إعادة استخدام لـ IV (= رقم الحزمة) أم لا.

مثال على مخرجات نقطة وصول معرضة للخطر:

	[15:59:24] Replaying Reassociation Request
	[15:59:25] AP transmitted data using IV=1 (seq=0)
	[15:59:25] Replaying Reassociation Request
	[15:59:26] AP transmitted data using IV=1 (seq=0)
	[15:59:26] IV reuse detected (IV=1, seq=0). AP is vulnerable!

مثال على مخرجات نقطة وصول مصححة (لاحظ أن IVs لا يُعاد استخدامها أبدًا):

	[16:00:49] Replaying Reassociation Request
	[16:00:49] AP transmitted data using IV=1 (seq=0)
	[16:00:50] AP transmitted data using IV=2 (seq=1)
	[16:00:50] Replaying Reassociation Request
	[16:00:51] AP transmitted data using IV=3 (seq=2)
	[16:00:51] Replaying Reassociation Request
	[16:00:52] AP transmitted data using IV=4 (seq=3)

إضافي: فك التشفير العتادي

لتأكيد أن فك التشفير العتادي معطل، نفّذ systool -vm ath9k_htc أو ما شابه بعد توصيل بطاقة Wi-Fi الخاصة بك للتأكد من تعيين المعامل nohwcript/swcrypto/hwcrypto. لاحظ أنه يجب استبدال ath9k_htc بوحدة النواة الخاصة ببطاقة الشبكة اللاسلكية لديك.

إضافي: النطاق 5 جيجاهرتز غير مدعوم

لا يوجد دعم رسمي لاختبار الأجهزة في نطاق 5 جيجاهرتز.

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

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

إضافي: اختبارات يدوية

من الممكن أيضًا إجراء اختبارات يدوية (أكثر تفصيلاً) عن طريق استنساخ مستودع hostap git:

git clone git://w1.fi/srv/git/hostap.git

واتباع التعليمات الواردة في tests/cipher-and-key-mgmt-testing.txt.