The slides are quite large (15 MB) as they contain two embedded videos. I will also link to the video recording on the DEF CON media server as soon as it is available, but historically that doesn’t happen until 3-6 months after the conference.

In other news, I will be renovating this site and bringing it back up as a more useful resource soon!

Note that as the slides are mostly video demos, the deck is quite large and is only available in PowerPoint format.

Finally, you can stream or download the full DEF CON presentation video with slides from the DEF CON media server.

But the thing about fingerprints is that they’ve been easy to bypass for more than 20 years. It’s not that hackers have figured it out “already”, rather spies figured it out decades ago. You dust the fingerprint, photograph the pattern, print it out with an impact printer (or, in a pinch, a laser printer with the toner on the heaviest setting to leave raised printing), pour plain old Elmer’s glue on it, let the glue dry until firm but not quite solid, and peel it off. Presto! Prosthetic fingerprint.

The problem with how fingerprints are being used is that fingerprints are a form of identification, not authentication. They quickly say who you are, but they don’t prove who you are — essentially, when trying to translate the traditional username/password paradigm to biometrics, a fingerprint is like a username, not like a password. Unfortunately, it’s being used as a password. It’s especially funny on the new iPhone because they’re using fingerprints to authenticate to a touchscreen device — that is, an object that has your fingerprints all over it! If someone wanted into such a phone it would be really easy to lift the user’s fingerprints off the screen, create a prosthetic, and unlock the device with the fingerprint reader. You can’t make a secure authentication method out of something that people leave everywhere.

On the other hand, I can’t bring myself to care that much. There’s a general rule in computer security: “If the adversary has unrestricted physical access to your computer, it’s not your computer.” If someone’s trying to bypass fingerprint lock on a phone, then they must have possession of the phone — and in that case there are many ways in, whether it’s locked with a fingerprint, a PIN, a password, or whatever. Fingerprint is more convenient than PIN and probably approximately as secure as a PIN. In either case, if the device storage isn’t encrypted getting access to it is trivial, and if it is encrypted the capability to perform an offline attack (a capability you have in a stolen-device scenario) means that bypassing a 4-digit PIN is equally trivial. You’re not really losing much, if any, security by going to a fingerprint.

The other problem with fingerprints as passwords — aside from the fact that you leave them everywhere — is that your fingerprint can’t be rotated. If your password gets stolen, you can change your password, but if your fingerprint is stolen, it’s stolen forever. There’s no way for you to change it. This is fine for an identifier (username), but not fine for an authenticator (password) — it puts you in the situation of “break once, break everywhere.” Once your fingerprint has been stolen by an adversary, they have it for the rest of your life. This also why fingerprints (or any biometrics) should never be used to generate cryptographic keys.

You’ll find fingerprint readers on a lot of enterprise-model laptop computers, too. On these, the fingerprint reader is just an alternate authenticator to Windows, so Windows will still let you log in with your password if the fingerprint reader doesn’t work. It does (by design) reduce your security a bit — but once again, not much, because if someone is trying to break in via the fingerprint reader then they must have physical possession of your computer, and they’re going to get in anyway. The only protection against that is to enable BitLocker in PIN mode — that is, full-disk encryption with a PIN code required at power-on to decrypt the hard disk, and even then you’re only really safe if your computer comes with a TPM (which most business laptops do, but most other PCs do not.) Most people don’t do this, which means fingerprint or password, your data is easily accessible to someone who has possession of your PC.

So all told, there’s not much reason not to use fingerprint unlock on a phone, since phone unlock is not normally a boundary where we expect much security (as our usual mechanisms — either “swipe to unlock” or a 4-digit PIN code with unlimited guesses allowed — provide very little security anyway.) But from a systems design perspective, if you want real security, fingerprint should not be treated as an authenticator, regardless of the technology being employed.

And then Edward Snowden turns the NSA’s terrible PowerPoint slides (seriously, could they put any more flag and eagle clip art in there if they tried?) over to the Guardian, and it looks like PRISM has direct access to every record of customer data in ten major Internet service companies. Quickly PRISM overtakes the Verizon scandal in attention.

What are we to make of this? A tempest in a teapot, or that the United States has already gone over the edge into a police state? The mainstream media certainly promulgates both views — and Congress has given them plenty of ammunition to do so, with Snowden called whistleblower, hero, criminal, or traitor depending on who’s giving the sound bite.

Of course, all the major Internet companies — Microsoft, Google, Facebook, etc. — have claimed to have no knowledge of PRISM, and not to be party to any worldwide NSA-led spy ring. As someone who works in security at a major Internet company, frankly, I believe them. Which is to say that I believe that spokesperson has no knowledge of PRISM and genuinely believes his employer is not party to any worldwide NSA-led spy ring. But these companies have criminal compliance teams — groups whose role is to liase with law enforcement around the world, and to determine which requests, subpoenas, and warrants to quietly obey and which to resist. These criminal compliance teams operate in secret, necessarily — it’s often outright illegal for them to share the requests they receive (the USA PATRIOT Act’s National Security Letters come with gag orders attached), and even if it’s not, it’s bad practice. Most of the time they’re assisting in the investigation of bona fide bad people, child pornographers and fugitive murderers and the like, and talking too much jeopardizes the investigation. Criminal compliance people are law enforcement people — they’re Lawful Good, they believe in what they’re doing, and generally rightfully so. They may care passionately about civil liberties, and they may push back on overreaching requests, but ultimately they believe in the power of government to do good, just as legislators do, or they wouldn’t be in that career — and that career requires a culture of secrecy. They don’t talk, and their managers don’t ask, because that’s their job. So the spokespeople at Microsoft and Google and Facebook and so on are telling the truth — they’ve never heard of PRISM, they don’t know about any NSA spy ring. And yet that means very little; they wouldn’t have heard of it, and they wouldn’t know about it, and the people who do won’t say. It’s their job not to say, and the great majority of the time, we as a society should be glad they’re doing their job. They put people like this guy in jail.

PRISM is probably not a spying system per se. It’s a glorified reporting layer — it presents to intelligence agents in usable form the intelligence the NSA has already collected, and allows them to easily request more. Those requests go through the usual due process, getting sent to some Internet company with an order from the FISA court. PRISM probably isn’t directly tied into the core systems of the Internet’s largest companies… but it indirectly is, by way of any number of other applications and processes, both technical and legal. Maybe even those criminal compliance teams have never heard of PRISM… they’ve heard of a few National Security Letters, and a few dozen warrants, and a few hundred subpoenas, and each one alone made sense, yet all of the data from all of them went into the NSA’s great oracle, and the whole is greater than the sum of its parts.

I will give the administration one thing: there’s no evidence that the data from PRISM is being abused. PRISM knows about your Google searches, it knows about your email’s contents, it knows all the little felonies and misdemeanors you’ve committed. And make no mistake, you have committed them: our legal code has become so labyrinthine, everyone is a felon — as Cardinal Richelieu said, “if you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him.” When even copyright infringement is a criminal offense, when the Computer Fraud and Abuse Act makes violating website terms of service (you haven’t read them) a felony, a prosecutor with the will and the political support can prosecute anyone. Yet… they don’t. The NSA isn’t turning over everyone’s drug purchases and porn habits and music downloads to local district attorneys — it doesn’t look like they’re turning over anyone’s. They’re using it to look for terrorists, because that’s their charter, and nothing more. Obama’s not lying when he says the program has thorough oversight and is carefully targeted.

Allow me to take a digression here. The Transportation Security Agency was established to secure the nation’s transportation system against terrorism. Their charter is very clear: strengthen the security of the nation�s transportation systems and ensure the freedom of movement for people and commerce. The TSA’s charter, notably, is not to wipe out drug trafficking, or to prevent smuggling, or to enforce customs laws, or to prevent illegal immigration. And thus it does not try to do these things: its rules are all regarding weapons and explosives, not drugs or contraband (those drug-sniffing dogs are CBP, not TSA), and its security measures aimed at that target. Sometimes they may be ridiculous — X-ray scanners that can’t detect objects placed at your sides, say, or the constant “preparing for the last war” of shoe removal and liquid bans — but their aim is clear even if the shots are wild. Thus, it was no surprise that they recently decided to stop screening for small knives, golf clubs, multi-tools, and other minor weaponry. These items are no threat to the security of an aircraft — any weapon that can’t threaten more than one person at a time isn’t. No one with a knife is going to get through a cockpit door, and even if they take a hostage they’re not likely to kill more than one person — tragic for that one person, to be sure, but no threat to the aircraft, much less the transportation system. The TSA wanted to focus on threats to the aircraft — bombs, guns, and the like.

Yet the flight attendant’s union objected (naturally — they’re the ones who will get stabbed with those small knives, hit with those golf clubs, etc. and the safety of the transportation system is, to them, little consolation), and some opportunistic members of Congress latched on and threw a fit. How dare the TSA not stop an obvious threat? It didn’t matter that it’s not the TSA’s mission to stop that threat. The TSA is beholden to Congress, Congress is driven by public opinion, public opinion is driven by the media, and the media is driven by fear, because fear gets ratings. Fear sells, so it owns the media, which owns the public, which owns Congress. So now the TSA has backed off from their threat — they can stop a drunkard with a pocket knife, so they must stop a drunkard with a pocket knife. Never mind that it’s not their charter, that it has nothing to do with the safety of the transportation system, that it’s unrelated to terrorism or homeland security.

Maybe Obama’s right — maybe PRISM isn’t really a threat, just a reporting system, and maybe the NSA, despite the fact that a random analyst “sitting at my desk certainly had the authorities to wiretap anyone from you or your accountant to a Federal judge to even the President” isn’t abusing that power. Like the criminal compliance employees at major Internet companies, people working for the NSA are by and large loyal American citizens who perform their role because they believe in it, and because they know they’re doing good for their country. They swear an oath to uphold the Constitution, and that includes the Fourth Amendment. In any case, NSA surveillance is absolutely inadmissible in court for domestic crimes; FISA orders are only valid for, as the name implies, foreign intelligence.

But what happens when the media turns its attention to something other than terrorism? What happens when public opinion gets incited against something else — something evil, of course, but nevertheless something outside the NSA’s purview? What happens when the public’s fear turns from terrorism to human trafficking, or child abduction, or illegal immigration, or foreign cyber-attacks, or “hackers,” or corrupt bankers? The NSA has the evidence to catch these people — Congress will demand action. We have a hundred thousand spies now: they have the capability, they have the information. The law will change; maybe not now, maybe not for a decade, but if don’t strangle this right now, it will change. Even if every word the President and General Alexander says is true, it cannot remain true as long as these capabilities continue to exist and grow — we know exactly where this road leads. They can do it, so they must: as Homer said, the blade itself incites to violence.

There’s been the usual casting of blame after such an incident, but it’s quite interesting to read over the incident response report they had Mandiant prepare for them. Despite being “PCI-Compliant”, they had a number of vulnerabilities that let the hackers break in. But what could they really have done to protect themselves? From the report, the attacker went through 16 steps:

1. August 13, 2012: A malicious (phishing) email was sent to multiple Department of Revenue employees. At least one Department of Revenue user clicked on the embedded link, unwittingly executed malware, and became compromised. The malware likely stole the user�s username and password. This theory is based on other facts discovered during the investigation; however, Mandiant was unable to conclusively determine if this is how the user�s credentials were obtained by the attacker.

It’s not clear here if this was untargeted spam phishing with off-the-shelf malware, or a spear-phishing attack on the DOR with custom malware. If it’s the former, then this would have been prevented by any decent mail security product (to block spam and phishing) and desktop anti-malware software with current signatures & centralized monitoring. Since I would think any “PCI-Compliant” institution would have this, my guess is that this was a spear-phishing attack. The unfortunate fact is that there’s basically nothing you can do about spear-phishing and targeted malware; by its nature it evades automated detection, and security awareness training is of limited effectiveness against a phishing mail customized for your employees. So far there’s no sign that the state DOR screwed up here.

2. August 27, 2012: The attacker logged into the remote access service (Citrix) using legitimate Department of Revenue user credentials. The credentials used belonged to one of the users who had received and opened the malicious email on August 13, 2012. The attacker used the Citrix portal to log into the user�s workstation and then leveraged the user�s access rights to access other Department of Revenue systems and databases with the user�s credentials.

And right here in step 2 I think we’ve found the root cause of the attack. They had an external remote access service that allowed single-factor login — coming in through the perimeter from the Internet using only a password. Given that spear-phishing & targeted malware are not preventable, you have to assume that passwords will be stolen and have barriers in place to keep password-bearing attackers out; two-factor auth on remote access services should be a bare minimum, whether that’s SecurID tokens, smart cards, or other mechanisms.

3. August 29, 2012: The attacker executed utilities designed to obtain user account passwords on six servers.

Dumping the LSA secrets requires administrative privileges. It’s possible the credentials the attacker acquired in step 1 were administrative on some servers, in which case there’s no new exploit here. But if they weren’t, the attacker elevated privileges in some way, implying that the DOR might have had a patch-management problem. Once again, though, it’s not clear that there’s much they can do about it — patching inside of 30-60 days is actually very difficult for an enterprise of decent size, even a mature, technically competent one. If the attacker used a recent exploit, then the DOR might well have been no worse-off patching-wise than everyone else is. On the other hand, if they used something ancient, this might be another problem by the DOR. This said, with proper authentication on the remote access service, the attacker shouldn’t have even gotten this far.

4. September 1, 2012: The attacker executed a utility to obtain user account passwords for all Windows user accounts. The attacker also installed malicious software (�backdoor�) on one server.

At this point the attacker is a domain administrator; if he’s dumping “all Windows user accounts” he’s got at least a network login on the domain controller. Chances are that a domain admin had logged onto the first compromised server at some point, and thus the attacker captured his cached credentials. No new attacks or exploits here.

5. September 2, 2012: The attacker interacted with twenty one servers using a compromised account and performed reconnaissance activities. The attacker also authenticated to a web server that handled payment maintenance information for the Department of Revenue, but was not able to accomplish anything malicious.
6. September 3, 2012: The attacker interacted with eight servers using a compromised account and performed reconnaissance activities. The attacker again authenticated to a web server that handled payment maintenance information for the Department of Revenue, but was not able to accomplish anything malicious.
7. September 4, 2012: The attacker interacted with six systems using a compromised account and performed reconnaissance activities.
8. September 5 – 10, 2012: No evidence of attacker activity was identified.
9. September 11, 2012: The attacker interacted with three systems using a compromised account and performed reconnaissance activities.

Nothing interesting here. Very few enterprises could have detected the above; it would require the sort of aggressive NIDS with extensive monitoring that’s normally only found in classified environments.

10. September 12, 2012: The attacker copied database backup files to a staging directory.
11. September 13 and 14, 2012: The attacker compressed the database backup files into fourteen (of the fifteen total) encrypted 7-zip archives. The attacker then moved the 7-zip archives from the database server to another server and sent the data to a system on the Internet. The attacker then deleted the backup files and 7-zip archives.

This was a database exfiltration of over 8 gigabytes of data. This is actually one thing that NIDS could be effective against if tuned properly.

The remainder of the attack steps were just some more reconnaissance, backdoor testing, and other probes, followed by Mandiant shutting down the attacker’s entry point.

The interesting thing here is that assuming this was spear-phishing with targeted malware, the only mistakes the DOR seems to have made were insufficient IDS tuning (which is honestly usually high-effort, low-payoff security work) and having single-factor remote access (which is catastrophic.) There’s nothing in this report that makes it look like the DOR’s IT department was run by a gang of idiots (like in, say, last year’s many Sony attacks); it looks like an organization that was doing most things right but had failed to deploy two-factor remote access. I’d wager their IT security guys wanted to, too, but were blocked by either the inconvenience to users or the cost of rolling out tokens or smart cards.

Having spent more than $14 million recovering from this incident, I’d bet two-factor auth is looking pretty cheap now.

This year I’ve decided to make a departure from the talk-by-talk trip reports I’ve done in the past. Most of the interesting presentations are already online (the whitepapers and slide decks, at least) and I’ll link to them here, but overall this was a very interesting year in information security and I think the gestalt and the keynotes are more important than the specific exploits demonstrated.

BlackHat has changed from what it was five years ago. The criticism that it’s turned into a “vendor dog-and-pony show,” while harsh (it’s still worlds better than the RSAConference ) has some truth to it — the security presented at BlackHat these days is mostly the kind that comes in a box and slides into a server rack. However, the reputation and importance the conference has long had still draws some interesting speakers, who will often put off revelations for weeks or months to be able to reveal them at what is still the world’s #1 professional security conference. Nevertheless, as someone whose occupation is in secure design, architecture, and development, without some significant changes I think that the time of my attending BlackHat every year is coming to a close. (Also, to RSA, McAfee, and a few other vendor offenders: “booth babes” are really tacky at a professional conference. BlackHat isn’t an auto show, it offends a fair number of attendees, and it strains credulity to imagine that anyone purchases, say, cryptography hardware based on the hot girl at your booth who couldn’t actually answer any questions about your product. Considering as in the past three years I’ve not seen this marketing practice responded to with anything but ridicule I’m kind of amazed you keep it up.)

DT (The Dark Tangent, Jeff Moss) introduced the conference as always, and this year’s Day 1 keynote was retired FBI Assistant Director Shawn Henry. With his time on the Homeland Security Advisory Council and current role in ICANN’s byzantine and unaccountable bureaucracy, DT often seems to have much “gone native” in government; this was at least the third consecutive year of a government keynote dropping “cyber” into every third sentence. DT’s intro was surprising, though — he brought up the Strikeback firewall from 15 years ago (a programmable firewall that could DoS your attackers, should you happen to feel like programming your corporate network carry out automated felonies) and observed that you can counterstrike attackers with lawsuits, diplomacy, or direct action. A mostly-favorable view of counter-hacking was not a viewpoint I’d heard publicly expressed in years, especially from someone with government connections. Shawn Henry presented a rather militarized view of the information security landscape, going so far as to call computer network attacks “the #1 threat to global security.” Seems hyperbolic to me, but at least it shows they take the problem seriously.

On one hand, Henry showed considerable insight into the scope of the problem — better than we�ve historically seen from government (many previous BlackHat government keynotes have been laughable.) While he claims that the vast majority of hacking & data breaches happen in the classified environment where we never hear about it — a claim I find dubious just due to the sheer difference in scale between the classified environment and the Internet, but can’t wholly rule out either — he recognizes that the “cyber domain” is a great equalizer. A sophisticated organized-crime group or circle of motivated hackers does not differ meaningfully in capability from a state-sponsored actor; while Stuxnet and Flame may have been crafted by governments, they do not differ in sophistication from other advanced malware, and plenty of people outside the classified sphere have access to 0-days. It doesn’t take billions of dollars and government resources to carry out a major electronic attack.

(An aside: while this wasn’t something Henry talked about, one of my biggest concerns for the future is the advancing state of 3D printing, desktop manufacturing, and synthetic biology. You can assemble a synthetic biology lab and genetically engineer organisms in your garage at this point on a budget within the reach of a well-off amateur. While molecular nanotechnology is a long way off still, I have no idea how to deal with a world wherein we have to somehow implement a defense against when fail-once-fail-everywhere existential threats can come from individual nuts anywhere in the world.)

Mr. Henry claims that we have to go from mitigating the vulnerability to mitigating the threat — that is, prevent the attacks from happening in the first place. Just as the FBI had to go from measuring cases and arrests to measuring threat elimination as an international intelligence agency after 9/11, we need to move from trying to set up perimeters to keep attackers off the network to trying to detect and remediate attacks as they happen. We have to assume a breach and plan accordingly. Considering as the progressive decline in the effectiveness of perimeters and the need for distributed defense throughout the network, the enterprise, and the world is the reason behind the name of this blog, that part at least I agree with.

Henry says that the NSA and DHS have the authority and responsibility to protect government and military networks, but no one in government is monitoring the commercial space. This is a contrast from how other countries do things — the United States is unusual in not having an overt industrial espionage program that attempts to advantage local businesses. He extols us — people in the information security sphere — to be proactive in finding out who our adversaries are and sharing that data with the government. Judging by the questions (some of which were amusingly prefixed with “Without using the word ‘cyber’…”) this was not a popular view, for a couple of reasons.

The panel following the keynote (including DT, Jennifer Granick, Bruce Schneier, and Marcus Ranum, all BlackHat alumni from the very first conference) went into these criticisms further. One is of course that “sharing” with the government tends to be a one-way street, which prevents people from viewing them as a partner. The other, however, is that many felt that this is a spectacular abdication of responsibility by the government — Really? We’re supposed to keep the Chinese intelligence community out of our servers? And what are the billions of tax dollars going to the NSA and DHS for, then?

The panel discussion also went into an interesting discussion on what they — as some of the luminaries of information security — believe a CISO should be spending their money on. DT advised them to spend it on their employees, which of course went over swimmingly with this audience. Other advice included to spend on security generalists, not experts in particular tasks or technologies, since narrow expertise is increasingly available via outsourcing, and to focus on detection and response rather than defense and prevention. “The cloud” is going to happen whether CISOs want it to or not, so we have to find a way to have a data-centric model where we know what’s out there and can tell if it’s been tampered with; keeping everything behind walls will not work indefinitely.

A final controversy came up over the issue of government-sponsored hacking like Flame and Stuxnet. DT looked favorably on it, saying that before this there wasn’t really any room between harsh words and dropping 2000-pound bombs; governments having a tool available to them to carry out an attack without killing people is on balance good for the world. Jennifer Granick and Marcus Ranum vehemently disagreed, describing it as a crime against humanity putting civilian infrastructure on the frontlines of a nonexistent war, then telling people to be glad that at least we didn’t blow them up. The world of information security has become the political world; the world has changed such that Internet policy is just policy now.

There was also a keynote interview with author Neal Stephenson, which while entertaining did not really provide any insight so I’m not going to relate it here. If you’re a science fiction fan, though, it’s worth looking up when it inevitably appears on YouTube in a few weeks.

And now, on to the talks. One interesting trend was the recurring theme of attacks on pseudo-random number generators. Dan Kaminsky discussed how PRNG breaks have compromised RSA (about 0.5% of keys were compromised) and Debian OpenSSH, and hardware RNG just isn’t available most of the time. The problem is that our entropy pools are very limited on servers, VMs, the cloud, and embedded devices — we don’t have keyboard or mouse and frequently don’t even have disk or good hardware interrupts. TrueRand (which used an interrupt every 16ms to generate noise) was disavowed by its author but does still work, and Dan presented DakaRand which uses multiple timers and threads to generate noise since multithreaded programming is to a degree nondeterministic (and his algorithm proceeds to SHA-2 hash the noise, use Von Neumann debiasing, Scrypt the results and use AES-256-CTR to turn it all into a stream.) Each call is independent so it’s secure against VM cloning; unfortunately, most developers will just keep calling /dev/urandom.

George Argyros and Aggelos Kiayias proceeded to demonstrate a variety of entropy reduction, seed attacks, and state recovery attacks against random number generators, managing to compromise PHP session cookies and administrative recovery tokens across multiple applications. They went into some detail on the various random implementations on both Linux and Windows and how entropy can be reduced or the seed reverse-engineered; some of them were fascinating (like attacking your own session cookie first to build an application-specific rainbow table.) If you’re up for the crypto math, take a look at their presentation.

Other topics included a resurgence of attacks on NTLM (mostly pass-the-hash and SMB relay variants), using browser exploits to pivot into more traditional infrastructure exploits against routers, the recently-publicized exploits against Windows Vista/Windows 7 gadgets (which were well known and described in Microsoft’s own gadget security whitepaper; in short, it’s easy for a developer to write a vulnerable gadget, so most of them do so), and persistent injection of browser exploits during a MitM session (e.g. on open WiFi.)

However, there was one other talk I’d like to go into some detail on — iSec Partners presented The Myth of Twelve More Bytes around the impact of IPv6, DNSSEC, and the new commercial gTLDs (the top-level domain identifiers like .com and .net) being issued by ICANN. In short, these changes remove artificial scarcity from the Internet in a variety of ways that are not broadly understood, and this is fundamentally changing the architecture of the network because assumptions of scarcity are deeply woven into our current designs.

IPv6 is not just changing IP addresses from 4 bytes to 16. It makes substantial adjustments to the layer 2 through 4 network stacks, removing ARP while modifying TCP, UDP, ICMP, and DHCP and adding new IP protocols like SLAAC (Stateless Address Auto-Configuration.)

ICMP becomes critical infrastructure — you can’t blindly drop it or SLAAC, router discovery, and neighbor discovery stop working. Yet those are unauthenticated protocols, spoofable by anyone on the segment; duplicate address detection is also impractical since it can be spoofed for a DoS. SLAAC eliminates the need for DHCP (though DHCPv6 does exist for procuring additional addresses) by allowing clients to just give themselves an IP with the static SLAAC prefix, ask for a network identifier, and append their own MAC address to get a globally-unique IP. There is also a protocol (RFC4941, Privacy Addresses) for generating additional random addresses since for obvious reasons not everyone wants to have a permanent, immutable, Internet-routeable globally unique IP (it would sure make ad networks’ and trackers’ jobs easier.)

If you’ve not disabled IPv6 entirely on your Windows machines, the fact that you may not be rolling out IPv6 in your network yet may not protect you from IPv6 attacks. SLAAC is the default on Windows, so your Windows machines all have IPv6 addresses already, and the IP stack in Windows 7 and beyond prefers v6 over v4 — your Windows machines are just waiting for something to come along and talk IPv6 to them, and it doesn’t have to be you. Likewise, there are many IPv6-over-IPv4 transition mechanisms, like 6to4, 6rd, ISATAP, and Teredo, and while these can be blocked, you have to do so proactively — they just work otherwise, on your existing hardware and software. Your Windows servers may be speaking to a hacker on the Internet via Teredo right now without your knowledge.

Other interesting implications of IPv6: since unlimited extension headers are allowed, TCP packets may be fragmented before the TCP header — you can’t do stateless filtering on port number! And when it comes to stateful filtering, consider that you can’t keep a full state table (the number of possible source addresses to keep state on is unfathomably large) and attackers can send every packet from a brand new, totally valid IP address — these aren’t spoofed addresses, they can make full connections. Stateful filtering that’s not subject to trivial DoS is going to be a challenge.

The new top-level domain process also causes its share of problems by breaking the Internet’s trust model. And there are going to be a lot of new top-level domains — despite the $185,000 application fee for a top-level domain, Amazon has applied for 76 and Google for 121, and that’s just for “brand” domains they want to reserve entirely for themselves and not run as a registry. (i.e. Google has decided that all “.search” sites should be Google sites; likewise, “.shoes” or “.clothes” domains will all be Amazon’s.) While the process for applying for a gTLD is labyrinthine, there’s no step of the process that tries to judge whether or not issuing a domain is a good idea.

Currently we assume that a trademarked domain likely belongs to its most recognizable holder — paypal.com goes to PayPal. But who does paypal.rugby go to? Paypal.shoes (if it were to exist) goes to Amazon. With 1400 new gTLDs, many of which will be run as public registrars, this assumption no longer holds — “defensive registration” becomes impossible because you can’t even identify all the registries. We assume that IP spoofing is highly limited in full-connection situations, but under IPv6 I don’t need IP spoofing to create unlimited connections. We assume that an individual is highly attached to a few IP addresses (their home, work, proxies, VPNs, etc.) which will no longer hold true. How do we handle browser homeographs when they can exist in 1400 TLDs?

How do we do anti-fraud and adaptive authentication without IP scarcity? What about DDoS prevention, rate limiting, IDS, SIEM, event correlation — even load balancing? How do we do IP reputation? Moving it up to the network level is a problem since one bad actor could DoS their entire network provider. Right now, if you advertise an IPv4 space you don’t own, the people who do own it will notice and complain — but in IPv6, if you own an AS — any AS at all — you can create IP ranges for dedicated tasks, advertise them, then tear them down and leave little evidence they ever existed at all.

For all my complaining about the changing nature of BlackHat (the vendor floor is really the center of the conference now), it certainly brought to my attention some issues that are not yet “common knowledge” in the information security world. We’re already past time to start preparing for these things, as attackers already are.

I started the day with Whit Diffie & Moxie Marlinspike’s Q&A session in Track 1. There was no topic in the program; instead, they just both answered questions about SSL and cryptography. One interesting detail: one of the reasons RSA has become more successful (or at least frequently used) than Diffie-Hellman was that Diffie himself favored it, on account of certain attacks for which RSA is more favorable (though Diffie-Hellman is better against others.) A lot of the discussion, though, was about Moxie’s notary system proposal. I have to give Moxie credit here — though I’m still not sure that I agree with his proposal, I probably spent more time debating it with people than I spent talking about any other presentation this weekend. It certainly spawned a lot of conversation.

Paul Craig’s iKAT tool is always interesting, and he presented a new version. The previous one only attacked Windows kiosks, and now he’s cross-platform. Essentially, the principle is that Internet kiosks are designed with the threat model of defending the kiosk from the user… and not defending it from the Internet. Thus, iKAT is an Internet site that can be used by the user to attack his own machine, under the assumption that his own machine is some sort of locked-down Internet kiosk with restricted permissions. iKAT allows the user to take full administrative control of most of them, either just to get unrestricted Internet orb, if he’s less friendly, to Trojan the card-reader.

Next, Alva Duckwall presented A Bridge Too Far, a talk on bypassing 802.1x via creating a layer-2 transparent bridge. This was actually a rather cool talk, and coupled very well with yesterday’s talk on exploiting hotel VoIP via VLAN-hopping by cloning the phone. With all the focus being on Layer-3 protocols these days, it’s cool to see that you can still do some interesting stuff at Layer-2.

There was a talk in the afternoon on bit-squatting — essentially, a binary version of typosquatting wherein you register a domain that’s a 1-bit error off from a legitimate domain, not intending to catch user error but rather to catch hardware and network errors. 1-bit errors are fairly common, at least when multiplied by billions of Internet users. I didn’t attend the talk because I felt that all the interesting material was basically contained in the title — the moral of the story is going to be that you should probably register the 1-bit-off domain names of your own if you’re going to create a highly-targeted site like a banking site. Talking to people who did attend… the consensus was that it shouldn’t have been a 50-minute talk.

Instead, I visited datagram’s talk on tamper-evident devices. Most of them, well, aren’t tamper-evident, at least not against a skilled attacker. The attacks range from very obvious (stretching plastic, razoring up adhesive) to requiring more knowledge (dissolving adhesive with a wide variety of organic and inorganic solvents) to very clever. Note that during the Tamper Evident contest at DefCon, wherein people tried to bypass a wide variety of anti-tampering seals and devices… none of the seals or devices successfully resisted attack.

I followed this up with a talk by the DefCon NOC on Building the DefCon network. It’s an interesting challenge — building a high-bandwidth network, wired and wireless, for use by 12,000 people, many of whom will be actively attacking it, given only 3 days, using only hardware you can afford to keep in a box 51 weeks of the year. Considering their constraints they do a remarkable job. This year’s secure wireless was, so far as anyone could tell, actually secure… and possibly safer than using GSM or CDMA in this environment (GSM is definitely broken, and the not-quite-confirmed rumor is that CDMA users were hit by an 0day MitM this year, too.) DefCon TV was a huge hit, even though it did not successfully reach all rooms.

The last talk of the day was Jayson Street’s dramatically-titled “Steal Everything, Kill Everyone, Cause Total Financial Ruin!” It was sometimes amusing, but overall it was mostly a self-aggrandizing pentester talking about various (mostly physical) exploits he had pulled off. Not really any valuable content for a security pro, though your average non-security person would probably be shocked at how trivially exploitable most systems are.

Having spent pretty much the whole weekend at DefCon events, I decided to go back down to the Strip, see a show, and have some delicious steak frites and wine at the Paris. It was a nice ending to a packed weekend.

Overall, DefCon this weekend was a huge success (I’m making a note here.) The Rio was a great environment, much better than the Riviera, with enough room to grow and real food to eat. Staying in the conference hotel and having a group to enjoy DefCon with made it a much more fun experience than past years; both will be things I’ll be sure to repeat. (Incidentally, Google Plus is a great tool for attending a con with a group — it’s like having your own private Twitter — though I can’t say that I have found much else it’s good for yet.) Speaking of Twitter, while it’s been indefensible for DefCon in prior years, at this point since everyone has a smartphone and a Twitter account the #defcon hashtag actually has so much traffic it’s almost impossible to keep track of. Every time you bring it up there are hundreds of new tweets.

I think the new non-electronic badges were a success. While perhaps less “cool” than the electronic ones, far more people participated in the badge contest this year than have ever participated in hacking the electronic badges, and while badge lines did run 2-3 hours, at least they were available before the con started. At some point, DefCon management needs to learn that the conference is growing 10%+ per year and that they need to order enough badges for growth; considering the much lower cost of non-electronic badges, perhaps they’ll do that next year. The lines are entirely unnecessary — they exist only because everybody knows that badges have been under-ordered and people at the back of the line won’t get one. Without this pressure to get badges first, the infamous LineCon could be avoided.

DC303 and Rapid7 threw great parties. However, most of the fun I had was around the Rio pools — having them open until 2am was great, though even later would be nice (and allowing alcohol instead of having everyone smuggle it in would be an improvement, though I’m not holding my breath on that one.) Finally, thanks to DC206 for a great time, a lot of very interesting conversation, and confusing the hell out of taxi drivers.

Mycurial gave an overview of High-Frequency Trading systems in the next talk. These are the systems by which computers trade stocks and other investments with other computers, as a form of arbitrage — they offer things for sale to fulfill trades before they actually have the items in question, then quickly buy them. It’s a speed game, with latency measured in nanoseconds, such that distance between the trader and the exchange matters (light can only go 11 feet per nanosecond, after all, so a few hundred yards might put you behind another trader, resulting in a loss.) As a result, conventional security measures are practically nonexistent. Networks run on custom, non-standards-compliant TCP/IP and Ethernet stacks. Firewalls and IDSs, which can add latency in microseconds, are absolutely prohibitively slow. These networks are “dedicated,” but these days no network connections are truly dedicated — leased lines are still packet switched and trunked. If someone managed to find their way into one of these networks they could do a lot of damage. For that matter, who’s to say the traders aren’t subtly attacking each other? We still don’t know for sure what caused the May 6th Flash Crash.

I did not manage to catch Richard Thieme’s Staring Into The Abyss at either BlackHat or DefCon, which is unfortunate; many attendees said it was the best talk of the conference. This will be another one to catch on video.

I went to a talk on the Metasploit vSploit Modules, which are modules intended to test IDSs, WAFs, and other network monitoring and filtering technology. Pretty neat code, but not really relevant to my interests.

Gus Fritchie’s Getting Fucked On The River explored vulnerabilities in online poker servers, and the arms race between cheaters and the poker sites’ attempts to stop them. There have been a host of exploits, from a predictable random number generator (if you seed your card-shuffling algorithm with a 32-bit number, there are only 4 billion possible decks of cards, which means someone can essentially build a deck rainbow table and predict draws with great accuracy), to back-door “cheat detection” code that actually leaked hole cards to an insider, to poker bots that play well enough to beat average players (and can beat even skilled players if many of them collude together, or be used to launder money.)

A talk called VoIP Hopping The Hotel was one of the very few technical exploit talks I saw at DefCon this year. Luxury hotels are starting to put VoIP phones in rooms, using the same Ethernet lines as the in-room Internet. If you plug into the phone’s port, though, you see nothing on the network, and can’t get an IP — 802.1q VLAN trunking is used so the phones exist on a different virtual network than the Internet connections, and only the phones can see it. Now, properly used, 802.1q trunking is secure… but “properly used” means never allowing an untrusted user access to a “trunk port” (a single port which hosts multiple VLANs.) Since the hotel port does just this — both the VoIP VLAN and the Internet VLAN — it’s possible to use some tools demonstrated in this talk to gain access to the VoIP VLAN with a computer, puzzling out the VLAN ID for the VoIP VLAN and cloning the phone’s MAC and IP addresses. It takes some skill — send one wrong packet on the VoIP VLAN and you’ll trigger port security and get the whole connection shut down at the switch — but with proper tools isn’t very hard. So why would you want to be on the VoIP VLAN? Well, network designers tend to be lazy… and that VLAN tends to be the hotel’s internal network.

Finally, This is REALLY Not The Droid You’re Looking For was another good exploit talk. On Android devices, it’s possible to craft an application that uses only common permissions (“Read Phone State”) and uses only “safe” APIs (meaning automatic approval for publication in the Android Market) that spawns a service that watches for a specified list of apps, and (upon seeing one) foregrounds itself silently over the app in question. So someone can make a game which, after you have played it once, silently lies in wait and when I load up Facebook, or my bank’s app, or my password manager, pops up a fake login screen over the real one and intercepts the password. As a user, there is no defense and no detection; there may be no fix for this short of a significant overhaul of Android’s UI APIs and permissions.

Also back this year (for the first time in many years) was DefCon TV — the talks were broadcast over the hotel’s internal cable system to all the rooms. So when a talk filled up, you could just go back to your room and watch it there if you were staying in the Rio. It was quite convenient, though in some rooms (including mine) not all 5 tracks were available. Still, according to the DefCon Goons this helped a lot with crowding, since many people would watch talks from their rooms and only come down to the conference floor for more social activities.

For the evening, I met up with the DC206 group again, ate over at the Gold Coast hotel, and then dropped into the IOActive Freakshow (yet another pool party), followed by the DC303 party (featuring Dual Core and C64, playing a mostly drum-and-bass set in lieu of the usual nerdcore, albeit still with some rapping) and finally the DefCon White Ball (with Miss Jackalope playing more drum-and-bass.) There was a lot of dancing and not a small amount of drinking, with the usual discussion of hacking, infosec, and reasons to make a Tesla coil out of DefCon badges. All in all, it was another good night.

I started the first day with 1o57’s talk on the new DefCon badge. This year’s badges were non-electronic (for the first time in several years) — they were antiqued titanium discs with the Eye of Ra and various codes inscribed in them with a water knife. Apparently making the 10,000 DefCon badges actually used the entire supply of sheet titanium in the United States at the time. Bright side of them being non-electronic: they actually had them before the con started! There has been a history of the badges getting hung up in customs on the way from China, but the non-electronic badges were produced in the USA. 1o57 designed an elaborate puzzle contest around the badges, but I can’t say much about it as I didn’t participate this year. There was, however, a very nice-looking code wheel on the floor of the Rio convention center rotunda that was key to the game and gave the room a nice DefCon look, so it was appreciated even by non-participants.

I spent the next couple of hours exploring the non-talk aspects of DefCon (none of the sessions in those slots were particularly interesting to me) and bought up some DefCon shirts and a couple of 2600 Hacker Calendars. I also donated $170 to the Electronic Frontier Foundation in my name and my wife’s, though I didn’t actually end up going to the party to which that entitled me admission (the donation and not the party was the primary purpose anyway.)

I dropped into Mark Weber Tobias’s physical security talk, called Insecurity: An Analysis Of Current Commercial And Government Security Lock Designs, which involved some hilarious attacks on “high-security” physical locks. You know those locks with 5 vertically-arranged pushbuttons you see in every airport or government building? They pop right open if you stick a neodymium-iron-boron magnet on the side. A keycard/keypad electronic lock with a USB port on the bottom for reprogramming is impervious to electronic attacks… but opens if you shove a paperclip to the back of the USB port. This sort of attack was ubiquitous — simple modifications that made sophisticated electronic locks open in purely mechanical ways. The overall point is that to get through a door, you do not have to open the lock — you have to actuate the mechanism that the lock actuates. Sometimes this is really easy.

The next talk was entitled Why Airport Security Can’t Be Done FAST, about the TSA’s Future Attribute Screening Technology. This project intends to detect malicious intent, based on biometrics and facial cues, kind of like an electronic Cal Lightman. The problem, in short, is the standard Bayesian statistical issues that always come up when trying to detect something vanishingly rare like terrorism. The top 10 airlines in the world carry a billion passengers per year — the top 5 US carriers alone carry 500 million per year. How many of these are terrorists who actually intend to blow up a plane that flight? Let’s be very conservative and pretend 100 people try to board an American plane with the intent to blow it up every year (probably an enormous overestimate.) Now let’s imagine my FAST system is 99.9% accurate at detecting terrorists — sounds great, doesn’t it? Let’s get that into our airports immediately! But wait… 99.9% accurate means it will probably catch all 100 terrorists. It’ll also catch 500,000 innocent people — 0.1% of the 500 million passengers. So if FAST points you out as a terrorist, there’s a 0.0002% chance it’s right! Due to the base rate fallacy, a 99.9% accurate terrorist detector’s alarms are false positives 99.9998% of the time. Oops.

What do you bet the real FAST isn’t 99.9% accurate, either?

I next attended the EFF Year in Civil Liberties panel for a summary of legal issues in information security, privacy, and free speech. This was followed by the Hackerspace Panel, about hackerspaces and DefCon groups around the country and what they do to encourage innovation and bring hackers, makers, and other interested people together. Both panels went very well, especially given that the Q&A nature of panels often makes them hit-or-miss.

Friday night at DefCon is surprisingly free of events — about all that’s going on is the Black Ball and the DefCon Pool Party. I met up with the DC206 group again, had some dinner, and mostly hung out at the pool party for the evening and discussed the day’s events and other topics in hackerdom. Frankly, talking about interesting topics (in a hot tub outside with DJs spinning techno in the background, no less) beats most parties anyway.

Next I went to Chris Paget’s overview of the Final Security Review for Windows Vista. Since I’m someone who’s actually done Final Security Reviews for Microsoft and is part of the team that owns the Security Development Lifecycle, there was nothing here I didn’t know. However, Chris gave a very favorable review of Microsoft, and it was clear that she really appreciated the work Microsoft does in securing their products. For all the bad press Microsoft used to get in security, Microsoft has the most mature and complete security processes in the industry, and this is a remarkable turnaround when you look at where they were in 2001. It’s good to know that even on the much-maligned Vista they gave Chris and her team full access to everything and everyone remotely relevant, and got a very good return on investment in terms of security bugs fixed.

I missed the next session to pick up my DefCon badge. In my five years of attending DefCon, they have run out of badges every time, thanks to DT underestimating attendance (each DefCon has been much bigger than the last, recessions notwithstanding.) As a result, everyone queues up early to get one, making for hours-long lines. Though this year they went for a non-electronic badge, and thus at least had them on time, they did still run out by midday Saturday. Lines were about an hour at BlackHat, and apparently ran to over two at the Rio.

In the afternoon, I dropped into Moxie Marlinspike’s SSL and the Future of Authenticity. Moxie is worried about the constant compromises of SSL Certificate Authorities — many have had bugs in them that made it possible to get real, valid certificates issued to you for other people’s domains (e.g. google.com, or your bank), thus making it possible to eavesdrop on SSL communications in a man-in-the-middle scenario. One of the most-public breaches was the attack on Comodo that resulted in many false certificates being generated for some of the most important sites on the Web. But what happened to Comodo? Nothing! The CA system has no ability to change. Browsers trust Comodo, and even if we don’t like the idea of trusting them anymore — when they have been proven untrustworthy — there’s nothing to do about it. If browser vendors dropped Comodo, 20-25% of all secure sites on the Web would stop working. Moxie proposed a new system (he demonstrated it with a Firefox plugin called Convergence) wherein the user selects trustworthy parties, called notaries, which verify certificates for him. The notary system will prevent a man-in-the-middle attack just as well as the CA system does, and if you distrust a notary you can just switch to others, and nothing breaks. The user chooses who to trust. On one hand, this does give trust agility — the ability to change who you trust — which Moxie highly values, and it does prevent man-in-the-middle attacks unless the attacker is very close (from a network-topology standpoint) to the destination host (which is unusual — in most MitM attacks, the attacker is very close to the source host, not the destination.) On the other hand, I’m not quite convinced — the system does not prove authenticity, only that no MitM is present, so it doesn’t really substitute for the CAs. However, I’d say my friends and I spent more time discussing this talk than any other at BlackHat or DefCon, so right or wrong he got us thinking, which can only be good in the long run. The CA system really is broken, and it’s untenably fragile — if one CA has its private key widely distributed, everyone will be able to make fake SSL certificates forever. And there are thousands of CAs.

I went up to IOActive’s IOAsis suite at the top of the Forum Tower in lieu of the next BlackHat session. I’m not sure what actually happened between BlackHat and IOActive this year, but for the first time since I’ve attended the conference, IOActive had no official presence at the conference (whereas before they’ve been one of the top-tier sponsors) and ran their own parallel events at Caesars instead. I had a pass to IOActive’s events as well — spend five years in infosec in the Seattle industry and it’s hard not to know half of IOActive, particularly their CEO who seems to have the remarkable ability to remember everyone she meets, instantly and forever. I went to a talk they hosted about malware tools like Spy Eye and Zeus. Overall, they’re remarkable professionally-developed tools, with high-quality tutorials and documentation. They really make being a criminal easy, and if you happen to live in a non-extradition country like Russia, it turns out crime does pay.

Finally, I went to a talk about the latest Chip & PIN exploits. I have to admit, as an American, Chip & PIN exploits always seem kind of lame. They boil down to “with this amazing exploit, we can make European credit cards almost as insecure as American ones are all the time!” The fact that if you steal a credit card you can, you know, buy stuff with it until the cardholder notices it’s gone and calls the bank just doesn’t seem like a revelation. This said, it is interesting to see some of the dubious security decisions made in this “secure” payment system, and Chip & PIN will be coming to the U.S. in the near future. The worst threat here is not technical but legal — in most European countries, the fact that a transaction happened via Chip & PIN is considered prima facie proof that you authorized the transaction and are fully liable — either that, or you were negligent with your PIN and still fully liable. The fact that it’s possible to make these transactions without a PIN makes this dangerous.

At this point, BlackHat USA 2011 was over. I headed back up to IOActive’s IOAsis suite for their post-conference reception. I not only met up with several people from IOActive, but I also happened to strike up a conversation with someone who informed me that she was with the DC206 group — the local DefCon club here in Seattle that meets at The Black Lodge about 10 miles from here. We quickly found we had several friends in common, and she introduced me to the other DC206/Black Lodge people at the party. This worked out very well, as I ended up hanging out with them for the next three days of DefCon, and had a lot of great conversations with a very interesting mix of security pros, makers, and hackers as a result. Though I’ve been by the Black Lodge and DC206 events before, I plan to make an effort to be present for more of them in the future.

We went to the Microsoft party at the Haze nightclub in Aria, primarily because given the youth of the Aria property, none of us had ever seen it before. The party itself wasn’t bad — quite good compared to last year’s event — and they had a nerdcore rapper performing (I honestly don’t remember if it was DualCore or MC Frontalot, having encountered both of them multiple times during the week.) However, we stayed only briefly then moved to the Rio, where we hung out with other DefCon attendees at the pool. The Rio was kind enough to keep the pool open until 1am (much later than normal) for DefCon attendees, and even until 2am on subsequent nights, which was quite appreciated.

Since work wouldn’t allow me to book travel until July 1st, I had to stay across the street from BlackHat, at the Flamingo. It’s an okay place, though my room’s wired Internet and one of the lamps was broken, as well as something else unimportant that I have now forgotten. But it’s as close to Caesars as you can get without actually being in Caesars. Next year I’ll book a room in Caesars’ Palace Tower (particularly ideal, since its elevator actually goes straight to the conference center) six months ahead of time, and just cancel it if work decides not to send me to the conference — the deposit is refundable, so I won’t be out anything.

BlackHat’s had the usual (for the last few years) dull government keynote speaker (Ambassador Cofer Black this year, who said “cyber” about 100 times, as only government speakers ever do) for the first day. I spent a bit of time at a WiFi Penetration Testing Workshop, followed by a very interesting talk on Google Chrome OS. The gist of it is that in Chrome OS, since the browser is the operating system, a cross-site scripting exploit (which is very common and very easy) becomes the equivalent of administrative remote code execution on a conventional OS like Windows or MacOS. Since an XSS can call Chrome OS’s APIs, clicking one malicious link can give an attacker full access to all data for all applications on the system. While I don’t use Chrome OS (and, frankly, neither does anyone else), rumors that Windows 8 will support DHTML-based applications (like all of Chrome OS’s apps are) make me hope that the Windows 8 team is considering exploits like this.

Next was Dan Kaminsky’s talk, Black Ops of TCP/IP 2011. While it sure beat last year’s Kaminsky talk (“Hey, let’s talk about DNSSEC! By the way, did I mention I started a new company that makes DNSSEC tools?”), the description was rather misleading — he spent a third of the talk talking about BitCoins (short-short version: the BitCoin system does not scale well, and unless used verycarefully is not anonymous), then talked a bit about various sequence-number prediction vulnerabilities (well, sort-of-vulnerabilities), and showed off a tool (“nooter”) that can detect non-neutral networks (i.e. networks, like your ISP, that may be favoring some companies over others for extra cash rather than providing you a straightforward Internet connection.) The nooter tool was kind of clever, though, and it really would detect non-neutral ISPs, which is a valuable public service even if, well, not all that interesting.

I missed a talk on femtocells that I’ll have to catch on video, as it sounds interesting. Femtocells are the cell-network extension terminals you can get put in your house if you have terrible cell reception, but since this amounts to the cell phone company giving you physical control of an extension of their network, they’re apparently eminently hackable. But instead, I went to a talk on post-exploitation forensics with Metasploit. He made a module for Meterpreter that allows you, the attacker, to remotely mount a block device from a compromised victim machine. As a result, you can actually access the disk as if it were local, even to the point of using forensic imaging tools like EnCase on it. It’s slow, of course, but this brings capabilities to every hacker that… well, that the FBI and NSA have probably been doing to people for several years now.

I skipped the talk on bit-squatting, because I felt the description essentially encapsulated all there was to say about the topic. Due to quantum mechanics, thermodynamics, and other inescapable laws of physics, computers make one-bit errors pretty frequently. If you register a domain that is 1 bit off from a real domain, occasionally (very occasionally) someone who types in the real domain name perfectly fine will get sent to your domain instead. So if you are running a high-sensitivity business site, you might want to register all the valid 1-bit-off versions of your domain name, too, to keep malicious people from squatting it. It’s just typo-squatting with binary. From talking to people who went to the talk, they pretty much agreed that this could have been a 10-minute talk instead of 75.

Instead, I hit Aerial Cyber-Apocalypse. These people bought a cheap Army target drone, replaced the engine with electric, and added WiFi, GSM, and Bluetooth sniffers to it. The result: a tiny UAV, with GPS-guided autopilot, that can fly autonomously, circle an area, and eavesdrop on all the wireless networks and Bluetooth devices there, as well as hijacking nearby cell phones. Plus you can connect to the UAV via 900MHz radio and actually launch proactive attacks over the WiFi. Suddenly wireless networks inside a walled or fenced compound aren’t so safe. Though what this really made me think is “So, less than $2000 will make you a little aircraft, capable of carrying 20-50 pounds, that’s GPS guided and can take off, fly for over an hour, and land on its own on a 40-foot runway without any external control. Why exactly do drug smugglers build manned submarines instead of building these things by the dozen? 20-50 pounds of coke is not insignificant.”

Also during the day, Microsoft announced a $200,000 prize for development of the best new mitigation technology of the year. This is actually kind of neat — companies pay bug bounties all the time, but a prize not for finding something wrong but for finding a way to prevent exploits is new. They’re looking for things like StackGuard, DEP, and ASLR that have really made modern OSs much harder to exploit than older versions (well, except MacOS, which falls over if you blow on it.) On one hand, $200,000 is a lot of money, but on the other hand, you’d think someone who developed something like this would make a lot more money just starting a company to sell it instead of handing it to MS for a prize. Anticipating this, the terms of the contest say that collecting the prize gives MS the non-exclusive right to use the technology if they wish — including building a version of it into Windows if they think it appropriate — but does not sign over the IP to Microsoft. You retain ownership.

The evening’s Pwnie Awards included a well-deserved lifetime achievement award, and some very amusing award categories — all five nominees for “Most Epic Fail” were divisions of Sony, and the award for “Epic 0wnage” had nominees of Anonymous for the HBGary hack, LulzSec for hacking everyone, Bradley Manning, and Stuxnet. “Worst Vendor Response” went quite deservedly to RSA, for essentially losing the keys to the kingdom and then trying to cover it up, resulting in the Chinese breaking into Lockheed Martin.

For the evening, I went to the private Qualys reception at Yellowtail restaurant in the Bellagio and ate some sushi, while chatting with someone visiting from Germany. I then moved over to McAfee’s party atop Chateau at the Paris, where I spent a lot of time talking to security pros, as well as reminiscing about 1990s games with someone in a DOOM shirt (it said “IDDQD” and “IDKFA” on it.) Alas, I spent a little too much time there, as by the time I left to head to the WhiteHat Security/Accuvant Labs party (they had Crystal Method playing) at PURE, the club was full and they weren’t letting anyone else in, even those like me with invitations. So I took a taxi over to the Palms to drop into the Rapid7 party. Rapid7 (owners of the fantastic, indispensable, and free Metasploit tool) threw by far the best BlackHat party I’ve ever been to — normally these are fairly dull events (95% male, mostly standing around trying to talk over the music), but this was an actual party — I mean, people were actually dancing on the dance floor, which is unheard-of for a BlackHat party. Admittedly, part of what made it good was that Moon (the club on top of the Palms) is an incredible space — top of a skyscraper, roof open to the sky, balconies overlooking the Strip and the city on all sides, multiple levels so that there was both a “loud” area and a “quiet” (relatively) area so that both talkers & partiers could have a good time, etc. Still, it was a good time and pretty impressive for a vendor party. And thus ended Day 1.

Pretty good. The actual algorithm used is generally AES-256, which is so far as anyone knows unbreakable. The only known way to bypass it is by guessing the key, and guessing a 256-bit key is computationally infeasible. Imagine the NSA has a computer that can break 56-bit DES — the standard government code of a decade ago — in a single second. If they had a billion of those computers (vastly more than they do, even though the NSA has acres of supercomputers), it would still take 5×10⁴² years to crack a single AES-256 key — that’s a billion billion billion billion times the age of the Universe. It cannot be done.

But here’s the good news for people trying to break into Osama bin Laden’s hard drives — they probably don’t need to crack AES-256. Implementing a crypto algorithm is really the easy part of cryptography — the hard part is key management. How do you keep track of the key (which is basically a 77-digit number) and make it usable by people? There are a variety of potential weaknesses:

1.) Crypto software often has bugs or environmental factors that leak keys. AES may be unbreakable, and software like TrueCrypt and PGP implement AES, but is their actual implementation perfect? It may not be — there may be bugs in the software that make extracting the key possible.

2.) Software doesn’t run in a vacuum. For instance, when running software on Windows, segments of code and data not in use are swapped out to disk. If the crypto key happened to be in memory and was swapped out, that key might remain on the disk for quite some time. A skilled attacker using forensics software might be able to obtain some or even all of the key this way.

3.) Because no one can remember a 77-digit number, generally not only is the data on a disk encrypted, but the key itself is encrypted with a password and stored next to the data. Unless the password is 50+ characters long, it’s actually a lot easier to try every possible password than it is to try every possible key. And short passwords (<12 digits to those of us in the civilian world, maybe up to 15-16 for the NSA) can be cracked instantly using a rainbow table. What's more, people re-use passwords -- if the same password as is used for the crypto software is also used to log into the PC, or into some web sites, or for multiple kinds of encryption, etc., it may be possible to attack some other, weaker system for the password and then use it to decrypt the key. The NSA probably has key-extraction scripts already written and ready to go for hundreds of kinds of crypto software, operating systems, etc. to prevent them from having to do the comparatively very hard task of cryptanalysis. With Osama bin Laden in particular, they may have another advantage -- due to the fear of CIA/NSA "back doors" in American and European cryptography products, there has been a tendency in Islamist movements to write their own cryptography software. Ironically, the back doors probably don't exist -- but writing your own cryptography software is almost always a recipe for disaster. The problem is that anybody can write a security system so strong that they can’t figure out how to break it, and many times they mistakenly assume that means nobody can figure out how to break it. Almost everybody gets cryptography wrong the first few times they try to implement it; if bin Laden were using some sort of “homebrew” crypto that hasn’t been peer-reviewed by a few dozen cryptanalysts, it almost certainly has a key-leaking bug in it somewhere.

Overall, despite that consumer-grade encryption is actually very strong and computationally infeasible to break, it is extremely likely that the NSA will be able to bypass whatever crypto Osama bin Laden used on his hard drives — if, indeed, he used any at all. They just won’t do it by attacking the crypto.

Well, I suppose there’s nothing wrong with that, but it’s usually not very useful. Let’s look at the advice in the second article above:

1.) Don’t be cute
Okay, they have a good point here. Using a password like 123456, qwerty, password, secret, etc. actually will get your password hacked. If your password is subject to a dictionary attack, it genuinely is very easy to get into your account. Keep in mind that a “dictionary” doesn’t mean the Merriam-Webster one, though — it means a wordlist of common passwords, so things like 123456 and major historical dates and most proper names are in the dictionary. Don’t use them.

2.) Longer is better.
3.) Use the shift key.
4.) Comic book cussing is good.
These three are sort of true, but usually aren’t useful. Assuming all lower-case letters, there are 308 million possible 6-character passwords, yet 208 billion 8-character ones. Numbers, case, and symbols turn that 208 billion to 722 trillion. But for passwords on web sites, it’s irrelevant! To crack a website password, the attacker has to send each guess to the server. The proper solution here isn’t longer passwords for users — it’s password lockout. If after 3 wrong passwords, you’re required to wait just 5 minutes before you can try again, even that all-lower-case-letters 6-character password will require an average of 655 years to crack. Password lockout makes brute-force hopeless — so all your password has to be is something not in the dictionary (for hacker values of “dictionary”). More secure sites like banks could implement progressive lockout — say, after being locked out for 5 minutes three times without a correct password, disabling the account entirely and requiring you to call or otherwise verify your identity.

The one place this is true, however, is for passwords protecting or being used as cryptographic keys. If you have an encrypted file, you want the password to be long and complex, because someone who has the encrypted file can try all the passwords he wants as fast as he wants. There’s no server to lock him up — he’s doing the cracking on his own machine! But for web site passwords, it just doesn’t matter at all.

5. Keep it centered.
This is just plain silly. It’s not remotely true that “nearly all” passwords are stored with the last character in clear; in fact, most aren’t stored at all, using a hash check instead. This is a particular flaw in one specific password storage routine. There have been others — for instance, the old NT LANMAN hashes were split such that a password could be broken into 7-character chunks and each cracked individually, so passwords of 8-13 characters were actually easier to crack in some cases than 7-character ones. Must we always figure out exactly what password-storage routines every app and website uses, and craft passwords to match? Of course not.

6.) Keep it fast, keep it mental.
If it’s your ATM PIN, you may have to worry about shoulder surfing. Likewise if you work for the CIA and there are spies everywhere. But passwords you use at home? Probably not a big concern. And what about writing down passwords — why not do it? If the password record is stored in your house, someone would have to burgle you to get it, which is (hopefully) pretty unlikely. Now, writing it down in a place proximate to attack is a bad idea, of course — putting your work password on a post-it on your workplace desk, for instance, or writing down your banking & credit card passwords on a paper in your wallet (right next to the credit and debit cards that identify which banks you use and the ID that shows your name…) is a recipe for getting hacked. Putting a password list into a dedicated device is very secure, albeit excessive for most people.

7.) Remain paranoid.
8.) Don’t double up.
Password rotation and avoiding reuse are actually the best recommendations on the list. For websites, a simple 6- or 7-letter password you change every 6-12 months and don’t recycle is probably a great deal more secure than setting your password to &*Q}}@#$7-=[\?~^.

It’s also very hard to remember to do.

9.) Loose lips sink ships.
This isn’t really related to password selection like the others, but yeah, don’t tell other people your passwords unless you’re entirely comfortable with them being you. If it’s your spouse, fine, but sharing passwords among semi-trusted groups like coworkers is a bad idea, and giving it to anyone on the phone who claims to need it is a terrible one. (One of the most famous hacks of AT&T’s COSMOS billing system back in the 80’s came from someone simply calling an operator and saying “Hi, this is Ken [the name of the company CEO at the time]. What’s the root password?”)

10.) Don’t turn your back on your computer.
Oh, come on, this is why we have screen savers.

If I were to come up with a list of password security advice, it would look like this:
1.) Don’t use dictionary words, people’s names, or anything you think might be a common password. Make up something unique.
2.) If the password is to something important — like your bank account — change it every few months.
3.) Never use the same password for important things as you use for frivolous websites.

And that would be about it. Short enough to remember.

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.

Apple doesn’t want you to run anything on your phone that they didn’t approve. But of course, customers want to run whatever they want on the phone they bought, regardless of if Apple likes it. This creates end-user demand for jailbreaks — software that attacks their phone’s OS to remove Apple’s restrictions. Whenever one is discovered, Apple patches it, but another one is always discovered soon afterwards.

Right now, there’s a website, jailbreakme.com, that offers the easiest, most convenient jailbreak yet. You browse to the site on your iPhone, iPad, or iPod Touch, and suddenly it’s jailbroken and the non-Apple application stores like Cydia are available. It’s very slick, and much easier than any previous jailbreak, many of which required modifying OS images, caching key signatures from Apple, and other tasks that required at least some moderate technical savvy. People really like jailbreakme.com — it makes taking ownership of your own phone quick and easy!

How does it work? Well, it’s a combination of two exploits. When you visit the site, it loads a PDF that exploits a bug in Apple’s font rendering (iPhones render PDFs themselves, using Apple code — Adobe’s reader is not even involved) to load and run arbitrary code. Then that code exploits another vulnerability, in the iOS kernel, to run code as root, outside the app sandbox. This third piece of code jailbreaks the phone and installs the necessary backdoors to wrest control away from Apple and give it to the user.

But… there’s a problem here. The fact that this works means that there’s an unpatched remote root exploit on every iOS device. That is, on an iPhone, iPad, or iPod Touch, any website you visit or any email you receive can silently load and run arbitrary code on your device, which will then reside there permanently and do whatever the attacker wants. How do you know this hasn’t already happened to your phone, and your location isn’t being tracked, your calls tapped, your SMS messages and web passwords forwarded to some Russian crime syndicate? You don’t. There’s no way to know, because there’s no anti-malware software for iOS — Apple would never approve it anyway, since you’re not “supposed” to be able to run anything but Apple-approved apps anyway.

In a normal, open ecosystem, like that on PCs, this problem would be less likely to happen. If a security researcher discovered remote exploits like this, they would often follow responsible disclosure practices, and contact the vendor and let them know about the problem so it could be fixed. But they’re not willing to do this for Apple — because they need the remote exploit to have unfettered access to their own phones!

Apple has created a situation where someone acting in good faith to help iPhone users use their own devices has to keep security flaws away from Apple, so that they can also be used by malicious attackers. Apple and Apple’s users are on opposing sides — helping Apple hurts legitimate users, yet helping users jailbreak also means helping attackers exploit them.

What’s more, when Apple releases a patch to iOS to make it no longer vulnerable to these attacks, they will undoubtedly reverse the jailbreaks in the same patch. Thus, users will not want to install the patch, since it will kill functionality that they want on their phones! In the IT world, it’s hard enough to get people to patch even when there’s no downside, and Apple’s creating customers who deliberately avoid patches and updates, since most of Apple’s “security fixes” are aimed at protecting Apple from customers, not protecting customers from harm.

Come on, Apple, would a settings checkbox marked “Allow execution of unsigned code” be so bad? You could even pop up a warning that turning it on makes you ineligible for Apple support. Is it really better to force your userbase to help hackers?

While the released versions are available on the BlackHat official website, I’m also making these available here for those who are interested. You can download either the unabridged slide deck (which was cut down considerably to fit in the BlackHat 75-minute time limit) or the complete whitepaper. These are both more recent than the versions on the BlackHat site.

In addition, I’ll be posting writeups of the talks I attended at BlackHat 2010 and DefCon 18 in the coming days.

XML
iCal
HTML

This is accurate as of 7/27, so be aware that more recent schedule changes may not be reflected! I’ll be attending the conference, not editing a Google Calendar.

On the other hand, search is not exactly something people have been clamoring for SSL on.  Implementing SSL for large amounts of web traffic is not cheap (done right it’s not terribly expensive, either, but it’s an engineering effort at least,) so normally it’s only done in response to either regulation or customer demand.

I think Google has an ulterior motive here — possibly two of them.  Current web browsers, as a privacy feature, will not pass extra headers from an SSL site to a non-SSL site or vice-versa.  This means that if I click a link on the SSL Google site, the web site I clicked on will not receive a Referrer: header indicating what I had searched for on Google.

(Incidentally, yes, this does mean that right now every time you click a link or ad on Google, the site you click through to gets to see what you searched for.  It’s always been this way, most people just don’t know it.)

There’s a big business in website analytics.  People run various statistics packages on their website to find out what searches lead to them, what sites link to them, etc.  It’s critical for optimizing marketing or advertising strategies.  There are also several analytics services that will do this for you, including Google’s own product Google Analytics.  If everyone started using SSL for searches, all of these would be broken… well, except Google’s of course, because Google Analytics doesn’t need to rely on the Referrer: header — it has the inside scoop from Google Search itself.

In addition to this, in the pay-per-click advertising world, conversion tracking is very important.  One advertiser may pay for thousands of keywords and run dozens or hundreds of ads.  They track each click all the way through to sales — in other words, they look not just at which ads people click on, but which ads buyers click on, vs. ads that only attract browsers who don’t follow through and purchase.  Once again, these usually work via the Referrer: header, which SSL takes away.  And once again, Google offers its own conversion tracking system, which will no doubt still work when all the others are broken.  This one can be worked around — you can make a third-party PPC conversion-tracking system that doesn’t use Referrer:, it’s just a little more work — but not everyone will work around it.

Both of these results would mean, in a world where many searches were over SSL, rather than just a tiny fraction as it is today, that advertisers & webmasters would have the choice of either operating “blind” or giving all their data over to Google.  And they have a very good reason not to want to do this — if you’re an ad buyer, and Google is the supplier you buy from, do you want Google to know exactly what keywords & placements are most profitable to you?  Clearly Google can use this inside knowledge of their customers’ businesses to maximize prices on the most effective advertising spots.

This is the sort of thing that can lead to an antitrust lawsuit.  So far Google has managed to spin it as a consumer-friendly privacy feature, but we’ll see if that lasts.

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.