Defense in Depth

LAS VEGAS--On the second day of the Black Hat security conference, a trio of journalists turned on other journalists within the press room.

This was my ninth Black Hat in nine years, and I have lived in dread year after year that such a headline would affect me. On Thursday, CNET News was named as one of the two organizations "hacked," but I disagree that any such hack occurred.

Just before noon on Thursday, a trio of reporters from Global Security Mag sat in one of the two press rooms at Black Hat. Both rooms have a wired LAN that is a separate part of the wireless network open to all attending the security conference. What happened on Thursday was not a wireless attack--it is important to stress that. Most of the reporters in the press room are veterans of security conferences and take precautions against such attacks. Even so, the press room is separate from the conference and often a safe harbor for posting our stories to the Internet. Conference speakers and members of the Black Hat staff also use this network.

Mauro Israel, one of the Global Security Mag reporters, is alleged to have used a USB on his laptop to turn it into a gateway for all Internet packets going through the wired network switch located at each table in the room. In other words, he routed all the signals going through the LAN through his computer and used a program called Cain to view the packet information. It is unclear how long this was done. Log files seen by CNET News suggest it might have only been a short period before lunch on Thursday.

Cain, the tool used to view the packet information, can be a helpful network administrator tool. But in the wrong hands, it can also be used to gain access to a network in violation of federal wiretapping laws.

After lunch, Isreal, Dominique Jouniot, and Marc Brami from Global Security Mag moved to the table where I was sitting with my colleague Elinor Mills. I use a commercial encrypted VPN service to connect to my office remotely; Mills uses the corporate VPN we have at CNET. We suspect that when I left the table, the trio turned their attention to CNET. Mills, also a veteran of many security conferences, offers a first-person account of being targeted here.

The reporters' badges sit on a chair after they were confiscated.

(Credit: Declan McCullagh/CNET News)

Ironically, I left the table to go and interview Aries Security, the guys running the Wall of Sheep, a project that passively monitors the wireless open network traffic at Black Hat and Defcon for the purposes of educating users on safe practices. What I didn't realize was that Brami, Jounio, and Isreal had been talking with the Wall of Sheep guys just prior to my arrival. One member of Aries Security, Riverside, even made a comment about "journalists hacking journalists."

I didn't get the reference at the time.

Apparently, Israel and his colleague tried moments before I arrived to get the usernames and passwords for reporters from eWeek and CNET added to the Wall of Sheep, a display of partially obscured usernames and passwords that is sometimes referred to as the "Wall of Shame." Riverside and others at Aries Security told them they would not post journalists' names to the Wall of Sheep because the press room was on a network separate from the one they were monitoring.

Another reporter that had been sitting in the Wall of Sheep room, Humphrey Cheung of TGDaily, overhead the conversation with Brami, became curious, and was allowed to take a photo of Israel's laptop screen. Those photos are important. The images that appear on the TGDaily site are redacted, of course. I later saw the originals.

What the trio of French reporters offered the Wall of Sheep was a Cain log with columns for timestamps, HTTP, client, username, and other information. From the log screen, it is apparent that on Thursday, beginning at 10:55 a.m., there were packets captured that were going out to eWeek.com. The IP address in the log resolved to a log-in page, presumably for a publishing tool used at that publication. The Wall of Sheep asks that submissions be done via Notepad file, so Israel pasted the username, password, and destination IP address into a file.

One eWeek reporter, Brian Prince, later confirmed his username and password were collected and displayed. eWeek immediately changed his password. Prince was not using a VPN for reasons he explained here.

But here's where it gets curious. A second line was added to the Notepad file, this one purportedly showing log-in information from news.cnet.com. When I saw the un-redacted photo, I knew instantly that the reference to CNET was a fake. My colleague Declan McCullagh resolved the IP address given as the destination to the CNET News home page--not a tool page, but our standard home page. That could be explained as anyone in the press room could have surfed to that page.

What tipped me off that the reference to CNET was truly bogus is that the username was a word within the code of the home page, a word anyone might find by right clicking and viewing the page source. Second, the password "control" wasn't strong enough, nor did it belong to Declan, Elinor, or myself. It was a fake.

I went back to the Wall of Sheep. Riverside was incredibly helpful, confirming that reporters from Global Security Mag had been there offering some log data. He even had the business card for Marc Brami, director of the publication. Moments later, a spokesperson for Black Hat confirmed that conference officials were looking for Brami and his colleagues as well. The three were later required to leave the conference and are banned for life from Black Hat and its sister conference, Defcon.

What I don't understand is if this was a prank--as Brami has suggested to Mills--then why didn't they simply say to Prince or anyone else in the press room that they could see their network communications? And, if they simply wanted to send a message to U.S. journalists about laptop security--as they reportedly suggested to the Black Hat officials--why did they apparently lie about CNET also being exposed?

A strange thing happened on Thursday. As the story unfolded, reporters from competing publications gathered in the press room. It was a bonding moment. The protected network in any press room is a circle of trust, and when that trust is violated, bad things can happen. Potentially everyone in the room had been a victim. And as such, we rallied around each other for support.

As a result of Thursday night's events, I think I know my security colleagues a little better, and that's a good thing. They're good, hard-working reporters. But in the future, if anyone I don't know joins me at a press table, I'm going to interrogate them, and a few others have told me they will as well, and that's a bad thing.

Like the biblical story, this instance of Cain has also brought evil into a world that was previously safe and welcoming.

Kurt Opsahl, left, a senior staff attorney at the Electronic Frontier Foundation, discusses the ejection of the three French journalists over networking snooping allegations.

(Credit: Declan McCullagh/CNET News)

Click here for full coverage of Black Hat 2008.

LAS VEGAS--This year marks my ninth year of attending Black Hat in Las Vegas. From a small gathering of security professionals in 2000 to an uberconference in 2008, Black Hat has scaled well. And the transition from private company to corporate-owned also appears smooth. But hardly anyone's here yet.

On Tuesday, there are only a thousand or so attendees of the 30-some training sessions. Already I've noticed a few minor changes from last year.

The press room is now on the third floor, away from the maddening crowds. This may or may not work since almost all the sessions are on the fourth floor. So far the escalators have been jammed during breaks and it will only get worse as Black Hat ramps up.

Lunch, served in a tent located in the front of Caesar's Palace, is now buffet as opposed to being a serviced meal. This gives quicker access to the food (no more waiting until everyone at your table had finished a course before the next course was served). However the buffet itself (at least four different food stations) also removed a good chunk of tables and seats. By my count only one thousand people can eat at one time.

To accommodate the rest of us, Black Hat is also serving boxed lunches on the third floor. My lunch ticket is for a boxed lunches. I suspect that vendors and press will be shunted into the cold box-lunch room.

There are about 30 vendors set up across from the Augustus ballrooms. Last year it was impossible to move from session to session without bumping into the vendor tables. While this year's location is better, it's still not ideal. Perhaps next year Black Hat will simply shunt the vendors into a separate room. Those who want to chit-chat with the vendors can do so, while the rest of us get to our sessions unimpeded.

The hall for Dan Kaminsky's DNS talk seems too small. Maybe they'll simulcast it on jumbo screens in the hallway. We'll see on Wednesday.

Click here for full coverage of Black Hat 2008.

Jay Foley, co-founder of the Identity Theft Resource Center, told me recently that 57 percent of all identity fraud involves opening new accounts "for short-term gain." The ITRC should know: it has been surveying ID fraud victims for several years and has amassed some impressive real-world statistics.

Foley also said 13 percent of the identity theft victims found out about the attacks only after criminals had established utility or cable service in their names. "So your credit record is more theirs than yours, making it harder to fight them in court," he said.

Clearly the best solution is to stop credit fraud at the moment it starts, when the account is first applied for, but for years credit histories and scores lay shrouded in mystery.

Fortunately, there's greater transparency with regard to credit reports these days. Since 2003, the Fair and Accurate Credit Transactions Act, or Facta, makes it possible for individuals to request one free annual credit report from each of the three major credit reporting agencies. (Go to AnnualCreditReport.com.) Initially, it was to correct any errors in the credit report; many people, however, use this process to monitor their reports for credit fraud.

While you can request all three credit reports at once, experts recommend staggering these, requesting one from a different reporting agency every 90 days or so. That way you'll see a comprehensive view. In addition to requesting your credit report, Congress, through laws such as the Fair Credit Reporting Act (FCRA), has provided other tools for monitoring your credit activity.

A fraud alert placed on your credit history requires an issuing entity to contact you first before opening a new account. Fraud alerts need to be renewed every 90 days unless you are a documented victim of identity fraud, in which case you are entitled to additional protection for up to seven years.

Another option is to place a credit freeze on your credit history. As of November 1, 2007, all three major credit reporting agencies offer this option. Lenders looking to issue credit in the name of someone with a credit freeze will be unable to access the credit history without your explicit permission. In most states there is no termination date, however there is a $10 fee to institute a freeze, and a $12 fee to lift it whenever you want to allow a credit check. These fees are waived if there is proof the individual is an identity fraud victim. The main advantage of a credit freeze over a fraud alert is that the credit freeze does not expire. Credit freezes, however, do not apply to entities with whom the consumer has an existing account. Nor do they apply to law enforcement agencies and certain governmental agencies.

The plans from Experian, Trans Union, and Equifax are similar, each providing a complementary credit report from all three reporting agencies, continuous monitoring of credit activity and any online use of your personal information, and some insurance against identity fraud abuse. The plans range from $11 to $14 per month, with annual and family plans available for less. They do not, however, place alerts or a freeze on your credit history.

This creates a market for private identity protection companies. One of the first was TrustedID, which costs $10 per month per adult (with annual and family plans available) and places both a fraud alert and a credit freeze on your credit history (requiring you to be contacted in both cases), opts you out of credit offers, $1 million in loss insurance, scans for personal data on the Internet, and monitors change of address. TrustedID also scans for medical fraud and protects against spyware.

Providing similar protection is LifeLock. This company is perhaps the best known because its CEO advertises his personal Social Security number as an example of how secure the company is. Bruce Schneier recently did an analysis of what's right and what's wrong with LifeLock as did the CNET Blogger Network's Chris Soghoian.

The Achilles' heel in all of these plans is that the financial institution does not have to make a reasonable attempt to contact you, so the fraudulent account may still get opened. Even with a credit freeze, some financial intuitions won't contact you. There's no way to prove or disprove an institution called you, said ITRC's Foley.

Until now.

Back in 2004 a guy named Bo Holland took a gamble. He bet that that identity fraud would only get worse, not better. And he was right. Having built a series of start-ups within the financial services industry, Holland had an insider's perspective on the problem; he knew how banks and other institutions handled credit requests; he also had worked at Critix Systems, so he had understanding about application delivery. With his latest start-up, Debix, an identity protection network, Holland pulled together all of his skills.

Not only does Debix put a credit freeze on your profile, but it uses its own phone number to log whether the credit institution tried to contact you. And if you're not available, Debix puts the pending account or loan on hold until you are able to return the call. And by using a Debix phone number, not your home number, on your credit report, that adds another layer of security to the product.

So how does Debix work in the real world? Say you are at a car dealership and you need to finance a new car. Shortly after the salesperson leaves the showroom floor, your mobile phone should ring. That's Debix; you know it because it's your voice saying a secret code. Then Debix asks if you indeed are seeking to establish a new account. If yes, you type in a secret personal identification number.

Say you are on vacation and Debix conveys a permission request for a new account. Since you didn't request a new account, you press star and you are instantly put in touch with a Debix investigator, who then contacts the party requesting the credit check. The advantage here, says Holland, is that the ID fraud case is still hot. In some cases, Debix has been able to identify a particular IP address and then turn that information over the local law enforcement. This saves local law enforcement time; they don't have to get a warrant for the bank's information--Debix has already provided the information.

Jerry Dixon, former director of the National Cyber Security Division of the U.S. Department of Homeland Security, told me that there are many reasons why ID fraud cases aren't investigated.

"An assistant U.S. attorney might ask 'What's the likelihood of this going overseas?' 'What is the likelihood of being able to nail down who this is without having to write 20 subpoenas first?'"

If the IP address goes out to Belarus, then Dixon says forget it; the U.S. no longer has a law enforcement attache in Belarus so it's hard to enlist sympathy from law enforcement in that country. But if a company like Debix can provide law enforcement with details from the financial institution and a party willing to press charges, your odds of getting someone arrested improve.

Sound too good to be true? In a study published by Julie Fergerson, vice president of Emerging Technologies, and Debix's Holland, the authors looked at 30,000 Debix-secured transactions during a two-month period at the end of 2007. Of those, 380 were identified as fraud and were stopped immediately. Overall, the rate of new account fraud among Debix customers was zero percent.

ITRC's Foley said he was impressed with the results within the survey. Holland told me that during the survey period there were four instances of new account fraud. In each case, however, the financial institution did not call the customer. With Debix, though, you have some recourse. Debix maintains a record and can prove the institution in question did not attempt to call the customer.

Since learning about Debix in June, I've been trying to knock the protection, but so far cannot. Holland, it turns out, is no stranger to the computer security community; since 2004 he's been showing his wares and soliciting opinions at Defcon in Las Vegas. He invited Phil Zimmerman, creator of Pretty Good Privacy (PGP) to fault it, and he could not. Holland has invited other computer hackers to pick apart his logic. Even Foley and Dixon are full of praise for Debix.

And it gets better.

As of Monday, Debix is lowering its prices "way down" says Holland. One adult can sign up for $24 a year; families with up to three adults and four children can sign up for $72; and families with up to five adults and four children can sign up for $144 a year. That's much less than similar plans being offered by Experian, Trans Union, Equifax, TrustedID, and LifeLock. And Debix has been protecting people since 2004, so it's not some untested entity.

If you can name a more secure ID protection service for less cost, I'd like to hear from you.

For the last few months, I've been hearing some well-regarded security people tell me they are considering ditching their antivirus protection all together. They haven't done it, but these individuals feel the days of having a special application scan to remove malware on your desktop are numbered. Malware has changed, but the applications to ferret them out have not.

Antivirus programs, as we know them today, are based on 20-year-old technology of pattern matching. Pattern matching may have worked in the days of the Micheangelo virus and even as recently as Netsky, but methodically matching each and every file on a computer against a list of known malware is getting tedious, if not archaic. In 2007, Symantec detected more than 1 million viruses, with two-thirds created within the calendar year. Loading 1 million signatures, or even a percentage of that if generic signatures are used, is a pretty serious undertaking.

That's why vendors are talking to me about newer strategies for 2009 (and beyond). Among these is the exact opposite of signature file databases--something called whitelisting. If pattern matching is just another way of saying certain bad files have been blacklisted, whitelisting goes to the other extreme: it only allows certain trusted files to run on your machine.

That's more or less what Symantec CEO John Thompson called for at this year's RSA: "If the growth of malicious software continues to outpace the growth of legitimate software, techniques like whitelisting--where we identify and allow only the good stuff to come in--will become critical." He actually didn't say much more about whitelisting, yet everyone talks about this speech as though Thompson had provided clear guidance the year of whitelisting.

So how viable is whitelisting? Turns out we've been using it to defend against spam for years.

To see how whitelisting works on an enterprise level, I spoke with Tom Murphy, chief strategy officer for Bit9, a Massachusetts-based company that has been quietly leading the way in whitelist technology.

For several years Bit9 has been building what it calls a Global Software Registry or GSR (formerly called Bit9 Knowledgebase), cataloging "known good" and "known bad" applications and files. Murphy said Bit9 uses three methods--MD5, SHA1 and OMAC--to create a unique hash of the file and ensure that the file is what it says it is. For the moment, the catalog is used for Bit9's enterprise products. But they've entered into an agreement with Kaspersky, who will be using the registry for its 2009 desktop security products.

Bit9 is not alone. SecureWave's Sanctuary, Savant Protection, and DriveSentry have also been creating whitelisting technology for the enterprise. What's interesting is that the big guys Google (Green Border Technologies), Microsoft (Winternals Software's Protection Manager, and now Symantec have started paying attention to whitelisting.

Which gets us back to antivirus software.

If hosting a million antivirus signature files is daunting, how many "clean" files might there be? Think about all the versions of software that exist, not to mention the files those products create.

The downside of whitelisting, indeed the main argument, is that all those clean files outnumber the bad guys by a considerable margin. Right now, maintaining a whitelist file is impractical for the desktop.

Trend Micro (if it wants to get into the whitelist space) thinks it has the answer. For the last few years, Trend Micro has been building servers around the world to provide continuous service to its Software-as-a-service enterprise systems. Last month, Trend Micro CEO Eva Chen told me it's time to bring that SaaS service down to the desktop. Instead of having all the signature files on the desktop, the desktop app would instead ping "the cloud" and get results from the much larger database of known malware stored there.

Make no mistake, Trend Micro is still using antivirus signature databases. Chen said even after 20 years, there are still advantages to pattern-matching antivirus signature files. For one thing, she says it's faster than firing up a heuristic sandbox and testing each individual piece of malware. True, although we're talking about shaving nanoseconds between the two processes. Still, with several thousand files, those saved nanoseconds do add up. So instead of running the operation on the PC, the PC sends all its unknowns to a server in the cloud and gets the results back lickety-split. An added benefit, says Chen, is that new samples are submitted in real time and evaluated quickly. In her estimate, Trend Micro can have a new signature file for an unknown threat ready within 15 minutes.

Fifteen minutes is also the new mantra over at Symantec. For its 2009 Norton products, Tom Powledge, vice president of consumer product management at Symantec, told me the new products are lighter and faster in part because they've jettisoned the multiple copies of the signature database found in previous versions. They're also not scanning each and every file. Instead, the 2009 products will be building a trust index--that is, the app will declaring certain files (say photos or MP3s) clean and then not scan them again unless the files change. He showed me a graphic where roughly 70 percent of a given machine is trusted, and only that last 30 percent is actively scanned.

Like Trend, Norton is experimenting with faster new malware turnaround. Powledge says Norton should be updating not every 15 minutes, but every couple of minutes. This is a vast improvement from hourly or even daily updates by some antivirus vendors.

Given the improvements to the traditional antivirus programs proposed by Trend Micro and Symantec, are the days of antivirus applications numbered?

Yes.

I asked Murphy if white lists worked well enough to replace traditional antivirus protection at some companies. He answered, very diplomatically, "if (a customer) feel(s) that they have a control over the environment, some customers have removed antivirus off their machines."

I'm still not convinced that white listing is the way to go, but I do know that security solutions in the enterprise space have a way of trickling down to the desktop.

It's a question I get asked a lot: what's a good way to remember passwords for a computer?

Here's how Christopher Horn over at Real Simple chose to answer it:

Writing down random log-in user names and passwords is unsafe and leaves them vulnerable to getting lost. Use a spreadsheet or a word-processing document to keep track of all the information safely. List the link for each website you have an account with and the specific user-name and password information that goes with that account. Click the Save As option under the File tab and name the document. The Save As window will have an Options or Security Options key, which you should select. Navigate through the menus, entering the necessary password--for both opening and modifying the document--until you have successfully secured and saved your list. To retrieve the information, open the file and enter one password to access all the others.

I disagree.

There are some problems with Horn's answer. What happens if you want to log in to an account using a different computer? And, shouldn't you encrypt the file as opposed to just using a password?

Even the security people at Microsoft have told me that using the passwords within Windows and Office aren't necessarily your strongest security option. I know that password protection within Word or Works can be defeated with a variety of password-cracking programs. John the Ripper is perhaps the best known program and uses lists of common dictionary words to brute force unknown passwords. Chances are, Real Simple readers will probably use "password" as the password for their password list. But, still, placing a password on a file (placing a lock on it) is not the same as encrypting the entire file (scrambling the contents so only you can read it).

Me? I go low-tech. I write down all my passwords with pen and paper and do so in such a way that it would take someone a long while to associate a password with a given account. I also change these passwords from time to time. And I don't store my low-tech, highly obfuscated password crib sheet anywhere near my computer.

For a more thorough discussion of the various issues around passwords and password management, check out Elinor Mills' latest CNET News feature.

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.