基於802.11Fuzz技術的研究
轉自安全客
關於無線的Fuzz最開始接觸了解時，國內基本毛線都搜不到。經過幾個月的資料搜集和學習，將大約全網的fuzz資料整理翻譯分析並讀懂寫下，就為填補國內空白，也希望無線愛好者能多多交流。
在各個安全領域的漏洞挖掘方法中，Fuzz都挺流行的. Fuzz是一種黑盒軟件測試技術，這基本上是使用畸形或半自動化的方式在一個畸形的數據註入發現執行錯誤，運用在協議也比較多。當源代碼是不可用的時候，還是不錯的，在802.11協議方面，Fuzzing的層面也比較多，特別是針對驅動和接入點的。
802.11的 State machine ，802.11標準規定的State machine
這裏有‘State1 ，State2，State3’這三個狀態。它這寫的比較模糊，不太容易懂，翻譯過來有點懵逼。其實這三個State的本意該是：
State1：是用於訪問點的客戶端設備的初始狀態。
State2：是通過對訪問點進行身份驗證的身份驗證狀態。
State3：是一個授權發送接受數據通信幀並通過無線接入點和有線網絡的關聯的狀態轉換過程，然後反饋802.11Frames.
上面都提到了，802.11標準規定狀態機必須在固件或者驅動中實現，許多的驅動管理的狀態為了保證它的運行，都采用例如一個AP接受了Assoc請求後，只包括一個網絡配置名稱，這三個狀態是很重要的，Fuzz的思路就是從這三個State機制中來。
802.11還定義了三種幀類型（就是上面那Class）：
Class1 Frames：允許從State1、2和3探測請求/響應,beacon,身份驗證請求/響應/解除認證
Class2 Frames：只有經過身份驗證,可以從State2和3(重新)Assoc請求/響應/解除關聯
Class3 Frames：只有在Assoc請求下，可以能在State3內解除認證
每個State都可以進行fuzzing，但是第一個肯定是比後兩個容易，因為後面兩個都提到了需要成功認證的協議。
（兩個圖，第一個詳細點，那個能看懂就看那個就行了）
一、Access Points Fuzzing 802.11 的介紹：
1、Fuzzing原理
無線協議裏面，Beacon是802.11裏面的一個重要組成部分，它涵蓋了幾乎所有AP的重要配置信息。
下面舉個ApFuzzing框架的例子，就是通過構建畸形數據包，並將針對Wi-Fi 設備，然後發現已知和未知的漏洞。
Fuzzing802.11接入點，類似於802.11 client的fuzzing。無線客戶端功能由接入點解析
802.11個訪問點棧將解析大量的802.11的數據包：
*Probe request
*Authentication requests
*Association requests
*Crypted and unencrypted data frames
*Control frames
還有一些其他協議接入點可以fuzzing：
WPA/WPA2 handshakes
基於EAP的認證
基於State的Fuzzing
State1進行成功的身份驗證請求
State2 進行成功的關聯請求
State3是基於認證成功的密鑰交換
2.Fuzzing 舉例
Scapy是一個開放源代碼的網絡編程語言，它是基於Python，可以重放數據，捕獲分析，產生隨機數據包。可以根據自己的測試需求去改變，好像好多東西都需要它的支持，用處挺大的。有人基於Scapy寫了一個叫做wifuzz的工具，寫的接入點挺全的，能夠fuzz出一些堆棧錯誤或者Crash，支持的接入點：
我選了個auth 模式的FUZZ，它會將FUZZ出來的的數據保存到一個路徑下供我們查看。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$ sudo python wifuzz.py -s fuzztest auth
Thur Sep 26 21:41:36 2016 {MAIN} Target SSID: fuzztest; Interface: wlan0; Ping timeout:
60;PCAP directory: /dev/shm; Test mode? False; Fuzzer(s): auth;
Thur Sep 26 21:41:36 2016 {WIFI} Waiting for a beacon from SSID=[fuzztest] Thur Sep 26 21:41:36 2016 {WIFI} Beacon from SSID=[fuzztest] found (MAC=[11:22:33:44:55:66])
Thur Sep 26 21:41:36 2016 {WIFI} Starting fuzz ‘auth‘
Thur Sep 26 21:41:36 2016 {WIFI} [R00001] Sending packets 1-100
Thur Sep 26 21:41:50 2016 {WIFI} [R00001] Checking if the AP is still up...
Thur Sep 26 21:41:50 2016 {WIFI} Waiting for a beacon from SSID=[fuzztest] Thur Sep 26 21:41:50 2016 {WIFI} Beacon from SSID=[fuzztest] found (MAC=[11:22:33:44:55:66])
Thur Sep 26 21:41:50 2016 {WIFI} [R00002] Sending packets 101-200 Thur Sep 26 21:42:04 2016 {WIFI} [R00002] Checking if the AP is still up...
Thur Sep 26 21:42:04 2016 {WIFI} Waiting for a beacon from SSID=[fuzztest]
Thur Sep 26 21:42:04 2016 {WIFI} Beacon from SSID=[fuzztest] found (MAC=[11:22:33:44:55:66])
Thur Sep 26 21:42:04 2016 {WIFI} [R00003] Sending packets 201-300 Thur Sep 26 21:42:18 2016 {WIFI} [R00003] Checking if the AP is still up...
Thur Sep 26 21:42:18 2016 {WIFI} Waiting for a beacon from SSID=[fuzztest] Thur Sep 26 21:42:19 2016 {WIFI} Beacon from SSID=[fuzztest] found (MAC=[11:22:33:44:55:66])
Thur Sep 26 21:42:19 2016 {WIFI} [R00004] Sending packets 301-400
Thur Sep 26 21:42:42 2016 {WIFI} [R00004] recv() timeout exceeded! (packet #325) Thur Sep 26 21:42:42 2016 {WIFI} [R00004] Checking if the AP is still up...
Thur Sep 26 21:42:42 2016 {WIFI} Waiting for a beacon from SSID=[fuzztest]
Thur Sep 26 10:40:42 2016 {WIFI} [!] The AP does not respond anymore. Latest test-case has been written to ‘/dev/shm/wifuzz-69erb.pcap‘
|
再來個Beacon的內容配置：
在Metasploit中呢，有一個專門用於fuzz Beacon的模塊，不過要自己安裝Lorcon2這個無線註入模塊。https://github.com/gitpan/Net-Lorcon2 安裝後要配置好環境變量，這時候容易出錯，細心點就行了。
因為是 Beacon這個接入點的FUZZ，那麽它會產生無規則信息。
這就是個簡單的舉例，大家讀懂了協議，Fuzzer都可以自己來。
二、基於802.11 Driver 的Fuzzing
關於802.11協議標準的深入解析
（1）802.11擴展有點復雜的...
幾種幀類型（管理，數據，控制）大量的信令
速率，信道，網絡名稱，密碼
所有這些東西都必須由固件/驅動程序解析
單獨的針對驅動進行閉源驅動、逆向，開源驅動，黑白審計什麽的，會很難....也很費勁，所以，Fuzz是一種很不錯的選擇
（2）Madwifi：是個Linux下的無線驅動，例如Atheros芯片驅動（沒搞過無線的應該不知道不同芯片之間有啥區別，google一下就行了）
（3）802.11芯片提供了幾種模式的操作用處：
監聽802.11層
作為AP接入點
作為一個Ad-Hoc網絡
作為一個Station
（4）802.11一共有兩個掃描技術（主動與被動）
主動掃描：發送探測請求，並監聽探測響應
被動掃描：監聽Beacon和信道跳躍
（驅動可以監聽Beacon和探測的響應數據。）
（5）802.11的掃描技術（主動與被動）
主動掃描：發送探測請求，並監聽探測響應
被動掃描：監聽Beacon和信道跳躍
驅動可以監聽Beacon和探測的響應數據
1、Fuzzing原理及Fuzzer
關於information elements
信息元素是management frames.中的必要字段，信息元素是由類型、長度和值組成的。
信息元素由一個8位的類型字段，一個8位的長度字段，和多達255個字節的數據。 這種類型的結構是非常類似於在許多不同的協議中使用的普通類型-長度-值（TLV）形式。 信標和探測響應分組必須包含一個SSID 信息元素，對於大多數無線客戶端處理數據包。一個支持信息元素值和信道信息元素。
拿這個老外的例子來說吧：
類型的元素為（1byte）
長度是Payload總長度的值（1byte）
Payload的信息元素值為（0-255byte）
有一些信息值是有固定長度的，如果不正確可能緩沖區溢出，如果在802.11內長度高於buffer的大小，則可能出現溢出。
例如。SSID屬性，0為它的最小值，最大為32byte
用個循環來表示：
| 1 2 |
For SSID, test fuzz ssid {0, 1, MIN-1, MIN, MIN+1, MAX-1, MAX, MAX+1,
254, 255} length
|
長度值可能是有用的，以觸發緩沖區溢出，如果不仔細檢查的執行過程中的分析過程中的 802.11幀。這些信息大部分元素最小、固定或極大值可以不同於字節邊界(0-255byte)。
發送幀只有Beacon Frames的信息不一定是802.11中制定的元素，這個是為了測試Driver是否能在Beacon中解析有用無用的信息。
SSID的information elements Random
frame = Dot11( proto=0,FCfield=0,ID=0,addr1=DST,addr2=BSSID,
addr3=BSSID,SC=0,addr4=None)
/Dot11Beacon(beacon_interval=100,cap="ESS")
/Dot11Elt(ID=0)
sendp(fuzz(frame), loop=1)
老外的這一個框架，什麽都明白了就。
必須要知道解析器通常檢查哪些信息元素，了解底層協議那是肯定的.例如WPA的information elements
WPA IE (1 byte)
WPA OUI (3 bytes)
WPA TYPE (1 byte) + WPA VERSION (2 bytes)
WPA multicast cipher (4 bytes)
Number of unicast ciphers (2 bytes: m value)
WPA list of unicast ciphers (4*m bytes)
Number of authentication suites (2 bytes: n value)
WPA list of authentication suites (4 * n bytes)
當Fuzzer開始執行的時候，你可以用不同的“m”和“n”值來檢查溢出?截斷這些幀並且填充一些不相關的值來測試。
其實呢，我還是覺得，有了方法和思路，根據自己的Idea去Fuzzing比什麽都要好，有個叫wifuzzit的框架：
https://github.com/bullo95/WiFi--/tree/master/wifuzzit
挺好的，也發現了一些溢出的CVE等：
CVE-2008-1144年 ：Marvell的驅動EAPOL-密鑰長度溢出（無線AP）
CVE-2007-5474 ：Atheros的供應商特定信息元素溢出（無線AP）
CVE-2007-0933 ：緩沖區溢出在無線驅動程序6.0.0.18的的D-Link DWL-G650 +（無線STA）
CVE-2007-5651 ：可擴展身份驗證協議漏洞（Cisco的無線AP與有線交換機）
CVE-2007-5475 ：Marvell的驅動多個信息元素溢出（無線AP）
三、Windows上的Driver Vulnerabilities
其實關於Kernel的漏洞，只要你對Madwifi，無線協議比較清楚的話，再熟悉一些MIPS ,ARM指令就能看懂...註意是讀懂，讀懂不代表你也能挖出來。
差點把Google炸了才翻出一篇比較老的文章，專門寫kernel的，我把主要地方給翻譯下貼過來吧，前面講協議的我看得懂可以分析下，這個後面涉及到內核的我也分析不了，做二進制的有這方面的需求的，可以看下：
最開始他也是提了802.11 Driver 的State，也是說根據State1Fuzzing來的思路，前面劈裏啪啦說的跟我前面一樣，我直接就貼他後面的漏洞分析。
一個DWL-G132 USB A5AGU.SYS在WINxp下的測試：結果是造成內核崩潰
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 56149a1b, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 56149a1b, address which referenced memory
ErrCode = 00000000
eax=00000000 ebx=82103ce0 ecx=00000002 edx=82864dd0 esi=f24105dc edi=8263b7a6
eip=56149a1b esp=80550658 ebp=82015000 iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010296
56149a1b ?? ???
Resetting default scope
LAST_CONTROL_TRANSFER: from 56149a1b to 804e2158
FAILED_INSTRUCTION_ADDRESS:
+56149a1b
56149a1b ?? ???
STACK_TEXT:
805505e4 56149a1b badb0d00 82864dd0 00000000 nt!KiTrap0E+0x233
80550654 82015000 82103ce0 81f15e10 8263b79c 0x56149a1b
80550664 f2408d54 81f15e10 82103c00 82015000 0x82015000
80550694 f24019cc 82015000 82103ce0 82015000 A5AGU+0x28d54
805506b8 f2413540 824ff008 0000000b 82015000 A5AGU+0x219cc
805506d8 f2414fae 824ff008 0000000b 0000000c A5AGU+0x33540
805506f4 f24146ae f241d328 8263b760 81f75000 A5AGU+0x34fae
80550704 f2417197 824ff008 00000001 8263b760 A5AGU+0x346ae
80550728 804e42cc 00000000 821f0008 00000000 A5AGU+0x37197
80550758 f74acee5 821f0008 822650a8 829fb028 nt!IopfCompleteRequest+0xa2
805507c0 f74adb57 8295a258 00000000 829fb7d8 USBPORT!USBPORT_CompleteTransfer+0x373
805507f0 f74ae754 026e6f44 829fb0e0 829fb0e0 USBPORT!USBPORT_DoneTransfer+0x137
80550828 f74aff6a 829fb028 804e3579 829fb230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
80550854 f74bdfb0 829fb028 804e3579 829fb028 USBPORT!USBPORT_DpcWorker+0x224
80550890 f74be128 829fb028 00000001 80559580 USBPORT!USBPORT_IsrDpcWorker+0x37e
805508ac 804dc179 829fb64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
805508d0 804dc0ed 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
805508d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
|
Fuzz的五秒鐘已產生一個缺陷，已經可能對指針進行控制。 為了執行任意代碼，然而，一個惡意框架必須定位。在這種情況下，在EDI寄存器所指向成一樣的方式，它在Broadcom漏洞做了幀的源地址字段。 隨機生成信息元素之一-假EIP值到源地址。
| 1 2 3 4 5 6 |
kd> dd 0x8263b7a6 (edi)
8263b7a6 f3793ee8 3ee8a34e a34ef379 6eb215f0
8263b7b6 fde19019 006431d8 9b001740 63594364
kd> s 0x8263b7a6 Lffff 0x1b 0x9a 0x14 0x56
8263bd2b 1b 9a 14 56 2a 85 56 63-00 55 0c 0f 63 6e 17 51 ...V*.Vc.U..cn.Q
|
下一步是確定哪些信息元素是Crash的原因。 解碼後的內存Frame進行了一系列的修直到導致崩潰的特定信息元素被發現。 通過這種方法，確定了溢出的存在利用這個漏洞涉及發現內存中的返回地址指向一個JMP EDI，EDI ，或推電子數據交換; ret指令序列。這是通過運行msfpescan應用程序中包含的ntoskrnl Metasploit框架。 所得的地址必須被調整以考慮內核的基址。ntoskrnl.exe中的地址是0x804f16eb（0x800d7000 + 0x0041a6eb）
| 1 2 3 4 5 6 |
$ msfpescan ntoskrnl.exe -j edi
[ntoskrnl.exe]
0x0040365d push edi; retn 0x0001
0x00405aab call edi
0x00409d56 push edi; ret
0x0041a6eb jmp edi
|
實在找不出比這更新的研究內容了，關於國外針對802.11 Fuzz的研究也停滯在了11年。閱讀了大約30多份洋碼子PDF與PPT以及學術論文，綜合寫下，有點辛苦.....不管研究不研究，只想讓大家明白存在這麽一種技術，它的原理是這樣，也希望在中文引擎的搜索上，出現關於這一技術的研究內容，如果你也恰好研究過，發現了那裏不妥或者出現了錯誤或者是有更好的方法，歡迎交流指正。上來就噴的，你也放心，我一定會給你噴回去的。
基於802.11Fuzz技術的研究