Is there any end to the ways in which attackers can exploit a networked computer system? Probably not. I read an interesting story in the current issue of Nature magazine entitled "Parasitic Computing" that reveals yet another way intruders can attack networked systems. The article, written by three men from the University of Notre Dame, discusses a method of exploiting nuances of the TCP/IP protocol family to cause systems to unwittingly participate in a distributed computing effort (e.g., solving mathematical problems). Exploits of this type are possible by relying on the TCP checksum status of packets as mathematical indicators for a given formula.
In summary, attackers construct packets that contain a candidate answer for a given math problem, then send the packets to remote systems that test the potential answer during normal packet checksum analysis. Because the attackers specifically construct the packets in a particular manner, when a target system receives that packet, the packet's checksum should succeed only when it contains the correct response to the mathematical problem. In this way, a system made to perform such computations responds back to the rogue client only when it actually has a correct answer to the problem.
As an example, the story points out that the HTTP protocol is required to respond to all requests received. But in the case of this type of parasitic computing, the HTTP service won't understand a valid packet's message, so it will simply respond to the client that it didn't understand the request. The client can then interpret that response as an acknowledgement that the packet contained the answer to the mathematical problem. And it's unlikely that the HTTP service would log anything because the attacker didn't make a valid request, and the system never established a valid session.
Interesting, don't you think? But don't worry about stolen CPU cycles too much just yet. The proof-of-concept the story presents—by the authors' own admission—isn't efficient enough to be useful for a practical exploit. Nevertheless, the authors point out that any impracticality is a function of the limitations in their proof-of-concept and not necessarily reflective of limitations of the overall concept of parasitic computing. It's entirely possible to develop a program that more efficiently exploits checksum analysis, and guarding against that type of unauthorized CPU usage is difficult. Read the story and tell me know what you think.
On another note, in the August 15 Security UPDATE, I reported that Microsoft had released its new Post-Service Pack 6a (SP6a) Security Rollup Package (SRP). Since that time, I've received numerous email messages about a serious problem with the SRP. In some cases, when you uninstall the SRP, the system no longer boots properly. This problem occurs on systems that have SYSKEY installed to protect the SAM database. The NTBugTraq mailing list recently posted a workaround for this problem. A list member reports that to successfully uninstall the SRP, you must first edit the associated uninst.inf file (located in the \%SYSTEMROOT%\$NtUninstallQ299444$ directory) to remove the entries for the lsasrv.dll and samsrv.dll files, which are located in the section labeled \[systemroot\system32.restore.nodely.files\]. After you remove the entries, you can safely uninstall the SRP without causing the system to hang during its boot phase.
Before I sign off this week, I want to ask if you've seen our monthly Security Administrator print newsletter? If you haven't, you're missing some really good content! In the current issue (September 2001), you'll find articles about manipulating services with scripts; securing Windows 2000 certificate services; removing C-2 compliant settings; securing private key storage, remote procedure call (RPC), and firewall configuration; properly applying security settings in Group Policy Objects (GPOs); tips on using IP Security (IPSec); and much more. Stop by our home page, and sign up for a free sample issue. It's a great resource! Until next time, have a great week.
