BlackHat started out with a keynote from Jane Holl Lute, Deputy Secretary of Homeland Security. She gave the sort of banal, predictable speech we expect from a political appointee — the country needs a secure homeland, dynamic economy, and the rule of law. “Cyberspace” isn’t a warzone, because wars happen somewhere, kill people, are lawless, and “cyberspace” isn’t like this. (The one sure sign you’re listening to a government official is the constant use of the prefix “cyber-”. An even more sure sign is the use of “cyber” as a noun by itself, which so far as I can tell is done only by feds.)

She states that the five essential missions of DHS are to prevent terrorist attack, secure borders (while expediting trade & travel), enforce immigration laws, ensure the safety & security of “cyberspace,” and help build a resilient society. While I really like the emphasis on resilience in her rhetoric, I do wish DHS had more visible efforts in that direction rather than appearing to be wholly focused on prevention. She also laments that billions have been spent in cybersecurity, but the most fundamental problems still aren’t fixed, and claims that the administration wants to build a cybersecurity strategy and vision for the nation. I find this claim curious for two reasons: first of all, billions have been spent on physical security, too, and yet we don’t seem to have “fixed” crime and violence, so why should we expect information security to be any different? And second, DHS saying we need a “cybersecurity” strategy implies that they don’t have one.

Jeff Moss seemed far more excited about this talk than its content warranted. Simple politeness to a speaker, or the effect of his presence on the Homeland Security Advisory Council? Also, during Q&A one person asked her why, given that the TSA is the laughingstock of the world, we should expect DHS to do any better with the Internet. (While the question is admittedly a cheap shot and not an actual argument, her response — which was to say that the TSA is just fine and not mocked throughout the world at all — did not exactly inspire confidence either.)

My first session after the keynote was called Base Jumping, by the Grugq. This was one of two major talks about cell phone hacking on GSM this year. The GSM protocol specification runs dozens of documents and thousands of pages, but according to the Grugq, the important one is GSM 04 08, which defines layer 3.

GSM is based on TDMA (Time Division Multiple Access,) so decoding is based on time — the clock in a phone must be synced with the clock in the base station. Only a tiny amount of data is sent per timeslot. There are only 23 bytes in a timeslot, so you can do a complete exhaustion fuzzing in 3 days (and he did.)

Communication is done over a variety of named channels. BCCH (broadcast control channel) is how a base station sends out its information messages. PCH (paging channel) announces incoming SMS or phone calls. RACH (random access channel) is used by the phone to request a channel, which it gets back over AGCH (access granted channel.) Opening a channel is slow – it takes 2-3 seconds. Since it’s based on timeslots, can take quite a while for the base station to have an open slot of the appropriate channel to reply in.

Collisions are frequent since channel number is just 25 bits, and some cheap phones actually hardcode a list of random numbers instead of generating them (apparently generating a 25-bit number is just too hard for them.)

Police sometimes use IMSI catchers, which impersonate the network and make the phones all hand over their IMSI (International Mobile Subscriber Identifier — your ID off your SIM card that tells the phone company who you are.) The protocol is flawed — the phone authenticates with the network, but the network does not authenticate to the phone, and thus can be impersonated.

A German group built an open-source baseband for a common, cheap cell phone (the Motorola C118 or C123, about 5 Euro on eBay.). This can then be hacked to send arbitrary GSM traffic. Among the Grugq’s apps were:

RACHell: request channel allocation, then flood the base station with requests. This will DoS the entire cell by using all the channels. A cell can only hold about 1000 users. Since the cell is backed up to a base station controller (BSC), this attack may take down the BSC as well (which shuts down the whole tower for half a day.)

IMSI Flood: send IMSI ATTACH messages, indicating a user coming online. These are sent pre-authentication, and if you send too many random numbers as IMSIs, it can overwhelm the HLR/VLR infrastructure (the database that tells which tower has which phones attached to it) and takes down the whole network. This could also be used to make police IMSI catchers pretty much useless. I got the idea that the Grugq had not actually tested this, since taking down a cell network might get a little unwanted attention.

IMSI DETACH: When phones are turned off, they tell the network they’re no longer available via sending a single unauthenticated frame. If you have someone’s IMSI (which you can look up by phone number for $0.006,) you can send one for someone else, which disables that phone from receiving calls or SMS and cuts off any in-progress phone calls. The victim can still make new calls, however, which will reattach them to the network — but if you’re sending DETACHes every 5 seconds, this will do little good.

Baseband fuzzing: fuzzing the baseband (the radio in individual phones) by impersonating the tower pretty much causes every phone available to crash. However, lacking the code for the basebands, the Grugq didn’t find any remote exploits here. However, the overall point is that GSM is no longer a walled garden — anyone can send GSM traffic with minimal equipment now, and protocol security is required.

The next session I attended was More Bugs in More Places, by David Kane-Parry of Leviathan Security. This was an overview of the SDKs and security models for Android, Windows Phone 7, BlackBerry, and iPhone. There was nothing particularly new here, nor did he come to any conclusion as to the superiority or inferiority of any one of the platforms, so I’m not going to go into details.

The next talk was Barnaby Jack of IOActive with the wildly popular topic of jackpotting ATMs.

Current ATM attacks are mostly skimmers, physical theft, Ram raids (dragging the ATM away with a truck,) card trapping and shoulder surfing PINs, or frontal attack via safe cutting or even explosives. Barnaby Jack wanted to instead attack the software. Most new model ATMs are Windows CE based, with an ARM/Xscale processor, remote connection via TCP/IP or dial-up, with SSL support and a Triple DES encrypted PIN pad. Since the developers of Windows CE developers concerned were more concerned with protection (in the process sense) than security, this provides an opportunity.

To reverse engineer this, he bought a couple of ATMs and had them delivered to his house (which the delivery people found rather bizarre, but did.) ATMs boot directly to a proprietary ATM application. In order to get a shell, he connected a JTAG interface for full debugging access to the processor core, set a breakpoint on CreateProcess(), and replaced the target ATM executable string with explorer.exe. With explorer, he could connect a USB disk and keyboard and copy files off for offline research, make registry changes permanent (so as to always boot Explorer), create a debugging environment, then set up remote app debugging in Visual Studio.

The external attack surface is limited to the card reader, keypad, network, and motherboard inputs. This leads to two possible attack plans — remote over the network ,or a walk-up attack. It turns out the walk-up attack is quite possible, since while the cash is protected by a two-inch-thick steel safe, the motherboard is protected by a one-key-fits-all lock you can buy keys for on the Internet.

With motherboard accessible, you can access USB, SecureDigital, and CompactFlash slots. On boot, the app code checks these drives for firmware upgrades and applies them. (And there’s a reboot switch on the motherboard, too!)

From a remote perspective, ATMs support remote monitoring and configuration to allow changing splash screens, cash denominations, etc., or even do remote firmware upgrades. There are multiple levels of authentication, but Barnaby Jack found a vulnerability in this authentication process allowing for a remote authentication bypass. (He did not disclose his authentication bypass, but said he found it by fuzzing, so this work will probably be duplicated by others.)

He demonstrated two tools — one was Dillinger, a remote ATM attack and administration tool which exploits the remote authentication bypass. It’s reliable on dial-up or TCP/IP, and exchange scanning with a VoIP wardriver like WarVox is possible. Dillinger allows management of unlimited ATMs, can test remote bypass, retrieve location & master passwords, upload rootkits, and even retrieve the track data from all the cards that have been inserted into the machine.

Scrooge, an ATM rootkit, runs on the device hidden in background, activated by special key sequence or custom card. It runs on any ARM/Xscale ATM, or Intel ones with some tweaks, but must be customized for different ATM models. It has a keyboard filter that hooks the ATM keypad & side buttons — SetWindowsHook() is undocumented on CE but still works. A special key sequence (or a card whose track data spells out “GIMMEDALOOT”) launches a menu. Scrooge captures track data and pin-pad input, and can issue remote commands.

This is better seen than described. Here’s some video of remote ATM hacking with Dillinger:

And here we have the aftermath of a physical attack, where he opened the ATM with a key, stuck in a USB drive, and hit the reset button on the motherboard:

The “777 Jackpot!” on the screen and the peppy music are a nice touch.

As for how to prevent these sorts of vulnerabilities in the future, he recommends that ATM vendors offer upgrade options on the physical locks (say to at least making the key unique), implement binary signing at the kernel level to prevent unauthorized firmware upgrades, and disabling remote management on the device.

For the final presentation of the day, I attended Dan Kaminsky’s talk, which was actually not the talk described in the BlackHat documentation at all, but rather an entirely different talk on using DNSSEC to implement public key infrastructure, due to the fact that the DNSSEC root was finally signed (after only 18 years…) three weeks ago.

Dan seeks to use DNSSEC to solve a variety of problems, by creating what he calls a Domain Key Infrastructure:

• For users: when you receive an email, you can actually know for certain who it came from.
• For infrastructure buyers: we need strong authentication as much today as we did when trying (and failing) to create PKI in the past, and with DNSSEC we can actually create a working PKI. 60% of security breaches are credential-related.
• For infrastructure builders: DKI will make security products scale, and allow devices to validate the identity of peers. You can build scalable federated systems.
• For hackers and penetration testers: Dan’s new company will be actively supporting an aggressive public audit of all DNSSEC and DKI technologies.

Dan’s definitely right about one thing — we aren’t going to get security via moralizing about user education or waiting for regulation. Will have to deliver a better product as judged by the people who have to run it.

DNSSEC is simple — it works just like DNS, but referrals and authoritative records are signed. Thus, when referred elsewhere, you’re told not only where the server to ask is, but also how to recognize it. Keys can lead to other keys.

DNSsec was complex to deploy because it was designed to allow “key in a vault” security, where keys are offline and not generated on demand. When it was proposed eighteen years ago, CPUs were slow, and some installations are incredibly large (e.g. .com) Offline keying is cumbersome. However, there’s an alternative that’s relatively simple to deploy.

Phreebird is a DNSSEC server that’s simple because it uses online keysigning, just like SSL, SSH, and IPsec. There is some risk here, of course, but we seem to accept it everywhere else, as everyone keeps keys online for some protocols. Those who are really concerned about security can use a hardware security module. Phreebird works as a proxy, and has effectively nothing to configure — you change the port of the DNS server, run Phreebird, and then supply the signature to your DNS registrar. It’s presently implemented as a UDP port forwarder, but they’re rebuilding it as a Linux mangle table. It’s very fast; according to Dan, it’s an order of magnitude faster than the DNS servers it’s proxying, so there should be almost no load. For performance, it caches signed responses, but always passes queries to the real nameserver so that all scenarios work — but if it gets the same thing, it pulls up the cached signed response instead of resigning. Phreebird is open source and will be out in the next few weeks.

Distributed authentication is only interesting if it’s end-to-end. The current methods of DNSSEC lookups, chasing & tracing, are blocked by various types of servers, which makes operational implementation difficult. Phreebird also supports wrapping DNS (and DNSSEC) in HTTP, using a custom DNS server that exposes an HTTP endpoint and takes base64-encoded DNS requests. They claim there is no performance hit.

Likewise, while X.509 is flawed (since a certificate just has to chain to one of a few hundred root CAs by way of thousands of untrustworthy intermediaries, and there is no exclusion or delegation,) it can still be used to wrap DNSSEC — high performance, easy tunneling via DNS over X.509 over SSL. When one of these certificates is received, you just need to extract all the keys from the trust chain and validate it all.

From here, Dan got into the more interesting stuff — what he calls DKI (Domain Key Infrastructure.) What if you could use DNSSEC to create a working PKI system? Since DNSSEC lets you strongly authenticate a domain, you can then ask that domain to authenticate users, and trust the response since you have a key for the domain. To demonstrate this, he presented PhreeShell: federated identity for OpenSSH. With this modification, .ssh/authorized_keys2 contains identities (e.g. grant@perimetergrid.com) rather than keys — it makes delegating access trivially easy.

Trusting DNSSEC eliminates the scaling issues of federated PKI. Really, you’re not trusting DNSSEC so much as ICANN, but it seems a fairly good choice for a single root keyholder in that it has external political constraints and a delegation system designed to prevent operational dependency.

So how do we implement DKI everywhere? Eventually, by adding the functionality to everything — link in LDNS or libunbound. On Linux, you can make most things work by patching X509_verify_cert in OpenSSL, because practically everything calls out to it for crypto, but there’s nothing so simple in the browser world, where IE uses CryptoAPI, Firefox and Chrome use NSS, and most apps are cross-platform. For this, Dan has an app called Phoxie, which is a remote validation proxy for production browsers that allows certificate verification against DNSsec in current browsers. It’s also possible to make self-certifying URLs, but they look horrible and become unusable if the certificate ever expires or needs rotated, so they’re not a good solution.

Finally, we may get secure email out of this. If we can verify what server sent an email (which with DNSSEC we can), we can also in many cases be sure who sent it (as if the email came from a “respectable” domain it wouldn’t let users send mail as each other.) Right now the user experience around secure email is minimal, but our faith in it has been low — if most email could be verified, we could easily get to a world where email clients only stated mail was “From” someone if this fact had been cryptographically verified, and otherwise used some suspicion-inducing verbiage (e.g. the X-Supposedly-From header.)

Overall, Dan’s talk was interesting, but I find my enthusiasm is rather limited by lack of faith any of this stuff will be used. DNSSEC has been around for 18 years and no one uses it yet; having the root signed is a wonderful step and I hope it leads to the revolution in PKI Dan’s touting, but I also feel like I’ll believe it when I see it.

After all the talks, I dropped in on parties thrown by Mandiant, IOActive, and NetWitness, but unfortunately had to skip Tenable and Rapid7. There are so many parties, receptions, and events that it’s impossible to visit all or even most of them.

a

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

The day began with Hacking E.S.P. (Educational Software Packages.)  Schools, by their nature, have sensitive PII data — transcripts, schedules, billing information, etc.  A lot of this data is either stored directly in web-based educational software used by students, or is stored in other systems students access… probably with the same password.  Overall, though, this was a pretty typical application service provider hacking presentation — many of the schools they investigated used the same software on their sites, and that software was often woefully bad: Passwords sent “encrypted” in Base64 encoding — and not even that if JavaScript is turned off.  Trivial session stealing via Hamster-style sidejacking, with the added bonus that the Session ID is set before login so you can steal a session ID then wait for someone to use it.  Copious cross-site scripting vulnerabilities to allow for cookie stealing.

Generally someone would have to have a login on such a system to be able to exploit these things.  However, the username/password scheme is often helpfully revealed on the front page, and some schools even allow you to create your own account on the system. Google showed 34,000 instances of this one flawed software package alone.  Considering as schools account for 34% of data breaches, this sort of buggy software is probably commonplace.

The second presentation I attended was about Adobe local shared objects.  In short, these are Flash cookies.  Just as your browser will store small data items (cookies) for a website, and return those items to the website when asked, Adobe Flash has a similar mechanism for Flash applets.  However, since these are stored by Flash and not by the browser, your browser doesn’t manage them — there is no indication to the user what data is being stored, and the data is not removed when you delete cookies or “private data” in your browser.  Ad networks have used these to “back up” your cookies — if you delete them, they are restored from a Flash local shared object when you next visit a site with the ads on it.  These are also hard to filter for systems like Privoxy and other anonymizers, because Flash uses a proprietary encoding for its XML RPC calls, in which the local shared objects are embedded.

On the bright side, there is a Flash applet on the Adobe site called Flash Settings Manager that will let you delete these objects and put in settings to manage them.  On the not-so-bright-side, this is in-band signaling (i.e. Flash is configured by a Flash applet), so any advertiser can override your settings later.  Also, as you may recall from the RIA presentation at Black Hat that I discussed earlier, there are a lot of other local storage mechanisms besides this one in Flash — Silverlight, HTML 5, and other frameworks also have local storage that is outside your browsers’ ability to manage.

I next attended a presentation about vulnerabilities in TOR, the onion-routing anonymity provider originally developed by the Department of the Navy and until recently maintained by the EFF.  TOR has become quite popular, at this point containing 1,500 relays and 200,000 users.  However, over the last several years, it’s seen several vulnerabilities that have threatened the anonymity it provides:

• 2004: Error in how AES counter mode was used resulted in cryptography with only 16 bits of entropy.
• 2005: A relay cell length overflow could be used to force an exit node to send contents of memory
• 2005: Diffie-Hellman handshake bug in OpenSSL didn’t check for trivial keys, so a malicious entry node could mount a man-in-the-middle attack
• 2006: By running several fast TOR servers, an attacker could end up as both entry & exit node for a user, thus compromising anonymity and potentially finding hidden services.  The fix for this was the addition of “entry guards” — trusted entry nodes that are re-used by users.
• 2006: Clients could create or extend channels even if server mode was turned off
• 2007: “Stable” or “Guard” status, normally applied to the top n nodes, could be stolen by malicious nodes by claiming high uptime and bandwidth.  The fix for this was to put in thresholds above which a node always gets guard status, rather than making it a top n calculation.
• 2007: XSRF attacks by web sites could make use of the TOR control port
• 2008: Nodes could be made to connect to their own public IPs
• 2008: The Debian OpenSSL PRNG flaw compromised 300 of the 1,500 relay identity keys, and 3 of the 6 directory authority keys.  If one more authority key had been compromised, someone could have taken control of the network

There are still some outstanding issues in TOR:

• You can build infinite-length circuits and use them as a DOS multiplier
• Snooping on exit relays works — if someone uses an insecure protocol that gives away their identity (like POP… or even HTTP depending on what they send), TOR won’t necessarily protect them.  This isn’t a bug in TOR, but just the nature of what it does — no software package will give totally anonymous communication if the communication itself gives your identity to the recipient.
• People who run relays are unknowns — there is no way to know how many are malicious.  However, TOR depends on having a large, diverse set of servers, so making more restrictions on who can run servers might actually lower, rather than raise, the network’s secuirty.
• Exit relays sometimes end up in restricted space (e.g. behind China’s firewall) — which means TOR users get restricted, too.
• Many users of TOR toggle it on and off during a single browser session.  However, a JavaScript refresh attack on one of the non-TOR sessions can sometimes retrieve data from the previous TOR session.
• Firefox bugs leak data, and that data doesn’t go through TOR, since on Windows it works as an HTTP proxy.  Users can work around this by proxying their entire network stack through a VPN connection like a JanusVM.
• It’s possible to block access to TOR.  If an adversary (say, the Chinese government) filters out the directory authorities, the download site, and all the relays, it’s very hard to get on.
• If you can see both input and output (by running many, many nodes, or having a massive filtering apparatus at the Tier3 ISPs — FBI, maybe?) traffic confirmation is easy.  (i.e. if I already suspect you, specifcially, of doing something, I can confirm you did it much more easily than I can “go fishing” for people doing unknown bad things.)  Defensive dropping or adaptive packing would help with this, but would raise TOR’s latency.
• You can fingerprint websites based on the size & response time of the pages and tell what people are doing via traffic analysis.
• A congestion attack by a website can find TOR nodes, and coupled with latency analysis on routers, can find the person communicating.
• Data retention laws in many countries are resulting in data being stored that could make traffic analysis easier.

So, with all these problems in TOR, does that mean we shouldn’t use it?  Not at all!  The known vulnerabiliites currently outstanding would apply to any low-latency mix network.  They’re not bugs in TOR, they’re limitations in this approach to anonymity, which remains better than any other approach to anonymity known.  TOR isn’t perfect, it’s just better than everything else.  Now, there may be better approaches to specific problems (e.g. there is one particular adversary you want to hide from, not just people in general), but for general anonymity, you still can’t beat TOR, even with its flaws.

I unfortunately missed much of strace and RSnake’s presentation on Google Gadgets.  In short, gadgets are pieces of HTML and JavaScript code hosted on third-party sites and brought into a Google-owned namespace.  Though this namespace doesn’t have direct access to Google cookies, the fact remains that it’s loading unknown JavaScript onto a Google page — it’s basically XSS-by-design.  Gadgets can communicate with or post to other users and gadgets on Google, and it turns out to be pretty easy to sneakily force a user to install a gadget onto their Google homepage.  If someone could crack a server hosting a trusted gadget, they could take control of the data of many Google users simultaneously.  Most of these vulnerabilities would apply to any gadget-based architecture, such as the Live start page, or Facebook’s apps, too.

The next presentation I attended was “Satan is on my Friends List,” about attacking social networks.  In short, social networks are full of promiscuous and pervasive trust relationships, which results in a large number of business logic flaws.  These attacks aren’t on code vulnerabilities like SQL injection, but rather just exploiting how the systems work.

Sites often don’t protect “non-sensitive” operations, like logging out or adding friends, from XSRF attacks.  Thus, it’s possible to craft comments that log out anyone who views them… which makes it rather hard to delete them (since you have to be logged in to delete a comment.)  XSRFs can be put into image links, meta refresh tags, IFRAMEs, etc.

In addition, social networks are ideal platforms for social engineering attacks.  Build a plausible profile for someone else using social and public sources, and then friend a few dozen people who are known to friend everyone right back to build a “respectable” number of connections.  Joing groups, and start friending real associates of the person being impersonated.  At that point, you have a web site that can be used to confirm your identity as someone else.

The Facebook and OpenSocial APIs for integrated social apps are also good avenues for attack.  They have convenient APIs and execute arbitrary code by design — the social networks don’t care about application malware, as it’s on a second domain and they’re legally protected by their EULA.  However, if you widely distribute an app based on some current meme, get hundreds of users, then replace that app in-place with malware, you have an instant social network botnet.  You can use them as open redirects, put phishing items on their social network page, etc.  Also, applications have all the access that friends do — just the data disclosure may be enough for identity theft, impersonation, or at least some minor mayhem.  They can publish to a user’s profile to infect others, too.

Unfortunately, the fixes for these issues are just what the social network sites don’t want to hear — less external content, reduced API functionality, no opt-in security models, review and lifetimes for applications, etc.  Thus, these vulnerabilities are probably here to stay.

The last presentation I attended was by Errata Security, about interesting penetration tests.  Modern penetration tests are “supposed to be boring” — they’re often done for the purpose of meeting compliance objectives, so companies are mostly interested in meeting a checklist, not in security.  They want to be secure against likely attacks and “script kiddies,” but are not interested in making the kinds of expensive changes required to defend against a determined, well-funded adversary.  The main exceptions are government agencies and Wall Street, who know they’re the targets for those determined adversaries.

Maynor & Graham walked through a couple of interesting things they did as part of penetration testing.  One of these involved hacking the well-firewalled network of a company that was based at a secure facility, one where they could not simply walk onto the premises.  Instead, the wired an iPhone to a UPS battery and put it into the original iPhone packaging, then mailed it to the company.  With a UPS battery, an iPhone can run for 5 straight days with the WiFi on.  They modified the phone to add tcpdump and APlogger, and added a cron job that would send an SSH tunnel out to their computers every hour over the AT&T EDGE connection.  The result was a WiFi sniffer & endpoint inside the “secure facility” from which they could scan the internal network and run Metasploit to break into things.  An iPhone, after jailbreak has been run, is essentially a tiny BSD box — a perfectly suitable hacking platform.  Who thinks about their network being hacked by a cardboard box in the mailroom?

They also built a better phishing site.  Even security-aware people who are looking for phishing sites look for a valid SSL certificate bound to the site and signed by a trusted authority.  However, all it takes to get a real SSL certificate signed is about $2,700.  Start a business, register with Dun & Bradstreet to get a credit rating, then apply for a real certificate from VeriSign or Thawte.  You can even sign ActiveX controls and require users to install them as a “secuirty feature.”  Since so many banks and companies outsource their applications or their HR and IT infrastructure, a phishing site with a good certificate is often indistinguishable from an outsourced site.  Just send someone at the comapany an email saying that the company has changed 401(k) providers, and they need to go to this outsourced site and sign up.

As is customary with DefCon, there wasn’t much talk about how to prevent these vulnerabilities.  However, it gives you something to think about, and it’s often very hard to guard against clever attacks against business logic flaws.  There’s no substitute for good threat modeling and flexible thinking.

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

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.

a

Whole-disk encryption products — such as PGP Whole Disk Encryption, TrueCrypt System Encryption, and Windows Vista’s BitLocker — work by encrypting the entire hard disk with a symmetric key, save for a small loader.  When the computer is powered on, the loader prompts the user for a password or other authenticator (like a smart card or a certificate on a USB keyfob), which is used to decrypt the key.  Assuming the correct authenticator is provided, the key is decrypted and then the OS is booted from the encrypted drive.  The key remains in memory until the machine is powered off, since continuous access to the key is required to access the drive.

The purpose of whole-disk encryption is to protect against an attacker bypassing all of the operating system’s defenses (logins & passwords, filesystem ACLs, etc.) by simply pulling out the hard disk and putting it in another computer (or, equivalently, booting up a LiveCD on the system) such that the operating system isn’t loaded at all.  Instead, the drive is mounted into an OS the attacker controls, where he has the ability to change ACLs, bypass logins, etc.  With whole-disk encryption, you can’t do this — even if you steal a laptop, without the boot password the entire drive contains nothing but a useless encrypted bitstream.

(As a side note, Vista BitLocker has a mode in which the symmetric key is stored in the TPM of the laptop, so no boot password is required.  At first this seems useless — why encrypt if decryption is automatic? — but it does provide protection against simply stealing the hard disk or booting into another OS.  The OS being booted must be in that specific computer, as only it has the TPM, and must be BitLocker-aware and capable of getting the key from the TPM.  It’s not completely secure in the stolen-laptop scenario, but neither is it useless.)

The Princeton group’s attack on whole-disk encryption relies on a little-known fact — computer memory (DRAM) is not wiped out when the system is powered off.  Rather, it becomes unreliable, decaying over a period of seconds to minutes as it gets randomized bit by bit.  It turns out that if cooled to a very low temperature, this decay is slowed considerably, to the point of being stable for tens of minutes.  Thus, the attack is as follows: get access to a laptop that is currently operating (so that the whole-disk encryption key is in memory), spray the RAM with an inverted compressed air can to cool it to -50 degrees Celsius, and power the system off.  Either move the RAM to a system with a custom OS, or attach an external drive to the system and boot off that.  The custom OS boots with a minimal memory footprint and then copies everything from RAM to a file on disk.  Thus, in less than a minute a “snapshot” of RAM has been taken.  This snapshot can then be inspected to locate prospective cryptographic keys and try them on the target drive.  Some knowledge of the particular whole-disk encryption product being used would be needed to find the exact spot in memory where the key is, and some error-correction techniques must be used in case a bit or two has been flipped, but it reduces the problem from cryptographically impossible to something that can be cracked in a few minutes or at worst hours.

So is this the end of whole-disk encryption?  No, not at all.  First of all, whole-disk encryption still successfully protects computers that are powered off (or in hibernation) — in that state, the computer does not have a copy of the encryption key available to it until the user re-enters his password.  In most stolen-laptop scenarios, the computer isn’t running at the time!  Whole-disk encryption is still a critical mitigation in the case of portable computers containing confidential data, and enterprises and government agencies would do well to implement it.  Of course, the best mitigation for this is to not carry confidential data around on your laptop.  It always strikes me as absurd when some government employee loses millions of confidential records on a stolen laptop — why did they need to have millions of records to carry around with them?  Do they really need all of those on-the-go?  It’s possible that in a minority of cases they do, and in those cases encryption is imperative (either of the whole-disk variety or on the file), but in most cases they’d have been better off leaving those files at the office.

Second, this is only a concern in targeted attacks.  If a typical thief rips off your laptop and discovers whole-disk encryption in place, they’re not going to execute this attack and get at your data.  Instead, they’ll just reformat the hard drive and sell the laptop as hardware.  The only reason someone would carry out this attack is if they knew that your laptop in particular contained valuable data and thus set out to steal it specifically.  In other words, if you’re a spy, and your laptop is classified TOP SECRET UMBRA, you have to worry about this attack.  If you have a typical corporate desktop and aren’t widely known to carry around your company’s entire credit card database, whole-disk encryption will probably protect you just fine.

There are several things that can be done, both by end-users and whole-disk encryption vendors, to mitigate this attack.  For end-users:

• If using Vista BitLocker, do not use the automatic mode — choose a mode that requires the use of a USB keyfob or a password to unlock.  This makes this attack ineffective when the system is entirely powered off.
• Do not use sleep/suspend-to-RAM when the computer is not actually in your hands — either power off or use hibernate.  In a sleep or suspend-to-RAM scenario, the whole-disk encryption key is still maintained in memory and can be recovered.
• If you have a few truly critical files, use file encryption (such as Windows’s Encrypted File System or PGP’s file encryption) on those files with a different password than that used on the whole-disk encryption.

For makers of whole-disk encryption software:

• Provide an option to re-encrypt the symmetric key during sleep or screen-saver activity.  This would mean the the laptop would need to be stolen during a truly active state; however, it would also inconvenience the user with more frequent password prompts.
• Consider the cryptographic key expansion mitigation described in the Princeton research paper.  It vastly increases the chances of even a small amount of decay of memory rendering the key unrecoverable.  Of course, it does so at the cost of performance (by requiring an additional hashing and XOR operation every time the key must be used.)

a

This is a good thing; people using services like this does help protect their privacy and anonymity, and due to how TOR works the more people that use it, the more secure it becomes (indeed, the Navy, who developed TOR, released it publicly because they realized that if only the military used it, it was worthless.) Most of all, if normal, everyday people value and use anonymity and privacy services, it shows policymakers that anonymity is a social good desirable to all and not something that people only want when they have something to hide.

The argument against anonymity, however, is that it can be used to cover up crimes. Will something like TOR protect criminals? How do we track down a malicious hacker if the attack comes from a TOR node?

There are actually quite a few ways TOR leaks information, and really they’re all centered around idea — one cannot simply “be secure,” one must be secure from something. TOR protects against some attacks and adversaries but not against others.

TOR (“The Onion Router”) provides anonymity by encrypting your traffic multiple times and routing it through TOR nodes. Loading the Amazon.com home page through TOR would look like this:

1. Your computer contacts two TOR nodes, which I’ll call A and B, and requests their public keys.
2. Your computer forms the web request to Amazon.com.
3. It encrypts the web request in key B, then encrypts the result (along with the address of B) in key A.
4. The packet is sent to node A.
5. Node A, which has the private portion of key A, decrypts the packet. Inside is another address (that of B) and an encrypted blob. Thus, Node A knows you you are, but it doesn’t know what you’re transmitting, or who you’re sending it to. It forwards the blob to Node B.
6. Node B, which has the private portion of key B, decrypts the packet. Inside is your transmission to Amazon.com, which by its nature says where it should be sent. Thus, Node B knows what you’re transmitting, and who you’re transmitting it to, but has no idea who you are or where the packet came from. Node B sends the packet to Amazon.com.
7. Amazon.com gets the packet and replies, sending the reply to Node B. Note that Amazon.co, like Node B, has no idea who you are or where the packet came from.
8. Node B gets the reply and forwards it to Node A.
9. Node A gets the reply and forwards it to you.

This is simplified; there’s additional encryption so the nodes can’t all read the reply as it makes its way back to you, and there can be more than two nodes in the chain (in which case the intermediate nodes know even less about the transmission than A and B above.) However, the above is the simplest case, and shows how much each part of the chain knows and doesn’t know.

The primary adversary TOR is designed to protect against is the actual site you’re browsing. It hides your IP address (which, with a subpoena or some social engineering to your ISP, can be tied to you personally) from the target site, so that the site does not know who is visiting it. The obvious counter to this, though, is for the site to apply a cookie to your browser when you visit it, such that it “recognizes” you on subsequent visits. TOR alone will not protect against this, which is why TOR is almost always packaged with Privoxy, a filtering proxy that runs on your own computer, examines all your web traffic, and strips out data that can be used to identify you. Here’s the first weakness in TOR — it can only strip out so much.

Web traffic is stateless; each web request is not tied to any other in any persistent way. When you load a web page, your browser nearly-simultaneously requests the page and all the images, media, embedded frames, ads, etc. on the page. When you click a link, the server has entirely forgotten who you are — it’s a totally different page load. This would make any kind of integrated experience impossible (the web was originally designed just to serve up static reference pages, not implement shopping carts), but for cookies. The web server sets a session cookie (a cookie that is deleted when you close your browser) when you load the first page, and uses that to track your movement through the site. There’s nothing menacing about this — it is not “tracking” in any Big Brother-ish way, it’s just linking all your page loads together to provide a sense of state or flow — and the web doesn’t work without it. Thus, Privoxy has to let these session cookies through. This can leak a little bit of information about you.

How is this anonymity defeated? In the simplest case, the user leaks the data on their own! A web request contains a decent amount of information about you (what browser you’re using, your operating system) as well as any cookies the user sends. Privoxy strips most of this, but if the user uses TOR alone, then the fact that the endpoint can’t see your IP may be irrelevant — you just told it who you are anyway. Likewise, browsing a site that requires login (like a webmail provider) through TOR is plain silly — it’s obvious who you are, you just logged into the site. This is true even if you’re worried about investigation not from the site but from authorities, spies, or other hackers — the webmail site logs that you connected, and it probably logs everywhere you’ve ever connected from. Thus, using a site with login through TOR only provides anonymity if you never use that site except through a TOR connection. Otherwise, your communication can be correlated over time.

Also, it’s possible to make an end run around TOR. If someone simply hacks into your computer (or seizes it, in the case of legal authorities), they don’t need to have logs from the other end to know what you’ve been doing; your own computer probably has records of your activity. Deleting them usually does little good in the legal case — modern data recovery can get deleted data quite easily. To avoid this, it’s necessary to have a computer that simply doesn’t keep any records — and this is hard to do in a normal Windows or Linux system (for one, they both arbitrarily swap portions of memory to disk during normal use.) For better anonymity, it’s necessary to boot a LiveCD environment (i.e. an OS with no hard drive or writeable media), where all evidence is destroyed when the computer is powered down. But unless your oppressive dictatorial nation’s secret police are after you, this is probably excessive when it comes to normal protection of privacy and anonymity.

Finally, there’s one more attack through TOR that’s more troubling than either of the above — anyone can be a TOR node. “Node B” (the exit node) in the example above gets to see your traffic, in both directions — it just doesn’t know your IP address. You are, thus, trusting a complete stranger somewhere on the Internet with your traffic, complete with the ability to carry out man-in-the-middle attacks on you (i.e. maybe he doesn’t forward your traffic to Amazon.com at all, but rather a fake site of his own design; or maybe he edits the traffic to add a virus or Trojan.) This actually happens; Bruce Schneier linked to some logs of a TOR exit node trying to carry out a MitM on an SSL session. So while TOR protects your anonymity, it may actually risk your privacy — it’s very hard to carry out MitM attacks on random Internet users, but doing it as a malicious TOR exit node is comparatively easy.

Another thing to consider: there are only so many TOR exit nodes. There are few enough of them that if, say, the NSA, or the RIAA/MPAA, wanted to, they could set up hundreds of exit nodes, all of which spy on traffic, and have a set of nodes large enough to comprise a substantial portion of the TOR network. If one agency controlled, say, 10% of the exit nodes, their ability to figure out who you are would be pretty significant. If they controlled normal nodes as well (even easier), they might even get lucky and get both the incoming and exit communications on their hostile network, allowing them to completely monitor your traffic.

TOR is meant to protect your anonymity from the site you’re browsing. It does this pretty well, as long as you’re reasonably careful, don’t browse sites that require you to identify yourself, and use a cookie-filtering proxy like Privoxy. However, it is not meant to provide privacy from TOR node operators, and thus it does not. You can have privacy, or anonymity, but you can’t have both at the same time in a perfect fashion. (Even using open WiFi access points with an obscured MAC address provides anonymity but not privacy — the operator of the access point can do everything a TOR exit node operator can do to you and more.

Overall, it’s a valuable tool, but if someone wants to track you down badly enough, and they have the resources or authority, they can still do so. This is why criminals aren’t out there committing heists with TOR every day; if you do something bad enough, it won’t protect you. Of course, most computer criminals aren’t caught due to malicious TOR exit nodes or anything so arcane — they’re caught because they brag about their accomplishments, or because investigators follow the money. Even hackers that excel in covering digital tracks thankfully usually have no experience in money laundering.

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

1.) Wireless Networks Use Shared Media

Back in the 80′s and 90′s, most wired Ethernet networks were based on shared media topologies. In principle, when you plugged into an Ethernet network and sent a packet, the packet on the wire (the actual electrical impulses) went to every other machine on the network. Hubs were simple repeaters, broadcasting everything they received. Only when your signals reached the router at the Internet edge were they actually intelligently processed. Thus, every computer on the LAN got every packet – the network cards just threw away any packets whose destination address specified another computer. However, a hacker wanting to eavesdrop on others had an easy job – just toggle the network card into “promiscuous mode” (a hard task on some network cards and OSs, but completely trivial on others) and it will receive every packet, giving you a god’s-eye view into the network. Protocols were mostly unencrypted then, too – so you saw everyone’s email, their paswords as they logged into Telnet or IMAP, etc. You could also spoof traffic – since you saw the packets sent by others, you could simply send responses back claiming to be the recipient. So long as your response arrived before the real one, yours would be accepted and the actual response discarded as out of sequence. It was the golden age of network-protocol hacking. Such easy access to passwords made other types of hacking easy, too – once you had the password to someone’s UNIX account or email box, there was a very good chance it would work on all their other accounts, too.

Then it all changed. Shared media has significant disadvantages as it scales – since everyone is dumping packets onto what essentially amounts to a single wire, collisions occur when two systems transmit simultaneously. Both then have to back off, slow down, and retransmit their garbled packets. The packets are tiny (Ethernet frames are normally restricted to 1500 bytes or less), but if you have 100 systems communicating at once, collisions can become quite frequent. Plus, even in the late 90′s people were not totally unaware of the security risks – the fact that any student could read all the network traffic of everyone else in their dorm was not considered desirable by universities, for instance. Thus, Ethernet was converted over to switched media. Switches, unlike hubs, do not treat all ports as equal. Instead, they remember which ports they have received traffic from an address on, and only forward traffic to an address to those ports. Traffic is only broadcast to all ports when a switch has no idea for which port it is intended, or when a packet is actually marked as a broadcast. Now, when you put your Ethernet card in promiscuous mode, all you hear is traffic meant for you – everything else has been blocked by the switch. Suddenly, packet sniffers went dead – there was nothing to see anymore. Ethernet became a lot more secure.

But wireless changes things again. Wireless networks are shared media, and they are shared inherently, in a way that cannot be changed. Radio waves fly in all directions. There is no way for your laptop to transmit only to another laptop or an access point – all radio is broadcast. Thus, when you sit down in a coffee shop and turn on wireless, you begin broadcasting everything to everyone within range (about a mile, for attackers who have good antennas and high-power network cards.) The shared media nature can be mitigated somewhat via cryptography – if all the traffic to the access point is encrypted, it hardly matters if someone can eavesdrop since they can’t understand it anyway. But open access points are, by their nature, open – they’re either not encrypted at all, or they’re encrypted in such a way that everyone is using the same key. Once the hacker has the key (either by cracking it, which is not hard on most Wi-Fi networks, or by simply paying as a legitimate user of the wireless hotspot), they can read all the traffic just like in the hub-based glory days of old.

There are solid wireless encryption systems. A network based on WPA2 with a strong passcode is quite secure, about as good as a wired connection (keeping in mind that “as good as a wired connection” is not an absolute guarantee of safety, either.) Modern encryption systems like AES coupled with 802.1x certificate-based authentication can make a well-engineered corporate wireless LAN quite safe.

But hackers don’t love well-engineered corporate wireless LANs. They love the terrible ones in coffee shops and bookstores and your house. On these networks, they can listen to all traffic, they can spoof traffic, and they can even kick people off and hijack their connections, or edit their connections on the fly. The “airpwn” attack from a DefCon 2-4 years ago was particularly amusing; using two wireless cards, it would sniff everyone’s HTTP traffic on one connection, then on the other card spoof responses to all requests for images, substituting other images (such as the hacker group’s logo, or more unsavory fare like the infamous goatse.cx site; that is not a hyperlink on purpose, do not navigate to that URL as it is not safe for work or, indeed, for anywhere else.) The result was that one laptop at a security conference was able to dynamically edit the HTTP streams of everyone else there – hundreds of people. That’s the kind of power a hacker can have on a shared-media network. In addition, on these sorts of networks, it’s trivially easy to hijack sessions. This means that on any site that uses HTTPS for authentication only, but then HTTP for the actual service (a category that includes all of the Google apps like GMail, as well as all the Yahoo! and Windows Live services), a hacker gains full access to your account if they overhear any of your wireless traffic.

The only truly safe way to use a public wireless hotspot is to use it only to VPN to a network you trust. Anything else is dangerous.

2.) Wireless Networks Provide Plausible Deniability

The legal system is not terribly friendly to hackers. Even innocuous and non-destructive activity, when applied to networks you don’t own, is often illegal. Now, for the most part hackers don’t worry overmuch about getting caught – if you don’t cause more than $5,000 in damages, the FBI won’t get involved, and the average local police department is about as capable of investigating sorcery as computer crime. However, when a hacker does worry about legal prosecution, a public wireless network is the next best thing to Siberia for where to commit a crime from.

When you do anything on the Internet, a host of servers are recording your activity based on your IP address. IP address, however, is not necessarily long-lived. Depending on how you access the Internet, your IP address might change every time you plug your computer in, or reboot, or move from building to building. Thus, investigators must be able to tie the IP address they know committed a crime to a specific, physical person.

With wireless, this is a problem. All the sites being attacked don’t see the IP address of the hacker – they see the IP address of the wireless access point. Thus, they have to subpoena the owner of the access point and demand to know who was using it. In the case of a well-designed corporate wireless LAN, they can check their logs to see which 802.1x certificate was using that IP at that time, and uniquely identify you. But in the case of a public hotspot, there probably aren’t any logs at all! They’re completely incapable of giving you up. And even should someone who was there say “I saw a shifty guy in the corner using a laptop!” to the police, that’s not going to be enough evidence. And if there are logs, they will tie your traffic to your MAC address, a unique code assigned to your network card at the factory.

Most people think MAC addresses cannot be changed, so it uniquely identifies your network card. If the police get a hold of your network card, they’ve caught you. This is actually totally untrue. Many network cards will allow you to change the MAC address to whatever you want (in Windows, it’s on Connection Properties -> Configure -> Advanced -> Physical Address), though this is entirely up to the network driver. Many Windows drivers block this functionality, thinking that users don’t need it. On Linux, however, the network drivers have been written by geeks, who operate under the impression that users need everything. Thus, on Linux systems changing your MAC address is as simple as typing one command (“macchanger eth0 00:11:22:33:44:55″), and you can even configure the network stack to give you a new, random MAC address every time you connect to a network.

As a result, a trail that leads to a wireless hotspot is basically a dead end for investigators. They get nothing but a fake MAC address that could correspond to any computer within a 1-mile radius – the hacker might not have even been in the building. Hard to get “beyond a reasonable doubt” out of that.

And those are why hackers love wireless networking. It’s like the 80′s phone networks, where a hacker can be a ghost in the machine, undetectable, and with tremendous power. It’s a dangerous place.

You might wonder, if wireless networks are so anonymous, how hackers ever get caught. Actually, there are three main ways:

1. They get stupid, and brag about what they did.
2. They get stupid, and while performing their illegal activities they also do something that identifies them, like log into their email account.
3. Investigators follow the money. We don’t catch you breaking into the bank, we see where you sent the money to. We don’t catch you stealing credit card numbers, we catch you using them.

Luckily for those of us in the business of investigating and preventing computer crime, wireless networks won’t save criminals from their own stupidity, and you can’t send cash through the airwaves.

a

There have been many security vulnerabilities in NetBIOS in the past, and some in SMB, so these protocols are (rightly) considered moderately risky by network administrators. However, scarier than any of these patched vulnerabilities is the flaw in the design — SMB is subject to a sort of replay attack, called SMB Relay or SMB Reflection.

SMB at first appears safe from replay attacks. After all, it uses challenge-response authentication (normally; there is a protocol for SMB with cleartext, but basically no client or server will accept this protocol now), whose whole purpose is to prevent eavesdropping and relay. If you try to replay the same response to a server, it won’t work, because the challenge is different. There are three ways SMB allows challenge-response authentication — LANMAN, NTLM, and two-way NTLM. In any case, the principle is the same — the client asks to authenticate, the server sends a challenge, the client encrypts the challenge with a password, and sends the encrypted result as a response.

So how do you perform a replay attack on SMB? Via SMB Relay (to attack another host) or SMB Reflection (to attack the client.) It goes like this:

1. Client (C) connects to you (a malicious server, M) and asks for a challenge.
2. M connects to C in a separate sessions and asks for a challenge. It still has the connection from (1) on hold, having not responded yet.
3. C receives the request from M, and responds with a challenge (challenge_C).
4. M takes challenge_C, modifies it to appear to be coming from M (challenge_M), and responds to the connection from (1) with it.
5. C finally receives the challenge (challenge_M) that it asks for. It uses its credentials to respond to it (response_M).
6. M receives response_M, which is correct for challenge_M, and so grants C the access it requested. Of course, this response also matches up with the challenge it’s holding onto (challenge_C). It forwards it right back to C as response_C.
7. C receives response_C, which is correct for challenge_C, and so grants M the access it requested.

No, C doesn’t ever realize that it just received and responded to the challenge that it, itself, sent out moments before. By requesting access to M, I have unwittingly given it all it needs to authenticate against me at the same time. It can’t be carried out later — the reflection attack has to happen at the moment I am trying to connect.

Note that this is a design flaw — there’s no “bug” to patch here (I suppose Microsoft could modify SMB to ensure that it’s not responding to its own challenges; it would be possible but not trivial), this is the behavior of SMB since time immemorial. No buffer overrun is exploited; SMB is acting precisely as it’s intended to. This issue has been known since 2001.

Host firewalls like Windows Firewall and ZoneAlarm help some — at least, they keep SMB Reflection attacks out. However, they don’t help if the attack is coming from a zone you trust — i.e. if you’re sharing files with your corporate Intranet, someone on the corporate Intranet can attack you this way if you try to authenticate against them. And it also doesn’t stop SMB Relay – if I connect to M with my firewall up, he can’t use reflection to attack me, but he can relay to yet another host and impersonate me, passing me its challenge and relaying my response to the remote host.

It actually gets a bit worse than this, because the NTLM package used to authenticate SMB is the same one used to authenticate you against Intranet websites in Internet Explorer. The attacker might not need to get you to try to make a file-share connection to him; a web connection can be sufficient.

This attack sounds relatively tricky to carry out, and it is… by hand. However, the ever-popular Metasploit Framework contains an SMB Relay module (which also works for SMB Reflection) that makes it quite quick and easy (you need the live-tree version of Metasploit out of CVS, not the release build, as the module is relatively new and was just demonstrated at Defcon 15 this August.) You do have to disable SMB on your computer to use it, though (which is simple on Linux, but on Windows involves unbinding the Server service.)

This makes SMB reflection trivial. You load the module, tell it your IP address, load your choice of many payloads (such as having a shell started and passed to you, or simply having an SMB connection opened that you can do with as you will), and then wait for someone to connect to you. You can either specify a target server if you want SMB Relay, or leave that unspecified for an SMB Reflection back to the person connecting. The only thing Metasploit won’t do for you is make people connect to you.

So the moral of the story is apparently to be careful who you connect to, especially on local networks where your file-sharing ports are open. That’s a pretty good moral in general… but it’s really not enough. People who run Windows Firewall often have a blanket exception for File & Printer Sharing, which opens port TCP/445… if you’re not behind a home firewall or router, this sort of attack may be able to be carried out on you from any site on the Internet. And tomorrow, I’ll be talking about why nothing of any kind is ever safe on a public wireless hotspot.

a

To people not very familiar with cryptography, it may seem odd that random number generators are very significant.  However, all modern key-based cryptography is based on having a source of entropy (true randomness) — somewhere it can get a key that is unlikely to be guessed or otherwise determined.  When we talk about “40-bit” or “128-bit” encryption, we’re really talking about the key length, which provides an upper bound on available entropy.  Ideally, cryptography would be based on true random numbers, for which every bit of number is a bit of entropy.  However, true random numbers have to be generated physically — we have devices that do it based on radioactive decay, but you can also get it by asking a human to move a mouse around or bang on a keyboard, as PGP does when generating keys.  Thus, for most applications, we settle for pseudo-random number generators — programs which generate a stream of numbers that are unrelated to each other, have a uniform distribution, and are for most purposes entirely random.

However, a psuedo-random number generator usually needs a seed — a starting point for the generator.  If you use the same seed, you’ll get the same stream of “random” numbers.  Thus, the seeds chosen are usually very large numbers.  Cryptographic pseudo-random number generators are considerably more processor-intensive than the regular “random” number generators used in non-security applications, as they’re usually based on multiple iterations of a hashing algorithm.

What happens if your pseudo-random number generator isn’t very good?  Well, in the early 2000s, an online casino in the Caribbean (I wish I could remember the name of it to provide a link to the news coverage) lost several million dollars.  Apparently, a player realized that to shuffle the decks of cards, they used a standard, non-cryptographic random number generator — the sort of thing that’s built into Windows and Linux and such.  A shuffled deck of cards is very random — there are 8×10⁶⁷ ways to shuffle a deck, which is about 225 bits of entropy. However, the random number generator used only a 32-bit seed!  There are only 4×10⁹ 32-bit numbers.  This is still a lot, but with modern computer aids, it’s a manageable number.  So what did this player do?  He had his computer generate shuffled decks for each of the four billion 32-bit seeds.  He then wrote a program that let him enter specific cards that were drawn (e.g. “fourth card was a queen of spades, fifth card was a 9 of diamonds…”) based on the draws he could see (such as his own cards in poker, or the up cards in blackjack) and it would pare down the four billion decks to the ones that could have potentially produced those draws.

It turns out that when you know that almost all decks are invalid (not able to be generated by the random number generator in use), there aren’t many decks that can produce a given set of cards.  Thus, within 3-5 known cards, his program would spit out the entire deck, and that player could now predict the future.  He would know exactly what cards would be coming out, and what ones already had.  Thus, poker and blackjack were trivial, and he won a ton of money.

Many things in cryptography operate similarly.  If you can predict the random numbers being used, you drastically simplify cracking the code.  It is generally still not what a layman would call simple — but it brings a message from “even the National Security Agency with its thousand acres of supercomputers couldn’t crack it in our lifetime” to “it’s still out of reach for you and I, but, well, the NSA could probably crack it in a day or two.”  Well-funded, skilled adversaries can use any small defect in a cryptosystem that lowers entropy to shorten the time to break codes.

And that’s why the NSA would be interested in putting a back-door in a pseudo-random number generator.  Did they actually do this?  In my opinion, the evidence Schneier presents is pretty convincing, and while Schneier is today best known as a popularizer of security rather than a technical expert, one would do well to remember that he also wrote Applied Cryptography, a very technical book that sits on the bookshelf of basically every security developer, including mine.  The NIST publication presents four random number generators, based on different algorithms, and then recommends the use of one, Dual_EC_DRBG, that is about 1,000 times slower than the other three.  Unlike the others (Hash_DRBG, HMAC_DRBG, and CTR_DRBG), however, with this particular algorithm it would be possible to craft a set of input constants that are defective in a specific way — such that someone armed with a corresponding set of constants could predict the output of the generator.

Now, we don’t have proof that the NSA actually did this.  It’s possible that the input constants in the NIST publication are truly random, chosen arbitrarily, and the NSA does not have a matching key that will break the generator.  But the NSA is pretty smart, and almost certainly knew about the flaw in the algorithm — in general, people in the cryptographic industry assume that the NSA is a few years ahead of them and just hasn’t said so.  The old adage about not attributing to malice what simple incompetence will explain usually applies to government pretty well, but not to the NSA.

Really, this is a rather ingenious way to backdoor a crypto algorithm.  The normal method — just make a cryptosystem with a mathematical flaw or known backdoor key — has a serious issue: if you can figure out the mathematical flaw, so can someone else.  The NSA wants to be able to listen to our phone calls — it doesn’t also want every other country to be able to do so.  To backdoor a cryptosystem requires making it so you can read messages without also weakening it for everyone else.  This method does exactly that — without the specific numbers that match the provided input constants, the system isn’t flawed at all.  The NSA has the key (if, indeed, they do), and no one else does.  Putting it in the random number generator rather than the cryptosystem itself is a good way to draw attention away from it, too.

And if the NSA didn’t choose the constants to have a backdoor, why recommend an elliptic-curve based generator that’s three orders of magnitude slower than several other generators, all believed to be just as secure, that are based on much more easily understood mathematics like hashing?  It just doesn’t seem to make much sense.

a

However, these researchers found a flaw in the cryptosystem. Due to a flawed protocol, they can mounting a chosen-plaintext attack on 2¹⁶ keys (requires about 65 minutes access to the car.) And once they have that, there’s a cryptanalytic attack on the manufacturer key (that’s a bit more cryptographically strenuous; they took 2 days to do it using 50 dual-core Opterons), which makes unlocking any car by that manufacturer very easy.

But do we care? Car thieves aren’t going to run up to your car with a radio antenna, spend 65 minutes gathering data, run back to their PC and run a cracking app, then come back and steal your car. It’s easier to just pick the lock, use a slim jim, or break a window. (Actually, these things are frighteningly easy, much more so than most people imagine; key-based locks are not very secure.) However, the risk isn’t from single attackers — it’s that this turns cars from having a physical lock to a software lock. Now that this attack is known, someone could make an effort to gather manufacturer keys from many car manufacturers and model years, and create a simple piece of software which (when paired with an appropriate-frequency radio antenna) opens any car by those manufacturers. The bad thing about software hacks to things that aren’t general-purpose computers is that they’re really hard to fix. If someone does come out with Car Unlocker for Windows Mobile PCs (or even cell phones), what do you do about it? You can’t just download a patch to your car. Manufacturers will change the keys in future cars, but there’s nothing to be done about current ones. One guy isn’t going to do this to steal one car… but someone might do it for organized crime to steal many cars.

It’s dangerous to embed cryptographic keys. Key management and rotation is actually a much, much harder problem than strong cryptography — it’s one thing to make the key hard to break, it’s quite another to be able to change it when it’s broken. (And if the target is high-value enough, it’s a when, not an if — just ask the RIAA and MPAA’s DRM developers.)

a