Auditing Your Systems Can Improve Security

As you hopefully know by now, Microsoft released nine security bulletins this month as part of its regular patch release schedule. One of the bulletins includes a vulnerability in Microsoft Distributed Transaction Coordinator (MSDTC). The vulnerability is serious, and an exploit has already been created. Although the exploit was created by Immunity Security strictly for release to its business customers, by the time you read this newsletter, someone else will likely have already released another exploit onto the Internet--possibly in the form of a worm or Trojan horse, either of which could lead to a complete compromise of your entire network.

Protecting your systems in advance is of paramount concern. The obvious approach is to load the patch as soon as you can, and if you can't, for whatever reason, then take other defensive measures. MSDTC listens on TCP port 3372. Minimally, scan your network to determine which systems listen on TCP port 3372. You can disable MSDTC on individual systems or by using Group Policy. But doing so might break various types of functionality. Review Microsoft Security Bulletin MS05-051--Vulnerabilities in MSDTC and COM+ Could Allow Remote Code Execution (902400) for details.

The fact that someone created an exploit for the MSDTC vulnerability in fewer than 24 hours points out the need to stay on top of vulnerability reports and patching. It also points out the need to know precisely what software runs on your systems. A fantastic case in point is Mozilla Foundation, which I wrote about in a news story on our Web site that's also included in this newsletter.

In summary, the Spread Firefox Web site was compromised back in July. After that intrusion, Mozilla Foundation rebuilt the entire server. But, when doing so, the company failed to properly record what software runs on that server. Apparently between July and October, no significant audit was performed on the server either. As a result, Mozilla Foundation overlooked the fact that TWiki runs on the server, although not as a prominent service. (For more information about TWiki, go to )

You can probably guess what happened next: A vulnerability was discovered in TWiki, and soon an intruder began attempts to break into the Spread Firefox Web site. So Mozilla Foundation once again spent considerable time rebuilding a server that was rebuilt only a few months prior. The Spread Firefox site was taken offline by October 4, and didn't come back online until yesterday. I have no idea what the combined incidents cost the company in terms of time and money, but in addition to those costs, the incidents cost the organization in terms of reputation.

These sorts of incidents can happen to anybody who doesn't know exactly what software runs on their systems and doesn't stay up to date on new vulnerabilities. The bottom line is that you're responsible to determine what software runs on your systems, and you can't rely on your software vendors to consistently provide you the latest vulnerability information. The reason for the latter is simple: When vulnerabilities are announced to the public (sometimes with only scant details), potential intruders can use that information to begin looking for a way to breach security. In some cases, all a discoverer needs to say is, "I found a problem in XYZ application," and someone else can use logic to figure out where the vulnerability might be, find it, and develop a way to exploit it.

The lessons here are clear. In order to maintain optimum network security, you must audit your system regularly, keep precise and up-to-date records, and monitor the Internet for new vulnerability developments. Doing so can make even the biggest networks a much smaller target.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.