The Good, Bad and Ugly about Assigning IPv6 Addresses

Published: 2012-08-27. Last Updated: 2012-08-28 21:55:46 UTC
by Johannes Ullrich (Version: 1)

As you are planning to roll out IPv6, one of the questions that keeps coming up is how to assign addresses. Sure, you may do so manually one system at a time, but that is not exactly the preferred method. IPv6 provides two different protocols to assign addresses:

Router Advertisements (RA)

The router may advertise itself, and the network it is supporting, via Router Advertisements. In this case, the router will typically advertise the first 64 bits of the address, and the host will make up the last 64. Router advertisements that advertise more then 64 bits are ignored. Router Advertisements are widely supported by client devices. The problem with this method is that you will see very little accountability as to who is using what IP address at what time. Unlike DHCP, there is no "lease" and the router will not log who used what address when.

DHCPv6

DHCPv6 is a complete rewrite of the DHCP protocol, but provides many of the same features you are used to from DHCPv4. Your DHCPv6 server will hand out leases, you can assign static IP addresses, and you will obtain logs with details who obtained what IP address, just like in IPv4 (of course, just like in IPv4, a malicious user could just "pick up" an address without using the DHCP server).

RA and DHCPv6 interactions

It gets tricky if you have both, router advertisements and DHCP. This is actually "normal" when it comes to IPv6. Router advertisements include two flags, which will indicate the presence of a DHCP server:

- "managed" flag: used to indicate that there is a DHCP server handing out addresses.
- "other" flag: used to indicate that there is a DHCP server handing out other information (like DNS server addresses) but not addresses. The address is still provided by the router advertisement.

I ran some preliminary tests to see how different operating systems resolve the conflicts that may occur if both router advertisements and DHCP is present. I used a Cent OS server as router and DHCP server, and as client, I used Cent OS 6.3 ("Linux"), OS 10.8 Mountain Lion (OS X), Windows 7 and Windows 8 (latest pre-release from technet).

"Other" and "Managed" flag cleared, but the DHCP server is still running and the systems had a DHCP address prior to the last reboot
Windows 8 and OS X will still use the DHCP server.
Linux and Window 7 will only use the RA provided address
"Managed" flag set, DHCP server running
all operating systems tested will use RA and DHCP provided addresses
"Managed" and "Other" flag set, but the DHCP server is not running
all operating systems tested will just use the RA provided addresses
"Managed" and "Other" flag set (and DHCP Server running
This test was a bit tricky. In a first round, all operating systems ignored the RA, and only used the DHCP address. In a second round, they accepted all.

Advertising recursive name servers via RA

A relatively recent extension to router advertisements allows the inclusion of the recursive name servers IP address ("RDNSS"). This option was originally introduced by RFC 5106, and later revised by RFC 6106 [1]. Linux and OS X appears to accept it, but Windows doesn't. (7 or 8).

iOS/Android

According to my tests, neither operating system appears to support DHCPv6. You have to use router advertisements to configure IPv6. However, both operating systems make it hard to review the IPv6 configuration, and I am still working on more systematic tests. According to some sources, iOS appears to support DHCPv6, but I wasn't able to verify this so far in my tests [2].

[1] http://tools.ietf.org/html/rfc6106
[2] http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

(thanks to feedback from readers, I did edit some parts of the diary removing confusing statements about "RA" and stateless auto configuration as well as cleaning up the language around RFC 5106).

(want to learn more about IPv6? Or just want to go to Vegas? See http://www.sans.org/network-security-2012/description.php?tid=5086 )

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: hacking internet isc phishing sans security threat virus vulnerability worm

2 comment(s)

Quick Bits about Today's Java 0-Day

Published: 2012-08-27. Last Updated: 2012-08-27 23:16:15 UTC
by Kevin Liston (Version: 2)

20 comment(s)

This is what we know so far about the vulnerability: there is an exploit in the wild, it works on the latest FireFox, and Chrome, and it targets Java 1.7 update 6, there is currently no patch available, the exploit has been integrated into the metasploit framework.

What this means: the potential hit rate for drive-by attacks is currently elevated. Since this is a java vulnerability, this may also affect more than just Windows platforms (multi-platform attacks currently unconfirmed, based on the multi-platform compatibility of java itself.) Update: Metasploit claims to work on Mac OS X via Safari. So consider it just a java issue and ignore the OS and the browser when considering if you're exposed.

The next patch cycle from Oracle isn't scheduled for another two months (October.)

What you can do: this places normal end-users in a pretty bad position, relying mostly upon disabling, or restricting java and hoping that AV catches the payload that gets installed. None of these are really good options. There is a 3rd-party developed patch that is said to exist, but it's not intended for end-users. My current recommendations are to disable java if you can (see Brian Kreb's handy guide here: http://krebsonsecurity.com/how-to-unplug-java-from-the-browser/ ,) or use something like no-script to help control where you accept and execute java from. Update: Downgrading to 1.6 might be an option for you as well, make sure you're using the latest update. Credit or blame Steven depending on how that works out for you. (JK Steven.)

Malware Spam harvesting Facebook Information

Published: 2012-08-27. Last Updated: 2012-08-27 13:40:02 UTC
by Johannes Ullrich (Version: 1)

2 comment(s)

A couple years back at our annual RSA "top threat" panels, one of the possible exploits I suggested was the use of social network information for more automated targeted e-mail. At that time, most "spear phishing" was done by first manually collecting information about the victim, then creating an e-mail based on that information. In short: The exploit didn't scale and was expensive. Most of what a half way skilled attacker can do can be done cheaper and faster by a decent python/perl script.

Since then, we have seen a number of mass mail campaigns using automated harvesting of social network information. For example, some of the early campaigns searched Linked-In for specific job titles.

This latest one abuses information published on Facebook. The spam appears to come from a "Facebook Friend" of yours. As a sample:

From: Some Friend <randomname@yahoo.co.id> Subject: FOR FIRSTNAME To: your@emailaddress

The e-mails contain what appears to be valid Yahoo DKIM signatures, so they are likely sent from compromised or throw away Yahoo accounts. "FIRSTNAME" would be the recipients first name, and "Some Friend" would be the friends name. Depending on your e-mail client, you may not see the email address used in the "From" header.

To double check your Facebook (or other social network) privacy settings, make sure you log out, then search for yourself on the social network and verify that the information you get back is in line with your privacy expectations.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter