廣州大學銳捷認證協議安全性研究
摘要: 本文通過分析802.1X協議,發現其存在離線字典攻擊漏洞。同時對廣州大學銳捷認證協議的具體實現進行黑箱測試後,找到了同一個子網的機器和饒過認證進行通訊的方法。
關鍵字:802.1X,銳捷,離線字典攻擊
Research on Ruijie Authentication Protocol in Guangzhou University
Abstract: This paper found a weak point, offline dictionary attack in 802.1X protocol. Also after carrying out black box test on the implementation of Ruijie Authentication protocol in Guangzhou University, we proposed a method that machines in the same sub network can communicate with each other without 802.1X authentication.
Keyword: 802.1X, Ruijie, offline dictionary attack
1 序言
網路的認證接入一直都是市場比較關注的問題,目前用得比較多的認證協議有PPPoE, 802.1X等。而銳捷認證協議就是以802.1X為基礎進行修改擴充套件的。本文主要關注的是該協議的自身安全性和協議實現的安全性,實驗環境為廣州大學的校園網。
在此之前,已經有人指出了由於實現上的出錯,導致多臺相同MAC地址的機器只要其中一臺成功通過了認證協議,就都可以同時正常訪問網路。進一步地,我們指出了,同樣是由於實現上的問題,導致網路中沒有通過認證的機器仍然獲得對網路的部分訪問能力。
2 廣大銳捷認證協議
2.1 802.1X協議
通過前面的介紹,我們知道廣大的銳捷認證協議是基於802.1X擴充套件的私有協議,因此在研究之前必須先了解清楚標準的802.1X協議。具體可以參考RFC 3748,下面只給出簡單的協議描述。
認證過程簡述:
1. 主機向伺服器(多播或廣播地址)傳送EAPOL-Start
2. 伺服器向主機發送EAP-REQUEST-Identity要求驗證身份的請求
3. 主機向伺服器傳送EAP-RESPONSE-Identity迴應
4. 伺服器向主機發送EAP-REQUEST-MD5_Challenge要求驗證密碼的MD5校驗值
5. 主機向伺服器傳送
6. 伺服器向主機發送EAP-Success
7. 保持連線的通訊...
當然這只是一般過程,如果在任何時候伺服器發來EAP-Failure資料包,都表示整個認證過程終止。在乙太網中,EAP協議當然也是通過乙太網幀的格式來傳送,幀型別為0x888e,在基於pcap的抓包程式中,可使用"ether proto 0x888e"來抓取。當用作802.1x應答幀時,常使用802.1x分配的多播地址01-80-c2-00-00-03作為目的地址。
EAP協議不僅可用於本文關注的乙太網環境中,還可在無線WLAN、令牌環網中應用,而這些鏈路幀是各不相同的,這就是為什麼有EAPOL型別的資料幀,用以抽象EAP協議報文。
EAPOL-報文結構:(byte)
0-13 |
14 |
15 |
16-17 |
18- |
Ethernet-Header |
a:EAPOL 協議版本 |
b:EAPOL 報文型別 |
c:EAPOL 幀長度 |
Packet Body |
a型別說明:通常為常量0x01
b型別取值:
EAPOL-Packet : 0x00
EAPOL-Start: 0x01
EAPOL-Logoff: 0x02
各種EAP協議的資訊互動,封裝在EAPOL-Packet型別的EAPOL報文內。至於EAP報文的格式,基本就是如下所示。
EAP-報文結構(byte)
18 |
19 |
20-21 |
22 |
22- |
d:EAP通訊型別 |
e:EAP通訊id |
f:EAP資料長度 |
g:EAP協商型別 |
EAP Body |
d型別取值:
EAP-Request: 0x01
EAP-Resopnse: 0x02
EAP-Success: 0x03
EAP-Failure: 0x04
e型別說明:
通常由伺服器發來的報文指定,在連續的報文內使用這個id來協商或者計算MD5值的資料之一。
g型別取值:
Identity: 0x01
MD5_Challenge: 0x04
2.2 802.1X協議的安全性分析
在協議的資料流中,我們關心的是與密碼有關的部分,關鍵是對於EAP的MD5挑戰的響應。這裡記住幾個變數:
1. SID:會話編號。這個就是上面提到的EAP通訊ID。在通訊過程中以明文出現的,長度為1個位元組。
2. Salt:隨機鹽。在MD5挑戰報文中附帶過來的,也就是上面提到的attach-key。在通訊過程中以明文出現,長度為16個位元組。
3. SK:會話金鑰。SK=MD5(SID+Password+Salt)
伺服器端正式通過這個SK來判斷認證請求是否合法。我們看到,由於MD5函式的單向性,要得到使用者的口令是不可行的,除非採用字典攻擊。因此,該協議首先就存在被執行離線字典攻擊的缺陷,這也是大部分現行的網路協議所共有的問題。
不過,即使存在這樣的漏洞,但是對於一般使用者來說,字典的大小還是讓人生畏的,我們還需要尋求其他方法。關於該協議更多的安全細節可以參考[2].
3 廣大銳捷認證協議的實現
再安全的協議,如果實現不當的話,都會變得十分脆弱。由於設計之初並沒有考慮到不同子網之間存在相同MAC地址的問題,導致只有一個埠的MAC地址通過了認證,那麼具有相同MAC地址的其他網路埠也可以通過認證。實踐證明,接在不同交換機上的任何兩個網路埠都可以利用這個漏洞。不過,最近實施的網路埠和MAC地址的繫結政策,又讓大家失望了。那麼,接下來,我們就是要考慮繫結MAC地址之後的環境下的實驗了。記住,我們實驗的幾個目標:
1級目標:可以不經認證就傳送資料到同一個交換機中的其他埠;
2級目標:可以不經認證就接收到同一交換機上其他埠傳送過來的資料;
3級目標:可以不經認證就傳送資料到其他交換機中的其他埠;
4級目標:可以不經認證就接收到其他交換機上埠傳送過來的資料。
3.1實驗環境說明
下面是實驗的網路拓撲:
在該拓撲下面,重複一遍我們的目標:(A機器不經認證)
1級目標:可以傳送資料到B機器
2級目標:可以接收來自B機器的資料
3級目標:可以傳送資料到C機器
4級目標:可以接收來自C機器的資料
相關實驗軟體工具:
1. VC++6.0。用於編寫程式碼實現傳送經過精心構造的資料包
2. wireshark。基於pcap的網路監聽工具,以分析是否滿足實驗的目標
3. winpcap。一個跨平臺的,提供驅動級別的訪問網路底層能力的庫pcap在Windows下的實現。
3.2關於2級和4級目標
對於2級和4級目標,所謂交換機控制的是機器A訪問網路的能力,指的是其主動訪問網路的能力,對於被動接收網路上發過來的資料是沒有做限制的,因此,這兩個目標是自然成立的,只需要按照正常的網路通訊那樣進行就可以了。不過需要注意的是,由於TCP連線存在三次握手和ACK包,因而,傳統意義上的TCP連線是無法建立的。只有UDP資料包就可以正常通訊。
備註1:因為考慮到跨子網問題,故而需要考查高層網路協議,如IP, TCP, UDP等,而鏈路層上的協議在當前環境的交換機中是不跨子網的。
3.3實現1級目標
為了實現這個目標,我們首先觀察到這樣的一些事實:
事實1:源地址為任意,目標地址為01-80-c2-00-00-03的802.1X認證報文,能夠通過交換機。
事實2:IP地址為202.192.18.0/24的IP資料包能夠通過交換機。
根據以上兩個事實,我們首先嚐試了將802.1X認證報文的目標地址改為機器B的MAC地址,實驗後得到以下這個事實:
事實3:目標地址不為01-80-c2-00-00-03的802.1X認證報文,無法通過交換機。
既然這樣滿足不了我們的要求,下面就要利用事實2了。我們首先截獲了一個到DNS伺服器的Query資料包:
uint8_t DNSPackage[] = {0x00, 0x0c, 0xdb, 0xd0, 0x01, 0xa0, 0x00, 0x23, 0x54, 0x86, 0x94, 0xf3, 0x08, 0x00, 0x45, 0x00, 0x00, 0x3b, 0x45, 0x67, 0x00, 0x00, 0x40, 0x11, 0x8f, 0x2a, 0xac, 0x12, 0x1d, 0x4d, 0xca, 0xc0, 0x12, 0x01, 0xde, 0x59, 0x00, 0x35, 0x00, 0x27, 0x0c, 0xc9, 0x97, 0x26, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x77, 0x77, 0x77, 0x05, 0x62, 0x61, 0x69, 0x64, 0x75, 0x03, 0x63, 0x6f, 0x6d, 0x00, 0x00, 0x1c, 0x00, 0x01};
其中0x0023548694F3是機器A的MAC地址,0x000CDBD001A0對應為閘道器的MAC地址。我們將資料幀的目的地址改為機器B的MAC地址0x00235A11CC50,驚喜地發現機器B可以接收到從機器A發過來的資料。這樣,我們得到這樣一個事實:
事實4:機器A要傳送資料到機器B,只需要修改資料包的目的MAC地址為對方的MAC地址,並且將IP包的目的地址改為202.192.18.1,然後再發送到網路中即可;機器B根據接收到的資料包如果IP目的地址為202.192.18.1,源目的地址不為0x000CDBD001A0,那麼就認為是機器A傳送過來的。
由事實4,我們實現了1級目標。實驗的關鍵程式碼為:
uint8_t remote_mac[ETHER_ADDR_LEN]= {0x00, 0x23, 0x5a, 0x11, 0xCC, 0x50};
memcpy(sendpackage, DNSPackage, 38);
int len_pack = sizeof(DNSPackage);
memcpy(sendpackage, remote_mac, ETHER_ADDR_LEN);
3.4 突破3級目標
在完成了1級目標之後,接下來就要突破3級目標了。注意到3級目標要求我們構造的資料包可以通過不同的交換機。然而由事實2,通過簡單的嘗試後就很容易得到另一個事實了:
事實5:IP地址不為202.192.18.0/24的資料包無法通過交換機。
既然無法通過交換機,那麼要達到跨網就無從談起了,這樣,只好在目的IP地址為202.192.18.1的前提下進行討論了。既然目的地址已經確定了,為了識別另一個網段上的機器,又只好將源IP地址設定為機器C的IP地址了。於是,我們的想法很自然,就是希望通過DNS伺服器轉發訊息給機器C。當然了,通常的DNS查詢應答是無法為我們傳遞所需的訊息的,那麼唯一的辦法就是將我們的訊息巢狀到DNS查詢當中。這裡,我們說的是這樣一個事實:
事實6:機器A通過構造一個包含有傳送訊息T的DNS資料包,並修改資料包源IP地址為機器C的IP地址,那麼機器C將收到來自DNS伺服器的一個DNS應答資料包,並且該應答資料包中包含了訊息T。
由事實4,我們實現了3級目標。通過構造DNS查詢資料包的方法的效率比較,其效率為:
其中38為構造DNS查詢所必須花費的網路頻寬代價。
除去DNS資料包之外,FTP和BBS的短訊息功能也都可以作為資訊交換的中心,然而,這樣通過第三方進行資訊交換的方法會加大伺服器額外的負擔,甚至會被認為是惡意的拒絕服務攻擊,因此並不建議採用這樣方法來處理。
綜上,對於突破3級目標對於我們來說只是基本實現,還沒有很完美地滿足要求,仍需要更進一步的實驗。
4 結論
請記住,我們上面的所有實驗都是在沒有通過銳捷認證的條件下進行的,我們很好地實現了1級,2級和4級目標,並且基本實現了3級目標,也就是說可以進行基本的網路通訊。在接下來的實驗裡面,如何更好地實現3級目標還是一個有挑戰的問題。
參考文獻