IPv6 Traffic Hijack Test System and Defense Tools Using DNSSEC

Transcription

1 IPv6 Traffic Hijack Test System and Defense Tools Using DNSSEC Lin Tao Liu Wu Duan Haixin Sun Donghong Abstract IPv6 is widely deployed in recent years, but IPv6 protocols still have many security threats, especially the traffic hijack in LAN (Local Area Network). In this paper we implement an IPv6 traffic hijack test system to help user aware the security risks, and then design a defense tool using DNSSEC to avoid traffic hijack attack. Keywords-IPv6; Security; Traffic Hijack; Attack Testting I. INTRODUCTION When IPv6 (RFC 2460) [1] was designed, it s compulsory to include IPSec in IPv6. Thus, it s claimed that IPv6 is more secure than IPv4. In fact, IPSec isn t implemented in most IPv6 network and this leads to a lot of security problem. The attacker can implement IPv6 LAN traffic hijack easily. Like IPv4, an IPv6 client should get the link-layer address (MAC address) of gateway to send their packets to the global network. If the IPv6 global address and default gateway address of the client are configured statically, the client will use NDP (Neighbor Discovery Protocol, in RFC 2461) [2] to get the MAC address of gateway. If the client wants to configure the IPv6 global address dynamically using RDP (Router Discovery Protocol, in RFC 2461) [2], DHCP,in this paper we take RDP for an example. Unfortunately, the attacker can forge both NDP and RDP packets in LAN, and then he can assign a fake MAC address of gateway to the client and the client will send his packets to the attacker, which is traffic hijack. Traffic hijack may cause great risk. If the attacker modifies the http traffic and then returns a phishing web page, the user account and password may be stolen. Someone may think that https and some security controls can avoid this risk. For https, we take Gmail for an example, user usually type in URL bar and Google server will send a redirect response of https link, but the attacker can discard the redirect response, and return a phishing web page directly. As a result, the trust system of https will not work. The rest of this paper is organized as follows. In section 2, we introduce security threats of existing protocols. Section 3 shows the details on implementation of IPv6 LAN traffic hijack test system. Section 4 describes the defense tools using DNSSEC. Finally we present our conclusions in section 5. II. BACKGROUND In this section, we assume that the reader has the basic acknowledgment of IPv6 and Ethernet. Thus, we concentrate on explaining the essential points of protocol s vulnerabilities, attacking method and some existing solutions to the attack. A. Vulnerabilities of Existing Protocols 1) Neighbor Discovery Protocol: IPv6 uses NDP to replace ARP in IPv4. There are two message formats in NDP, i.e. NS (Neighbor Solicitation) and NA (Neighbor Advertisement). In the LAN, client sends NS message to the whole LAN for gateway s link-layer address which means that the attacker can sniff the NS message, and then the gateway use NA message to response its MAC address. The NA message has an override flag, when the flag is set, it indicates that the advertisement should override an existing cache entry and update the cached link-layer address. In this result, the attacker can forge a NA message (a packet in LAN) with a fake link-layer address and setting the override flag, and then send it to the client. If client accepts the forged packet, the client s cached link-layer address of gateway will be updated and the client s traffic will be hijack by the attacker. Fig1 shows the attack. Figure 1. Attack on NDP 2) Link-local Address: In IPv6, link-local address is an important address for every network interface. This address /11/$ IEEE

2 first 64 bits is specified (fe80::/64) and last 64 bits are generated by the interface MAC address using EUI-64 algorithm (RFC 2464) [3]. The EUI-64 algorithm is reversible which means that we can get the MAC address by the linklocal address without any request. Thus, if client configure gateway (router) with link-local address, NDP is unnecessary when getting the gateway s MAC address. 3) Router Discovery Protocol: Client can use RDP to configure the IPv6 global address and router address dynamically. There two message formats in RDP, i.e. RS (Router Solicitation) and RA (Router Advertisement). In the LAN, client sends RS message to the whole LAN for the information used to configure. The router response a RA message including the 64-bits prefix, router s link-local address and router priority etc. with RA message, client will use EUI-64 algorithm to generate the last 64 bits of the IPv6 global address and set the router s link-local address to the default router. The problem is that, the attacker can forge a RA message with attacker s link-local address and high router priority. If the forged RA message is accepted, client will set the attacker s link-local address to the default router and he s traffic will be hijacked by the attacker. The main vulnerability of these protocols is that, all the messages are without any authentication. The attacker can forge the message and control the client s neighbor entries and routing table easily. B. Existing Solutions to the Threats 1) SEND (Secure Neighbor Discovery, RFC 3971) [4]: To avoid these security threats, RFC 3971 give a solution that message like NA, RA, NS and RS should extend an additional field. The message sender should give a RSA signature, and the receiver can authenticate the message with an X509 certificate. But the trust system is hard to build. Just like IPSec, although it makes traffic more secure, clients don t prefer to implement it. 2) Filters in Switches: Now, some switches have some filter, and the filters can detect the malicious message and discard them. This kind of switch isn t widely use and updating the existing switches need a large amount of work and much money. In addition, switch is not flexible when some new attack occurs, so the clients need some flexible tools to detect and avoid the known and unknown attack. So we need some lightweight method to help user aware the security risks and avoid traffic hijack. III. DESIGN OF IPV6 LAN TRAFFIC HIJACK TEST SYSTEM In the section, we will introduce the techniques and implementation of our IPv6 LAN traffic hijack test system. This system is composed of two modules (Traffic Hijack Module and Traffic Modification Module) and running in Linux system. The Traffic Hijack Module forges the RA and NA message to hijack the traffic. The Traffic Modification Module implements the man-in-the-middle attack on http traffic to help users aware the security risks. A. Traffic Hijack Module This module is divided into 4 components: Initialization, NS & RS Sniffer, Forged NA and Forged RA, which can be seen in Fig. 2. Figure 2. Traffic Hijack Module Initialization: There are some initial information and pre-works which include: o IPv6 global address of the legal gateway o The attacker s MAC address o The attacker s link-local address generated by MAC address o Enable the IPv6 forwarding Sniffer: this component is equivalent to a sniffer. The sniffer catches the NS, RS packets in the LAN and extracts some important fields of the packets. For NS message, we extract the target address (MAC address of whom is asked for) and the source address (sender s address). For RS message, we extract the source address (sender s address). NA Forger: If a NS packet is caught and its target address is the gateway address, this component will generate a NA packet with attacker s MAC address and send it to the client (the NS packet s sender). RA Forger: If a RS packet is caught this component will generate a RA packet with attacker s link-local address and high route s priority and send it to the client (the RS packet s sender). Figure 3. Traffic Hijack After this module running, if a client uses NDP or RDP to ask for the gateway s MAC address, his traffic will be hijacked by the attacker. Because we enable IPv6 forwarding, the traffic

3 will still forward to the gateway, and the client can feel nothing, but the path has been changed like Fig. 3. B. Traffic Modification Module This module implements a man-in-the-middle attack on http traffic and it will inject a link at the top of the page. If the user clicks the link, we can show the vulnerabilities, risks of existing protocols and provide some tools to avoid it. Fig. 4 shows the original web site and Fig. 5 shows the web site modified by this module. Traffic Analysis: This part extract the packet s protocol type e.g. ICMPv6, TCP, and UDP etc. For TCP packets, we extract the destination port to indentify http packets (http packet s destination port usually is 80). Packet Forwarding: Because we enable IPv6 forwarding, the non-http packet will send to the gateway automatically. Link injection: For client s http request packets, the attacker modifies the source address to attacker s address and sends them to http server, when the http server returns the response packets, the attacker modifies the destination address to client s address and sends it to client. Fig. 7 shows the address modification. At the same time, we search the string "</head>" (html head tag) in the response traffic and add the link after it. If a client clicks the link, we record the client s IPv6 global address for the component of Client Control. Figure 4. Original web site Figure 7. Address modification This test system only needs to be deployed on one client in the LAN, and it helps client to aware the risks of their network. Some defense tools are also available from the injected link. Figure 5. Web site modified by our module This module is composed of 4 parts as seen in Fig. 6. Figure 6. Traffic modify module Client Control: If a client has clicked the injected link recently, this means the client has known the risks and we won t inject the link again. The clients are identified by their IPv6 global address. IV. DESIGN OF DEFENSE TOOLS The key to the problem of traffic hijack is that we need to add some authentication to the NDP and RDP message. Also, the trust system should not be hard to deploy. Therefore, we can design the defense tools based on the existing trust system being widely deployed. DNSSEC (DNS Security Extensions, in RFC 2535) [7] builds a trust system based on PKI and is supported by most DNS services now, and the network managers can add some resource records to the DNS services their own easily. In addition, DNS server is necessary for client to browse most web sites. As a result, we can utilize DNSSEC to help client authenticate the NDP and RDP message. The defense tools can divide into two parts: The detection tool will fetch the correct information, and the filtering tool will reject the malicious message. A. Detection tool 1) Additional resource records of DNS: The network manager should add some resource records to DNS server and make the DNS service support DNSSEC, that clients can fetch the correct information use from DNS service.

4 a) To authenticate a NA message, the client should know the correct MAC address of the gateway. At first, the client only knows the Gateway s IPv6 address, e.g. "2001:da8:2:101::1", then a resource record for DNS reverse lookup should be added. When reverse lookup "2001:da8:2:101::1", the service should return "MAC00121e5e4020.router.cmbl.ccert.edu.cn". "cmbl.ccert.edu.cn" represents the zone of the client s network. The child zone "router" means that it s a router (gateway) of the network. "MAC00121e5e4020" is generated by the string "MAC" and the MAC address of the gateway. If client lookup "2001:da8:2:101::1", he will get this record, then he can get the string " MAC00121e5e4020" from the domain name and the MAC address "00:12:1e:5e:40:20". b) To authenticate a RA message, the client should know the correct link-local address of the router. When a client receives a RA message, he will get the 64-bits prefix and the link-local address of the router from the message. Then he generates the virtual global address of the router using the 64- bits prefix and the last 64 bits of the router s link-local address. E.g. 64-bits prefix is "2001:da8:2:101::/64" and linklocal address is "fe80::212:1eff:fe5e:4020", the virtual global address is "2001:da8:2:101:212:1eff:fe5e:4020". A resource record for DNS reverse lookup should be added. When reverse lookup "2001:da8:2:101:212:1eff:fe5e:4020", the service should return "MAC00121e5e4020.router.cmbl.ccert.edu.cn". The same as authenticating NA message, the client can know that, this router is legal. c) One more thing should be paid attention: the reverse lookup s DNSSEC trust chain hasn t been built from the root yet, because for most networks, the reverse lookup for IPv6 address isn t be deployed. We can solve this problem easily: after receiving the DNS response "MAC00121e5e4020.router.cmbl.ccert.edu.cn", the client just need lookup the "MAC00121e5e4020.router.cmbl.ccert.edu.cn". If the DNS server s response includes the gateway s IPv6 address or the router s virtual IPv6 address, the client can confirm that the MAC address of gateway or router is correct. 2) Implementation of the Defense Tool: This tool can be divided into 5 components as follow: a) Initialization: This component checks the client s default router s address. If the default router s address is linklocal address, we check the RDP message. Otherwise we check the NDP message. b) NS sender: This component will send a NS message to ask gateway s MAC address. c) NA checker: This component receives all the NA responses, and uses the method we discussed in IV.A.1 to authenticate them and record the correct MAC address of the gateway. If there is an attacker, we make warning for user. d) RS sender: This component will send a RS message to ask for RA message. e) RA checker: This component receives all the RA responses, and uses the IV.A.1 method to authenticate them and record the correct link-local address of the router. If there is an attacker, we make warning for user. B. Filtering tool Using the detection tool in IV.A, we can fetch the correct MAC address of gateway and a list of correct routers' link-local addresses (the LAN may have several routers). Then we should design filtering tool to discard the illegal message. If we receive a RA packet, we check the source address (it should be a link-local address). If the source address not in the list, we discard the packet. If we receive a NA packet, we check the target address and MAC address, if the target is the gateway and the MAC address isn t correct, we discard the packet. At the same time we should disable the router redirection message (an ICMPv6 message, RFC 2463) [6]. This message tells client that there is better router for forwarding packets, and the client s traffic will be redirected to the other router. This message is usually unnecessary in LAN and attacker can use it to hijack our traffic, which is discussed in another paper of us [5]. In Linux system use this command to disable route this message: "echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects". C. Test Results of the Tools We use the detection tool and the filtering tool in the traffic hijack test system that discussed in section 3. The static IPv6 global address of gateway is "2001:da8:200:9002::1" and the correct MAC address of gateway is "00:0f:f7:b0:5d:c0". The router s link-local address is "fe80::20f:f7ff:feb0:5dc0". The detection tool shows that there are some attackers in the LAN. At the same time, the correct link-local address of router and correct MAC address of gateway are detected. The filtering tool rejects all of the NDP and RDP messages forged by the test system, and the client can browse the web site without any warning link injected by our traffic hijack test system. For NDP, Fig. 8 shows that, the client s gateway MAC entry will be changed by the attacker, and he can avoid the forged NA message using the defense tool. Figure 8. NDP Test results of the tool For RDP, Fig. 9 show that the client accepts the forged RA message and his default router is changed by the attacker. Also, he can avoid the forged RA message using the defense tool.

5 paid more and more attention in the future, and our works are meaningful to the problem. Figure 9. RDP test result of the tool V. CONCLUSION In this paper, we designed and implemented the IPv6 Traffic Hijack Test System, which can help users aware the security risks of IPv6 s existing protocol and provide some defense tools for them. At the same time, we designed and tested the defense tools based on DNSSEC. The tools can use DNSSEC s trust system to authenticate NDP and RDP message in LAN. NDP and RDP are only a part of IPv6 protocols. There are many other protocols in IPv6 which should be authenticated, e.g. DHCPv6. And our authentication method based on DNSSEC can be widely used and easily deployed. We believe that the security risks and the vulnerabilities of protocol will be REFERENCES [1] S.Deering and R.Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, Internet Engineering Task Force, December [2] T. Narten, E. Nordmark and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, Internet Engineering Task Force, December [3] M. Crawford, Transmission of IPv6 Packets over Ethernet Networks, RFC 2464, Internet Engineering Task Force, December [4] J. Arkko, Ed. Ericsson, J. Kempf, B. Zill and P. Nikander, Secure Neighbor Discovery (SEND), RFC 3971, Internet Engineering Task Force, March [5] LIU Wu, Duan Hai-xin, LIN Tao, LI Xing, WU Jian-ping, H6Proxy: ICMPv6 Weakness Analysis and Implementation of IPv6 Attacking Test, Symosia and Workshops on Ubiquitous, Autonomic and Trusted Computing. July [6] A. Conta and S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, Internet Engineering Task Force, December [7] D. Eastlake, Domain Name System Security Extensions, RFC 2535, Internet Engineering Task Force, March 1999.