This article can also be found in the Premium Editorial Download "Information Security magazine: Comparing seven top integrated endpoint security suites."
Download it now to read this article plus other related content.
Our second test measured how well each product defended listening services on the protected system, particularly services associated with Windows networking. We attempted to exploit both the MSRPC DCOM buffer overflow flaw (MS03-026) and the LSASS buffer overflow issue (MS04-011). To add some variety to this network service testing, we attempted each exploit with both a standard command shell payload and the Metasploit Meterpreter shell, a more sophisticated and often harder-to-detect attack that provides specialized remote shell access running from within an exploited process. Our client-side and server-side testing relied on Metasploit Framework version 3.0, using all default settings except for the HTTP port for browser exploits, which we changed from 80 and 8080 to another number to simulate an attacker who tricks a client into clicking on a link with a port number in it.
Our third test was designed to look at how each vendor could defend against zero-day exploits of third-party applications. We created our own network-listening program with a buffer overflow flaw, and wrote some code to exploit it to give remote command-shell access on the target machine.
Overall, eEye performed best in detecting exploits. It was the clear leader in identifying client-side attacks, alerting on all of our tests, but by default did not block; it simply displayed the alert
| "Application Protection: Suspicious System Call." This default behavior could be altered to block such exploits, as a global switch applied to all such suspicious system-call detection. While blocking is the goal, concern over false-positive blocks makes eEye's default setting reasonable.
eEye successfully stopped all service exploits. However, in the process of blocking the MSRPC DCOM exploit, it killed the svchost.exe process, which made our Windows machines reboot themselves within 60 seconds. It is generally considered better to kill an exploited process rather than run the attacker's code, but re-booting could result in loss of valuable data.
eEye detected and alerted on our zero-day exploit; when we tweaked the configuration to an action of "Terminate Process," it blocked as well.
This was first published in November 2007