geekmerc (geekmerc) wrote,

Will IPv6 stop worms like Conficker?

For the record, I nominate iPwn for the first IPv6 worm's name. Apple may not approve, but worm names are getting rather boring. Now on to the topic at hand.

When you initially look at the IPv6 address space and layout and how current worms randomly scan across the net, the initial presumption is that IPv6 will slow down if not stop such worms. Sadly, I believe it just means the worm, like everything else, must evolve to a new level.

There are a few reports I've read concerning use of DNS to determine host infection vectors. They spend a lot of time showing how it might be possible and how the delay of DNS queries won't effectively slow the worm down. However, they seem to depend on there not being as many dns entries as there are IPv6 addresses. This would presume that all end node DNS will use DDNS updates. I find this unrealistic in an ISP model, where it is more likely that templated naming will be used and dynamically generated as requested, if rDNS is even bothered with anymore for such end points. However, just because this method may not be useful for end nodes for ISP's do not rule it out as a vector which might be used for corporate network propagation or for worms who are looking for server based vectors. This last is really extremely key.

Another point on IPv6 which many have considered is the address usage. For example, the EUI is often derived from the 48-bit MAC address. Even systems using SLAAC with Privacy extensions, still generate an EUI address and respond to it. This decreases the number of addresses within a /64 that needs to be scanned. It also allows for catered scanning. After all, MAC addresses begin with a vendor code. Only scanning for a Netgear, for example, will reduce the necessary address space to scan considerably. The other address assignment method which is common is DHCPv6. Most implementations of DHCP tend to be incremental. This can lead to address space clustering, which will greatly improve scanning performance.

Let's look at our favorite OS for worms; Windows. Many exploits which effect end users will also effect a level of servers. While Windows does hold the market on end users, the server world is much more diverse, but the OS is still there. However, you can also reduce this infection base even more due to the fact that a server is more likely to be up to date on patches and more secure. Infection of servers creates a good base for infection of end users who might contact the servers. Servers are MOST susceptible to DNS based scanning to find vulnerable hosts. This has multiple uses. The first being an initial infection point, which is not just a end node, but a system which will most likely have communication with other systems. These communications can be monitored to contact and infect those other systems which may be other servers or end nodes.

So we have some servers and their end nodes that contact them infected. Unfortunately, the largest target that a worm really wants is the end nodes. Unless they get lucky and infect an extremely popular server, how will it find a majority of the end nodes? Yes, address clustering and current implementations of IPv6 drop address space considerably, but we're still talking about a large number of /64 subnets to scan. Local infection performance will be incredibly fast, but remote detection will require a lot more work.

This is where I haven't seen much speculation. End nodes don't just talk to servers these days. Peer to Peer (p2p), which IPv6 hopes to utilize more, lets end nodes talk to other end nodes. Standard p2p networks today can have an end node talking to thousands of other end nodes. Each of these connections to an infected end node provides an instant target to attempt infection on as well as a subnet which we know is in use in some form (begin the quick scans of the new subnet, both EUI and incremental).

When we look at the sheer volume of peer to peer participants, end node propagation can not only keep up with today's IPv4 worms, but should even be able to surpass them. Finally, Conficker added some internal support for p2p. What little I've read on it says that not much is known about the code, except that the worm can apparently update through it. However, what happens when they take it a step further. An isolated worm comes online and using a series of local scans and DNS scans attempts to find another host that is a) infected or b) can be infected. If the new host isn't infected, we now have 2 infected hosts that know of one another and can collaborate in detecting new hosts; reducing duplicate work which many worms are subject to perform today. If the new host is infected, it will already have a list of collaborators and the two networks merge into one. The larger the network, the more work that it can perform. The system can easily determine host bandwidth, latency, availability, and stability of IPv6 addressing. These factors can allow the network to segment into clusters, with master/multi-slave relationships within a cluster and master to master communications between clusters.

Such a scenario shouldn't even require the standard C&C model we see today for botnets, and while still capable of operating as a botnet, the cloud computing aspect allows the worm to propagate itself more efficiently by dividing up resources across the entire net and reducing duplicate work. It can also do the exact opposite of many worms and allow individual nodes or even clusters to cut back on their aggressiveness to limit detectability (people actually try and fix things when their connection trashes out which is counterproductive for the worm). High latency or low bandwidth links can be detected, and when possible work shifted through the net to allow the best clusters/nodes to scan a specific section of address space. While the hope was IPv6 would be hierarchal, I doubt anyone believes it will be much different than IPv4 deployments; though perhaps with a few less announcements needed in BGP.

So there you have it. Our future. There are a few things we can do to mitigate the above, but I fully expect to see every aspect of it in IPv6 worms as we move into the future.



  • CentOS 6 usbKey UEFI boot on a Supermicro server

    Some servers, including my Supermicro, don't handle the hybrid ISO on a USB stick very well. That is to say, they won't detect the EFI. Using…

  • Exim 4.72 (EPEL) Ratelimit rules

    Newer version have the ability to count the recipients from an acl_smtp_data block, but this version requires per_rcpt to be set in the…

  • New Project - VM Hell

    So I had to scratch the LAG with SR-IOV plan. I don't need the SR-IOV performance boosts, and the RHEL kernel version is way behind the necessary…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded