So Your Private Key Has Been Compromised

 
 
By Larry Seltzer  |  Posted 2008-05-21 Print this article Print
 
 
 
 
 
 
 

The Debian OpenSSL bug is one to take seriously. The possibilities if you don't are not pleasant to contemplate.

Internet alert systems such as the ISC's Internet Threat Level and Symantec's Threatcon may have gone back to "Green," but it's way too early to say the Debian OpenSSL bug has played itself out. I think this is one of those problems that will be exploited for months, if not years to come.

Most of the time when there is a serious security-related bug, those at risk have the job of applying patches as soon as possible, and that can be an imposing enough task. But that's not all in this case. In this case you also have to generate new keys *after* you update the software. And you may need to create new certificates and have them signed by a certificate authority, or deploy them to certificate repository, and you may need to use them to sign other items such as program files.

Rest assured that there are still lots of small ISPs and businesses that are vulnerable. Someone will figure out, rather easily it turns out, that they have the vulnerable keys and crack them.

Then what? The question I haven't seen asked yet in this is what the implications are of having someone exploit your weak cryptographic keys. Here are some scenarios.

I think it's fair to guess that the overwhelming majority of digital certificates are used for SSL (Secure Sockets Layer) for secure Web sites. SSL in such cases is used both for encryption and for authentication, and so those functions could be compromised. Are you surfing an SSL Web site from a public Wi-Fi connection? Other people on the network can sniff your packets and decrypt them. Same deal if they're on the same physical LAN as you; they can sniff the network, and your user names, passwords, credit card numbers and so on are theirs. Oh, and on the subject of encryption, SSL VPNs that use certificates generated with weak keys are also completely vulnerable.

You Didn't Plan to Enjoy the Weekend, Did You?

As for authentication, an attacker could make a much more convincing phishing site by faking up the same certificate as the site. Faking a code-signing certificate is an especially interesting possibility. Or, if I have access to the physical network, I could fake up a client certificate and log in, and then all sorts of inside attacks are possible.

Or if that's not enough, consider this entry from the taint.org blog discussing the possibility of an SSH worm. Scanning for vulnerable systems over the Internet is easy and fast. Bang, someone's logged into your box, although what account they have and what privileges it has is less clear.

No doubt there are lots of small sites set up by consultants that sit, relatively forgotten because they run perfectly fine, that now have a problem.

If I were running an enterprise that I thought might have vulnerable systems in it, I would do some of the scanning discussed in the taint.org blog and see if I could find any internally, or from the outside.

And if you've got weak certificates issued by VeriSign and you need to revoke and republish, note that VeriSign is offering those services for free through June 30 to those affected by this problem. This also applies to GeoTrust, thawte and RapidSSL certificates. No word yet from other CAs (certificate authority), but VeriSign is the 800-pound gorilla in that market. It's yet another reason to move fast in dealing with this problem. You weren't really planning to take any time off this weekend, were you?

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack.

 

 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel