Wednesday, September 13, 2006

What happens when Windows is under attack – from the Ethernet?

There always seems to be a percentage of the population that believes Windows is able to withstand network attacks—and with every new version of Windows, that percentage grows—perhaps in the hopes that eventually Windows security will improve.

If these individuals were security professionals, their outlook would not be quite so rosy.

Fortunately for them, Microsoft seems to be making some progress by recasting the network stack in Vista. Because let’s see what can happen if Windows XP or Windows Server 2003 is subjected to an ARP attack from a local network. (Smart Address Resolution Protocol (ARP) filtering protects users from fake requests to initiate communication and shields wireless networks (WiFi LANs) against unauthorized connections.)

Let’s start with a computer running Windows XP or Windows Server 2003 and 30,000 times per second we’ll report that machine that its IP address is already in use. In itself, this is quite easy, but to send ARP packets, we’ll need an NDIS protocol driver, such as WinPCap; in our tests, we’ll use a specially-created high-performance driver that was built for our test environment. We’ll use a network with a 100 Mbit bandwidth and a Pentium 4 630 with 2 GB of RAM as our test PC.

Using the Performance snap-in, with information refreshing every second, we will start sending packets and see what we get.

Performance snap-in

Note the areas circled in red.

In area 1, packets are just starting to pass through the system and CPU usage begins to rise sharply.

In area 2, we see the system become so overloaded that the performance counters could not be updated. Also note the dramatic change in Paged Kernel Memory usage.

Between the second and third areas, CPU usage stays very high, even though packets have already stopped passing.

In area 3, CPU usage finally drops and I captured the screenshot.

Now let’s take a look at the System Log using Event Viewer:

System Log

At this point, we must ask ourselves—how is this scenario even possible? Fortunately, this pattern of activity would only affect unroutable Ethernet networks, which may be a company’s local network, a public airport network, or a discrete segment of a university network. So at least the effect of the attack is contained.

So what does this experiment tell us? Quite simply, the act of plugging your computer into a local network can put it at high risk if that computer is vulnerable to IP spoofing or other ARP-related attacks. The result might be anything from interfering with a university exam, to disrupting a public presentation, to preventing a busy executive catching up with work between flights—all because of IP address conflicts.

But would this happen if your computer had Outpost Firewall Pro installed? Of course not (otherwise, I wouldn’t mention it!). Since Outpost Firewall Pro 3.0 was launched this time last year, the program has been able to detect and block this type of attack. An Outpost-protected computer simply will not accept ARP replies if no ARP request was sent before, and the stream of ARP garbage shown in our test Event Log above would be ignored. Zone Alarm Pro also provides a level of protection against this type of attack.

Would the CPU usage still run up? Unfortunately, yes it would. It always costs dearly in terms of CPU cycles for the Windows network stack to receive packets, especially a high number of packets. Fortunately, the increase in CPU usage is not so great that it would interfere with normal PC activities.

Suppose you are a victim of this kind of attack and you neither have Outpost Firewall Pro nor Zone Alarm Pro—how can you isolate the attacker? Unfortunately, the only way to fight back against an attack like this is to disable your network segments one by one until you find the source of the attack. Doing this with a wireless network, however, is close to impossible and most likely you would need to disable the entire network to stop the attack—which is of course what the attacker wants you to do.

Microsoft developers are making significant efforts to give Vista a fundamentally different level of security and reliability, and the recasting of the network stack and other changes should make network managers very happy. But whether these efforts are actually going to improve security for the majority of Windows networks is a whole different story.

Watch this space for my thoughts on that subject.

Alexey Belkin,
Chief software architect at Agnitum

No comments: