I don’t usually post about newly-discovered vulnerabilities, simply because there are so many of them — a dozen come out every day, especially in web applications.  However, this one has further-reaching consequences.  Security researcher HD Moore (of Metasploit fame) has discovered a vulnerability in the OpenSSL cryptographic random number generator used by Debian Linux, the widely-used distribution on which Ubuntu is based.  As I have discussed before, flaws in the RNG underlying a cryptosystem can compromise the entire system — both block ciphers and public-key systems rely on a source of entropy to create the large numbers they work with.  If the bits of entropy in this source is smaller than the key length, a “back door” is created — instead of cracking the key, you essentially “crack” the RNG, by trying all the possible seeds and seeing which one produces the key you need.

In this case, the result of this OpenSSL bug (an erroneous “bug fix” made in 2006) is to reduce the entropy in the seed to only 15 bits — a terribly small number (32,768) in cryptographic terms.  Moore was able to produce all the possible SSH keys that could be generated on this system in a matter of hours, save for those few people using 8192-bit RSA keys (and he’ll have those in a few days, too.  He’s placed them all on his website for download.

So what are the implications of this?  The most important one is SSH authorized keys.  SSH is the secure replacement for Telnet and FTP; security-conscious administrators and users use it instead of older protocols.  SSH has an option wherein instead of using a password to log in, you can save a set of keys in your user account, so that when you connect to another server the keys automatically authenticate you.  It’s quick, convenient, and generally more secure than passwords — and thus secures the most sensitive accounts (such as root) on almost all Linux-based servers.  With this exploit, it goes from being more secure than passwords to being much less secure — 32,768 guesses and you’re sure to get the right one.  This can be automated in a couple of hours if there is no lockout on the target machine (and the root account is normally not protected by a lockout since doing so means that an attacker can intentionally lock out the legitimate administrators.)  You could even use this as a local attack — log into your webhost account and run a script that will shortly give you root access to the server (from which you will have root access to most of the other servers at the hosting provider, too.)  Moore’s website includes a couple of scripts that can easily do this.

The nasty part about this is that keys are sticky.  Upgrading your Debian/Ubuntu servers to fix the bug is, of course, required.  However, also necessary is to replace every key generated on a Debian-based machine in the last two years (since 5/2/2006.)  It’s quite a task for administrators to even find all of those keys.  The first step is that if you use SSH to or from a Debian system, you need to immediately delete your authorized_keys and generate new sets (after applying the patch for this bug, of course.)  After that, it’s important to make sure all your users do the same.  Purging the SSH keys of all the users is not going to be a painless process and will undoubtedly involve some support cost, but keep in mind that not doing so is the equivalent of having all your users using 3-character lowercase alphabetic passwords.

The harder problem, though, is this: this bug isn’t really in SSH, it’s in the OpenSSL libraries.  These are commonly used by all sorts of apps to generate keys — OpenSSL is practically the Linux equivalent of CryptoAPI/DPAPI on Windows.  Everything uses them.  Essentially, every key generated on a Debian-based system for any purpose whatsoever in the last two years is potentially vulnerable.  You won’t be able to use HD Moore’s linked scripts to crack these, but they are all potentially cryptographically feasible now.  This is a major breach; if the NSA didn’t already know about this vulnerability (which I wouldn’t rule out), they’re no doubt engaging in a flurry of excited codebreaking right this minute.

Auren Hoffman at Summation has an interesting post on the “black hat tax.”  Essentially, how much do hackers and other online criminals actually cost us?  He estimates it at 25% of time and resources, after taking into account not just hackers but also scammers, phishers, and responding to law enforcement requests.  According to James Currier (who founded a good number of social-networking type sites, some of which are quite substantial), this “tax” is 25-40% for consumer Internet companies, with it being especially high in unexpected places (like online dating sites.)

That’s a lot of money.  More importantly, it’s a lot more money than most managers think we’re spending on security.

Now, the accuracy of these statistics is obviously dubious — even a respected and experienced person’s ad hoc estimate is still just an ad hoc estimate.  But it’s worth thinking about this for your company.  How much time and effort gets spent on problems that are, if not strictly security problems, problems you wouldn’t have were it not for malicious users?  This includes not just the things you do to defend your sites (firewalls, IDS, code reviews, etc.), incident response, and responding to subpoenas.  It also includes having to carefully write & test your emails to make sure they don’t get caught in spam filters, and setting up logging & auditing on your sites so you’ll be capable of responding to a subpoena if you get one in the future, and planning for regulatory compliance, and some of your disaster recovery & backup costs.  Consider not just purchases of security hardware & software and the hours of work by the security team, but also all the time consumed by product development and IT teams planning for or responding to security threats.

This “black hat tax” is your real security budget.  And importantly for security managers, this is a genuine, demonstrated cost, as opposed to the “risk” we spend most of our time talking about.  It’s one thing to say the company might suffer a $10 million loss in the case of a data breach, so we need to spend more on security.  Managers can go on believing that “it won’t happen to us.”  It’s quite another to say that the company already does lose $500,000 every year due to the cost of dealing with malicious users, and that we should spend that same money proactively, on planned security measures, rather than spending it reactively.  Don’t just think of your security budget as simply mitigating risk — think about what your company is already spending, just not on the security team.  Can you prevent some of that cost from being incurred?  Can you centralize some of these effors?  Security spending as a way to reduce cost, rather than as a cost center, may be a lot more appealing to your CIO.

A story in the New York Times tells us that Charter Communications (the United States’s fourth-largest cable company) is going to start tracking user behavior and using it to sell ads.  They spin this as a potential problem because of privacy implications — it means that the cable company is watching your web surfing so it knows what ads to show you.  While they say it will be anonymous (i.e. they only know that a specific tracking cookie is associated with one user, but not who the user is), when it comes to an ISP this simply isn’t true — they do know who you are (due to billing information) and if they were not-so-politely asked (i.e. with a subpoena) they would be able to associate your tracking cookie with you as the individual user.  As a matter of policy they don’t associate the tracking profiles with individual users’ personal information and share it with their advertising partner — but they have the data, which means law enforcement can have the data.

However, all the discussion about privacy in the article is, in my opinion, a secondary issue.  As I’ve discussed before, using an ad replacer has other effects that may be much more serious.  It means Charter is now mounting a man-in-the-middle attack on all its customers and editing the web pages they view.  Thus, if there are any security flaws in the NebuAd software (like, say, a cross-site scripting vulnerability as we saw with Barefruit in a previous post), they are now embedded in every web site viewed by every Charter customer.  When you’re a large ISP like Charter, this makes it worthwhile for hackers to try to attack the system — being able to steal the bank account passwords of every Charter customer at a given bank is almost as good as being able to do it to all customers of the bank.  It may only be 10% of people, but 10% of everyone is still a lot of people.  In addition, Charter customers are no longer contributing to the revenue of the web sites they visit (which could be interpreted as an attack on those websites by Charter — they just stole all their revenue.)  I don’t much expect Charter to care, nor their customers, but the more ad replacers that are out there, the less advertising is able to support web sites.

So, what to do if you’re a Charter customer?  Well, you can opt out of the tracking system by setting a cookie, which means the ads you’re served will not be targeted.  However, the ads probably will still be replaced, so you’re still not helping pay for the web sites you visit.  And chances are that Charter could still come up with a record of all your web surfing if they were served a subpoena.  If you want to avoid that, the only choice is using an encrypted tunnel and mix network like TOR (which law enforcement has probably at least partially compromised, but this puts them in a situation like the Allies after they broke the Enigma machine — if they use evidence from a TOR compromise to prosecute you, then they give away that they’ve compromised the network and criminals will stop using it.  Thus, you’d need to do something pretty serious for them to be willing to admit they know about it.)  And what to do if you’re an advertiser-supported website?  Not much.  You can lobby for net neutrality laws, or ban Charter customers outright (which will hurt you more than it hurts them.)  However, I would expect Google, DoubleClick, and other ad networks to start working on obfuscating their ads soon if more major ISPs embrace ad replacement.

According to the EFF blog, customs has taken to randomly searching electronic devices for suspicious data.  It is somewhat mysterious what they are searching them for — given only a few minutes and a technically unskilled border guard doing the searching, it’s hard to imagine them actually finding anything better hidden than a file on the desktop labeled “terroristic threats.doc” and a hyperlink to the Al-Qaeda Homepage.

Thus, from a security perspective, this just isn’t a good idea.  There’s a large tradeoff in inconvenience, delay, and civil liberties violation for a miniscule increase in security.  However, it does get me thinking about an interesting problem — how does one hide data from people inclined to search your electronic devices for it?

A legal search is a totally different kind of threat from a hacker attack.  With a hacker attack, you simply have to keep them out of the data — with a legal attack, you have to hide the existence of the data, as the legal system has at their disposal an additional channel for getting the data — they can subpoena it and demand you disable any protective measures and hand over the data.  Thus, encryption — the primary defense against data disclosure to hackers — is of limited use against a legal attack.  (And note that a “legal attack” doesn’t just mean law enforcement or other rightful authorities — it also means attack via lawsuit.  Abuse of the legal system is not limited to the political administration — competitors and other adversaries can and do use the legal system to get at things they shouldn’t have.  In other words, this information isn’t of value only to criminals — there are a lot of perfectly legitimate reasons to hide data.)

The EFF points out a few possible ways of avoiding scrutiny from customs:

• Create multiple accounts on the machine, and just log in with an account with nothing sensitive in it when asked to log in.  This is basically taking advantage of the lack of technical expertise on the part of the searcher.
• Take only the data you need on the trip — just minimize what there is to find.  This is a good idea anyway, but probably unsatisfactory if you are carrying, say, diplomatic communications.
• Bring no data at all, and when you arrive at your destination, retrieve the information via VPN.  Before flying back, VPN the data back and delete it.
• For sensitive business communications, have the data encrypted by someone else who provides the key only when you arrive at your destination.  This would work to protect the data, but it also means that, being unable to comply with an order to reveal the data, you may just have to miss your flight.

I have two more that they didn’t mention:

• Encrypt the data onto something that is not an “electronic device” subject to search, like a CD-ROM, USB key, or whatever.  It no longer falls under the search provision.  Obviously it could be searched if you were actually arrested or sued, but it gets around this particular issue.
• Use TrueCrypt Hidden Volumes.  Merely hiding an encrypted file on a disk will not hide it from a skilled attacker, because cryptographic data is distinctive.  Statistically, it has a uniform distribution, which makes it look unlike any other kind of data except white noise (random numbers.)  Essentially, it looks so bland and generic that it stands out — because no real data is that essentially devoid of information.  Since nobody keeps a hard disk full of random noise files, if one exists, it must be encrypted data — which means you can be subpoenaed for the key.  TrueCrypt’s hidden volume feature gets around this in a novel way, which I’ll discuss below.

Hidden volumes take advantage of the similarity between random noise & encrypted files.  A section of disk is reserved for an encrypted virtual disk.  When this is created, it is filled with random noise, which is replaced by encrypted data as needed.  The trick is that you can create another encrypted virtual disk inside the first one.  So long as some data is in the “outer” volume (as no one would have a huge encrypted file on their hard drive with nothing in it — it’s not plausible), there is no evidence that the “inner” volume even exists unless you have the key.  The inner volume’s encrypted data blends into the outer volume’s white noise.  Thus, you put slightly-secret data in the outer volume, and really-secret data in the inner volume.  When asked to reveal the key, you reveal the key to the outer volume only, and have plausible deniability of the inner volume’s existence.

As with any countermeasure, though, there are limits.  If you’re hiding from the NSA or some foreign government’s equivalent, just putting a couple TrueCrypt volumes on your laptop’s hard disk will not do the job.  The problem is that the operating system and the applications you use may leave traces that reveal the existence of the inner volume (e.g. Word’s file history notes that you opened a file on Drive F:, when your laptop doesn’t have an F:…)  For extremely sensitive data, it would be necessary to not only put it in a hidden inner volume, but also to only ever access that inner volume from an ephemeral operating system (e.g. a LiveCD, or an OS you boot off a USB key and load into a RAMdisk.)  If the OS you use never makes any changes to the disk outside the encrypted volume, evidence of the volume remains hidden.  You would of course want a normal OS and outer volume to be present and used, for plausible deniability to be present (as, once again, it’s not reasonable to have a laptop with only random noise on the hard drive.)  You would also want to access the outer volume with the laptop’s native OS after any session in which you accessed the inner volume (as otherwise the access date on the encrypted file could be newer than the last boot date on the OS, once again leaving a breadcrumb trail.)

And all this makes me wonder once again what the government plans to get out of casually searching the data on laptop hard disks.  The only people whose data will be discovered are those with nothing to hide.