摘要： 本文通過分析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)

a型別說明：通常為常量0x01

b型別取值：

EAPOL-Packet :   0x00

EAPOL-Start:     0x01

EAPOL-Logoff:    0x02

各種EAP協議的資訊互動，封裝在EAPOL-Packet型別的EAPOL報文內。至於EAP報文的格式，基本就是如下所示。

EAP-報文結構(byte)

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級目標還是一個有挑戰的問題。

參考文獻