IPv6 Security

IPv6 is the communication protocol of the future - there is no escaping from it. Everyone who takes a closer look at the list of IPv4 allocations will come to the conclusion that the time is running out - and quite fast according to the latest estimations which predict the end of available IPv4 addresses by 2011/2012.

But what will this new IPv6 protocol bring us? New features? Improved security?

The following list includes the main improvements of IPv6:

• Larger Address Space
• Simplified Header
• Stateless Address Configuration
• Multicast
• Mobile IPv6
• Jumbograms
  
• IP Security (IPsec)

The most significant reason to introduce IPv6 is surely the extended address space. IPv4 is based on 32 bit and thus provides connectivity for 4.294.967.296 hosts. With tricks like NAT this number can be increased to fit to the needs of the industry today, but not for the needs of tomorrow.

IPv6 is based on 128 bit and thus provides an address space for 340.282.366.920.938.463.463.374.607.431.768.211.456 hosts. A number which is far away from being, even, imaginable.
A reasonable comparison is if you think of the IPv6 address space as the volumen of the earth and IPv4 as the volumen of an IPod. This may appear as an incredibly large amount of addresses, but if you think that every car , fridge or mobile gadget will have an IPv6 address - you get the idea.

When IPv4 was designed as a communication protocol there was not much (if any) time spent on security. Not so with IPv6.

The new version of the Internet Protocol has a suite of features for secure communication commonly called IPsec - well proved an due to its success also back ported to IPv4.

After a brief overview of the main facts I will focus on the security improvements which come with IPsec in future posts.

Clemens Kurtenbach
S21sec e-crime

Don't touch my Rustock.B

Rustock.B (aka Mailbot, Clicker, Costrat, ...) is a well-known malicious code that we have covered in this blog through several posts, and we came across it in every different computer scenarios: customers, friends, family and of course, analyzing its main features at work. Its aim is to send spam email (remember McColo?) hiding some of its files by hooking typical APIs:

• ZwOpenKey
• ZwEnumerateKey
• ZwQueryKey
• ZwCreateKey
• ZwSaveKey
• ZwDeviceIoControlFile
• ZwQuerySystemInformation
• ZwInitializeRegistry

Rustock.B is an old piece of software (2006) that didn't follow a security development lifecycle, having the same problem than any other type of software: vulnerabilities; and it seems that the Rustock.B authors didn't worry about that :) Not only the malicious code authors, but some anti-rootkit software ones.

The vulnerability is inside the ZwOpenKey handler (remember that this function is hooked), and can be triggered when opening a registry key with more than 524 (0x20C) bytes. It is not so common to have a registry key with more than 524 bytes, but it can happen in some computers (long hardware ids). In fact, you need:

• to be infected by Rustock.B
• that any process open a registry key with that length

in order to get a beautiful blue screen in Windows XP (Windows 2000 is not affected), or a bugcheck windbg screen:

The bottom line is that anytime that we are 1) infected by Rustock.B and 2) opening a big registry key, our system will halt. And that sometimes happens: any anti-rootkit software (GMER for example) that looks for hidden registry keys will trigger the vulnerability; it is not its fault, but will freeze our Windows system. So, which is, in your opinion, the best solution for avoiding this kind of errors in anti-rootkit software? Detecting if the computer is infected with Rustock.B when scanning the registry with, for example, GMER, and if it is, then take control of the error, or just ignore the error and crash the system?

Hat tips to Rubén, Alonso and Alfredo for finding and fixing :) the vulnerability

David Barroso

S21sec e-crime