Last month, we looked at how a patched vulnerability in the Microsoft DHCP client could provide the conduit for a wireless "worm". This has been quickly patched by the company. That said, there are other vulnerabilities that might be used to propagate such a worm.
There is, for example, a problem with a particular Windows driver for the Intel Centrino 2200BG and 2915ABG wireless chipsets, found in the majority of Windows laptops, that creates an opportunity for a buffer overflow. This allows for execution of remote code on a target laptop using a wireless connection.
Essentially one could hack a target machine over the air in a hotspot or anywhere else where wireless laptops are found. This discovery also unveiled a new propagation route for our theoretical worm. The public exploit code for this vulnerability is rather flaky, but it does work, and it's available on the internet. Refinement to the code will come, and will increase its effectiveness.
A patch for the above vulnerability has been available for some time, however, the issue is this: driver updates are not deployed by default by Windows auto update or server update service. Only "critical" updates are deployed by default; hardware driver and software updates have to be selected manually. As a result, it's unusual for systems to have driver vulnerabilities patched. Unless you specifically review and deploy driver patches, you're likely to have an interesting range of vulnerabilities on your systems.
Driver vulnerabilities operate at a low level; network card drivers operate at a sufficiently low level to be able to bypass firewall protection when compromised through a vulnerability, potentially giving the hacker significant access to your systems.
Mac users often relish the relative lack of interest by hackers in their operating system, however, some driver issues are cross-platform. For example, a problem with some Broadcom wireless chipsets, which are common to both PCs and Macs, allows an attacker to crash a device remotely, and probably even enables remote code execution over the air.
Netgear, D-link and others have all had similar problems. In general, driver issues appear to be caused by a rush to get a product to market: hardware vendors are pushing their developers hard to produce the drivers required to launch products. As a result, the drivers aren't thoroughly tested and may not be subject to the most robust development processes. This is a little scary, given how widely deployed the drivers are, and the fact that many are involved in providing network access to your servers and PCs.
Beta exploit code for some of these driver vulnerabilities is already incorporated into "point and click" hacking tools such as Metasploit. Once refined, it will significantly reduce the technical knowledge required to compromise a target system.
From my perspective, the ultimate goal for a hacker would be to attack a corporate wireless laptop sitting on the local area network. It would be wired to the network with an RJ45 cable, but its wireless chipset would be running, probably because the user hadn't bothered to turn it off. The attacker, sitting in a cafe across the street from your HQ, would compromise the laptop over the air using a driver exploit, place a back door or Trojan, and use this to gain access to your network. As they will have bypassed your external perimeter defences, let's hope your network doesn't conform to the "hard shell/soft centre" approach to network security.
It would appear that Microsoft is implementing a security test process for all third-party drivers they digitally sign for deployment via Windows update. This is a commendable step. I wonder if Apple has similar plans?
In conclusion, don't overlook the driver as part of your patching regime. As operating systems become more secure, hackers will look to third-party components such as drivers to attack your systems. The price of overlooking these vulnerabilities could be high.
- Ken Munro is managing director of SecureTest. He can be contacted at firstname.lastname@example.org.
Drivers need patching too
By Ken Munro on Apr 24, 2007 10:07AM