Defense in Depth

For the last week, I've written that Dan Kaminsky undertook unprecedented action in coordinating a variety of vendors in secret over the last six months. Ari Takanen, co-founder and chief technology officer of Codenomicon, wrote to challenge that notion.

In an e-mail on Thursday, Takanen cited his work on a Simple Network Management Protocol version 1 (SNMPv1) flaw back in 2002 as an example. Like Domain Name System, SNMP is a fundamental element of the Internet.

I wrote: "There have been other multiparty patch releases, but never has there been one on such a massive scale. It took someone with the gravitas and reputation of Kaminsky to pull together the affected parties."

Takanen writes: "Well, actually that is not true. Our SNMP case was secret for nine months after reporting it to relevant vendors, and as far as I know it involved more than 100 vendors and other organizations (1,000+ people). We saw all possible attempts to disclose it, but even public disclosure lists appreciated the stand that CERT-US chose to take."

CERT-US released its advisory on February 12, 2002, after word of the flaw leaked.

Takanen goes on to say Codenomicon provides a commercial tool to defect the SNMPv1 flaw as part of its quality assessment process.

The funny thing is six years later, the tool still finds active systems vulnerable.

Takanen, who advocates nonpublic disclosure of security flaws, said, "This just proves that reporting individual bugs for fame and fortune does not motivate the vendors to improve their quality assurance processes."

Gaining the ability to remotely control your HVAC might seem like an energy-responsible thing to do, but it might also pose hidden security risks.

In a recent blog titled Security implications in HVAC equipment SANS handler Swa Frantzen wrote of his concerns regarding one energy-saving program in Texas. The utility, TXU, uses what's called an iThermostat, which allows you to program your thermostat remotely over the Internet from any laptop or desktop.

In California, PG&E offers a similar program, SmartAC. PG&E also uses an Internet addressable, programmable thermostat, however, the user guide (PDF) mentions only remote access from the utility, not from the end user.

Frantzen makes it clear that's he's not intentionally picking on the iThermostat system; he's only using it for educational purposes. Nor am I necessarily saying the SmartAC program is flawed either. I do, however, think his academic questions are quite valid because they go beyond just HVAC systems.

Recently there was a security hole identified within an Internet-connected coffee maker. I think the first question here should be: do we really need to access our coffee machine remotely?

It might be argued that these systems (the HVAC and coffee machine) both terminate--they don't necessarily allow a remote attacker access to a home computer network. But that's for right now. Jump ahead a few years when these systems start talking each other, when you'll be able to create a warm and comfy home environment from your desktop at work.

Until then, what if someone remotely views your schedule of when the AC turns on and off? It could tip a potential burglar to when you're likely to be home and when not. And what if, asks Frantzen, the remote lockout on the thermostat fails and some remote hacker cranks the heat or air conditioning setting to its maximum setting while you're on vacation?

Is anyone even thinking about these issues? If not, shouldn't someone be?

Programming note: As of Friday, July 11, 2008, Defense in Depth will now only carry my weekly column plus additional commentary on the state of computer security. My security news blogs will instead appear under the CNET News Security banner going forward. And my CNET News Security Bites podcasts can be found at here. All of these can be subscribed to via RSS.

While security researcher Dan Kaminsky still won't comment on the specific nature of a flaw within the Domain Name System--for fear that criminal hackers might exploit it before the worldwide network of name servers worldwide and client systems that contact them can be updated--he nonetheless went public on July 8 with some details, backed by simultaneous patch releases from Microsoft, Cisco, and others.

There have been other multiparty patch releases, but never has there been one on such a massive scale. It took someone with the gravitas and reputation of Kaminsky to pull together the affected parties.

Dan Kaminsky at DefCon in 2006.

(Credit: Declan McCullagh/CNET News)

What he and others he took into his confidence did over the last few months was not only responsible but extraordinary. The flaw that Kaminsky discovered could allow criminal hackers to guess the transaction ID of any request to a DNS server for a particular domain, such as one used for a bank or an e-commerce site, and then redirect that request to another site, a phishing site. It would do so silently, evading most anti-phishing technology because the change would be made not at the desktop level but at the DNS server itself. Certainly this is big, and certainly one would want to get the news out as soon as possible--but Kaminsky took the time to inform the proper vendors and authorities and, only after they were ready with patches, did he disclose some of what he'd discovered.

That isn't to say what Kaminsky did was perfect; he himself admits there are lessons to be learned and improved upon the next time this happens. Whether you agree with the severity of the flaw Kaminsky disclosed last Tuesday, I do think all future vulnerability disclosures could benefit from his example.

Kaminsky, director of penetration testing at IOActive, is no stranger to vulnerabilities. Over the years he's found a fair share and says that in the case of the DNS flaw he wasn't looking for it. In this week's Security Bites podcast, Kaminsky told me that after three days of testing he knew he had something important. At that point, early in 2008, he had a few options.

One was to tell the vendor (or, in this case, vendors) directly. Ari Takanen of Codenomicon told me he prefers that security researchers keep vulnerabilities between them and the vendor. Vendors, Takanen said, have their own development cycles, and for a researcher to burst into a room or go public and demand that everyone work on his or her vulnerability is unrealistic. While Kaminsky was willing to work with the vendors, he wasn't willing to give them forever.

Another option was to sell the vulnerability to a third party like TippingPoint's Zero Day Initiative. ZDI acts as the middleman, talking with the vendor and communicating with the researcher. The advantage here is that a researcher with no connections to the affected vendor can communicate the problem clearly.

ZDI has been credited with several vulnerabilities, such as those announced by Apple and Microsoft. Kaminsky has no qualms with those who opt for this method, although he said he didn't understand why a company would pay for this information. (I know the answer: TippingPoint uses the vulnerability data it purchases to protect its customers first, thereby giving it a competitive advantage in the vulnerability assessment space).

Another option for Kaminsky was to go public, to announce the vulnerability and publish details, including an exploit, on, say, Bugtraq. A few researchers have gone this route, but often as a last resort after getting a cold shoulder from the vendor. A few researchers have published flaw details first without contacting anyone, taking both the public and the vendor by surprise. But such moves are unwise since they give the bad guys all the information they need while everyone is vulnerable.

Finally, as Kaminsky reminded me, there's the option of selling your vulnerability to the criminal underside of the Internet.

With the DNS flaw, Kaminsky was in a very weird position. What he found wrong with DNS, the servers that translate a Web site's common name to its IP address, wasn't just within one vendor's product, it cut across various products, from various vendors. He said he consulted with DNS expert Paul Vixie, and together they decided they had to convene a meeting, and do so within a few weeks of the discovery.

That meeting occurred at Microsoft's Redmond, Wash., headquarters on March 31, 2008. There, representatives from 16 vendors sat down and listened to Kaminsky's pitch. After deciding this was a real and exploitable problem, the vendors decided they would have little choice but to agree to release simultaneously their respective patches.

At some point, July 8, 2008, was agreed upon as the date, perhaps because it coincided with Microsoft's monthly Patch Tuesday. The date was significant in other ways: for example, it fell roughly 30 days before Kaminsky was scheduled to speak at Black Hat in Las Vegas.

Between March and July, there was considerable back and forth among Kaminsky and the vendors, and then, as the date neared, he decided to share the details with a few others.

In retrospect, Kaminsky confessed that he really should have told more people. He had gone through great pains to inform the DNS community, the specific vendors, and few researchers. He did so to keep word from getting out.

But within hours of making his announcement, Kaminsky faced a chorus of public ridicule by other security researchers, most hearing about the flaw for the very first time. The complaints, at times, trivialized the announcement, with fellow researchers citing that similar claims had been made against DNS 3 to 10 years before or even longer. Some suggested Kaminsky was simply trying to advertise his talk at Black Hat next month.

Most vocal was Matasano Security researcher Thomas Ptacek, who blogged his doubts. But Kaminsky called Ptacek and he retracted his comments. He now says, "Dan has the goods. Patch now, ask questions later."

Whether or not Kaminsky knocks the socks off of everyone at Black Hat seems considerably less important than the responsible nature of his disclosure. He could have, as Ptacek notes, made thousands of dollars off this DNS thing. Instead, Kaminsky has set a high mark for future disclosures. He has changed Internet security, and done so for the better of us all.

On Thursday, Check Point Software Technologies released updated versions of all its ZoneAlarm products, addressing an incompatibility with a patch Microsoft released earlier this week.

The fix requires ZoneAlarm users to download the latest version, 7.0.438.000, from its site. A reboot is required to complete installation.

Since Tuesday, ZoneAlarm customers have complained that access to the Internet was denied after installing MS08-037, a patch designed by Microsoft to correct a vulnerability in both the client and server Domain Name System packages within Windows. Earlier on Tuesday, a security researcher announced a massive, multi-vendor patch release to address a fundamental flaw in DNS that could allow attackers to spoof IP addresses.

Workarounds included uninstalling MS08-037, changing ZoneAlarm's settings from high to medium, or temporarily using the Windows Firewall instead.

Check Point provided no additional comments about the cause of the outage.

Apple released a security update on Thursday for its Apple TV. Version 2.1 includes six patches that address buffer overflow and arbitrary code execution vulnerabilities.

Apple TV 2.1 can be automatically downloaded when the update is detected by the Apple TV device. The patches may take up to one week to be detected, depending on the day a device checks. A manual update can be accomplished by using the TV interface and selecting Settings > Update Software. This update will not appear in your computer's Software Update application or in the Apple Downloads site.

Here's an overview of the six patches, which affect only users of Apple TV:

1. The update addresses a buffer overflow vulnerability described in CVE-2008-1015. According to Apple, "an issue in the handling of data reference atoms may result in a buffer overflow. Viewing a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution." Apple credits Chris Ries of Carnegie Mellon University Computing Services for reporting this issue.
2. The update addresses a buffer overflow vulnerability described in CVE-2008-1017. Apple says "an issue in the parsing of 'crgn' atoms may result in a heap buffer overflow. Viewing a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution." Apple credits Sanbin Li, working with TippingPoint's Zero Day Initiative, for reporting this issue.
3. The update addresses a buffer overflow vulnerability described in CVE-2008-1018. Apple says "viewing a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution." This update addresses the issue through improved handling of format strings."
4. The update addresses an arbitrary code execution vulnerability described in CVE-2008-2314. Apple says "a URL-handling issue exists in the handling of 'file:' URLs. This may allow arbitrary applications and files to be launched when a user plays maliciously crafted QuickTime content. This update addresses the issue by no longer launching local applications and files. Apple credits Vinoo Thomas and Rahul Mohandas of McAfee Avert Labs, and Petko D. (aka pdp) Petkov of GNUCitizen working with TippingPoint's Zero Day Initiative, for reporting this issue.
5. The update addresses a buffer overflow vulnerability described in CVE-2008-0234. Apple says "a heap buffer overflow exists in the handling of HTTP responses when RTSP tunneling is enabled. Playing maliciously crafted QuickTime content may lead to an unexpected application termination or arbitrary code execution."
6. The update addresses a buffer overflow vulnerability described in CVE-2008-0036. Apple says "a buffer overflow may occur while processing a compressed PICT image. Opening a maliciously crafted compressed PICT file may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by terminating decoding when the result would extend beyond the end of the destination buffer." Apple credits Chris Ries of Carnegie Mellon University Computing Services for reporting this issue.

Recent e-mails stating that the U.S. has already attacked Iran and, in some cases, also offering links to a video purportedly from a soldier, are not to be believed, according to Websense. The security vendor said in an advisory Wednesday that it has linked the provocative e-mails to the Storm worm.

Storm got its name because it first took advantage of a huge winter storm in Northern Europe in early 2007. Since then, it has used a variety of social engineering tricks, including the use of political themes, to get unsuspecting users to open its malicious payload.

This time Storm is offering form.exe and iran_occupation.exe as executable payloads.

Acording to Dancho Danchev over at ZDNet, the latest iteration of Storm appears to be using the following domains:

• statenewsworld . com
• morenewsonline . com
• dailydotnews . com
• dotdailynews . com
• newsworldnow . com

A link from one of the Storm worm e-mails leads to this page.

(Credit: Websense)

Check Point Software Technologies, maker of ZoneAlarm, on Wednesday said it is working with Microsoft to resolve an issue with one of the patches within the software maker's July 2008 Patch Tuesday release.

At issue is the Microsoft Update KB951748 (MS08-037) from Microsoft, which addresses the flaw in DNS made public on Tuesday by security researcher Dan Kaminsky.

For ZoneAlarm customers who have automatic update selected for Windows Updates, and whose ZoneAlarm Internet security level is set to "high," they will experience a loss of Internet connectivity upon reboot.

ZoneAlarm users without automatic update may wish to wait to install the update until the matter is resolved.

For those who have already installed the patch, Check Point recommends users remove Microsoft Update KB951748 from their systems. Detailed instructions for doing this can be found here. Another option is to lower the ZoneAlarm Internet security setting to "medium," although Check Point doesn't recommend that.

On Thursday, Webmasters around the world noticed unusual spikes in traffic. For some smaller sites the sudden surge of Web traffic toward their sites appeared to be almost a denial-of-service attack.

Turns out it was the free version of AVG Antivirus 8.0 just doing its job.

In a statement on Saturday, Grisoft said "We have actively listened to the Webmasters who have brought this to our attention, and as a company we have reacted quickly to solve them." What it did was issue a new build of the popular free program.

What's different in version 8 from previous versions is the inclusion of Linkscanner, a scanner that stops malware components embedded on compromised Web pages. LinkScanner was created by Exploit Prevention Labs and purchased last summer by Grisoft, maker of AVG products.

One feature of LinkScanner, Secure Shield, works by downloading the home page of each site returned in a common Web search then populates the search result page with colored icons indicating the relative safety of those sites. The feature, which has been previously available, apparently didn't scale to the large numbers of AVG free customers. On Monday, Roger Thompson, who developed LinkScanner and is now chief research officer for Grisoft, confessed, "We knew it would create a spike of some sort, but nothing like what happened."

How dramatic was the surge in traffic? The site AVG-Watch.org provides charts on bandwidth use after the release of AVG 8.0.

In an e-mail to CNET News, Thompson went on to say: "We did not consider the multiplying effect of any given Web site's own marketing within search engine results. In other words, if a Web site, through its marketing, became a common search result, it was scanned much more often than we expected. As soon as we found out, we gathered some data, talked to some Webmasters, and figured out what to do."

However, Thompson disputed a claim by AVG-Watch.org that the updated AVG version now only "pretends to prefetch," and does little more than a DNS (Domain Name System) lookup of the site. Thompson said "it doesn't pretend to pre-scan. It just works off the local blacklist. That involves a DNS lookup, so that we can compare both IPs and URLs."

Making matters worse last week, AVG disguised the scans as coming from Internet Explorer 6 browsers, and not Secure Shield. For a few days it was unclear who was responsible for the surge in Internet traffic. Thompson said they could have made the LinkScanner scans entirely stealth, but they wanted to give Webmasters the option of filtering the scans.

"The real issue is that, like it or not, we're at war on the Web," said Thompson. "Criminals, both organized and opportunistic want our PCs and our money, and they're attacking via the Web. It's no longer like the old days when they wrote this stuff for fun."

Users of an older version of Microsoft Word could have their computers compromised after downloading and opening a specially crafted .doc file, according to an advisory issued late Tuesday.

Microsoft said only limited and targeted attacks have so far attempted to use this vulnerability against systems running Microsoft Word 2002 SP3.

To become infected, a vulnerable user would have to open a specially crafted .doc document. An attacker using this vulnerability would then have the same user rights as the victim. If a victim were running as administrator, the attacker would gain full access to the compromised PC.

Attacks such as this are often used against corporations and government sites as a means of gaining access to desktop computers inside the security perimeter and, eventually, to its networks shares.

In a press release, Microsoft's security response communications manager Bill Sisk said Microsoft could issue an update as part of its monthly Patch Tuesday program, or, if the situation warrants, it could issue an out-of-cycle update. At the moment, Microsoft is still investigating the matter. "Security advisories address security changes that may not require a security bulletin but may still affect customer's overall security."

Only users of Microsoft Office Word 2002 SP3 are affected. Not affected are users of Microsoft Office Word 2000 Service Pack 3, Microsoft Office Word 2003 Service Pack 2 and Microsoft Office Word 2003 Service Pack 3, Microsoft Office Word 2007 and Microsoft Office Word 2007 Service Pack 1, Microsoft Office Word Viewer 2003 and Microsoft Word Viewer 2003 Service Pack 3, Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats and Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats Service Pack 1, Microsoft Office for Mac 2004, and Microsoft Office for Mac 2008.