This year, BlackHat had an entire Cloud Computing track, running all day on Thursday, of which I attended a great deal. Part of my job involves protecting cloud computing services, so it seemed very relevant, and it’s certainly a hot topic in the industry right now. It began with Alex Stamos, Nathan Wilcox, and Andrew Becherer presenting a lecture on cloud computing models and vulnerabilities.

They defined cloud computing as not just virtualization, but including general-purpose hosts, central management, application mobility, distributed data, low-touch provisioning, and soft failover. They looked at three different cloud models: Software as a Service, Platform as a Service, and Infrastructure as a Service, and the differences & vulnerabilities in each.

The Software as a Service (SaaS) model is to outsource everything. From a security perspective it’s not necessarily a bad idea — the cloud provider probably has a lot more security people than the average company. On the other hand, you also outsource all your data — the recent Twitter “breach” via somebody logging into Twitter’s Google Docs account shows the risks this can entail. You lose the perimeter, endpoint management, the ability to use better authentication than simple passwords, credential quality controls, password reset processes, and realtime anomaly detection (though you hope the cloud provider has some of these things.) It puts all your eggs in one basket — if someone can read your email, they can access all your data. SaaS products include Office Live, Google Apps, and Salesforce.com. None of these have decent audit & rollback capability; Google Apps at least provides login history (though you have to write code & call an API to get at it) but still no read/write level auditing. Salesforce.com offers some write logging. However, the biggest flaw with SaaS models may well be authentication — all your security relies on a password, with all the vulnerability that entails, and you can’t even set a strong password policy (for all the good it would do you.) Google Apps actually lets you use a SAML-based SSO system; with other SaaS apps the best you can do is set a strong password policy via employee education.

Another issue with SaaS providers is the legal concerns — the cloud service EULAs tend to promise basically nothing and disclaim all liability. Also, they forbid malicious traffic — even pentesting your own app. There’s also decreased protection from search and subpoena. Since the data is stored with someone else, there’s no Constitutional protection from search, and even statutory protection is usually only for “communication.” Are Google Docs communication? Courts haven’t really defined this yet. The net result of this is that there’s no need for a warrant, probable cause, or even notice of a search — you can’t fight a seizure before it happens, but only after the fact.

Platform as a Service (PaaS) is the model of having a common development platform provided, yet allowing people to customize their applications. This is the model of Google AppEngine, Force.com, and (maybe) Windows Azure. (Azure is a unique case, kind of halfway between PaaS and IaaS; I’ll come back to this.) This section of the presentation was rather odd, as they really looked at the common web vulnerabilities (CSRF, XSS, SQL injection) and investigated how the platform protected you from them. In short, the answer is that they don’t. Some of the platforms have some inherent protection available (e.g. Windows Azure apps are typically ASP.NET, which has some built-in XSRF protection via ViewStateUserKey, XSS protection via encoders, and SQL injection via LINQ), but it’s up to the developer to actually use them. I found this section somewhat lacking, because it wasn’t really about the cloud platforms at all, but rather the common web technologies sitting on them.

The Infrastructure as a Service (IaaS) model is that taken by Amazon EC2 and similar services. It provides virtual machines with short-lived instances, non-persistent local storage, and available helper services. Though the presenters thought of Azure as very much a PaaS model, I think it’s a little fuzzier here — while Azure does not allow you to choose an operating system (the Windows Azure OS runs on every VM), it does not constrain you to anywhere near the degree of Google AppEngine or Force.com, as you can run arbitrary native code on it. It would be impossible to use AppEngine or Force.com to run anything but a web site; Azure is like EC2 in that it could be used for any flexible computing task, not just web sites.

The problems with IaaS services are usually hypervisor flaws or problems in the helper services. However, they brought up something very new here that I don’t think any of the current cloud providers consider — lack of entropy. Virtual hardware has mostly deterministic timings — input events don’t exist and block device events are abstracted. Thus, entropy is generated very slowly if at all. What’s more, in the case of Amazon EC2, since OS images are available to everyone, an attacker can get a copy of the stored entropy pool you’re using (which will never update after the image is originally created, thus depriving the system of another source of entropy) and eliminate it as well. The net result of this is that pseudo-random number generators — even cryptographically strong ones — are unreliable and may be predictable. This attack may or may not be practical given the specifics of the system in question, but for now you may not want to build your online casino or public key infrastructure in an IaaS environment! Cloud providers may actually have to have random number generation as a helper service as well, supported by quantum hardware.

Next, Jeremiah Grossman and Trey Ford presented a sequel to last year’s talk on “making money the black hat way.” Essentially, it was a survey of interesting hacks-for-profit that have been carried out recently. They noted that hacking activity is up this year (layoffs create more hackers?) and that 69% of attacks are discovered only because a 3rd party tells the company it’s been hacked.

Some of the interesting ones: eBay gave away 1000 items for $1 in a “Holiday Doorbusters” promotion. However, almost 100% of them were bought by bots, which was evident because the items were purchased before the item description page was even viewed. StrongWebmail.com had a contest to give $10,000 to whoever could hack into the CEO’s webmail account; rather than attacking the servers, the winners of the contest sent the CEO phishing mail with an XSRF in it that stole the contents of the account. (Amusingly, they got him to open the mail by labeling it “I think I won.”) Grossman & Ford also brought up cookie-stuffing, a type of affiliate fraud that’s been around for many years; it’s a well-known technique in the affiliate marketing world (basically you spoof the referrer while iframing the advertiser’s site on your site, then drive traffic to your site in ways that would not please the advertiser if they knew about it) but was apparently new to most of the BlackHat audience. They also brought up the technique of using embedded site search to fake authority links, another well-known “black hat” SEO technique. Marketers have apparently also begun spamming Google Maps with fake businesses, so as to come up first in “local searches” with their web-based and not-remotely-local businesses. A man in Britain used Google Earth to find all the lead roofs in London, then steal the lead tile in the middle of the night.

Some of the more ambitious hacks were more intriguing, though. One man discovered that you could order “advance replacements” for broken iPods from Apple just by giving them a credit card number as collateral; he used low-balance anonymous Visa gift cards to get 9,000 iPods. Another group put their garage band music in the Amazon and iTunes stores using Tunecore, then bought hundreds of downloads of their own album with stolen credit cards (thus getting a big check from Tunecore.) One thing to note is that these people got caught only because they weren’t trying not to. The iPod guy shipped all 9,000 to his home address; the Tunecore fraud was so blatant as to get this garage band’s album onto Amazon and iTunes top-10 bestsellers.

Finally, in South America, the system for getting logging permits for the Amazon rain forest was put online. An investigation discovered that 107 different logging companies had hired hackers to compromise the site, which was full of common web vulnerabilities. All told, 1.7 million cubic feet of lumber were smuggled out of the country. Scary permit systems in the United States that are now protected only by a web site: entrance visas, hazardous material transport, and open burning permits.

Next, Haroon Meer, Nick Arvanitis, and Marco Slaviero presented a talk on “Clobbering the Cloud.” This SensePost talk covered much of the same material as the iSec Partners talk earlier in the day. Their primary risk factors for cloud computing were as follows: lack of transparency from cloud providers (opaque EULAs), people don’t want to store regulated data in the cloud, vendor lock-in especially if the vendor goes out of business or stops offering the service, availability concerns (not just servers being down, but also things like password lockout from DoS attacks), monoculture issues (worms and cascading compromise are a big concern when you have thousands of perfectly-identical boxes), and trust in the cloud provider — you have to trust your cloud provider implicitly not to lose your data or have system failures. In addition, there’s the problem that the cloud is available to the bad guys, too — cloud boxes can be used for click fraud, DoS, or spamming (for a short time Amazon EC2 was the net’s #1 spammer.) Finally, the security of your environment is all in the hands of the account owner, who authenticates with nothing more than a password, and is (in most companies) probably a non-technical executive. Breaking into the CIO’s email now makes you the global administrator of the company’s entire infrastructure.

The presenters then went into more detail about attacks on Amazon Web Services (EC2, S3, SQS, and DevPay) in particular. I can understand why they chose AWS; due to its flexibility, it’s certainly the most fun of the cloud services for a hacker to play with (though Windows Azure is getting there, too.) EC2 is based on a modified Xen hypervisor, and supports running any OS you want that can run in that environment. Amazon provides 47 OS images, but users have contributed over 72,000 more, and an EC2 user can choose to boot any of them. Sometimes user images have interesting things in them, like other user’s EC2 credentials, for example.

Scanning EC2 is prohibited, but you can start up one of the images and scan it yourself via an SSH tunnel (or even have the machine scan itself.) They found 646 Nessus critical vulns in Amazon’s public images; you can also steal Amazon’s own Windows activation keys off their images. The DevPay system is interesting; it’s supposed to allow a user to make an image then charge other users for its use (e.g. to resell an application on EC2.) However, the presenters found you could get a DevPay image and modify its ancestor info (stored in the image itself) so as to credit use of it to you rather than the original author, then reregister it for others to use.

Simply putting up pre-owned (pun intended) images for others’ use can be an attack on AWS. If you prop up a box with a good name (e.g. “Ubuntu 9.04 Standard Image, All Patches”) and a low-numbered ID (so it shows up at the top of the list), and people will use your image to host their apps! You can get a low-numbered ID simply by registering repeatedly; since it’s a hash, eventually you’ll get lucky and have one start with zero. You can only have 20 images per account, but you can create 20 accounts in 3 minutes, so there’s no effective limit.

After that talk, I went over to the mobile track to hear Jesse Burns talk about Android. Android interests me because I’d really like a phone that behaves like a computer (i.e. a device I own) rather than like a toy the phone company is reluctantly allowing me to touch, and Android’s open-source nature has real potential to give me that. It’s not that I trust Google any more than any other wireless provider, just that the platform seems much more hackable and thus inherently harder to control.

Android has a dual security model — Android permissions on various privileges, plus Linux permissions on the filesystem. Applications have their own UIDs/GIDs and are thus somewhat isolated from each other. A package (application) is made up of Activities (GUIs,) Services (background tasks,) Broadcast Receivers (event handlers,) Content Providers (databases,) and Instrumentations (used for testing.) For interprocess communication, there are Intents, which are sets of name-value pairs with routing information. Applications are written in Java, but they’re not applets (i.e. no Java sandbox.)

Available attack surfaces for a malicious app include other apps, system services under privileged accounts (like the clipboard or the surfaceflinger, which draws the UI and owns the screen,) the binder (the inter-process communication system, similar to domain sockets,) and anonymous shared memory. There are a variety of tools available — one can just install a bash shell on Android (either interactively or over the wire or network,) use logcat to look at logs, view Android system properties, check the /proc and /sys filesystems, run dmesg to get kernel output, and all the usual Linux attacks. There’s also a file in /data/system/packages.xml that contains data about every installed app, including the location of the app and its manifest. /proc/binder contains a transaction log of the inter-process communication, and /proc/binder/proc contains data of all the processes themselves.

Another interesting detail about Android is the “secret code” handler. When you dial *#*#somenumber#*#*, this triggers the secret code handler for that number, which can do pretty much whatever an app wants it to do. The only secret codes on “stock” Android are 8351 and 8350, which turn voice dialer logging on and off, respectively. However, wireless providers may add additional codes — the presenter found some in T-Mobile’s MyFaves app, for example. Finally, the presenter had a series of Android hacking apps he’d developed — Manifest Explorer (to view the system manifest and the manifest of each app, such as to see what events they react to,) Package Play (to see the parts of a package or to directly activate Activities,) Intent Sniffer (to view Intents as they’re routed at runtime,) and Ill Intent (an Intent fuzzer.)

The last presentation of the day was Bruce Schneier, whose talk was entitled Reconceptualizing Security. Mostly, he gave the same speech he always does, about fear, psychology, security vs. security theater, why we mis-estimate risk, etc.; pick up a copy of Beyond Fear or Secrets and Lies if you want the details. However, during Q&A he did also talk about the attack on AES-256 that was just demonstrated. It’s a feasible attack on 10 rounds of AES-256 (out of 14,) in 2⁴² time. It’s a related-key attack that works only on 256-bit keys (not on shorter ones,) so there’s no reason to panic right now, but it does show that the margin of safety on AES is smaller than we thought. There may need to be a Double-AES in the same way Triple-DES was devised as a stopgap until a new cryptosystem is developed. Alternately, the standard could be changed to increase the number of rounds, but that would require replacing or updating all the AES-based crypto hardware out there.

And that wrapped up BlackHat 2009. Overall, there was nothing as Earth-shattering as last year’s DNS exploit, though it turns out that the SSL issues are pretty nasty. After BlackHat, I hit the Microsoft Security Researcher Appreciation Party at Christian Audigier, which was actually a pretty good party this year without any of the problems of previous years. It’s only drawback was that it only ran two hours. However, at this point DefCon festivities had begun, so there was still plenty going on; my next post will get into DefCon 17.

a

The Wednesday keynote was presented by Douglas Merrill, the COO of EMI Records, formerly of Google, RAND Corporation, and several other places. He spoke on a popular topic for security conference keynotes — risk assessment and innovation. 80% of CEOs believe they’ve had a data breach, even though the statistics show that it’s basically impossible for the actual rate to be that high. And most of the breaches that do happen are trivial — looking at Privacy Watch’s statistics, 16% are lost laptops, 11% are paper that’s thrown away, etc. Actual hacker activity accounts for only a small percentage of the breaches — certainly not enough to justify what we spend on security. We constantly try as an industry to come up with “security ROI” metrics to show execs, but most of them are just nonsense; we make up numbers, then multiply them by numbers we also made up, and that’s how much you saved in the security breaches that didn’t happen but might have.

The #1 driver of security for CEOs is BCP (business continuity planning) — they just want to make sure things keep running no matter what. For security people, the #1 driver tends to be compliance — because it’s a stick with which we can make executives spend money even when they don’t want to. Due to the huge downside of a breach for us (since our job is preventing them, having one happen looks really bad), we overinvest in prevention.

Merrill’s point was that this overinvestment in security can stifle innovation, especially when perimeters (my favorite thing to hate, I know) are involved. People use consumer tools because the enterprise tools restrict them too much. Giving people control of their machines promotes innovation, and companies where people are free to innovate are more profitable — but giving people control makes endpoint security impossible, and reduces control by security and IT. We risk our jobs by doing the right thing for the company, and so we continue to do the “safe” thing even when it doesn’t make sense. Overall, it was a pretty good keynote — nothing revolutionary in it, but certainly food for thought for an audience of security professionals.

The second talk I attended to was three “mini-talks” about new Metasploit functionality, presented by Dino Dai Zovi, Mike Kershaw, and Chris Gates.

Dai Zovi adapted Meterpreter for the Mac. He created a Mach-O function resolver, and found one in the OS that wasn’t covered by the library randomization. His payload injects a remote execution loop, creates a bundle in RAM, then loads and executes it (neat trick, very hard to do in Windows but apparently easy on a Mac.) This can be used to load either Dai Zovi’s CocoaSequenceGrabber payload (which forces the webcam to take photos and send them to the hacker), or Macterpreter, a Meterpreter port by Charlie Miller. Pretty much all of Meterpreter works except process migration (processes owned by the same user can’t write to each other on Macs), so it should be good for all your Mac-hacking needs. He’s also added 4 exploits from the Mac Hacker’s Handbook to Metasploit.

Kershaw sought to adapt all the old shared-media attacks (i.e. what we did in the 80′s and 90′s on hub-based Ethernet) to WiFi. His LORCON2 library translates between 802.11 (WiFi) and 802.3 (Ethernet), so you can spoof ARP, DNS, even TCP connections. This gives you the airpwn attack in Metasploit — you can spoof, say, urchin.js or other common embedded JS files, give them a cache lifetime of a decade, and have someone’s browser calling home for a good long time even when they move off the unsafe network. Open and WEP networks literally can’t be secured against this, since you can spoof the AP to the client (so no AP-based defenses can be effective — the AP doesn’t even see the attack.) If you have the key, you can even do this on WPA-PSK (by forcing deauths and spoofing the AP.)

Gates essentially ported every Oracle attack of the last 10 years to Metasploit (all 11 of ‘em.) Since Oracle charges for updates, there are tons of vulnerable servers out there (albeit not usually on the Internet.) There’s a TNS mixin, and an Oracle DB access plugin that executes queries via Oracle Instant Client (on Linux and Mac OS only, though Chris offered a reward to anyone who would port it to Windows this weekend.) It can grab the SID from the server on Oracle 9, or brute-force it on Oracle 10 (or sometimes grab it, depending on what Oracle modules are loaded.) All of these exploits were old, but they’re now really easy to perform.

David Lindsey and Eduardo Vela gave a talk on bypassing XSS filters. They weren’t looking at escaping/sanitizing functions, but rather HTTP IDS and other external anti-XSS measures.

They went through a long list of HTML tricks that can be done to evade these filters. Omitting whitespace, using / for spaces (did you know <img/src=”file.gif”alt=”text”> — no spaces — is treated as valid HTML by most browsers?), roundabout parameters (using separate<param> tags for everything even when you don’t have to), using data= rather than src= in tags that support it, embedding JavaScript in weird tags like <isindex>, prepending useless namespaces on tags (e.g. <x:script xmlns x=….>), using alternate syntax (why say “document.cookie” when “document[cookie]” or “with(document)alert(cookie)” will do), etc.

They even went into truly strange things, like using the ternary operator to make strings that were valid as both HTML and JavaScript but had different meanings in each, or using deprecated or broken syntaxes (which tends to be browser-specific.) Adding multiple parameters with the same name has undefined behavior, but works in some browsers. With Unicode, you can pad small (one-byte) characters out to extra bytes, which shouldn’t work but is accepted by some Unicode implementations (including Java and PHP.)

Perhaps most interestingly, filters could often be bypassed by ridiculous measures — such as using prompt() instead of alert() when testing for XSS, or using ‘ or ’2′=’2′ instead of ‘ or ’1′=’1′ to test for SQL injection, or /etc/x/../passwd instead of /etc/passwd. Some badly implemented filters just look for specific attacks, not general patterns.

Dan Kaminsky had managed to keep his talk secret this year, so we went into it knowing nothing but that it was “something about network security.” His talk was entitled “Black Ops of PKI,” and covered some vulnerabilities involving X.509 certificates (a theme I’ll revisit a lot when I do my DefCon writeup.) 60% of data breaches are not due to vulnerabilities, but just bad password handling — and PKI, based on X.509 certs, was supposed to fix all that. Of course, what’s actually been implemented is not really what most of us mean by PKI — the universal directory of distinguished names was never built — but certificates are everywhere now.

For those of you not familiar with them, X.509 certs are the basis of SSL/TLS and many other encrypted protocols. A certificate is supposed to indicate that the entity presenting it really is the entity named in the certificate. These are signed by various Certificate Authorities, which all themselves have certificates signed by other authorities, chaining all the way to the Root CAs, which have their certificates just built in to your browser & other software. As long as you trust the root CAs to validate other CAs, and trust those CAs to only sign legitimate certs, the system should work. But… that’s a lot of trust.

The problem is, X.509 can’t exclude — every CA can issue certs for every name. It’s too hard to interoperate with private CAs, so companies promise to behave and root CAs like VeriSign give them a signed intermediate certificate, allowing them to give out valid certs for anyone. What’s more, these certificates depend on various hashing algorithms for their security (since the hashes are what gets signed.) RapidSSL used MD5 for its signatures, and last year some security researchers took advantage of known issues in MD5 to create their own intermediate cert that was “signed” by RapidSSL’s signature. Luckily, that group had no intent to abuse the cert, so RapidSSL moved to a better hash and all was well.

Kaminsky discovered that one of VeriSign’s own certs is self-signed with MD2. There’s not even any good reason to self-sign a root cert, but they always do (because people — and programs — just expect a cert to be signed.) MD2, like MD5, has known vulnerabilities — it’s subject to a preimage attack that will eventually let someone create their own root cert that VeriSign’s self-signature works on. The complexity of this attack is outside our capabilities right now (2⁷³), but won’t be for much longer. This certificate was replaced by VeriSign (with one signed in SHA-1), but it will still probably be a long time before every client gets it off the list.

Much more interesting, though, were attacks on CAs themselves via PKCS#10 (the protocol by which you request a certificate to be issued to you.) When you request a certificate, you provide a “distinguished name”, part of which is the “common name” (domain name, in the case of SSL certs), as a specially-formatted string (it’s fixed-length, not null-terminated), in a binary package. Originally, requesting a cert was a manual process with lots of in-depth verification, but now it’s all automated. Kaminsky asked… what happens if you have multiple common names in one distinguished name? (Undefined; different CAs and clients do different things.) The identifier for common name is 2.5.4.3… what if you provide 2.5.4.03? Is that the same? The strange binary protocol means it may be, and 2.5.4.2⁶⁴+3 might be, too. What if there’s a null in the name? Since the protocol uses Pascal strings (length specified) rather than C strings (null-terminated), nulls in the name are valid, but practically every SSL client there is blows up at them.

And that was about it. Kaminsky ended with a recommendation that we embrace DNSSEC, so we can put certificate hashes in DNS. Unlike X.509, DNSSEC can exclude — we can ensure that only the authorized owner of a domain can provide its certificate, as well as make it possible for domains with EV certificates to exclude normal certificates for that domain. After what Dan presented the previous two years, this one seemed kind of disappointing — an MD2 cert and some parsing flaws in CAs? That’s it?

Actually, it turns out that these are devastating, and essentially render SSL unable to protect communications on untrusted networks (you know, precisely the places where you want SSL to protect you.) Smart hackers will be picking up wildcard certificates while they can, as CAs will be scrambling to fix this. As to why, I’ll explain that during my DefCon Day 1 writeup — Moxie Marlinspike and Mike Zusman presented research (apparently done at the same time as Kaminsky’s) that actually exploits this stuff.

The last presentation I went to on Day 1 was Riley Hassell‘s talk on “Exploiting Rich Content.” The description made this sound like it was about attacking web sites that use rich content (e.g. Flash, Java, Media Player, QuickTime, etc.), but it was actually about attacking the content engines themselves (e.g. making Flash malware), which, to me, is a much less interesting space. But then, my job is protecting web sites & services from attack, not being Adobe.

Hassell demonstrated how, using a fault injection fuzzer called FlashFire, he found 23 vulnerabilities in Flash on 785 codepaths, most of them being read-beyond-bounds issues. Normally those aren’t considered terribly serious, but since Flash runs in a browser, they can be. Essentially, it’s possible to write a Flash component on one web page that steals all the information in your browser’s memory space. If you have your bank’s website open in another tab, that could obviously be a bad thing. It’s quite the scalable bug, considering as Flash is installed on 99% of browsers, and the bug works on all platforms.

And that was it for Day 1. I went to an IOActive reception at Spago, met some interesting people (most of them from IOActive), and called it a night — most of the BlackHat nightlife seems to be on Day 2. I’ll update this post with links to the presentation decks and/or videos when they become available online (decks will probably be relatively soon, but BlackHat does not usually post videos until months after the conference since they are sold for a pretty hefty fee at first.)

a

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (“something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

a

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.

a

Schneier mentions Microsoft’s BitLocker in passing, and I wanted to add some detail. BitLocker is a whole-disk encryption system integrated into Windows Vista, and integrates with the Trusted Platform Module if available (the TPM is a smart chip on the mainboard that stores keys and performs secure cryptographic operations.) You tell BitLocker to encrypt your drive, and then choose one of several options for how to store the key. The simplest mode simply prevents someone from mounting the drive in another system or operating system, by storing the key in the TPM and retrieving it automatically on boot (this actually does make it significantly harder to get at the data on the disk without your password.) More complex modes store the key in the TPM and require either a PIN code from you or a certificate stored on a USB key to extract the key. Thus, on booting your PC you enter your PIN or insert the key, and the drive is unlocked.

The PGP product Schneier advocates encrypts the drive similarly to BitLocker, though rather than storing the key in the TPM it relies on a user-supplied passphrase to decrypt the key. While this is theoretically less secure (with the TPM, even the encrypted key is stored in tamper-resistant hardware and difficult to access), in practice it makes little difference — it’s still quite secure, and unlike BitLocker will let you encrypt other drives.

However, one feature BitLocker has and PGP lacks is key escrow. Now, this is normally thought of by privacy activists as an anti-feature, remembering the Clipper Chip fiasco of the late 90′s. However, the purpose of BitLocker’s key escrow is not to give a back-door key to the government, but rather to make the system palatable for enterprise deployment. Large corporations have traditionally been unwilling to embrace whole-disk encryption products like PGP even on laptops carrying sensitive data, for fear that the person with the key will forget the passphrase or simply leave the company and refuse to disclose it. By having the BitLocker keys escrowed with the domain controller such that appropriate corporate officers can retrieve it, it makes BitLocker “safe” for corporate use. If you’re not a domain member (i.e. it’s your home computer), then the keys aren’t escrowed with anyone else — there’s no government back-door.

Schneier rightly points out that an issue with any sort of whole-drive encryption is that they do not protect your data from government subpoena. If the government seizes your computer as evidence, they can (in the United States at least) subpoena the keys, and if you don’t turn them over you can be fined or jailed for contempt of court. This is not an issue for most (legal) data, but if you have something to hide from everyone, there are solutions other than the one Schneier posits (“just don’t keep data on your laptop that you don’t want subpoenaed.”) One option is the open-source disk encrypter TrueCrypt.

The problem with encrypted data on your disk is that it’s really obvious. It is not plausible to say “Oh, I don’t have any encrypted data” if served with a subpoena. For one, you probably have encryption software on your computer, and links to data that can’t be followed without decryption. But besides that, encrypted data is provably, mathematically distinguishable from almost everything else. Encrypted data consists of a binary blob with a uniform distribution across its entire data space — that is, any given byte is just as likely to be 00 as it is to be 01, 02, 03, or any other value. If you plotted it on a histogram, given enough data the graph would be approximately flat (subject to the variation and “clumpiness” always present in random data) and there would be no more repetition than expected by random chance. This is unlike every other type of data — executable programs, graphics, sound, word processor files, spreadsheets, etc. all have their own characteristic histograms and repeated patterns. Even compressed files have specific, recognizable headers and certain characteristic patterns (though they come closest to looking like encrypted data, since they have high entropy.) Thus, encrypted data stands out because it is “more random” than any other data on your hard drive. Since no one keeps large blobs of totally random noise on their hard drive, if one is found, it’s pretty certain to be encrypted data, and the courts know this (or at least can be convinced of it by expert witnesses.)

TrueCrypt has the feature of being able to place an encrypted volume inside an encrypted volume. Combined with the fact that it pads encrypted volumes with random noise, this leads to the ability to have plausible deniability of encrypted data. Essentially, it works as follows:

1. You create a TrueCrypt volume on your hard drive with a specified size, say 10 GB. TrueCrypt reserves that much space, and fills it with random noise.
2. You create a second TrueCrypt volume, with a different key, inside the first volume, with a smaller specified size, say 2 GB. TrueCrypt takes that space and fills it with different random noise.
3. When you want to access encrypted data, you mount both volumes. You put really secret stuff on the inner volume, and moderately secret stuff (e.g. pirated MP3s) on the outer volume.

Now, if someone gets your laptop, they can see that you have TrueCrypt installed, and that there is a 10GB encrypted volume (as there’s a 10GB blob of random noise on your hard drive.)  They force you to give them the key, and you do so.  This unlocks the outer volume, revealing its encrypted files.  However, there is no sign that the inner volume exists.  Unless you know it’s there, and know the key, there is no way to distinguish the random noise of its encrypted files from the random noise TrueCrypt filled the outer volume with anyway.  There could be a dozen encrypted volumes, or none — it’s impossible for anyone to know, and indeed, most people without a security mindset would never even think of such a thing.

Now, there are drawbacks to this technology.  If you mount the outer volume but not the inner one, neither TrueCrypt nor your operating system knows about the inner volume, either!  This means that writing files to the outer volume may overwrite and destroy the inner volume if you’ve not mounted it.  This isn’t a major problem, but it is inconvenient, especially if you have many volumes (as you need to type in the different passphrases and addresses of all of them every time you want to write to any of them.)  And no automation will help you, because having any would defeat the purpose — the existence of automation scripts would tip off a smart forensic investigator that your outer volume contains inner volumes.

It’s an interesting solution to the problem of plausible deniability — using steganography to hide encrypted data in encrypted data.  Admittedly, Schneier’s solution (just don’t have the data at all) is even safer, but sometimes that’s not good enough.

a

Essentially, they embed a smart chip and an LCD display inside a bank card. When you need the password to your account (such as to log into online banking), you type your PIN into the card itself, and the display shows your password. This provides true two-factor authentication (something you have — the card — and something you know — the PIN) for online financial transactions, and is tamper-resistant.

Now, OTP tokens are not new. RSA has been producing the SecurID line for over a decade. However, they have not been widely adopted for online banking because of bulk and inconvenience. Nobody wants to have an extra device (they’re usually keychain fobs) that they have to find every time they log into their bank’s website. People want this even less because of the lack of standardization — you’d need one for every bank or credit card you have, and you’d need to be able to tell them apart. Embedding it in the card itself, though, solves this customer inconvenience. After all, you have the card on you anyway.

The trick now is to get banks to actually adopt this thing. This is very convenient for customers, and makes them substantially more secure. However, it requires the banks to actually buy the devices for all their customers — and eMue/InCard don’t say on their web site what they cost. An RSA SecurID keychain fob, however, costs $86, so I wouldn’t be terribly surprised if the cost to the banks of these cards is similar. And because of the costs, banks, like corporations, are inclined to go for what Alex at Worse Than Failure whimsically calls “Wish-It-Was-Two-Factor Authentication:” simply requiring you to provide something you know, and… something else you know.

The problem is that passwords are simply not very secure anymore. There was a time when even a modest password (say, an 8-letter combination not found in the dictionary) was pretty secure against most attackers. However, that time has passed; there are too many ways to crack a password. For example, if I want a user’s password so I can log into his online banking site, I could:

1. Lure him to my website, which installs spyware on his machine which records what he types.
2. Intercept his communication to the website and grab the password (mitigated by SSL login)
3. Steal his session cookies and hijack the session (mitigated by using SSL beginning-to-end on the website — common for banks/financial institutions, but rare for online email and other sites)
4. Wait for him to sign onto a public wireless hotspot, spoof the bank’s website, and steal the password with a man-in-the-middle attack (gets past the mitigations in #2 and #3)
5. Break into his email account, tell the website I “forgot” my password, and read the password-reset email it sends
6. Break into the banking website itself and get the encrypted password file. Admittedly, in this case I probably don’t even need to get his password anymore. But if I do, I can then use a rainbow table to break the encryption in seconds. A 12-character password with numbers and symbols still falls in seconds.
7. Break into any other website the user subscribes to; chances are he uses the same password on all of them
8. Send a phishing email tricking the user into supplying me with his password. He won’t fall for that? Send one asking him to sign up for some other service and create a username and password, then see #6

Password strength is irrelevant. Today, there’s really only two levels of password strength:

1. Guessable — blank, “password,” “secret,” your pet’s name, your wife’s birthday, a dictionary word
2. Not guessable — something meaningful only to you

There is not much variation in #2 — whether your password is “i like cheese” or “jR3&sJ7#iK9(wV2$” makes little difference (it makes no difference whatsoever to the 8 attacks listed above), but the former is far easier to remember. The problem with passwords isn’t that they’re too short, or not complex enough — it’s that a password is just data, and there are many ways to steal data.

So why do banks and corporate IT departments keep harping on longer, more complicated passwords? Why do banks require you to answer “secret questions?” (Technically called cognitive passwords — things like “what was your high school’s mascot?” — these are really just extra passwords, only required to be easily guessable.) Simple — it passes the cost, both in money and in effort, on to you. Asking the customer to answer extra questions, or the IT user to remember harder passwords, puts the onus of maintaining security on them. The IT department or bank doesn’t have to do anything at all to implement these “solutions” — it just asks you to do it. In the case of banks, there’s the added benefit of making people believe (falsely) that they are more secure by jumping through these hoops.

The problem is that these methods don’t actually do anything. Asking for “something you know and something else you know” is pointless; whatever method is used to steal the first password can also steal the cognitive password. Requiring strong passwords mitigates only against attack #6 above (stolen password database), and these days it doesn’t do even that (if your password is under 14 characters I can crack it in seconds with a rainbow table; even if the hashes are salted, preventing that sort of attack, distributed cracking with GPU offload will still get it in days.) What is needed is true two-factor authentication — not just for banks, but for anything online for which real authentication is required.

Unfortunately, this requires banks to shoulder the cost of providing either a token or a biometric reader to all their customers. The token is the simpler solution, though it has the disadvantage that, since there is no common token infrastructure out there, every bank or site has to do it. A biometric solution would scale better (one reader for every site,) but has a first-mover problem (which bank is going to give you the reader, thereby subsidizing all the other banks you use?) and may have robustness issues. This token-on-a-card technology is a good way to provide real security without inconveniencing the customer, and I hope to see it go somewhere.

Unfortunately, this is a case where the “security theater” (as Bruce Schneier calls it in Beyond Fear) interferes with real security. Banks have been telling us that their sites are secure, and their silly questions keep us safe. How do they now convince us that we’re not safe and we need to prefer the bank with the token-on-a-card? Without competitive pressure, there’s little incentive for banks to spend the money — but banks are loath to exert competitive pressure that harms public trust in the banking system.

a

Password hashes have been weak for quite a while now — as far back as 1997, it was practical, if you got a hold of the SAM hive from a Windows machine or the shadow file from a UNIX machine, to brute-force crack the passwords stored inside so long as they were relatively short and didn’t make use of obscure characters (hence all those “password complexity” guidelines urging you to use long, incomprehensible passwords.) However, at this point you could usually crack even a strong password in a few weeks using a desktop machine. This development cuts password cracking time by a factor of 20 or more.

Why is the GPU so much better than the CPU for cracking password hashes? Parallelism. Rendering a screen of graphics essentially consists of doing one task — figuring out what color a pixel on the screen should be — many, many times every second. As a result, graphics cards are optimized for doing many simple tasks simultaneously. CPUs, on the other hand, can do one task much faster than a GPU, but only do one thing at a time (multitasking is largely an illusion, as the CPU switches between tasks very quickly.) We’re just now seeing dual-core and quad-core CPUs, but a “dual-core GPU” would be nonsensical — they’ve got 10 or more processing pipelines already.

The Elcomsoft software further speeds up password cracking by allowing you to offload processing to many different machines, so each box tries a different section of the keyspace. If you have access to many machines, this can make it a very quick task.

Of course, sometimes you don’t need to go through this much work to crack a password. For any Windows password 14 characters or shorter, you can already crack it in seconds with a rainbow table attack. There are even online services that will do it for you for a small fee — you input the hash and PayPal a few bucks to them, they give you the password; if you’re willing to spend a few days on BitTorrent getting 64+ GB of data, you can get your own rainbow table for free.

So how do you make a safe password, when a table can crack it in seconds or new software in days, no matter how good it is? You don’t. There is basically no such thing as a strong password anymore — there is the total insecurity of having no password, or the moderate security of having a password. If someone manages to break into a server that your password works on, they will get your password if they want it. Not re-using passwords on multiple sites and servers is thus quite important if you care about what’s on it (we all use the same password on random registrations on the Internet, but you shouldn’t use that password for banking, too.) However, the only long-term solution to this is two-factor authentication; the password alone just isn’t enough anymore.

a