FragAttacks: विखंडन और एकत्रीकरण हमले

1. परिचय

इस रिपॉज़िटरी में FragAttacks टूल शामिल है। यह वाई-फ़ाई क्लाइंट और एक्सेस पॉइंट्स का फ़्रैगमेंटेशन (विखंडन) और एग्रीगेशन (एकत्रीकरण) हमलों के लिए परीक्षण कर सकता है। ये कमज़ोरियाँ सभी संरक्षित वाई-फ़ाई नेटवर्कों को प्रभावित करती हैं। इन कमज़ोरियों के बारे में अधिक जानकारी के लिए देखें fragattacks.com।

निम्नलिखित अतिरिक्त संसाधन उपलब्ध हैं:

• USENIX Security प्रस्तुति खोजी गई कमज़ोरियों का सारांश देती है।
• सभी निर्धारित CVE का अवलोकन उपलब्ध है।
• प्रत्येक कमज़ोरी के मूल कारण और प्रभाव का सारांश देने वाली स्लाइड्स।
• परिणामी हमलों और पूर्वशर्तों का 2-पृष्ठ सारांश।
• अतिरिक्त पृष्ठभूमि देने और कमज़ोरियों को अधिक विस्तार से समझाने वाले हैंडआउट।
• तीन उदाहरण हमलों का प्रदर्शन।
• USENIX Security में प्रकाशित शोध पेपर।
• कुछ कमज़ोरियों को दर्शाने वाले उदाहरण नेटवर्क कैप्चर।
• इस टूल और संशोधित ड्राइवरों के साथ पहले से स्थापित एक लाइव USB इमेज।
• कंपनियों से ज्ञात एडवाइज़रीज़ की सूची

अगस्त 2020 से अब तक टूल में किए गए अपडेट्स की विस्तृत जानकारी के लिए चेंज लॉग देखें। इस चेंज लॉग में यह भी जानकारी है कि FragAttacks टूल hostap के किस संस्करण पर आधारित है।

ध्यान दें कि WPA2 और WPA3 के विरुद्ध हमले समान हैं, क्योंकि उनके CCMP और GCMP एन्क्रिप्शन साइफर समान हैं। पुराने WPA नेटवर्क डिफ़ॉल्ट रूप से एन्क्रिप्शन के लिए TKIP का उपयोग करते हैं, और TKIP के विरुद्ध हमलों की प्रयोज्यता पर पेपर और वेबसाइट पर चर्चा की गई है। यह दर्शाने के लिए कि वाई-फ़ाई अपनी शुरुआत से ही कमज़ोर रहा है, पेपर और वेबसाइट WEP के विरुद्ध हमलों की प्रयोज्यता पर भी संक्षेप में चर्चा करते हैं।

2. समर्थित नेटवर्क कार्ड

केवल विशिष्ट वायरलेस नेटवर्क कार्ड समर्थित हैं। इसका कारण यह है कि कुछ नेटवर्क कार्ड इंजेक्ट किए गए फ़्रेमों का सीक्वेंस या फ़्रैगमेंट नंबर अधिलेखित कर सकते हैं, या विभिन्न प्राथमिकता वाले फ़्रेमों को पुनः क्रमबद्ध कर सकते हैं, और यह परीक्षण टूल में हस्तक्षेप करता है (अर्थात् टूल किसी डिवाइस को सुरक्षित बता सकता है, जबकि वह सुरक्षित नहीं है)। मैंने पुष्टि की है कि निम्नलिखित नेटवर्क कार्ड ठीक से काम करते हैं:

अंतिम दो कॉलम निम्न को दर्शाते हैं:

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" चुनें, और फिर "Ubuntu, with Linux 5.8.0-63-generic" चुनकर कर्नेल 5.8 प्रारंभ करें। आप अपना 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
# Note: on Kali linux use the package firmware-atheros instead of 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
# Now reboot

./install.sh स्क्रिप्ट मानती है कि ath9k_htc फ़र्मवेयर इमेज /lib/firmware/ath9k_htc निर्देशिका में स्थित हैं। यदि आपके सिस्टम पर ऐसा नहीं है, तो आपको htc_7010.fw और htc_9271.fw को उचित निर्देशिका में मैन्युअल रूप से कॉपी करना होगा।

पैच किए गए ड्राइवर और फ़र्मवेयर स्थापित करने के बाद आपको अपने वाई-फ़ाई डोंगलों को अनप्लग करना होगा और अपने सिस्टम को रीबूट करना होगा। यदि आपका Linux कर्नेल अपडेट होता है या पैच किए गए ड्राइवर अपडेट होते हैं, तो उपरोक्त निर्देशों को फिर से निष्पादित करना होगा।

ध्यान दें कि भले ही आपका डिवाइस बिना किसी बदलाव के काम करता हो, फिर भी मैं संशोधित ड्राइवर स्थापित करने की सलाह देता हूँ, क्योंकि यह सुनिश्चित करता है कि कर्नेल और ड्राइवर कोड में कोई अप्रत्याशित रिग्रेशन न हो।

यदि आप संशोधित ड्राइवर/फ़र्मवेयर को मूल रूप से स्थापित नहीं कर सकते हैं, तो आप लाइव USB इमेज डाउनलोड कर सकते हैं, जिसमें संशोधित ड्राइवर/फ़र्मवेयर के साथ हमारा परीक्षण टूल पहले से स्थापित है। वैकल्पिक रूप से, आप USB नेटवर्क कार्ड वाली वर्चुअल मशीन का उपयोग कर सकते हैं, हालाँकि मैंने पाया कि व्यवहार में वर्चुअल मशीन का उपयोग कम विश्वसनीय है।

5. हर उपयोग से पहले

जब भी आप परीक्षण टूल का उपयोग करना चाहें, आपको पहले वर्चुअल python वातावरण को रूट के रूप में लोड करना होगा। यह निम्न का उपयोग करके किया जा सकता है:

cd research
sudo su
source venv/bin/activate

अब आपको अपने नेटवर्क मैनेजर में वाई-फ़ाई अक्षम कर देना चाहिए ताकि यह परीक्षण टूल में हस्तक्षेप न करे। यह भी सुनिश्चित करें कि कोई अन्य नेटवर्क सेवाएँ बाहर जाने वाला ट्रैफ़िक उत्पन्न नहीं कर रही हैं। आप ./droptraffic.sh निष्पादित करके iptables के माध्यम से ट्रैफ़िक को ब्लॉक करके इसकी पुष्टि कर सकते हैं (आप रीबूट करके इसे वापस बदल सकते हैं)। वैकल्पिक रूप से, यह देखने के लिए sudo airmon-ng check का उपयोग करके जाँच करें कि कौन सी अन्य प्रक्रियाएँ वायरलेस नेटवर्क कार्ड का उपयोग कर रही हैं और हमारे टूल में हस्तक्षेप कर सकती हैं।

परीक्षण टूल क्लाइंट और AP दोनों का परीक्षण कर सकता है:

• AP का परीक्षण: research/client.conf को संपादित करके उस AP को कॉन्फ़िगर करें जिसका आप परीक्षण करना चाहते हैं। यह एक मानक wpa_supplicant कॉन्फ़िगरेशन फ़ाइल है, इसके द्वारा समर्थित सभी विकल्पों का अवलोकन hostap दस्तावेज़ीकरण में देखें।

• क्लाइंट का परीक्षण: आपको परीक्षण टूल को --ap पैरामीटर के साथ निष्पादित करना होगा (नीचे देखें)। यह टूल को नाम testnetwork और पासवर्ड abcdefgh के साथ एक AP बनाने का निर्देश देता है। अपने परीक्षण किए जाने वाले क्लाइंट के साथ इस नेटवर्क से कनेक्ट करें। डिफ़ॉल्ट रूप से क्लाइंट को DHCP का उपयोग करके IP का अनुरोध करना चाहिए। बनाए गए AP के गुणों को संपादित करने के लिए, जैसे कि यह किस चैनल पर बनाया गया है, आप research/hostapd.conf संपादित कर सकते हैं।

6. इंटरफ़ेस मोड

6.1. मिक्स्ड मोड

इस मोड के लिए केवल एक वायरलेस नेटवर्क कार्ड की आवश्यकता होती है, लेकिन सामान्यतः एक पैच किया गया ड्राइवर और/या फ़र्मवेयर आवश्यक होता है। पैच किए गए ड्राइवर/फ़र्मवेयर को स्थापित करने के तरीके के लिए पैच किए गए ड्राइवर देखें, और संगत नेटवर्क कार्डों के लिए समर्थित नेटवर्क कार्ड देखें। इस मोड में परीक्षण टूल को निम्न का उपयोग करके निष्पादित करें:

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

$COMMAND के संभावित मान कमज़ोरियों के लिए परीक्षण और विस्तारित कमज़ोरी परीक्षण में सूचीबद्ध हैं।

इस मोड का एक लाभ यह है कि यह उन क्लाइंटों का परीक्षण करते समय काफी अच्छी तरह काम करता है जो स्लीप अवस्था में जा सकते हैं। फिर भी, यदि संभव हो, तो मैं परीक्षण किए जा रहे क्लाइंट की स्लीप कार्यक्षमता को अक्षम करने की सलाह देता हूँ, देखें स्लीप मोड को संभालना।

6.2. इंजेक्शन मोड

इस मोड के लिए दो वायरलेस नेटवर्क कार्डों की आवश्यकता होती है: एक AP या क्लाइंट के रूप में कार्य करेगा, और दूसरे का उपयोग फ़्रेम इंजेक्ट करने के लिए किया जाएगा। लाभ यह है कि यह मोड पैच किए गए ड्राइवरों की आवश्यकता के बिना काम कर सकता है। इस मोड में परीक्षण टूल को निम्न का उपयोग करके निष्पादित करें:

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

यहाँ इंटरफ़ेस wlan0 एक वैध क्लाइंट या AP के रूप में कार्य करेगा, और wlan1 का उपयोग फ़्रेम इंजेक्ट करने के लिए किया जाएगा। wlan0 के लिए, कोई भी कार्ड उपयोग किया जा सकता है जो Linux पर सामान्य क्लाइंट या AP मोड का समर्थन करता है। wlan1 के लिए, ऐसे कार्ड का उपयोग करना चाहिए जो समर्थित नेटवर्क कार्ड के अनुसार इंजेक्शन मोड का समर्थन करता है।

इस मोड में क्लाइंटों का परीक्षण करते समय, इंजेक्ट किए गए फ़्रेम तब भेजे जा सकते हैं जब क्लाइंट स्लीप अवस्था में हो। इससे हमले विफल हो जाते हैं, इसलिए आपको यह सुनिश्चित करना होगा कि क्लाइंट स्लीप अवस्था में प्रवेश न करे।

6.3. Hwsim मोड

यह मोड प्रयोगात्मक है और केवल शोध उद्देश्यों के लिए है। अधिक जानकारी के लिए hwsim मोड विवरण देखें।

7. कमज़ोरियों के लिए परीक्षण

आप इंटरफ़ेस मोड में चर्चा के अनुसार परीक्षण टूल चलाकर और $COMMAND को नीचे दी गई तालिका के किसी एक कमांड से बदलकर डिवाइसों का परीक्षण कर सकते हैं। हम मानते हैं कि क्लाइंट DHCP का उपयोग करके IP का अनुरोध करेंगे (यदि ऐसा नहीं है तो स्थिर IP कॉन्फ़िगरेशन देखें)। जब तक अन्यथा न कहा गया हो, सभी कमांड क्लाइंट और AP दोनों के विरुद्ध काम करते हैं।

यदि डिवाइस दिए गए $COMMAND के अनुरूप हमले के प्रति कमज़ोर है, तो टूल TEST COMPLETED SUCCESSFULLY आउटपुट करता है, और यदि डिवाइस कमज़ोर नहीं है, तो Test timed out! Retry to be sure, or manually check result आउटपुट करता है। परीक्षण पूरा होने के बाद आप CTRL+C का उपयोग करके परीक्षण टूल को बंद कर सकते हैं। अधिकांश हमलों के कई हल्के भिन्न रूप होते हैं, जिन्हें विभिन्न $COMMAND मानों द्वारा दर्शाया जाता है।

कुछ परीक्षणों के परिणाम को सत्यापित करने के लिए परीक्षण के तहत डिवाइस पर tcpdump या wireshark चलाने की आवश्यकता होती है (नीचे दी गई तालिका बताती है कि क्या tcpdump का उपयोग करना है)। इस tcpdump पैकेट कैप्चर में केवल वे पैकेट शामिल होने चाहिए जो PHY और MAC परत प्रसंस्करण को पार कर चुके हैं। उदाहरण के लिए, Linux पर यह कैप्चर तब बनाई जानी चाहिए जब वायरलेस इंटरफ़ेस "managed" या "ap" मोड में हो, न कि monitor मोड में, जिसका अर्थ है कि कैप्चर में केवल वे पैकेट होंगे जो वाई-फ़ाई परत पर प्रसंस्करण को पार कर चुके हैं। कुछ परीक्षणों को AP पर tcpdump चलाए बिना भी कैसे किया जा सकता है, इसकी चर्चा के लिए AP पर tcpdump से बचना देखें।

अपने परीक्षण सेटअप को सत्यापित करने के लिए, नीचे दी गई तालिका का पहला कमांड एक सामान्य ping भेजता है जो सफल होना चाहिए। दूसरा कमांड ping को दो विखंडित वाई-फ़ाई फ़्रेमों के रूप में भेजता है, और केवल उस दुर्लभ स्थिति में विफल होना चाहिए जब परीक्षण किया गया डिवाइस विखंडन का समर्थन नहीं करता है। यदि इनमें से कोई परीक्षण काम नहीं कर रहा है, तो यह सुनिश्चित करने के लिए नेटवर्क कार्ड इंजेक्शन परीक्षण के निर्देशों का पालन करें कि आपका नेटवर्क कार्ड फ़्रेमों को सही ढंग से इंजेक्ट कर रहा है। यदि परीक्षण किया जा रहा क्लाइंट स्लीप मोड में प्रवेश कर सकता है, तो स्लीप मोड को संभालना देखें।

तीसरे, चौथे और पाँचवें कमांड हमले नहीं हैं, बल्कि किसी डिवाइस के बुनियादी डीफ़्रैगमेंटेशन व्यवहार को सत्यापित करते हैं और तालिका के नीचे आगे चर्चा किए गए हैं।

कमांड किस प्रकार CVE से मेल खाते हैं, यह नीचे सूचीबद्ध है। ध्यान दें कि इम्प्लीमेंटेशन दोषों के लिए हम एक संदर्भ CVE पहचानकर्ता सूचीबद्ध करते हैं, हालाँकि, विक्रेता विभिन्न CVE का उपयोग कर सकते हैं क्योंकि एक इम्प्लीमेंटेशन कमज़ोरी को सामान्यतः प्रत्येक प्रभावित कोडबेस के लिए एक अद्वितीय CVE प्राप्त होता है। फिर भी, हम अनुशंसा करते हैं कि खोजे गए प्रत्येक प्रकार के इम्प्लीमेंटेशन दोष को आसानी से संदर्भित करने के लिए हमेशा इन संदर्भ CVE का उल्लेख करें।

7.1. सैनिटी जाँच

• ping: यह परीक्षण हमेशा सफल होना चाहिए। यदि यह विफल होता है, तो परीक्षण सेटअप में कुछ गड़बड़ है।- ping I,E,E: यह परीक्षण सभी आधुनिक लैपटॉप, स्मार्टफोन और AP पर सफल होना चाहिए। यदि यह विफल हो जाता है, तो संभवतः परीक्षण सेटअप में कुछ गड़बड़ है। समाधान के रूप में --icmp-size 100 पैरामीटर जोड़ने का प्रयास करें। यदि यह इस अतिरिक्त पैरामीटर के साथ काम करता है, तो आपको अन्य सभी परीक्षणों को भी इस अतिरिक्त पैरामीटर के साथ चलाना होगा। मुझे केवल तभी इस परीक्षण को वैध कारणों से विफल होते देखा है जब परीक्षण किया जा रहा डिवाइस खंडित (fragmented) फ्रेम प्राप्त करने का समर्थन नहीं करता, जो हल्के IoT डिवाइस और, उदाहरण के लिए, OpenBSD पर हो सकता है।

7.2. बुनियादी डिवाइस व्यवहार

• ping I,E,E --delay 5: यह परीक्षण दो खंडों के बीच स्वीकार्य अधिकतम देरी की जाँच करने के लिए उपयोग किया जाता है। यदि यह परीक्षण काम नहीं करता है, तो इसे --delay 1.5 या उससे कम के साथ पुनः प्रयास करें। उदाहरण के लिए, Linux 2 सेकंड के बाद खंडों को मेमोरी से हटा देता है, जिसका अर्थ है कि 1.8 की देरी काम करेगी जबकि 2.2 के परिणामस्वरूप कोई उत्तर नहीं मिलेगा। यदि स्वीकार्य अधिकतम देरी कम है, तो अन्य परीक्षणों में भेजे गए सभी खंडों को इस अधिकतम स्वीकार्य देरी के भीतर भेजा जाना चाहिए। अन्यथा, परीक्षण तुच्छ रूप से विफल हो जाएंगे और आप यह निष्कर्ष निकाल सकते हैं कि कोई डिवाइस किसी हमले के प्रति संवेदनशील नहीं है, जबकि वास्तव में वह है।

• ping-frag-sep: यह परीक्षण एक खंडित Wi-Fi फ्रेम भेजता है जो एक असंबंधित फ्रेम द्वारा अलग किया जाता है। अर्थात्, यह पहला खंड भेजता है, फिर एक (सामान्य) असंबंधित Wi-Fi फ्रेम, और अंत में दूसरा खंड। यदि यह परीक्षण विफल हो जाता है, तो (डिफ़ॉल्ट) मिश्रित कुंजी हमला (mixed key attack) और कैश हमला (cache attack) भी संभवतः विफल हो जाएंगे (क्योंकि उन्हें दो खंडों के बीच अन्य फ्रेम भेजने की आवश्यकता होती है)। यह परीक्षण तब भी विफल होगा जब रिसीवर जाँचता है कि खंडों के पैकेट नंबर क्रमागत हैं या नहीं (अगला परीक्षण ping-frag-sep --pn-per-qos देखें)।

• ping-frag-sep --pn-per-qos: उपरोक्त के समान, लेकिन --pn-per-qos पैरामीटर जोड़ने से यह सुनिश्चित होता है कि ping अनुरोध के दोनों खंडों में क्रमागत पैकेट नंबर (Packet Number - PN) हैं। सुरक्षित होने के लिए एक रिसीवर को यह सत्यापित करना चाहिए। दुर्भाग्य से, हमारे परिणामों के प्रकटीकरण से पहले, कई कार्यान्वयन यह सत्यापित नहीं करते कि PN क्रमागत हैं। यह परीक्षण तब विफल हो सकता है जब रिसीवर प्रति QoS TID नवीनतम प्राप्त पैकेट काउंटर को ट्रैक नहीं करता है, ऐसी स्थिति में आप --pn-per-qos पैरामीटर वाले अन्य परीक्षणों को अनदेखा कर सकते हैं।

7.3. A-MSDU हमले परीक्षण (§3 -- CVE-2020-24588)

परीक्षण ping I,E --amsdu जाँचता है कि कोई कार्यान्वयन गैर-SPP A-MSDU का समर्थन करता है या नहीं (यह जाँच नहीं करता कि डिवाइस CVE-2020-24588 के प्रति संवेदनशील है या नहीं)। हमलों को रोकने के लिए, आदर्श रूप से नेटवर्क को SPP A-MSDU के उपयोग को अनिवार्य करना चाहिए और सभी गैर-SPP A-MSDU को हटा देना चाहिए। हालाँकि, अधिकांश विक्रेता वर्तमान में इसके बजाय तदर्थ (ad-hoc) शमन उपाय लागू कर रहे हैं (पेपर की धारा 7.2 देखें)। इस कारण से, आपको यह जाँचने के लिए निम्नलिखित दो परीक्षणों का उपयोग करना चाहिए कि कोई डिवाइस एकत्रीकरण (A-MSDU) हमलों (CVE-2020-24588) के प्रति संवेदनशील है या नहीं:

• amsdu-inject: यह परीक्षण पेपर की धारा 3.2 में वर्णित A-MSDU इंजेक्शन हमले का अनुकरण करता है। विशेष रूप से, यह एक A-MSDU फ्रेम भेजता है जिसकी शुरुआत एक वैध LLC/SNAP हेडर भी है (क्योंकि हमारे संदर्भ हमले में भी ऐसा ही होता है)। यदि यह परीक्षण सफल होता है, तो डिवाइस CVE-2020-24588 के प्रति संवेदनशील है।

• amsdu-inject-bad: कुछ डिवाइस वैध LLC/SNAP हेडर से शुरू होने वाले A-MSDU फ्रेम को गलत तरीके से पार्स करते हैं, जिससे उपरोक्त परीक्षण विफल हो जाता है। ऐसी स्थिति में इसके बजाय amsdu-inject-bad आज़माएँ (पेपर की धारा 3.6 देखें)। ध्यान दें कि यदि यह परीक्षण सफल होता है, तो हमले का प्रभाव उन कार्यान्वयनों के समान ही होता है जो ऐसे फ्रेम को सही ढंग से पार्स करते हैं, जिसका अर्थ है कि डिवाइस CVE-2020-24588 के प्रति संवेदनशील है।

7.4. मिश्रित कुंजी हमले परीक्षण (§4 -- CVE-2020-24587)

• किसी AP के विरुद्ध मिश्रित कुंजी परीक्षण चलाते समय, AP को एक नया 4-way handshake निष्पादित करके नियमित रूप से (जैसे हर मिनट) सत्र कुंजी (PTK) को नवीनीकृत करने के लिए कॉन्फ़िगर किया जाना चाहिए। टूल इस PTK rekey handshake की प्रतीक्षा करते समय Client cannot force rekey. Waiting on AP to start PTK rekey प्रदर्शित करेगा। कम संख्या में AP के विरुद्ध, परीक्षण टूल --rekey-req पैरामीटर जोड़कर PTK को नवीनीकृत करने का अनुरोध भी कर सकता है, जिसका अर्थ है कि AP को समय-समय पर कुंजी नवीनीकृत करने के लिए कॉन्फ़िगर करने की आवश्यकता नहीं है।

• कुछ AP को सत्र कुंजी (PTK) को नियमित रूप से नवीनीकृत करने के लिए कॉन्फ़िगर नहीं किया जा सकता। ऐसे AP के विरुद्ध आप इसके बजाय कैश हमला परीक्षण आज़मा सकते हैं। यदि AP कैश हमलों के प्रति संवेदनशील है, तो यह संभवतः मिश्रित कुंजी हमलों के प्रति भी संवेदनशील है (जब तक कि इसके विपरीत स्पष्ट प्रमाण न हों, जैसे कि कोड ऑडिट यह संकेत देता है कि मिश्रित कुंजी हमलों को रोका गया है)। यदि AP कैश हमलों के प्रति संवेदनशील नहीं है, तो हम मिश्रित कुंजी हमलों के प्रति इसकी संवेदनशीलता के बारे में कुछ नहीं कह सकते, और ऐसी स्थिति में मैं इसके बजाय कोड ऑडिट करने की सलाह देता हूँ।

• ping I,F,BE,AE --pn-per-qos: अतिरिक्त --pn-per-qos पैरामीटर सुनिश्चित करता है कि दोनों इंजेक्ट किए गए खंडों में क्रमागत पैकेट नंबर हैं, जो कुछ डिवाइसों (जैसे Linux) के विरुद्ध मिश्रित कुंजी हमले को सफल होने के लिए आवश्यक है।

• कई डिवाइस 4-way handshake को अलग तरह से लागू करते हैं और यह प्रभावित करेगा कि ये परीक्षण सफल होंगे या नहीं। यदि परीक्षण विफल हो जाते हैं, तो विस्तारित भेद्यता परीक्षण में सूचीबद्ध मिश्रित कुंजी हमले परीक्षणों को भी करने की सिफारिश की जाती है।

7.5. कैश हमले परीक्षण (§5 -- CVE-2020-24586)

• किसी AP का परीक्षण करते समय, टूल पहला खंड भेजता है, फिर AP के साथ पुनः संबद्ध (reassociate) होने का प्रयास करता है, और अंत में दूसरा खंड भेजता है। हालाँकि, सभी AP पुनः संबद्धता (reassociation) प्रक्रिया का ठीक से समर्थन नहीं करते। ऐसी स्थिति में, तालिका में दिखाए अनुसार --full-reconnect विकल्प जोड़ें, जो परीक्षण टूल को पहला खंड भेजने के बाद डी-प्रमाणीकृत (deauthenticate) करने के लिए प्रेरित करता है।

• किसी क्लाइंट का परीक्षण करते समय, टूल पहला खंड भेजता है, क्लाइंट को डिस-संबद्ध (disassociate) करता है, और क्लाइंट के पुनः कनेक्ट होने के बाद दूसरा खंड भेजेगा। आदर्श रूप से क्लाइंट डिस-संबद्धता फ्रेम भेजने के तुरंत बाद पुनः कनेक्ट होगा। इसके लिए परीक्षण किए जा रहे क्लाइंट में अन्य सभी नेटवर्क को अक्षम करने की आवश्यकता हो सकती है। मैंने यह भी पाया कि कुछ क्लाइंट डिस-संबद्धता (disassociation) को ठीक से संभालते नहीं दिखते, और ऐसी स्थिति में आप तालिका में दिखाए अनुसार --full-reconnect विकल्प जोड़कर इसके बजाय एक डी-प्रमाणीकरण (deauthentication) फ्रेम भेज सकते हैं।

• मैंने पाया है कि प्रत्येक कैश हमला परीक्षण को कई बार निष्पादित करना सर्वोत्तम है। कभी-कभी कैश हमला परीक्षण विफल हो सकता है, हालाँकि कार्यान्वयन संवेदनशील होता है। यह पृष्ठभूमि शोर, अन्य डिवाइसों द्वारा परीक्षण किए जा रहे डिवाइस को फ्रेम भेजने आदि के कारण हो सकता है।

• ping I,E,R,AE [--full-recon]: यहाँ दूसरा खंड परीक्षण के तहत डिवाइस के साथ पुनः कनेक्ट होने के तुरंत बाद भेजा जाता है, जो महत्वपूर्ण है यदि डिवाइस थोड़े समय बाद खंडों को मेमोरी से हटा देता है। ध्यान दें कि full-recon, full-reconnect का संक्षिप्त रूप है।

• ping I,E,R,E [--full-recon]: यहाँ दूसरा खंड परीक्षण के तहत डिवाइस के साथ पुनः कनेक्ट होने के 1 सेकंड बाद भेजा जाता है, जो उपयोगी हो सकता है यदि handshake पूरा होने और बातचीत की गई कुंजी स्थापित करने के बीच थोड़ी देरी हो।

7.6. गैर-क्रमागत PN हमला (§6.2 -- CVE-2020-26146)

हमारे प्रयोगों में, यह परीक्षण केवल Linux और उन डिवाइसों के विरुद्ध विफल हुआ जो फ्रेमेंटेशन (fragmentation) का समर्थन नहीं करते।

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)

निम्नलिखित दो परीक्षण ब्रॉडकास्ट फ्रेम भेजते हैं, जो स्वचालित रूप से पुनः प्रसारित नहीं होते, और इसलिए उन्हें कई बार निष्पादित करने की सिफारिश की जाती है। ऐसा इसलिए है क्योंकि पृष्ठभूमि शोर परीक्षण किए जा रहे डिवाइसों को इंजेक्ट किए गए ब्रॉडकास्ट फ्रेम को प्राप्त करने से रोक सकता है। मेरे प्रयोगों में, मुख्य रूप से क्लाइंट प्रभावित हुए (परीक्षण किए गए AP में से केवल Free/NetBSD वाले प्रभावित हुए)।

• ping I,D,P --bcast-ra: कनेक्ट होने के बाद एक प्लेनटेक्स्ट ब्रॉडकास्टेड दूसरे खंड में यूनिकास्ट ping भेजें। हमले के इस प्रकार का परिणाम परीक्षण टूल द्वारा स्वचालित रूप से जाँचा जाता है।

• ping D,BP --bcast-ra: यहाँ उपरोक्त फ्रेम नेटवर्क से कनेक्ट होते समय (अर्थात 4-way handshake के दौरान) भेजा जाता है। यह महत्वपूर्ण है क्योंकि कई क्लाइंट और AP केवल 4-way handshake पूरा करने से पहले संवेदनशील होते हैं। इस परीक्षण के परिणाम की पुष्टि करने के लिए आपको पीड़ित (victim) पर wireshark या tcpdump चलाना होगा, और निगरानी करनी होगी कि इंजेक्ट किया गया ping अनुरोध पीड़ित द्वारा प्राप्त हुआ या नहीं। tcpdump में आप icmp फ़िल्टर का उपयोग कर सकते हैं और wireshark में आप इस ping अनुरोध को अधिक आसानी से पहचानने के लिए frame contains "test_ping_icmp" फ़िल्टर का भी उपयोग कर सकते हैं। मेरे प्रयोगों में मुख्य रूप से क्लाइंट प्रभावित हुए।

7.9. A-MSDU EAPOL हमले परीक्षण (§6.5 -- CVE-2020-26144)

• eapol-amsdu I,P: यह पेपर की धारा 6.5 में चर्चा की गई कार्यान्वयन-विशिष्ट भेद्यता के लिए मानक परीक्षण है। क्लाइंट और AP दोनों संवेदनशील हो सकते हैं। इसका परिणाम परीक्षण टूल द्वारा स्वचालित रूप से जाँचा जाता है।

• BP पर समाप्त होने वाले परीक्षण (eapol-amsdu BP और eapol-amsdu-bad BP): ये परीक्षण 4-way handshake के निष्पादन के दौरान दुर्भावनापूर्ण फ्रेम इंजेक्ट करते हैं। इस परीक्षण के परिणाम की पुष्टि करने के लिए आपको पीड़ित पर wireshark या tcpdump चलाना होगा, और निगरानी करनी होगी कि इंजेक्ट किया गया ping अनुरोध पीड़ित द्वारा प्राप्त हुआ या नहीं। tcpdump में आप icmp फ़िल्टर का उपयोग कर सकते हैं और wireshark में आप इस ping अनुरोध को अधिक आसानी से पहचानने के लिए frame contains "test_ping_icmp" फ़िल्टर का भी उपयोग कर सकते हैं।

• eapol-amsdu-bad से शुरू होने वाले परीक्षण (eapol-amsdu-bad BP और eapol-amsdu-bad I,P): कई कार्यान्वयन A-MSDU फ्रेम को गलत तरीके से संसाधित करते हैं जिनके पहले 6 बाइट EAPOL के लिए एक वैध RFC1042 हेडर के बराबर भी होते हैं। इन कार्यान्वयनों का परीक्षण करने के लिए, आपको eapol-amsdu-bad परीक्षण संस्करण का उपयोग करना होगा। ध्यान दें कि यदि यह परीक्षण सफल होता है, तो हमले का प्रभाव उन कार्यान्वयनों के समान होता है जो ऐसे फ्रेम को सही ढंग से पार्स करते हैं (विवरण के लिए पेपर की धारा 3.6 और 6.6 देखें)।

7.10. समस्या निवारण जाँच-सूची

यदि परीक्षण टूल काम नहीं कर रहा प्रतीत होता है, तो निम्नलिखित जाँचें:

1. जाँचें कि कोई अन्य प्रक्रिया नेटवर्क कार्ड का उपयोग नहीं कर रही है (जैसे अपने नेटवर्क मैनेजर को बंद करें)।

2. यदि पहले सब कुछ काम करता था, तो अपना Wi-Fi डोंगल निकालकर पुनः लगाने का प्रयास करें, अपने कंप्यूटर या वर्चुअल मशीन को पुनः आरंभ करें, और फिर पुनः प्रयास करें। साथ ही disable-hwcrypto.sh स्क्रिप्ट का उपयोग करके हार्डवेयर एन्क्रिप्शन को अक्षम करने का प्रयास करें (इस स्क्रिप्ट को निष्पादित करने के बाद अपने कंप्यूटर को रीबूट करें)।

3. सुनिश्चित करें कि आप जिस डिवाइस का परीक्षण कर रहे हैं वह स्लीप अवस्था में न जाए (जिससे वह इंजेक्ट किए गए फ्रेम को मिस कर सकता है)। मैं परीक्षण टूल को मिश्रित मोड में चलाने की सिफारिश करता हूँ क्योंकि यह स्लीप अवस्था में जाने वाले क्लाइंटों को बेहतर ढंग से संभालता है।

4. यह सुनिश्चित करने के लिए इंजेक्शन परीक्षण चलाएँ कि इंजेक्शन ठीक से काम कर रहा है। यह भी सुनिश्चित करें कि 20 MHz चैनल का उपयोग किया गया है, अन्य चैनलों पर इंजेक्शन का परीक्षण नहीं किया गया है।

5. जाँचें कि आपकी मशीन पृष्ठभूमि ट्रैफ़िक उत्पन्न नहीं कर रही है जो परीक्षणों में हस्तक्षेप करता है। विशेष रूप से, अपने OS में नेटवर्किंग अक्षम करें, अपने DHCP क्लाइंट/सर्वर को मैन्युअल रूप से बंद करें, आदि। हर उपयोग से पहले भी देखें।

6. पुष्टि करें कि आप सही नेटवर्क से कनेक्ट हो रहे हैं। client.conf की दोबारा जाँच करें।

7. सुनिश्चित करें कि परीक्षण किया जा रहा AP एन्क्रिप्शन एल्गोरिदम के रूप में (AES-)CCMP का उपयोग कर रहा है। TKIP या GCMP जैसे अन्य एन्क्रिप्शन एल्गोरिदम समर्थित नहीं हैं।

8. यदि आपने git का उपयोग करके कोड को अपडेट किया है, तो ./build.sh और ./pysetup.sh को फिर से निष्पादित करें (पूर्वापेक्षाएँ देखें)। यदि पैच किए गए ड्राइवर अपडेट हुए हैं, तो उन्हें भी पुनः संकलित करना याद रखें।

9. यदि आप वर्चुअल मशीन का उपयोग कर रहे हैं, तो इसके बजाय लाइव USB इमेज से परीक्षण टूल चलाने का प्रयास करें।

10. जाँचें कि परीक्षण किया जा रहा डिवाइस ICMP ping अनुरोधों को ब्लॉक नहीं करता है। यदि यह ping का उत्तर नहीं देता है, तो आप डिवाइस पर tcpdump या wireshark चला सकते हैं, या में सूचीबद्ध अन्य तरीकों में से कोई भी आज़मा सकते हैं।

8. विस्तारित भेद्यता परीक्षण

कार्यान्वयन भिन्नताओं के कारण कुछ भेद्यताओं की पुष्टि/शोषण करना कठिन हो सकता है, विशेष रूप से मिश्रित कुंजी और कैश हमले की व्यवहार में पुष्टि करना गैर-तुच्छ हो सकता है। इसलिए, मैं सिफारिश करता हूँ कि किसी डिवाइस को केवल तभी सुरक्षित मानें जब इन हमलों को रोकने के लिए कोड में स्पष्ट जाँचें हों। इसके अतिरिक्त, यदि समय अनुमति देता है, तो मैं निम्नलिखित अधिक उन्नत परीक्षणों की भी सिफारिश करता हूँ। इनमें नई भेद्यताओं का पता लगाने की संभावना कम होती है, लेकिन ये हमले के ऐसे प्रकार या विशेष डिवाइस व्यवहार प्रकट कर सकते हैं जिन्हें सामान्य परीक्षण पहचान नहीं सकते।

यदि भेद्यताओं के लिए परीक्षण में सामान्य परीक्षणों ने पहले ही किसी विशेष भेद्यता वर्ग की उपस्थिति की पुष्टि कर दी है, तो उस भेद्यता के अन्य हमले प्रकारों का परीक्षण करने की आवश्यकता कम होती है। जब तक अन्यथा नोट न किया जाए, सभी कमांड क्लाइंट और AP दोनों के विरुद्ध काम करते हैं।

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 का अनुरोध किया जा सके। फिर कुछ AP rekey handshake करेंगे। अधिकांश AP अनदेखा करेंगे इस अनुरोध को, और उन्हें स्पष्ट रूप से कॉन्फ़िगर करना होगा कि वे सत्र कुंजी (PTK) को नियमित रूप से नवीनीकृत करें।

परीक्षणों के संबंध में कुछ नोट्स:

• ping I,F,BE,E और ping I,E,F,AE: ये काफी सीधे मिश्रित कुंजी हमले के परीक्षण हैं, जहाँ दोनों फ्रैगमेंट अलग-अलग समय पर इंजेक्ट किए जाते हैं।

• ping I,E,F,AE --rekey-plain: कुछ ड्राइवर (जैसे MediaTek) rekey handshake को प्लेनटेक्स्ट में करेंगे। परीक्षण करने के लिए ऐसे ड्राइवर का उपयोग करने वाले उपकरणों में आपको --rekey-plain पैरामीटर जोड़ना होगा।

• ping I,E,F,AE --rekey-plain --rekey-req: यह विशेष संयोजन उन राउटरों के परीक्षण के लिए उपयोगी है जो MediaTek ड्राइवर का उपयोग करते हैं। ये राउटर rekey handshake को प्लेनटेक्स्ट में करते हैं, और क्लाइंट सक्रिय रूप से rekey handshake का अनुरोध कर सकता है।

• ping I,E,F,AE --rekey-early-install: कम संख्या में क्लाइंट (गलत तरीके से) कुंजी को बहुत जल्दी इंस्टॉल करते हैं pairwise सत्र rekey के दौरान। इन क्लाइंटों का विश्वसनीय रूप से परीक्षण करने के लिए, --rekey-early-install पैरामीटर जोड़ें। यह परीक्षण AP के विरुद्ध अर्थपूर्ण नहीं है।

• ping I,E,F,E [--rekey-pl] [--rekey-req]: यह परीक्षण प्रकार पिछले ping I,E,F,AE * परीक्षणों के समान है, सिवाय इसके कि दूसरा फ्रैगमेंट 4-way handshake के 1 सेकंड बाद भेजा जाता है। यह महत्वपूर्ण हो सकता है क्योंकि कम संख्या में उपकरणों में नई कुंजी इंस्टॉल होने से पहले थोड़ी देरी होती है। ध्यान दें कि एक संक्षिप्त रूप है का।

अंत में, यदि ping-frag-sep परीक्षण सफल नहीं होता है, तो आपको निम्नलिखित मिश्रित कुंजी हमले का परीक्षण आज़माना चाहिए:

• ping I,F,BE,AE --freebsd: यह अनिवार्य रूप से FreeBSD इम्प्लीमेंटेशन के विरुद्ध rekey handshake करता है, या FreeBSD से कोड उधार लेने वाले ड्राइवर के विरुद्ध, बिना डेटा फ्रेमों की defragmentation प्रक्रिया को प्रभावित किए। देखें विवरण के लिए पेपर में परिशिष्ट E।

8.3. कैश हमले के परीक्षण (§5 -- CVE-2020-24586)

• ping I,E,R,AE --freebsd --full-reconnect: इस परीक्षण का उपयोग यह जाँचने के लिए किया जा सकता है कि क्या FreeBSD AP, या एक ड्राइवर जो FreeBSD से कोड उधार लेता है, कैश हमले के प्रति संवेदनशील है। यह परीक्षण कैसे काम करता है, इसके विवरण के लिए पेपर में परिशिष्ट E देखें। आपको इस परीक्षण को बिना --full-reconnect पैरामीटर के भी आज़माना चाहिए। यह परीक्षण क्लाइंटों के विरुद्ध भी काम करता है, लेकिन उनके प्रभावित होने की संभावना कम है।

• ping I,E,R,AP --freebsd --full-reconnect: यह परीक्षण FreeBSD AP या FreeBSD से कोड उधार लेने वाले ड्राइवर के विरुद्ध एक प्रकार है, जो AP से पुनः कनेक्ट करने के बाद दूसरा फ्रैगमेंट प्लेनटेक्स्ट में भेजा जाता है। कुछ के विरुद्ध FreeBSD पर डोंगलों के विरुद्ध यह परीक्षण अधिक विश्वसनीय था और यह साबित करता है कि पुराने फ्रैगमेंट AP की मेमोरी में बाद में बने रहते हैं पुनः कनेक्ट करने पर। आपको इस परीक्षण को बिना --full-reconnect पैरामीटर के भी आज़माना चाहिए। यह परीक्षण क्लाइंटों के विरुद्ध भी काम करता है, लेकिन उनके प्रभावित होने की संभावना कम है।

• ping I,E,R,AP [--full-reconnect]: इस परीक्षण में दूसरा फ्रैगमेंट प्लेनटेक्स्ट में भेजा जाता है। यह उपयोगी हो सकता है यदि परीक्षण किया जा रहा उपकरण 4-way handshake के तुरंत बाद कुंजी इंस्टॉल नहीं करता है। यदि यह परीक्षण सफल होता है, तो यह दर्शाता है कि उपकरण नेटवर्क से (पुनः) कनेक्ट करने के बाद फ्रैगमेंट्स को मेमोरी में रखता है, जिसका अर्थ है कि यह कैश के प्रति संवेदनशील है हमलों के। उपरोक्त दो कमांडों के विपरीत, यह क्लाइंटों (साथ ही AP) के विरुद्ध करने के लिए भी उपयोगी है।

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 handshake के निष्पादन के दौरान) संवेदनशील होते हैं।

• ping I,P --bcast-ra: यह एक प्लेनटेक्स्ट ब्रॉडकास्ट वाई-फाई फ्रेम के अंदर एक यूनिकास्ट ICMP पिंग अनुरोध भेजता है (CVE-2020-26145)। यह परीक्षण क्लाइंट और AP दोनों के विरुद्ध किया जा सकता है।

• ping BP --bcast-ra: उपरोक्त परीक्षण ping I,P --bcast-ra के समान है, लेकिन पिंग क्लाइंट द्वारा नेटवर्क से प्रमाणित होने से पहले भेजा जाता है, अर्थात 4-way handshake के निष्पादन के दौरान (CVE-2020-26145)। आपको tcpdump चलाना होगा या wireshark यह जाँचने के लिए कि क्लाइंट फ्रेम को स्वीकार करता है या नहीं। tcpdump में आप icmp फ़िल्टर का उपयोग कर सकते हैं और wireshark में आप इस पिंग अनुरोध को अधिक आसानी से पहचानने के लिए frame contains "test_ping_icmp" फ़िल्टर का भी उपयोग कर सकते हैं।

• ping BP --bcast-ra --bcast-dst: यह परीक्षण पिछले परीक्षण के समान है, लेकिन तब उपयोगी है जब आप tcpdump नहीं चला सकते लक्षित AP पर। ध्यान दें कि यह परीक्षण केवल AP के विरुद्ध अर्थपूर्ण है। इस परीक्षण में अतिरिक्त --bcast-dst पैरामीटर एक संवेदनशील AP को इंजेक्ट किए गए पिंग अनुरोध को सभी कनेक्टेड क्लाइंटों तक ब्रॉडकास्ट करने का कारण बनता है। दूसरे शब्दों में, यह जाँचने के लिए कि कोई AP संवेदनशील है, इस कमांड को निष्पादित करें, और ऐसे दूसरे उपकरण पर ब्रॉडकास्ट वाई-फाई फ्रेम सुनें जो AP से जुड़ा है, icmp या frame contains "test_ping_icmp" फ़िल्टर का उपयोग करके।

• ping BP [--bcast-dst]: यह उपरोक्त दो परीक्षणों ping BP --bcast-ra [--bcast-dst] का एक प्रकार है, सिवाय इसके कि पिंग अनुरोध अब ब्रॉडकास्ट फ्रेम के बजाय एक प्लेनटेक्स्ट यूनिकास्ट फ्रेम में भेजा जाता है (अभी तक कोई CVE आवंटित नहीं है - यह CVE-2020-26145 से संबंधित है)। यह परीक्षण क्लाइंट और AP दोनों के विरुद्ध किया जाना चाहिए। पिंग क्लाइंट द्वारा प्रमाणित होने से पहले भेजा जाता है नेटवर्क के साथ (अर्थात 4-way handshake के निष्पादन के दौरान), जिसका अर्थ है कि आपको यह जाँचने के लिए tcpdump या wireshark चलाना होगा कि उपकरण इस फ्रेम को स्वीकार करता है या नहीं। वैकल्पिक रूप से, AP का परीक्षण करते समय, आप उपरोक्त परीक्षण के समान --bcast-dst पैरामीटर जोड़ सकते हैं, और फिर AP से जुड़े दूसरे उपकरण पर icmp या frame contains "test_ping_icmp" फ़िल्टर का उपयोग करके tcpdump या wireshark चलाएँ।

• eapfrag BP,BP: यह उपरोक्त ब्रॉडकास्ट फ्रैगमेंट परीक्षणों की एक विशेषज्ञता है, जो क्लाइंट द्वारा प्रमाणित होने से पहले की जाती है। यह लीक हुए कोड के विश्लेषण पर आधारित एक अत्यंत प्रयोगात्मक हमला है। यह पहले एक प्लेनटेक्स्ट फ्रैगमेंट भेजता है जो EAPOL हेडर से शुरू होता है, जिसे स्वीकार कर लिया जाता है क्योंकि 4-way handshake अभी भी निष्पादित हो रहा है। फिर यह समान अनुक्रम संख्या के साथ एक दूसरा ब्रॉडकास्ट फ्रैगमेंट भेजता है। लीक हुए कोड के विश्लेषण के आधार पर, कुछ उपकरण अब स्वीकार कर सकते हैं इस फ्रैगमेंट को (क्योंकि पिछला फ्रैगमेंट अनुमत था), लेकिन बाद का कोड इसे एक सामान्य फ्रेम के रूप में संसाधित करेगा (क्योंकि फ्रैगमेंट ब्रॉडकास्ट किया गया है)। फ्रेम ठीक से प्राप्त हुआ है या नहीं, यह निर्धारित करने के लिए आपको पीड़ित पर tcpdump या wireshark का उपयोग करना होगा , उदाहरण के लिए icmp या frame contains "test_ping_icmp" फ़िल्टर का उपयोग करके। एक वैकल्पिक प्रकार यदि सामान्य प्रकार काम नहीं करता है तो है।

8.6. A-MSDU EAPOL हमले के परीक्षण (§6.5 -- CVE-2020-26144)

इस परीक्षण का उपयोग तब किया जा सकता है जब आप eapol-amsdu[-bad] BP परीक्षणों को निष्पादित करना चाहते हैं लेकिन AP पर tcpdump या wireshark नहीं चला सकते । यह परीक्षण केवल AP के विरुद्ध अर्थपूर्ण है: eapol-amsdu[-bad] BP --bcast-dst कमांड एक संवेदनशील AP को इंजेक्ट किए गए पिंग अनुरोध को सभी कनेक्टेड क्लाइंटों तक ब्रॉडकास्ट करने का कारण बनता है। दूसरे शब्दों में, यह जाँचने के लिए कि कोई AP संवेदनशील है, इस कमांड को निष्पादित करें, और AP से जुड़े दूसरे उपकरण पर icmp या frame contains "test_ping_icmp"` फ़िल्टर का उपयोग करके ब्रॉडकास्ट वाई-फाई फ्रेम सुनें।

8.7. AP द्वारा EAPOL अग्रेषण हमले के परीक्षण (§6.6 -- CVE-2020-26139)

• eapol-inject 00:11:22:33:44:55: यह परीक्षण केवल AP के विरुद्ध अर्थपूर्ण है। इस परीक्षण को करने के लिए आपको कनेक्ट होना होगा दूसरे उपकरण का उपयोग करके नेटवर्क से और MAC पते 00:11:22:33:44:55 को इस दूसरे उपकरण के MAC पते से बदलें । प्रमाणित होने से पहले, परीक्षण उपकरण AP को अंतिम गंतव्य के रूप में इस दूसरे उपकरण के साथ एक EAPOL फ्रेम भेजेगा । यदि AP EAPOL फ्रेम को दूसरे उपकरण तक अग्रेषित करता है, तो AP को संवेदनशील माना जाता है। यह पुष्टि करने के लिए कि AP अग्रेषित करता है या नहीं 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: यदि यह परीक्षण सफल होता है, तो क्लाइंट या AP (डी)फ्रैगमेंटेशन का समर्थन नहीं करता है, लेकिन फिर भी हमलों के प्रति संवेदनशील है। समस्या यह है कि रिसीवर अंतिम फ्रैगमेंट को पूर्ण फ्रेम के रूप में मानता है। विवरण और कैसे के लिए पेपर में अनुभाग 6.8 देखें इसका शोषण किया जा सकता है।

• ping I,E,D: यदि यह परीक्षण सफल होता है, तो क्लाइंट या AP पहले फ्रैगमेंट को पूर्ण फ्रेम के रूप में मानता है। हालाँकि यह व्यवहार आदर्श नहीं है, वर्तमान में यह अज्ञात है कि क्या यह अकेले व्यवहार में शोषित किया जा सकता है।

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 का उपयोग करते हुए। पहला कमांड परीक्षण करता है कि फ्रेम ठीक से इंजेक्ट किए जाते हैं या नहीं, जब उपयोग किया जाता है मिश्रित मोड का उपयोग क्लाइंट के रूप में कार्य करते समय, और दूसरा कमांड मिश्रित मोड का उपयोग करते समय AP के रूप में कार्य करते हुए। परीक्षण शुरू करने के लिए, क्लाइंट को नेटवर्क से कनेक्ट करने में सक्षम होना चाहिए, और AP इंजेक्शन परीक्षण शुरू करने से पहले एक क्लाइंट के कनेक्ट होने की प्रतीक्षा करता है (देखें हर उपयोग से पहले क्लाइंट और AP के कनेक्शन सेटअप को कॉन्फ़िगर करने के लिए)।

यदि आप मिश्रित मोड में 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 का उपयोग करेगा, और यह पीयर को एक पिंग अनुरोध इंजेक्ट करेगा IP पता 192.168.100.1 पर।

जब कोई परीक्षण DHCP का उपयोग करके IP पते प्राप्त करने से पहले IP पैकेट भेजता है, तो यह डिफ़ॉल्ट IP पता 127.0.0.1 का उपयोग करेगा। विभिन्न (डिफ़ॉल्ट) IP पतों का उपयोग करने के लिए, आप --ip और -peerip का भी उपयोग कर सकते हैं पैरामीटर।

9.3. ICMP समर्थन नहीं होना

अधिकांश हमले के परीक्षण विशेष तरीकों से ICMP पिंग अनुरोध भेजकर काम करते हैं, और यह देखते हैं कि क्या हमें ICMP पिंग प्रतिक्रिया मिलती है। यदि परीक्षण किया जा रहा उपकरण ICMP पिंग का समर्थन नहीं करता है, तो आप इसके बजाय सभी परीक्षणों में --arp पैरामीटर जोड़कर ARP अनुरोधों का उपयोग कर सकते हैं। यदि कोई परीक्षण भेजने का समर्थन नहीं करता है ARP अनुरोधों को, उपकरण त्रुटि Cannot override request type of the selected test प्रदर्शित करेगा, ऐसी स्थिति में विशेष परीक्षण केवल ICMP पिंग अनुरोधों का उपयोग करके ही निष्पादित किया जा सकता है।

TODO: क्लाइंट के रूप में कार्य करते समय हम इसके बजाय DHCP अनुरोधों को भी इंजेक्ट कर सकते हैं।

1. वे नेटवर्क कार्ड जो ath9k_htc का उपयोग करते हैं

2. वे नेटवर्क कार्ड जो carl9170 का उपयोग करते हैं

3. वे नेटवर्क कार्ड जो iwlmvm का उपयोग करते हैं।

मैं ath9k_htc पर आधारित कार्डों की अनुशंसा करता हूँ। iwlmvm का उपयोग करने वाले सभी कार्ड संगत नहीं होंगे। जब वैकल्पिक नेटवर्क कार्ड का उपयोग कर रहे हों, तो मैं दृढ़ता से अनुशंसा करता हूँ कि पहले इंजेक्शन परीक्षण चलाएँ यह पुष्टि करने के लिए कि नेटवर्क कार्ड संगत है।

9.5. 5 GHz समर्थन

Read more