Five Year Old Bug Spawns Router Botnet Monster
In the news has been yet another router botnet. [Hui Wang] and [RootKiter] of 360Netlab announced their discovery of what they call the “BCMUPnP_Hunter” rootkit. They estimate this botnet to be running on over 100,000 routers worldwide.
There are two elements of this story that I found particularly baffling. First, this botnet infects routers using a vulnerability that was first reported by Defensecode over five years ago, in 2013! The second oddity is the wide range of devices that are vulnerable and are now part of the botnet. Dozens of brands and at least 116 models have been found to be infected.
One of the details of this story hasn’t been reported entirely accurately. The bug is not built into the Broadcom chipset. Unlike Spectre and Meltdown, it’s not actually a hardware fault. Broadcom distributes a Software Development Kit (SDK) that enables device manufacturers like D-Link, TP-Link, and Linksys to quickly develop firmware for routers using Broadcom chips. The vulnerability lies in this code, rather than part of the hardware itself.
UPnP Strikes Again!
The attack vector is the Universal Plug’n’Play (UPnP) protocol. This protocol was first developed by Microsoft for Windows ME. The use case for UPnP is to allow a program on the local network to request an open port for incoming traffic, essentially automating the port forwarding process. Peer to peer traffic like bittorrent, online gaming, and even teleconference applications like Skype require connecting directly to other users. As ISPs began handing out only a single IP address, and NAT routers became more popular, solutions like UPnP were needed to enable these peer to peer applications.
While the idea is a valid one, UPnP has had a storied history full of exploits. In 2013, Rapid7 released a whitepaper looking at UPnP accessible over the internet. They identified over 80 million unique IP addresses that responded to UPnP discovery packets from the internet, and around 20% of those IPs exposed the control port. UPnP is intended for internal network use only, and by definition should not be publicly discoverable. This means that in 2013, 80 million devices were using a broken implementation of UPnP.
After Years in Hibernation
As to why a botnet is only recently capitalizing on this specific vulnerability, DefenseCode realized how large of an issue this could be, particularly in 2013 when the vulnerability was first announced. At that time, there were estimated to be 15 million vulnerable devices across the internet. DefenseCode delayed releasing the full details of the attack until 2017, when they finally opted to publish the full vulnerability details. Once the proof of concept code was available, it was only a matter of time until someone built the self-propagating worm we’re now seeing.
It’s not too hard to find a copy of Broadcom’s SDK that contained this vulnerable code. That SDK was dated 2007, but based on the Linux kernel from 2003, release 2.4.20. This is one of the outstanding problems in the industry. Rather than working to upstream support for a chipset into the kernel, manufacturers release an SDK based on an old fork of Linux. Because this “works”, there is very little rush to use more recent software, even when there are known vulnerabilities in the old code. This widespread sharing of low quality and dated code leads to situations like this one, where over 100 devices are vulnerable to an attack.
Where To From Here?
Some progress has been made on this front, as chip manufacturers have started working more closely with the upstream kernel developers. Qualcomm Atheros, for example, is working directly with OpenWrt to provide higher quality SDKs. Chipset manufacturers are only part of the solution, as device manufacturers must also release timely firmware updates for their devices.
We do have an alternative to relying on vendor firmware updates, in the form of third-party firmware. OpenWrt is the distribution I’m most familiar with, and seems to be the best of the open source firmware replacements.
Even when an updated firmware is released, many users simply aren’t interested in updating their routers when everything is working. While some manufacturers have tried implementing automatic firmware updates, that process isn’t without problems, either. Notable are the devices that have automatically updated to a “cloud enabled” firmware, which introduces an entirely new class of vulnerabilities.
The problem of software vulnerabilities will probably never fully go away. We can insist that vendors like Broadcom do better with their code, but as users, we have some responsibility for our own security. Occasionally checking for firmware updates, being aware of opened ports, and replacing devices when they no longer maintained are squarely our responsibilities. While this botnet is the result of a badly broken UPnP implementation, it’s ultimately up to you to maintain your own network.
from Hackaday https://ift.tt/2DFx6k8
via IFTTT