In the recent article “Beware of your MAC address,” I put forth the premise that the inherent ability to set your MAC address was a vulnerability. While some TechRepublic members vehemently disagreed, others were disappointed I didn’t disclose the registry keys used to set the MAC address. In this article, I will defend my belief in the seriousness of this issue by outlining the type of attack I see being used to exploit this weakness. I am also extending a challenge to anyone who can defend against my outlined attack scenario. Are you up for the challenge?

Manipulating the MAC address
Virtually every OS on the market today is capable of communicating over Ethernet networks and has the ability to set the MAC address of its NIC. The default MAC address of a NIC, in most cases, is “burned” into the card, but that address can be overridden by software.

There are valid reasons for this capability. One example given in the discussion forums of the original article was the use of LAA (locally administered addresses). As noted in the article as well as the discussions, many protocols actually rely upon this capability.

However, a few problems do exist. First of all, it is not common knowledge that you can set your MAC address. Among the millions of newcomers to our industry, there are plenty of folks who should know this, but don’t. One of the chief reasons for writing the original article was the realization that many developers (including some at Microsoft) use the manufacturer’s hard-coded MAC address as a fixed reference point in their software.

Another problem stems from the fact that from a security perspective, not all operating systems are created equal. Specifically, Windows 9x and Me are not secure and cannot be adequately secured. NT and 2000 have the ability to limit access to the registry through access control lists. These lists, when used in conjunction with proper precautions, will prevent an attacker from writing to sensitive portions of the registry. But in far too many networks, local administrative permissions are given to the end user, usually for the convenience of installing software.

A possible attack scenario
Today’s midsized, corporate network typically is comprised of 1,000 clients, consisting of Windows 95, 98, NT, and 2000 operating systems. All of the users have Internet access (through a properly configured proxy server) and are Internet e-mail enabled. Beyond the proxy server is hopefully a firewall keeping users safe from the Internet’s evil villains. Our mythical network has a single switched segment using a private Class B address range.

The delivery mechanism
In order to wreak havoc on this network, we only need one of the 1,000 clients to execute a relatively simple piece of VBScript or Java code. This script will in turn set the client’s MAC address to the MAC address of the client’s default gateway. In true Trojan horse style, the necessary script could be embedded on a Web page or in an e-mail attachment. Any Windows application capable of viewing HTML is vulnerable. That includes most browsers as well as most e-mail clients.

Just in case you don’t believe that a simple script can modify the registry of a client computer, take a look at the code behind the “I Love You” virus. The mechanism is the same, only the payload is different.

With the exception of the Windows 2000 client, the impact of the script will not show up until the computer has been rebooted.

The impact
To put it in the simplest of terms, approximately 50 percent of all traffic that should be delivered to the default gateway for routing will instead be delivered to the targeted computer. The remaining 999 clients on the network will be unable to effectively communicate with their default gateway.

About the discussions
In the discussions posted to the original article, there were several members who believed that this type of attack would require a compromise of the target client computer. This is simply not the case. Still others argued that if the hacker had the ability to set the MAC address, the network was already compromised. Once again, I would point out that on a Windows 9x/Me client, no compromise of passwords or user accounts would be necessary for this attack to succeed. The only prerequisites for the attack are that a single client has the ability to set its own MAC address and that it executes the code to do so.

A challenge!
Here’s your chance to strut your stuff. I will offer 5,000 TechPoints to the person or persons able to provide a detailed means of preventing the attack outlined in this article. The solution must be specific. If it involves software or hardware, please provide the vendor names and model or version numbers so that it can be tested.

For those of you who feel the need to test your solutions first, I suggest you look into locally administered addresses. Once a solution is found, I will publish the complete details of the registry keys used to set the MAC address on a Windows-based computer.
If you have questions or would like to discuss this topic in more detail, I will be monitoring and participating in the discussion threads related to this article. Post a comment below or send me an e-mail.