Showing posts with label Vulnerabilities. Show all posts
Showing posts with label Vulnerabilities. Show all posts

Thursday, November 26, 2009

How fast are Debian-flawed certificates being re-issued?

In 2008 it was discovered that the OpenSSL package in Debian had been producing low entropy public keys for about a year and a half on its Etch distribution. While it was relatively easy to patch the offending code (only a few lines), it was going to be more difficult to track down and re-issue all the weak public keys that had found their way into SSL server certificates. From my post on the topic

An article in the Register, called Debian's Epic SSL Blunder, states that the number of SSL certificates that may need replacing could be in the hundreds of thousands or even millions. So while the OpenSSL PRNG code can be easily patched, identifying and replacing all the weak keys generated by the flawed code is a big operational headache. It may be months or years before all the weak keys and their corresponding certificates are tracked down and upgraded.

At the Internet Measurement Conference (IMC) held in early November, researchers Scott Yilek, Eric Rescorla, Hovav Shacham, Brandon Enright, and Stefan Savage presented a study on the rate at which Debian-flawed SSL server certificates were being replaced. In short, the news could have been better.

The researchers tracked a collection of approximately 50,000 public web servers over a period of 6 months. Initially around 1.5% of the servers (751 to be exact) were using Debian-flawed keys in their certificates, and the observed rate at which these certificate were being re-issued  is shown in the graph below

image

The researchers stress that as compared to typical patching rates for general vulnerabilities, re-issuing certificates for the sample of weak servers was very slow. A long term study by Qualys reported this year that the patching half-life for vulnerabilities is 30 days, and so over a 6 month period we should see an exponential decrease in unpatched endpoints. However the graph above is approximately linear, and 30% of the Debian-flawed certificates were still not re-issued after almost 180 days. The authors conclude that

… unlike other vulnerabilities which have been studied and typically show a short, fast, fixing phase followed by levelling off, certificates were replaced on a slower cycle with substantial fixing extending well past five months after the announcement. We also found that in some cases certificate authorities continued to issue certificates to weak keys long after the vulnerability was announced.

Incidentally the researchers also found that approximately 2% of the sampled servers (1000 or so) were still using 512-bit RSA keys. While such keys are not as weak as those produced by the Debian flaw, recovering the associated private keys was recently shown to require nothing more than a  3-day desktop calculation. Nonetheless, this fraction of 512-but keys is a dramatic improvement over the results of a  survey conducted in 2000 which found that almost a quarter of the 8,000 servers sampled were using 512-bit keys.

Monday, June 1, 2009

Going, Going … Gone! Auctioning IT Security Bugs

clip_image002

One day in 1947 the Mark computer at the Harvard Computer Laboratory failed, and the cause was traced back to a bug (specifically a moth) found in one of its electromechanical relays. It was already common for engineers to attribute inexplicable defects to “bugs in the system”, but the Mark team had now found real evidence of one of these mythical bugs. The bug was taped into the Mark log book entry for posterity, and soon all computer defects were referred to as bugs. While the Mark story has passed into computer folklore, the bugs themselves have not.

Most bugs today occur in software, and part of the reason for this is sheer size. Windows XP has 40 million lines of code, which if printed out on A4 paper would stretch for over 148 kilometres when laying the pages end-to-end. If you wanted to check Windows Vista, you would have a further 37 kilometres of reading, and a further 180 kilometres for the Mac operating system. When software becomes this large and complex it is not surprising that some bugs are introduced.

Security bugs, also referred to as vulnerabilities, potentially permit an attacker to bypass security mechanisms and gain unauthorized access to system resources. Security bugs normally do not interfere with the operation of software and typically only become an issue when a bug is found and further exploited in an attack. The Zotob worm that infected many high profile companies in late 2006 exploited a vulnerability that had been undetected since the release of Windows 2000. In May 2008 a 25-year old bug in the BSD file system was discovered and fixed.

How are vulnerabilities found? Well software vendors uncover many bugs themselves, but a significant number of vulnerabilities are also found by third parties such as security software specialists, researchers, independent individuals and groups, and of course, hackers. Software vendors encourage these bug hunters to report their findings back to them first before going public with the vulnerability, so that an appropriate patch can be prepared to limit any potential negative consequences. In the computer security industry this is called “responsible disclosure”. For bug hunters that abide by this principle, the software vendors are normally willing to give kudos for finding vulnerabilities, and in some cases, also provide a nominal financial reward.

Over time bug hunters have started to become more interested in the financial reward part rather than the kudos. For example, in August last year a lone security researcher was asking €20,000 for a vulnerability he had found in a Nokia platform. Was this a good deal? What monetary value do you place on finding such a vulnerability? Software vendors want to produce patches for vulnerabilities in their products as soon as possible, while hackers want to produce code exploiting a known vulnerability as soon as possible. Considering these alternatives, how much should the bug hunter be paid for his or her services? Are low financial rewards from software companies driving bug hunters into the arms of hackers? Perhaps a market could efficiently create a fair price.

Charlie Miller certainly thinks so. The ex-NSA employee described his experiences in selling vulnerabilities in an interesting paper, and you can read a quick interview at Security Focus. Miller found it hard to set a fair price and had to rely significantly on his personal contacts to negotiated a sale – contacts that are likely not to be available to most security researchers.

In 2007 a Swiss company called WSLabi introduced an online marketplace where security bugs can be advertised and auctioned off to the highest bidder. This latest experiment in security economics appears to have lasted about 18 months and the WSLabi site is now unavailable. The marketplace started running in July 2007, and in the first two months 150 vulnerabilities were submitted and 160,000 people visited the site. Of those sales that have been publicly disclosed, the final bids have been between 100€ to 5100€. An example list of advertised vulnerabilities on the marketplace is shown below.

image

The WSLabi marketplace was controversial since many security people believe that hackers, or more recently, organized digital crime, should not have early access to vulnerabilities. In 2005 eBay accepted a critical vulnerability in Excel as an item to be auctioned, but management quickly shut down the auction saying that the sale would violates the site's policy against encouraging illegal activity. "Our intention is that the marketplace facility on WSLabi will enable security researchers to get a fair price for their findings and ensure that they will no longer be forced to give them away for free or sell them to cyber-criminals," said Herman Zampariolo, head of the auction site. In another interview Zampariolo explains that "The number of new vulnerabilities found in developed code could, according to IBM, be as high as 140,000 per year. The marketplace facility on WSLabi will enable security researchers to get a fair price for their findings and ensure that they will no longer be forced to give them away for free or sell them to cyber-criminals" .

Unfortunately the marketplace experiment was unexpectedly cut short. In April 2008 the WSLabi CEO Roberto Preatoni blogged about his regrettable arrest and the damage this had on the trust of WSLabi as a broker, notwithstanding being Swiss! Six months later in a public interview Preatoni remarked that "It [the marketplace] didn't work very well … it was too far ahead of its time". Apparently security researchers recognised the value of having an auction site like WSLabi, but very few buyers proved willing to use the site. Buyers seemed to value their privacy more than they value a fair price. Preatoni is now directing his company’s efforts to using zero-day threat information for the development of unified threat hardware modules – which you can read about on the last WSLabi blog post from October 2008.