广州大学锐捷认证协议安全性研究

 

 

广州大学锐捷认证协议安全性研究

摘要: 本文通过分析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. 主机向服务器发送EAP-RESPONSE-MD5_Challenge回应

   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协议的安全性分析

在协议的数据流中,我们关心的是与密码有关的部分,关键是对于EAPMD5挑战的响应。这里记住几个变量:

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。一个跨平台的,提供驱动级别的访问网络底层能力的库pcapWindows下的实现。

3.2关于2级和4级目标

对于2级和4级目标,所谓交换机控制的是机器A访问网络的能力,指的是其主动访问网络的能力,对于被动接收网络上发过来的数据是没有做限制的,因此,这两个目标是自然成立的,只需要按照正常的网络通信那样进行就可以了。不过需要注意的是,由于TCP连接存在三次握手和ACK包,因而,传统意义上的TCP连接是无法建立的。只有UDP数据包就可以正常通信。

备注1:因为考虑到跨子网问题,故而需要考查高层网络协议,如IP,  TCP, UDP等,而链路层上的协议在当前环境的交换机中是不跨子网的。

3.3实现1级目标

为了实现这个目标,我们首先观察到这样的一些事实:

事实1:源地址为任意,目标地址为01-80-c2-00-00-03802.1X认证报文,能够通过交换机。

事实2IP地址为202.192.18.0/24IP数据包能够通过交换机。

根据以上两个事实,我们首先尝试了将802.1X认证报文的目标地址改为机器BMAC地址,实验后得到以下这个事实:

事实3:目标地址不为01-80-c2-00-00-03802.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是机器AMAC地址,0x000CDBD001A0对应为网关的MAC地址。我们将数据帧的目的地址改为机器BMAC地址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,通过简单的尝试后就很容易得到另一个事实了:

事实5IP地址不为202.192.18.0/24的数据包无法通过交换机。

既然无法通过交换机,那么要达到跨网就无从谈起了,这样,只好在目的IP地址为202.192.18.1的前提下进行讨论了。既然目的地址已经确定了,为了识别另一个网段上的机器,又只好将源IP地址设定为机器CIP地址了。于是,我们的想法很自然,就是希望通过DNS服务器转发消息给机器C。当然了,通常的DNS查询应答是无法为我们传递所需的消息的,那么唯一的办法就是将我们的消息嵌套到DNS查询当中。这里,我们说的是这样一个事实:

事实6:机器A通过构造一个包含有发送消息TDNS数据包,并修改数据包源IP地址为机器CIP地址,那么机器C将收到来自DNS服务器的一个DNS应答数据包,并且该应答数据包中包含了消息T

由事实4,我们实现了3级目标。通过构造DNS查询数据包的方法的效率比较,其效率为:

 

 

其中38为构造DNS查询所必须花费的网络带宽代价。

除去DNS数据包之外,FTPBBS的短消息功能也都可以作为信息交换的中心,然而,这样通过第三方进行信息交换的方法会加大服务器额外的负担,甚至会被认为是恶意的拒绝服务攻击,因此并不建议采用这样方法来处理。

综上,对于突破3级目标对于我们来说只是基本实现,还没有很完美地满足要求,仍需要更进一步的实验。

4 结论

请记住,我们上面的所有实验都是在没有通过锐捷认证的条件下进行的,我们很好地实现了1级,2级和4级目标,并且基本实现了3级目标,也就是说可以进行基本的网络通讯。在接下来的实验里面,如何更好地实现3级目标还是一个有挑战的问题。

 

参考文献

[1] EAP的总体流程, http://apt-blog.net/details_about_802_1x_in_campus_authentication_1

[2] Extensible Authentication Protocol (EAP), http://tools.ietf.org/html/rfc3748

[3] Wireshark, http://www.wireshark.org/download.html

[4] Winpcap, http://www.winpcap.org/install/default.htm

 

 

打赏

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注