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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For anyone who has never tried to use Internet in a hotel, the way this works is as follows:

1. You connect to the wired or wireless network, and are assigned an IP address via DHCP.
2. All Internet connections are directed by the gateway to the same IP — one that rejects everything but ports 80 and 443, and redirects those to a web page that asks you to confirm your acceptance of the exorbitant fees and provide your room number.
3. Once you accept the terms, the redirect goes away and you have unfettered access to the Internet, usually via a true Internet-routeable (not RFC 1918) IP.

Now, for me, the first thought I have is, “How have they implemented this? Doing it ‘for real’ would require tons of custom hardware and software! Surely they took shortcuts.” So, I booted into BackTrack 4, fired up Wireshark, and took a look around on the wired network.

The first thing I noticed was that, for the most part, all the traffic I was seeing was my own. So at least this wasn’t some kind of dreadful 1990′s-era shared-backbone network. However, there were two exceptions to this rule — ARPs, and DHCP Offers and ACKs.

So, what can we learn from this? We’re on the equivalent of switch-based Ethernet, where the only traffic that reaches our PC is that destined for our MAC address. The switch remembers which MACs are one which ports, and won’t forward us anything that doesn’t correspond to our MAC. We get ARPs and DHCP because those are sent to the Broadcast MAC — switches forward them to everybody. This tells us one avenue for attack — we can get other traffic routed to us by sending out packets with a spoofed MAC. If the switch learns that a given MAC is on our port, it will start sending us the traffic for it.

But that’s not useful. MACs are 48-bit numbers; I’m certainly not going to start guessing them. What’s probably of most interest to people on hotel Internet is how to get it without paying, not how to route others’ traffic to themselves. Okay, at BlackHat and DefCon, routing others’ traffic is probably of interest, but not generally.

But this tells us another avenue for attack, too. If we’re receiving broadcast traffic meant for others (presumably other hotel rooms) on switch-based Ethernet, then this means that the system doesn’t have the ability to send the DHCP and ARP traffic to only one room! If it were really designed securely, it would — there would be point-to-point traffic to each room. Since there’s not, then it must simply be addressing traffic to each room and putting it into a switch.

We have a clue as to how it addresses traffic to the room. The charge of $13.99 per day is per laptop — that is, if you use multiple machines, you have to pay for each of them. This policy is clearly daft — it seems very unlikely that the hotel expects anyone to actually pay the fee 2-3 times per day, and so all it does is curtail usability for no reason. Which means that it’s likely a technical limitation — which is to say, they’re identifying unique customers by MAC address.

MAC (Media Access Control) address is assumed by most people to be static. It comes with your network card, and whatever MAC your card has is the one you have for life. And in Windows, this is true with most network drivers — they provide no facility to change your MAC. On a Linux such as BackTrack, though, this assumption is wrong.

The easiest way to get free access on a hotel network, then, is to just use the MAC of someone who already paid. We fire up Wireshark, and add a filter excluding our own IP, such as:

ip.src != 1.2.3.4 && ip.dst != 1.2.3.4

Where 1.2.3.4 is the IP we get from ifconfig. This should filter down to nothing but DHCP offers & acks. We then pick any random DHCP ACK, and open the “Bootstrap Protocol” node, where we find a line labeled “Client MAC address.” This will list the address, both in the form that enumerates the manufacturer, and in the form we want — six colon-separated octets (e.g. 00:11:22:aa:bb:cc).

Now we just tell the system that we are, in fact, someone else. This is a simple task in Linux:

macchanger eth0 00:11:22:aa:bb:cc
/etc/init.d/networking restart

Now we’ve just changed or MAC to someone else’s, and requested a new IP address. But, how do we know that the MAC we changed to is any better than our own? Well, it stands to reason that if someone is connecting to the hotel network, they intend to access the Internet. If the ACK is brand new it may not work, but anything more than a few minutes old is probably golden — and if it’s not, you just pick a different DHCP ACK out of Wireshark and try again.

Drawback to this method: it is possible, depending on how the hotel runs its network, that you just DOSsed the legitimate user, which is clearly undesirable. It’s not likely, though — the gateway probably just redirects users who aren’t on a MAC whitelist to the paywall, and lets everyone else through. The switch is now routing that MAC to two different rooms, each of which have their own IP, and apart from occasional glitches from layer 2 or 3 collisions, it will probably work fairly well. Nevertheless, don’t fool yourself into thinking this sort of thing is totally harmless.

From the hotel’s perspective, this sort of thing is not trivial to foil. If they want to prevent this from happening, they need a way to address rooms, not laptops, and that means assigning a switch port or IP address to each one rather than doing a continuous dynamic re-provisioning. This is expensive… probably much more expensive than just allowing the occasional network-security geek with a Linux install bypass their paywall.

A privately-run alternative to the TSA’s Registered Traveller program, Clear started out with what seemed like a good idea — allow frequent travelers to undergo a thorough background check to make sure they weren’t terrorists or criminals in lieu of screening them every time they went to the airport.  For someone who travels by air every week or even every day, the long-run time savings would be worth a fortune.  The TSA was all for this idea, since their goal is to prevent hijackings, not just have people take off their shoes for fun.  So Clear (originally called Verified Identity Pass) was started — and frequent travellers could pay $200 per year, have a background check performed on them, and get a nifty-looking smart card that they could use at any of a dozen major airports to skip to the front of the security screening line.

Wait a minute… skip to the front of the security screening line?  Yep, somewhere along the line some government bureaucrat changed the rules such that Clear and Registered Traveller-certified people still have to undergo the screening, they just get to go to the front of the line.  I can easily see their motivation for doing so.  Imagine being an assistant director at the TSA in charge of such a program: “So, what happens if, God forbid, someone with a Clear card blows up a plane?  What would we say to the public?  ’Yeah, he had a bomb on him, but we didn’t search him, because he’d undergone a background check a couple years ago.  You see, he’d never blown up any aircraft before, so we had no idea this would happen.’”  It would go even worse for the TSA if said terrorist were a member of a group that the public would consider an “obvious” terrorist suspect (e.g. a Muslim of Arabic descent) and would pretty certainly end the careers of everyone involed in the program, if not end the TSA itself.

So the Clear card was changed to only allow you to skip the line, while still undergoing the full security screening.  What no one seems to have thought of, though, is… why bother with the background check?  If you still have to be screened at the airport, what’s the point of having to be investigated to get the card?  In what way does the screening line contribute to security?  Many of these same airports let members of airlines’ top-tier frequent flyer clubs skip the line, too, and they’re not required to have background checks.  Essentially, Clear and Registered Traveller simply morphed into HOT lanes — pay a fee, and you get to go faster than people who don’t pay a fee.  It’s not “trusted” status, it’s “VIP” status. A smart card with associated fingerprint and iris scans seems kind of excessive for jumping a line.

Also, Bruce Schneier brings up an interesting point — now that Clear is out of business and having all its assets transferred to creditors, what happens to all the personal data in the background checks?  Who gets that asset?

The obvious purpose of this is to help people scam their companies’ expense reporting system by “padding” receipts.  People who are reimbursed for hotel, meals, etc. can create receipts for slightly more than they actually pay (or for that matter, create receipts for meals they skip altogether or eat a balogna sandwich for) and pocket the difference.  Apparently the same company aims to help people rip off their employers in any way they desire, as they also run “Fake Sick Notes USA.”  (Though people running that particular scam are often caught by their own actions.)

It’s interesting that receipts are considered “proof” of purchase.  A receipt, after all, is just a piece of paper, and what’s more, there is no standard for what a receipt looks like.  People know it should be printed on “receipt paper” — which is usually thin thermal paper, but is sometimes quite heavy paper tape that’s inkjet or impact printed — and contain certain pertinent data, like the location of the purchase, the tax, the total, and some legalese at the bottom.  In the modern era, receipts often have serial numbers or bar codes on them, which makes the receipt uniquely identifiable by the issuer, but is quite useless for anyone else to authenticate them.  After all, only someone who has access to Target’s computer system can say if Target receipt #824935729345 is authentic or not.  And when it comes to small mom-and-pop retailers (which often have cash register receipts that contain literally nothing but prices) and online retailers (whose receipts are trivially-forged HTML emails), receipt as proof of anything becomes even more ridiculous.

All this false expense site does is make available to the general public an ability that’s been available to the tech-savvy for years. Someone with Photoshop and a USB thermal printer (easily available on eBay for under $100) has been able to forge receipts since the 1990s. This is another case (like checking accounts) where the “security” of a system comes not from any internal defense, but simply from the fact that most people don’t have a security mindset — most people don’t look at everyday systems and think about their weak points and where they break down.  Since a recept is used as proof of purchase, people assume it is proof of purchase.

Unfortunately, there’s really not much to be done to “secure” receipts.  To do so would require data-sharing between merchants, employers, and the IRS, so as to make receipt numbers authenticable — and that’s a case of the solution being worse than the disease (the privacy implications would be staggering.)  As an employer, the best solution may be to simply avoid the problem — have the company book hotel and travel for the employee (rather than reimbursing after-the-fact), and provide a per diem allowance for expenses rather than reimbursing exact receipts.  Any time you rely on receipts from employees, there’s the potential for fraud losses.

There was, admittedly, some cause for concern.  With 250,000 known machines infected with Conficker.C (and estimates of the full number of infected machines as high as 15 million before antivirus software started knocking them out,) activation of the worm would have created the world’s largest botnet overnight, far surpassing the Storm Worm’s 120,000-machine network.  It would have the power to bring down pretty much any target on the Internet at will, at least for a short time.  People feared that it would be turned against some critical infrastructure target (e.g. the root DNS servers) or major commercial site and bring down the Internet.

And that threat… is still there.  April 1st was only the first day Conficker.C could have been activated — not the only day.  Those infected machines are all out there, still polling for their master every day.  While the mitigations that have been put in place at many domain registrars will greatly reduce its impact, the fact remains that it would still be a huge botnet, not to mention that it could execute arbitrary code on any of the infected machines.  (If you’re worried you might be infected, just check out the rather-ingenious Conficker Eye Chart.)  But with the security industry aware of the threat, chances are that most of the machines that try to “call home” will not find anything listening on the other side, even if the worm’s authors do try to activate it.

If they’re smart, they probably won’t activate it at all.  Since botnet controllers constantly try to steal each other’s botnets, modern worms contain code to ensure that only the author can take control.  In the case of Conficker, this defense is actually very strong — orders for the worm have to be cryptographically signed, using a public-key algorithm.  On one hand, this means no one but the worm’s actual authors can give it orders — but on the other hand, it leaves them holding a smoking gun.  Only the worm’s authors can possibly have the private key that creates the signatures Conficker looks for — which means that possession of that key is all but proof of authorship (and thus of a very serious crime.)  Having such a trail pointing at them may prevent them from trying to use it at all, especially since the domain-registration algorithm has been cracked and domain registrars are monitoring attempted registrations for anyone trying to register a name that Conficker will eventually look for.

Overall, the response to the Conficker worm is another success story for the security industry.  There’s a paper about containing the worm over at the Honeynet Project that makes for good reading.  This said, it also points to the problem with the “detect-and-patch” model of computer security — this could have been much worse.  If the original Conficker variants had been as sophisticated as the C variant, and the worm activated on February 1st instead of April 1st, we would have had a very different story.

Back on December 10th, 2002, United Airlines really did file for bankruptcy.  It was all over the news, their stock plummeted, they went into reorganization (Chapter 11), and eventually emerged as a going concern.  it wasn’t a good thing for most involved, but it was over and done with.

Many online newspapers have archives of old stories that can be browsed.  The Florida Sun-Sentinel is no exception; it’s a pretty typical newspaper.  Online newspapers also often have dynamic lists of links — “Most Popular,” “Most Active,” etc., based on what articles have been read lately.  For some reason, which we may never know, the 12/10/2002 article somehow made it onto one of the lists.  Maybe it was a slow day and a couple people happened to click on it in rapid succession and it bubbled up to the list, and once it was there people started clicking on it (as the story would be pretty big news if it weren’t six years old.)  Whatever the cause, a link to this old story found its way onto the homepage — Tribune Co. says it was “due to traffic volume,” which I think lends credence to the “a few people clicked on a slow news day” theory, though it could have been deliberate, which I’ll get to later.

News aggregators, the most popular being Google News, crawl reputable news sources like online newspapers for interesting stories, then bump them up or down on their pages based on how popular they turn out to be.  Since this was on the Sun-Sentinel‘s homepage, and probably their RSS feeds as well, the Googlebot pulled it up.  However, the Sun-Sentinel‘s page did not list a dateline for the story — so, lacking any other information, the Googlebot concluded it was new; this is not unreasonable for something suddenly showing up on the front page of a newspaper.  Google News published the article in their aggregator with a dateline of 9/10/08.

People started reading the article, and that pushed it up in the rankings.  Soon, UAL’s bankruptcy was a top story on Google News, which is read by millions.  Some of those readers included stock analysts, one of whom proceeded to put the “news” on the Bloomberg wire, the primary source of breaking news used on Wall Street.  On one hand, it seems foolish of him, and this was probably a career-limiting move.  But on the other hand, Google linked him to the web site of a legitimate newspaper owned by Tribune Co. — he didn’t exactly read this on “hot-stock-picker.ru” or something; why would he doubt its veracity?  It was clearly a professionally-written news article in a major newspaper (or at least a minor paper from a major publisher.)

Wall Street today bears little resemblance to its history before the late 1980s, when “program trades” started.  Program trades are basically what they sound like — computer programs set to execute trades when certain conditions are met.  There were apparently a decent number of program trades set to dump UAL stock upon getting bad news about it over the Bloomberg wire, and they did just that.  UAL, as a mid-cap company with very high volatility, was quite heavily held by hedge funds, who are very heavy users of program trades.  Large, institutional investors — including hedge funds, perhaps especially hedge funds — limit their risk by having standing “stop-loss orders” on large positions.  These are orders to sell the entire position should its share price fall below a certain floor.  The hedge fund selling based on the news was enough to send the stock price down across a few stop-loss orders — and their selling sent it through more, and so on.  The stock dropped 79% in 15 minutes, eradicating literally billions of dollars in shareholder value.  At that point, the exchange stepped in and froze the stock, halting any further trading (as well as the runaway program trades.)

Once people figured out what was going on, the stock was bid back up to $10 again (about 85% of its original value.)  A lot of people ended up upset with Bloomberg, and Google, and the Sun-Sentinel, but there’s no one to sue — the Sun-Sentinel didn’t do anything wrong (they didn’t republish the story or try to call attention to it, it just sat in its archives like it had for the last six years), and the newswires and aggregators aren’t liable for checking the accuracy of things they link to.

What I found interesting, though, is the implications this has for deliberate manipulation.  This appears to have been an accident, but what if someone were to set out to do this on purpose?  All they would need is to find a newspaper or other reputable news source that doesn’t have reliable datelines on all their stories, then pick a stock that has recovered from old bad news or plummeted after old good news — just something where the news, if new, would affect the price substantially.  Rather than waiting for the story to coincidentally rise to the top, a botnet or set of proxies could bid the story up to “most popular” quite quickly.  The attacker would just have to keep it there long enough to be picked up by aggregators.

Essentially, this person would have tomorrow’s news today, and could trade on it.  (Well, really it’s yesterday’s news, but they’d know it before everyone else “knew” it.)  If you were doing this intentially to UAL, you’d first buy put options and short-sell the stock, in anticipation of the sudden drop.  Once it dropped 50%, you’d unwind those positions and start buying — after all, once the error is discovered, the stock will mostly revert to its original value.  It’s not even clear that this sort of manipulation would be illegal — the attacker isn’t a fiduciary, and can’t be charged with insider trading or most securities violations.  Federal law is fuzzy enough that prosecutors can sometimes find a way to charge just about any person with a crime if they really want to, but this would be quite difficult to prove.  It’s not like lots of people don’t hold put options and short sales on volatile, risky companies like UAL, and reversing the position after a big drop would hardly make you alone among traders.  Making 5-10 times their investment on something like this would not be difficult if it worked.

The interesting part about this is that it doesn’t involve an “attack” in the traditional sense.  There’s no cross-site scripting or SQL injection, no stealing of confidential data.  Nothing is involved but clicking on an old news story a few dozen times, and being positioned in the market such that the resulting chaos works to your advantage.  It’s even possible that this did happen with UAL, and the companies involved don’t want to talk about it, for fear of giving people ideas.

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

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

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

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

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

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

There are still some outstanding issues in TOR:

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

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

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

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

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

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

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

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

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

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

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

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