Archive for the IPv6 Category

whois smarter than I thought?

Posted in Information Leaks, IPv6 on 5 March, 2012 by Alec Waters

Whilst picking through the responses to the latest Spy Hunter challenge I stumbled over some interesting behaviour when using whois to query various kinds of IPv6 addresses, especially those related to v6-over-v4 tunnelling mechanisms. It turns out it’s rather insightful.

As a baseline, let’s start by performing a whois of a non-tunnelled IPv6 address – it’s pretty straightforward, as you would expect:

user@box:~$ whois 2001:200:dff:fff1:216:3eff:feb1:44d7
% [whois.apnic.net node-5]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inet6num: 2001:200::/32
netname: WIDE-JP-19990813
descr: WIDE project
country: JP
remarks: upgraded from /35
admin-c: JM46-AP
tech-c: AK27-AP
tech-c: SU19-AP
status: ALLOCATED PORTABLE
notify: kato@wide.ad.jp
notify: zin@wide.ad.jp
mnt-by: APNIC-HM
mnt-lower: MAINT-JP-WIDE
changed: hm-changed@apnic.net 20030423
changed: hm-changed@apnic.net 20071109
source: APNIC

person: Jun Murai
address: Keio University
address: 5322 Endo Fujisawa 252-8520
country: JP
phone: +81 466 49 1100
fax-no: +81 466 49 1101
e-mail: junsec@wide.ad.jp
nic-hdl: JM46-AP
mnt-by: MAINT-AU-APNIC-GM85-AP
changed: kato@wide.ad.jp 19990729
source: APNIC

person: Akira Kato
address: Keio University, Graduate School of Media Design
address: 4-1-1 Hiyoshi, Kohoku, Yokoahama 223-8526
country: JP
phone: +81 45 564 2490
fax-no: +81 45 564 2503
e-mail: kato@wide.ad.jp
nic-hdl: AK27-AP
mnt-by: MAINT-JP-WIDE
changed: kato@wide.ad.jp 20090225
source: APNIC

person: Satoshi UDA
nic-hdl: SU19-AP
e-mail: zin@jaist.ac.jp
address: Japan Advanced Institute of Science and Technology
address: Center for Information Science
address: 1-1 Asahidai, Tatsunokuchi, Nomi, Ishikawa 923-1292
phone: +81 761 51 1111
fax-no: +81 761 51 1305
country: JP
notify: zin@jaist.ac.jp
changed: zin@jaist.ac.jp 20040803
changed: zin@jaist.ac.jp 20041028
mnt-by: MAINT-JP-WIDE
mnt-by: MAINT-JP-JAIST
source: APNIC

In this case, there is a direct link between the IPv6 address and it’s “owner”, provided you trust what the whois server is telling you.

With tunnelled IPv6 addresses, there isn’t such a strong correlation between an observed IPv6 address and the actual IPv4 computer sourcing that traffic. Depending on the type, the IPv6 address may be “owned” by the tunnel provider, and one might be tempted to think that a whois query of such an address would merely tell you about the provider.

It turns out that whois is a bit smarter than that. Various flavours of IPv6-over-IPv4 tunnelling embed the original IPv4 address into the IPv6 address, and whois can parse it out for you. Taking a Teredo IPv6 address as an example, look at line 03 below:

user@box:~$ whois 2001:0:5ef5:79fb:3447:18d4:b0b5:1c05

Querying for the IPv4 endpoint 79.74.227.250 of a Teredo IPv6 address.

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '79.72.0.0 - 79.79.255.255'

inetnum: 79.72.0.0 - 79.79.255.255
netname: DSL-AS9105-UK
descr: Tiscali UK Ltd
descr: Milton Keynes
descr: Dynamic DSL
descr: ==========================================================
descr: Concerning abuse and spam ... Email abuse@talktalkplc.com
descr: e-mail to other addresses will not be dealt with.
descr: ==========================================================
country: GB
admin-c: TU935-RIPE
tech-c: TU935-RIPE
status: ASSIGNED PA
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered

role: Tiscali UK
address: Tiscali UK Limited
address: 11 Evesham Street
address: London W11 4AJ
phone: +44 207 087 2000
remarks: Information: http://www.talktalk.co.uk
org: ORG-TUL3-RIPE
admin-c: MJ3048-RIPE
admin-c: RH2381-RIPE
tech-c: MJ3048-RIPE
nic-hdl: TU935-RIPE
remarks: Hostmaster Role Account
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered
abuse-mailbox: abuse@talktalkplc.com

% Information related to '79.64.0.0/12AS9105'

route: 79.64.0.0/12
descr: Tiscali UK Limited
origin: AS9105
mnt-by: TU935-RIPE-MNT
source: RIPE # Filtered

Line 3 shows that whois has recognised a Teredo IPv6 address, and has parsed out the client’s obfuscated IPv4 address from bits 96-127 and run the whois on that instead. If we want to know the tunnel provider, we have to extract it ourselves – it’s unobfuscated in bits 32-63. In this example, this is 5ef579fb which translates as 94.245.121.251. A standard whois query tells us that the person connecting with Teredo from 79.74.227.250 on Tiscali’s network is doing so via Microsoft – they are therefore likely using Vista or Win7:

user@box:~$ whois 94.245.121.251
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '94.245.64.0 - 94.245.127.255'

inetnum: 94.245.64.0 - 94.245.127.255
descr: Microsoft Limited
org: ORG-MA42-RIPE
netname: UK-MICROSOFT-20081107
country: GB
admin-c: AS9763-RIPE
tech-c: EN603-RIPE
tech-c: BR329-ARIN
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: MICROSOFT-MAINT
mnt-domains: MICROSOFT-MAINT
mnt-routes: MICROSOFT-MAINT
source: RIPE # Filtered

organisation: ORG-MA42-RIPE
org-name: Microsoft Limited
org-type: LIR
address: Microsoft
 Darren Norman
 One Microsoft Way
 WA 98052 Redmond
 UNITED STATES
phone: +1 (425) 703 6647
fax-no: +1 425 936 7329
e-mail: danorm@microsoft.com
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
admin-c: NORM1-RIPE
mnt-ref: MICROSOFT-MAINT
mnt-ref: RIPE-NCC-HM-MNT
mnt-by: RIPE-NCC-HM-MNT
source: RIPE # Filtered

person: Allie Settlemyre
address: Microsoft Limited
address: One Microsoft Way,
address: Redmond, WA 98052
address: USA
phone: +1 (425) 705 0516
phone: +1 (425) 936 7329
e-mail: iprrms@microsoft.com
nic-hdl: AS9763-RIPE
source: RIPE # Filtered

person: Bharat Ranjan
address: Microsoft Corporation
address: Redmond, WA, 98102
address: One Microsoft Way
address: USA
phone: +1 (425) 706 3230
fax-no: +1 (425) 936 7329
nic-hdl: BR329-ARIN
source: RIPE # Filtered
e-mail: bharatr@microsoft.com

person: Edet Nkposong
address: Microsoft, One Microsoft Way,Redmond, WA 98052
address: USA
e-mail: edetn@microsoft.com
phone: +14257071045
nic-hdl: EN603-RIPE
mnt-by: MICROSOFT-MAINT
source: RIPE # Filtered

Pretty neat. You can pull off a similar trick for 6to4 addresses as well:

user@box:~$ whois 2002:4b95:26ad:0:d067:8ff6:b954:b37f

Querying for the IPv4 endpoint 75.149.38.173 of a 6to4 IPv6 address.

#
# Query terms are ambiguous. The query is assumed to be:
# "n 75.149.38.173"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=75.149.38.173?showDetails=true&showARIN=false&ext=netref2
#

Comcast Business Communications, LLC CBC-CM-5 (NET-75-144-0-0-1) 75.144.0.0 - 75.151.255.255
Comcast Business Communications, LLC CBC-SFBA-11 (NET-75-149-32-0-1) 75.149.32.0 - 75.149.63.255
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

There’s one last use case I’d like to illustrate – that of a static IPv6 tunnel via a tunnel broker. This is where you manually connect a 6in4 tunnel (using IP Protocol 41) to a tunnel broker service, such as that run by Hurricane Electric. The tunnel broker is your point of access to the IPv6 internet, and the next-hop for your ::/0 default route is the broker’s end of the tunnel.

When signing up for a tunnel like this, you might have to supply some information about yourself to the tunnel broker as required by the Terms of Service. Take care – this information may end up in the output of a whois query.

In the query below, I’ve obfuscated the actual IPv6 address and other items to protect the privacy of the individual concerned. Some interesting points:

  • Line 17 tells us that the IPv6 address is owned by Hurricane Electric
  • Line 74 is where we start to find the interesting stuff. This is talking about 2001:470:XXXX:XXXX::/64, the static IPv6 address block assigned to the user of the tunnel broker.
  • Lines 91 and 92 tell us that we’re looking at the address of the user’s private residence
  • Line 95 is the postcode you’d put into Google Streetview to start your cyberstalking.
user@box:~$ whois 2001:470:XXXX:XXXX::2
#
# Query terms are ambiguous. The query is assumed to be:
# "n 2001:470:XXXX:XXXX::2"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=2001:470:XXXX:XXXX::2?showDetails=true&showARIN=false&ext=netref2
#

NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR: 2001:470::/32
OriginAS:
NetName: HURRICANE-IPV6
NetHandle: NET6-2001-470-1
Parent: NET6-2001-400-0
NetType: Direct Allocation
RegDate: 2001-03-22
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET6-2001-470-1
OrgName: Hurricane Electric, Inc.
OrgId: HURC
Address: 760 Mission Court
City: Fremont
StateProv: CA
PostalCode: 94539
Country: US
RegDate:
Updated: 2011-04-13
Ref: http://whois.arin.net/rest/org/HURC

ReferralServer: rwhois://rwhois.he.net:4321

OrgTechHandle: ZH17-ARIN
OrgTechName: Hurricane Electric
OrgTechPhone: +1-510-580-4100
OrgTechEmail: hostmaster@he.net
OrgTechRef: http://whois.arin.net/rest/poc/ZH17-ARIN

OrgAbuseHandle: ABUSE1036-ARIN
OrgAbuseName: Abuse Department
OrgAbusePhone: +1-510-580-4100
OrgAbuseEmail: abuse@he.net
OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN

RNOCHandle: ZH17-ARIN
RNOCName: Hurricane Electric
RNOCPhone: +1-510-580-4100
RNOCEmail: hostmaster@he.net
RNOCRef: http://whois.arin.net/rest/poc/ZH17-ARIN

RAbuseHandle: ABUSE1036-ARIN
RAbuseName: Abuse Department
RAbusePhone: +1-510-580-4100
RAbuseEmail: abuse@he.net
RAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN

RTechHandle: ZH17-ARIN
RTechName: Hurricane Electric
RTechPhone: +1-510-580-4100
RTechEmail: hostmaster@he.net
RTechRef: http://whois.arin.net/rest/poc/ZH17-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

Found a referral to rwhois.he.net:4321.

%rwhois V-1.5:0012b7:01 ops.he.net (HE-RWHOISd v:r255,m1:r290)
network:ID;I:NET-2001:470:XXXX:XXXX::/64
network:Auth-Area:nets
network:Class-Name:network
network:Network-Name;I:NET-2001:470:XXXX:XXXX::/64
network:Parent;I:NET-2001:470::/32
network:IP-Network:2001:470:XXXX:XXXX::/64
network:Org-Contact;I:POC-TB-6NGV
network:Tech-Contact;I:POC-HE-NOC
network:Abuse-Contact;I:POC-HE-ABUSE
network:NOC-Contact;I:POC-HE-NOC
network:Created:20120217063259000
network:Updated:20120217063259000

contact:ID;I:POC-TB-6NGV
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Private Customer - Hurricane Electric
contact:Street-Address:Private Residence
contact:City:SOMECITY
contact:Province:SOMECOUNTY
contact:Postal-Code:POSTCODE-PLUG-INTO-GOOGLE-STREETVIEW
contact:Country-Code:UK
contact:Phone:+1-510-580-4100
contact:E-mail:hostmaster@he.net
contact:Created:20120217063225000
contact:Updated:20120217063225000

contact:ID;I:POC-HE-NOC
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Network Operations Center
contact:Company:Hurricane Electric
contact:Street-Address:760 Mission Ct
contact:City:Fremont
contact:Province:CA
contact:Postal-Code:94539
contact:Country-Code:US
contact:Phone:+1-510-580-4100
contact:E-Mail:noc@he.net
contact:Created:20100901200738000
contact:Updated:20100901200738000

contact:ID;I:POC-HE-ABUSE
contact:Auth-Area:contacts
contact:Class-Name:contact
contact:Name:Abuse Department
contact:Company:Hurricane Electric
contact:Street-Address:760 Mission Ct
contact:City:Fremont
contact:Province:CA
contact:Postal-Code:94539
contact:Country-Code:US
contact:Phone:+1-510-580-4100
contact:E-Mail:abuse@he.net
contact:Created:20100901200738000
contact:Updated:20100901200738000
contact:Comment:For email abuse (spam) only

%ok

The moral of the story is that you can’t hide behind a tunnelled IPv6 address, and it may well tell the world much more about yourself than you might think!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

The SLAAC Attack – using IPv6 as a weapon against IPv4

Posted in IPv6, Networking on 4 April, 2011 by Alec Waters

This article, written by myself, was originally published at InfoSec Institute in April 2011. The version below is the original text, without edits made by InfoSec Institute.

As anyone who has watched the reimagined Battlestar Galactica will tell you, Sixes are trouble. They are undoubtedly alluring, but all the while they are working covertly, following The Plan, right under the noses of their targets. Nobody realises the true nature of the threat until it’s too late.

The Internet also has its own Six, IPv6 (formerly IPng – IP Next Generation). Modern operating systems ship with it by default, but adoption has been slow for many reasons. Despite the passing of the IPocalypse, it lies largely dormant within today’s networks, waiting for the chance to rise up and usurp its IPv4 predecessor.

This article describes a proof of concept of an interesting application of IPv6. I’m going to show you how to impose a parasitic IPv6 overlay network on top of an IPv4-only network so that an attacker can carry out man-in-the-middle (MITM) attacks on IPv4 traffic.

IPv6 Background

Aside from the increased address space, IPv6 is fundamentally different to IPv4 in several key areas. This article isn’t intended to be an IPv6 primer, but I’ll highlight the main features that are relevant to the attack.

Firstly, IPv6 does not use ARP – instead, there are a set of neighbour discovery protocols implemented over ICMPv6 that allow hosts to discover the physical addresses of others on the local link. Also, routers routinely advertise their presence on the local link by multicasting “Router Advertisement” (RA) messages.

When an IPv6-aware host receives an RA, it can derive itself a valid routable IPv6 address by means of a process called Stateless Address Auto Configuration (SLAAC). The host will use the source address of the RA as its default gateway.

In as much as it facilitates automatic host addressing, SLAAC sounds a lot like DHCP in the IPv4 world. However, SLAAC alone can’t supply all of the configuration parameters that a host might need (DNS servers, for example), so DHCPv6 is still needed to fill the gaps. It turns out that you need RA, SLAAC and DHCPv6 to accomplish for IPv6 what DHCP alone can do for IPv4, but that’s another story.

Theory of operation

This proof of concept targets Windows 7 hosts, but the theory ought to apply to any operating system that ships with IPv6 installed and operational by default. Let’s start with a diagram of the target network:

slaacattack1

Pretty straightforward stuff; everything’s IPv4, and the border router is performing the usual NAT and firewall tasks. Let’s also assume that various countermeasures are in place to thwart conventional IPv4 MITM techniques such as ARP spoofing.

What we’re going to do is physically introduce a router, evil-rtr, to the target network. evil-rtr has two network interfaces – the victim facing interface is IPv6 only, and the Internet connected interface is IPv4 only. Our aim is to use evil-rtr to create a parasitic IPv6 overlay network that’s totally under our control, as shown by the tinted area in the diagram below:

slaacattack2

evil-rtr will send RAs to the local network which will cause the hosts to derive routable IPv6 addresses for themselves. It is also equipped with a DHCPv6 server to supply the address of a recursive DNS server that’s under our control (evil-DNS in the diagram above). What we have not done is connect our IPv6 overlay network to the IPv6 Internet – evil-rtr only has a connection to the IPv4 Internet.

The Special Sauce

The changes made by introducing evil-rtr are pretty benign so far. Thanks to evil-rtr’s RAs, all the target hosts have routable IPv6 addresses in addition to their IPv4 ones, plus the address of a DNS server. This isn’t enough to do anything useful – we need another ingredient to progress the attack.

The “special sauce” is NAT-PT, an idea that’s so riddled with issues and caveats that it’s been consigned to the trashcan of history by the IETF. However, just because it’s an obsolete mess doesn’t mean it can’t be useful.

NAT-PT is one of the many IPv4-to-IPv6 transition mechanisms that have been devised to ease migration from the old to the new. Its job is to allow islands of IPv6 hosts to communicate with IPv4 hosts by translating IPv6 addresses into IPv4 addresses and vice versa. There’s a writeup here that shows its intended operation. It’s NAT-PT that allows our IPv6-addressed victims to access the Internet through evil-rtr’s IPv4 interface.

To use NAT-PT you need to define an off-link /96 prefix; it can be pretty much any routable prefix you like. Any destination addresses seen by NAT-PT which match this prefix are interpreted as IPv6 addresses with a destination IPv4 address embedded in the last 32 bits.

slaacattack3

For example, I might tell my NAT-PT box that the prefix I’m using is 2001:6f8:608:ace::/96. The IPv6 address of the DNS server that we’re going to give out via DHCPv6 is 2001:6f8:608:ace::c0a8:5802 – this address matches the specified prefix, so if NAT-PT sees traffic destined for  it the last 32 bits (c0a8:5802) will be extracted and translated into the DNS server’s true IPv4 address of 192.168.88.2.

The Garnish on the Special Sauce

We’re nearly there. With NAT-PT in place, evil-rtr is now providing a working path from the IPv6 victims to the IPv4 Internet. If we can cause the victims to pump IPv6 traffic through evil-rtr (instead of sending IPv4 through the legitimate border router) we can have our MITM fun. It turns out that this is quite straightforward.

Thanks to evil-rtr, our victims have both IPv4 and IPv6 addresses; they are “dual stacked”. Dual stacked hosts will prefer to use native IPv6 where available, so we’re half way there already. The final garnish that will take us the rest of the way is DNS.

The dual stacked victims have an IPv4 DNS server (courtesy of the legitimate DHCP server) and an IPv6 DNS server (courtesy of evil-rtr’s DHCPv6 server). When one of the victims tries to look up http://www.google.com, it will send a DNS query to its IPv6 DNS server for both A (IPv4) and AAAA (IPv6) records. If the IPv6 DNS server can return results in a timely enough fashion, the victim will pick the IPv6 address over the IPv4 one if the former is present. It is this behaviour we will rely on to lure traffic through evil-rtr. Our IPv6 DNS server has to be quick, though – if it takes too long to reply, the victim will fall back to using the legitimate IPv4 DNS server instead, and no traffic will pass through evil-rtr.

But how can we make sure that any given DNS query always returns an IPv6 address?

NAT-PT implementations usually include a set of Application Layer Gateways (ALGs) which inspect traffic that has IP addresses carried within the application layer protocol. DNS is an example of a protocol that requires an ALG, as is FTP. Here’s what the IPv6 DNS transaction looks like with NAT-PT and the DNS ALG working their magic:

slaacattack4

Things to note:

  • The address of the victim’s DNS server matches the NAT-PT prefix on evil-rtr, denoting that the last 32 bits contain the DNS server’s IPv4 address.
  • NAT-PT translates the source and destination IPv6/IPv4 addresses in both directions.
  • The DNS ALG translates the victim’s AAAA query for an IPv6 address into an A query for an IPv4 address and vice versa on the way back.
  • The DNS ALG also translates the IPv4 address in the reply to an IPv6 address that matches the NAT-PT prefix.

As far as the victim is concerned, http://www.google.com is reachable via IPv6 at 2001:6f8:608:ace::d155:8f63. It has absolutely no idea that IPv4 is involved in any way. The victim will therefore contact Google like this:

slaacattack5

evil-rtr is therefore now a man-in-the-middle between the victim and Google.

To summarise the story so far:

  • We have not compromised or altered the operation of the victim’s IPv4 network, as we would have needed to do in order to MITM IPv4 traffic. We’ve not even needed to get an IPv4 address from their DHCP server.
  • We have not compromised an existing IPv6 network, because there wasn’t one before we arrived.
  • We have not compromised any given victim host (yet!). Each machine is behaving as designed and is choosing IPv6 over IPv4 of its own volition.
  • We have managed to totally alter the flow of traffic on the victim’s network by awakening the hosts’ latent desire to use IPv6 over IPv4.

The attack is also reasonably stealthy, since:

  • We’re introducing a new path to the Internet. Any defences or monitoring employed at the network’s IPv4 boundary are therefore ineffective and will raise no indicators of compromise.
  • There’s a chance that the victim’s security systems (e.g., host firewalls, HIPS, SIEM boxes, etc.) won’t be able to handle IPv6 traffic. IPv6 support on such systems is rarely as mature as its IPv4 equivalent.
  • Since the victims “aren’t using IPv6” they won’t be expecting an attack that makes use of it.

If the above is true, there’s a chance their Incident Response teams won’t have the necessary training and experience with IPv6 to deal with an incident that uses it.

Building evil-rtr

It doesn’t take much to implement evil-rtr. Only three packages are needed, namely radvd, dhcp6s, and naptd. Before we get these up and running, we need to set up our interfaces. In this example, eth0 is the Internet-facing IPv4 interface, and I’m going to assume that it can use a DHCP server somewhere to get an address. eth1 is the IPv6 interface, which we’ll configure like this:

root@evil-rtr:~# ifconfig eth1 inet6 add 2001:6f8:608:fab::1/64
root@evil-rtr:~# ifup eth1
root@evil-rtr:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:25:4b:fd:91:73
          inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

We also need to make sure that IPv6 forwarding is turned on:

root@evil-rtr:~# sysctl -w net.ipv6.conf.all.forwarding=1 net.ipv6.conf.all.forwarding = 1

Now we can install our IPv6 toys.

radvd

This package is responsible for sending RAs to our victim hosts, and can be obtained here. The configuration file is quite straightforward:

interface eth1 {
          AdvSendAdvert on;
          AdvOtherConfigFlag on;
          MinRtrAdvInterval 3;
          MaxRtrAdvInterval 10;
          prefix 2001:06f8:0608:fab::/64 {
                    AdvOnLink on;
                    AdvAutonomous on;
                    AdvRouterAddr on;
          };
};

The important parts are the link prefix and the setting for AdvOtherConfigFlag. Setting this to “on” will set the O flag in the RAs. The O flag tells a client that it should also try to contact DHCPv6 for further configuration. Fire up radvd according to the documentation, and move on to…

dhcp6s

I downloaded the WIDE DHCPv6 server from here. We have very little to hand out via DHCPv6, so the configuration file has just two lines:

option domain-name-servers 2001:6f8:608:ace::c0a8:5802;
option domain-name "pwned.by.v6";

Start it up, and move on to…

naptd

Get it here. Following the excellent documentation, we need to configure iptables and ip6tables like this:

root@evil-rtr:~# ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 1 -j DROP
root@evil-rtr:~# ip6tables -A FORWARD -d 2001:6f8:608:ace:: -j DROP
root@evil-rtr:~# iptables -A INPUT -i lo -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -j DROP

Then we can run napt-confmaker. I answered pretty much every question with the default answer, apart from the interface selections and the NAT-PT prefix.

Once we start naptd running, the trap is set.

The Attack

This is what the output of ipconfig looks like on the victim host before evil-rtr’s IPv6 interface is connected to the network:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . : 192.168.0.251
DHCP Server . . . . . . . . . . . : 192.168.0.251
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F
DNS Servers . . . . . . . . . . . : 192.168.0.251
NetBIOS over Tcpip. . . . . . . . : Enabled

The presence of a link-local IPv6 address confirms that the host is IPv6-capable. Once we connect evil-rtr’s eth1 interface, the victim host sees the RAs, derives a routable IPv6 address for itself, then queries DHCPv6 for further configuration. Almost immediately, the output of ipconfig will change to look like this:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : pwned.by.v6
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:6f8:608:fab:119c:ea76:23d4:290d(Preferred)
Temporary IPv6 Address. . . . . . : 2001:6f8:608:fab:687a:83f:caa7:8f9c(Preferred)
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . : fe80::225:4bff:fefd:9173%10
192.168.0.251
DHCP Server . . . . . . . . . . . : 192.168.0.251
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F

DNS Servers . . . . . . . . . . . : 2001:6f8:608:ace::c0a8:5802
192.168.0.251
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List : pwned.by.v6

It’s game over for the poor victim host:

  • It has routable IPv6 addresses of its own
  • It has an IPv6 default gateway, which is actually the link-local address of evil-rtr’s eth1 interface rather than the address we manually gave it earlier on.
  • It has an IPv6 DNS server whose address matches the NAT-PT prefix used by naptd, and which will be translated into the IPv4 address of evil-DNS.

We have successfully awakened the victim’s latent desire to use IPv6 in preference to IPv4. We’ve not needed any passwords, hacks or brute force. All we had to do was nudge the victim in the right direction.

Poetry in Motion

When the victim browses to http://www.google.com, evil-rtr’s IPv6 eth1 interface sees this (download capture):

slaacattack6

You can see the DNS queries sent via IPv6 to evil-DNS; both A and AAAA queries are sent, and IPv4 and IPv6 addresses delivered in response. Note that the returned IPv6 address matches our NAT-PT prefix, indicating that it has an embedded IPv4 address. The victim will choose to use this IPv6 address over the IPv4 one; evil-rtr is the man-in-the-middle.

The same transaction on evil-rtr’s IPv4 eth0 interface looks like this (download capture):

slaacattack7

Note that all the IP addresses are IPv4, and all the DNS queries are all for A records instead of the mix of A and AAAA that we saw on eth1.

Developing the Attack further

There are several things we can do to take the attack further:

  • Given that this attack uses implanted hardware, we can make it really really tiny. Gumstix is an ideal platform; they’re small, they run Linux, and there’s a wide range of hardware on offer giving you a very small platform with an Ethernet interface to attach to the target network and an autonomous Internet connection. I’ve used Gumstix before; once you’ve got the build environment set up, the world’s your oyster.
  • We control evil-DNS, so we can make it return any IP address we like for http://www.google.com, thereby opening up numerous opportunities for phishing.
  • In its current state, evil-rtr will MITM all traffic that is the result of a DNS query; this isn’t exactly subtle. If we can make evil-DNS return addresses only for sites of interest we can be a good deal more selective. If we can make evil-DNS ignore requests we don’t care about, the victim will fall back to their IPv4 DNS server and traffic will flow as normal.
  • As we are the man-in-the-middle, we have the opportunity to interfere with the traffic between the client and the server. We could inject malicious iframes, change https:// links to plain old http:// links, etc, etc.
  • <insert other creative evil here>

Defending against evil-rtr

The attack is possible because we were able to inject RAs onto a network of IPv6-capable hosts – the key differentiator between this attack and other similar ones is that we are not trying to subvert an existing IPv6 network; we are instead trying to build a new one out of nothing. Nevertheless, our rogue RAs were the catalyst for the successful attack. If we can stop them in their tracks, the attack will go nowhere.

Most of the time, rogue RAs are nothing more than a nuisance, often generated as a result of something as simple as turning on Windows’ Internet Connection Sharing. However, it is a serious enough issue for the IETF to put together RFC6104, the “Rogue IPv6 Router Advertisement Problem Statement”. This document is more concerned with brokenness caused by “accidentally-rogue” RAs than it is with security issues, but Section 3 gives a useful list of mitigation techniques. Sadly, most of these are difficult to employ either due to the lack of a suitable implementation (e.g., SEND), or a lack of capable hardware (e.g., RA Guard or switch ACLs). Cisco also have some tips on first hop security here and here.

If the attack can’t be prevented by the methods listed in RFC6104, perhaps it can be detected instead. NDPMon is an IPv6 equivalent to ArpWatch and is designed to detect suspicious neighbour/router discovery traffic.

However, neither RFC6104 nor NDPMon will help to defend against the SLAAC Attack. Why would anyone deploy IPv6 countermeasures when they “aren’t using” IPv6? The SLAAC Attack targets IPv6-capable IPv4 networks, not native IPv6 or dual stack ones. The most effective defence is simply to disable IPv6 on all capable hosts if there’s no business reason to use it:

slaacattack8

This is in complete alignment with the “Minimised” principle of the Defensible Network, but doesn’t exactly foster the accelerated adoption of IPv6. I know which way I’d jump!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Next Generation Naughtiness at the Dead Beef Cafe

Posted in General Security, IPv6, Networking, NSM on 23 December, 2010 by Alec Waters

The IPocalypse is nearly upon us. Amongst the FUD, the four horsemen are revving up their steeds, each bearing 32 bits of the IPv6 Global Multicast Address of Armageddon, ff0e::dead:beef:666.

Making sure that the four horsemen don’t bust into our stables undetected is something of a challenge at the moment; IPv6 can represent a definite network monitoring blind spot or, at worst, an unpoliced path right into the heart of your network. Consider the following:

Routers and Firewalls

Although a router may be capable of routing IPv6, are all the features you use on the router IPv6-enabled? Is the firewall process inspecting IPv6 traffic? If it is, is it as feature-rich as the IPv4 equivalent (e.g., does it support application-layer inspection for protocols like FTP, or HTTP protocol compliance checking?)

End hosts

If you IPv6-enable your infrastructure, you may be inadvertently assigning internal hosts global IPv6 addresses (2001::) via stateless address autoconfiguration. If this happens (deliberately or accidentally), are the hosts reachable from the Internet directly? There’s no safety blanket of NAT for internal hosts like there is in IPv4, and if your network and/or host firewalls aren’t configured for IPv6 you could be wide open.

IDS/IPS

Do your IDS/IPS boxes support IPv6? Snort’s had IPv6 support since (I think) v2.8; the Cisco IPS products are also IPv6-aware, as I’m sure are many others.

Session tracking tools

SANCP has no IPv6 support; Argus does, as does cxtracker. netflow can also be configured to export IPv6 flows using v9 flow exports.

Reporting tools

Even if all of your all-seeing-eyes support IPv6, they’re of little use if your reporting tools don’t. Can your netflow analyser handle IPv6 exports? What about your IDS reporting tools – are they showing you alerts on IPv6 traffic? What about your expensive SIEM box?

The IPv6 Internet is just as rotten as the IPv4 one

We’ve seen some quite prolific IPv6 port scanning just as described here, complete with scans of addresses like 2001:x:x:x::c0:ffee and 2001:x:x:x::dead:beef:cafe. The same scanning host also targeted UDP/53 trying to resolve ‘localhost’, with the same source port (6689) being used for both TCP and UDP scans. I have no idea if this is reconnaissance or part of some kind of research project, but there were nearly 13000 attempts from this one host in the space of about three seconds.

Due to the current lack of visibility into IPv6, it can also make a great bearer of covert channels for an attacker or pentester. Even if you’re not running IPv6 at all, an attacker who gains a foothold within your network could easily set up a low-observable IPv6-over-IPv4 tunnel using one of the many IPv6 transition mechanisms available, such as 6in4 (uses IPv4 protocol 41) or Teredo (encapsulates IPv6 in UDP, and can increase the host’s attack surface by assigning globally routable IPv6 addresses to hosts behind NAT devices, which are otherwise mostly unreachable from the Internet).

The IPocalypse is coming…

…that’s for certain; we just have to make sure we’re ready for it. Even if you’re not using IPv6 right now, you probably will be to some degree a little way down the road. Now’s the time to check the capability of your monitoring infrastructure, and to conduct a traffic audit looking for tunneled IPv6 traffic. Who knows what you might find!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Follow

Get every new post delivered to your Inbox.

Join 33 other followers