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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a

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?

a

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.

a

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.

a

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.

a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a

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

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?

a

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.

a

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.

a

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.

a

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

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

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

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

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

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

There are still some outstanding issues in TOR:

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

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

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

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

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

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

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

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

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

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

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

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

a

All that said, I wouldn’t argue for IP-izing currently-working non-IP networks like SMS, either. There’s simply no reason to.

Next, Arian Evans of WhiteHat security spoke on web application canonicalization, encoding, and transcoding attacks. This was one of the more interesting (and personally useful) talks of the conference for me. Web application vulnerabilities fall into two categories — syntax vulnerabilities, which fork code-paths, like SQL injection, cross-site scripting, etc., and semantic issues, consisting of errors in business logic. Syntax issues are normally fought by signature-based methods like IDS/IPS, WAFs (Web Application Firewalls), and XML firewalls. However, encoding syntax attacks can cause them to bypass these defenses.

Internationalized websites often require encoding and code page transitions in order to work. In addition, developers use encodings for type safety. An attacker can take advantage of these to get a syntax attack to its target:

1. Choose a vulnerability you want to exploit (e.g. XSS, SQL Injection)
2. Identify the parser on the target (browser, database, application, etc.)
3. Identify the supported encodings, codepages, and character sets on the target
4. Identify intermediate interpreters between you and the target that canonicalize alternative encodings, such as web browsers, web application firewalls, proxies, or other applications
5. Encode your attack such that it will be parsed in the desired way by the target after being canonicalized by all the intermediaaries

This results in complex nested encodings, such as encoding SQL with the CHAR/CHR functions, then decimal encoding that, then URI encoding that result. The resultant mess goes right past IDS/IPS, but each interpreter strips off a layer of encoding, and when the payload finally reaches the target, it is interpreted property and works. More sophisticated, internationalized apps are often easier to hit, because you have more options for submitting encoded (in another codepage) metacharacters that are later transcoded by the applications.

The solutions offered for this were the usual — strong data typing, strong output encoding (to prevent XSS), and enforcing the code/data boundary whenever possible (which isn’t often when it comes to web apps.) Still, this is very good stuff for demonstrating a SQL injection or XSS vulnerability to a business manager who insists that it’s not really exploitable.

Next, Ivan Buetler gave a presentation on smart cards, specifically the security of APDU, the Application Protocol Data Unit. Smart cards are mass-produced by a few companies, then sent out to companies or agencies that want to use them for security. The buyer initializes them with software and policy, then gives them to a user, who personalizes them with specific keys (often under the guidance of their employer.) Software from the manufacturer can be used to initialize or personalize cards. This demo used the Axalto Access Client, specifically the COVE and CMS administration tools.

The card itself enforces PIN policies and (sometimes) generates keys. During initialization, applets (written in Java and converted to a smart card bytecode) are uploaded to the card to add functionality. The upload, and all communication with the card, is done in APDU codes. These are laid out in the ISO 7816 specification, but there are many vendor extensions, which tend to be poorly documented — so many that the ISO spec is almost useless in reading APDU. However, it’s a simple command structure — a command consists of a class byte, an instruction byte, two 1-byte parameters, a data length, and a variable-length data field (and of course a checksum.) Ivan used an app called Smart Card Toolkit Pro 13.4.2 (I can find no reference to it on the Internet other than offers to pirate or crack it) to sniff the communication with the cards and read the APDUs. He also developed his own tools to hook winscard.dll so as to add himself to the stream as a man in the middle and be able to modify APDUs (and thus send arbitrary commands to the card.)

This revealed some significant vulnerabilities. For instance, during initialization, a card can be set to either generate its own keys, or to accept keys being uploaded as-is. However, this is “enforced” by the card later telling the personalization software that it would like to generate its own keys. It’s a classic trusted-client scenario; if you modify the APDUs, the application can be convinced to ignore the card’s settings, and the card takes whatever the app sends. Lacking any APDU documentation, Ivan was only able to find a few settings like this, but if the designers of the Axalto smart card system think that’s an acceptable practice, there are probably many more.

Scott Stender of iSec Partners spoke next, about concurrency attacks in web applications. This started out with an explanation of multiprocessing (in short, on any given core, two things that execute “simultaneously” don’t really — they alternate really fast, which means that they do execute in an order, and you can’t always predict what that order is.) This would have been a more interesting talk to me had I not spent years debugging crazy stress and performance issues in the past — I’m quite familiar with concurrency and race conditions.

With web applications, web app frameworks like .NET and Java Struts define an interface that contains request context (e.g. cookies, local variables, session variables.) Access to shared resources needs to be protected, but since web access is asynchronous, threads sometimes find themselves working with dirty or stale data. The classic example is a bank – imagine a money transfer process like this:

1. Collect source account number, destination account number, source account balance, destination account balance, and amount to transfer.
2. Verify that the source account balance exceeds the amount to transfer.
3. Set the destination account balance to its former balance plus the amount transferred, and set the source account balance to its former balance minus the amount transferred.

Seems perfectly sane. Now imagine that I put in a request to transfer my entire balance, then while that request is between steps 2 and 3, I start another request to transfer my entire balance, and it completes steps 1 and 2 before the first request resumes at 3. With multiprocessing this is quite possible — and it would result in my transferring twice as much money as I have (and likely without even having a negative source account balance.)

Concurrency flaws allow manipulating stateful assets (like the above bank accounts) or changing security parameters (like auth credentials or single-use redemption tokens such as gift certificate codes.)

The solution is well-established in the database world — transactions. Transactions are atomic, concurrent, isolated, and durable (the so-called “ACID test”) — a transaction succeeds or fails as a single unit (no part of it happens unless all of it happens), and none of the resources in a transaction may be touched until the transaction is complete. Web apps can implement their own transactions, or use the transactional support of their underlying database architecture. The important part is that there is some kind of end-to-end scoped lock (and global locks — that is, eliminating multiprocessing altogether and just doing one thing at a time — are both impractical for performance and lead to deadlocks.)

Concurrency flaws can be found in testing pretty easily — run load/stress tests and check for discrepancies afterwards. Usually something will show up. You can also add test hooks that encourage context changes to increase the likelihood of finding something. Scott also promised to upload his own tool, SyncTest, here in the coming weeks.

Jeremiah Grossman and Arian Evans also presented “Making Money on the Web the Black Hat Way.” This was all about business logic flaws, and the way they’ve been exploited to help underhanded people make tons of money without exploiting traditional “bugs” at all. These included:

1. Creating artificial scarcity in ticket sales for events via denial of service. When you consider purchasing tickets, the site “reserves” them for a short time until you choose to purchase or not. Since it costs nothing to reserve tickets for a few minutes… one person can reserve a lot of tickets.
2. Breaking CAPTCHAs for spammers. Some have terribly flawed implementations (e.g. the correct answer in a hidden field, or the image name), while others can be recognized by OCR software. Keep in mind that if OCR can read the CAPTCHA even 10% of the time, it’s “broken” — and it’s hard to make something that a computer can’t read even one time in ten that a human can still read. Also, there’s the Mechanical Turk solution — disguise CAPTCHA-solving as a “game” (usually one with porn as a prize) or just pay people overseas to solve them at low rates.
3. Various overseas companies offer “password recovery” services, that will tell you “your” password for a small fee, usually $30-$150. Basically, they just guess those horrible cognitive password questions (“What was your first car? Who was your favorite teacher?”)
4. Coupon fraud. Electronic coupons sometimes have predictable numbers, and some offers allow many coupons per order. Some people have bought over $150,000 of stuff with these coupons.
5. Gaming micro-deposits. When you set up an electronic transfer, the bank will sometimes send you a small deposit (less than $1), which you then tell them the amount of to verify account ownership. Michael Largent opened 58,000 brokerage accounts and collected these payments. It’s not illegal under any normal financial law — the bank is sending you a gift. However, he got charged under the USA PATRIOT Act for using fake names (58,000 of them.) This is a really dubious charge (who uses a fake name on the Internet? Oh, that’s right, everybody), but that’s par for the course in Federal law.
6. Application service provider bank robbery. Small banks don’t really make and run their own web sites — they buy a standard “banking product” from an application service provider. Some of these are really, really bad – the example one Grossman showed had no authorization. Once you logged in as a user, you could transfer money to and from any user so long as you knew the right account numbers (which other bugs in the site were very helpful in providing to you.) Crack an ASP, and you don’t just get to rob a bank, you get to rob many banks.
7. Slow order cancellation. QVC, the popular shopping channel, was apparently not very good at canceling orders. One woman started to order something, then canceled the order at the last step, and received the order anyway. Finding this interesting, she tried it again. And again, and again, until she’d received $412,000 in QVC merchandise and sold it on eBay. According to law, if you are sent merchandise you did not order you’re entitled to keep it as a free gift. She’d probably been able to keep doing it for years, too, if QVC hadn’t caught on because she sold the items on eBay still in their QVC packaging. Ah, criminals are always so entertaining.
8. Affiliate scams. People take advantage of affiliate offers in a host of ways. The most common are cookie-stuffing methods — rather than getting people to click links to affiliate sites like they’re supposed to, sneaky affiliates will embed links to the affiliate sites (often dozens or hundreds of offers) in IMG or IFRAME tags. Now whenever someone buys anything online the affiliate gets a check. They avoid referrer fields with SSL pages (or META REFRESH, or several other techniques.) Some get much more devious, with DNS rebinding, GIFAR, Flash malware, or other techniques. However, the affiliate networks can catch all this, because people sent to affiliate sites by such scams convert at a much lower rate (nearly zero) than those who clicked through to the site on purpose. This said, while people are caught constantly, apparently there is no evidence that anyone has ever been sued or charged over this sort of activity — it’s in a legal grey area where it’s not clear what, if anything, to charge them with.
9. Trading on semi-public information. BusinessWire (a popular place to post press releases for business) had a forceful browsing vulnerability — press releases that had been uploaded but not officially released were stored at publicly-accessible URLs and just not linked to the home page. When someone found out, they started reading tomorrow’s news today and making stock trades on it. They made $8 million. A federal judge declared that they did not violate SEC regulations, because they had no insider privilege or fiduciary duty to the company — they were trading on nonpublic information, but no one who was forbidden to give it to them gave it to them. They could still be prosecuted for hacking, maybe (is typing a URL directly to a page and not following a link trail “hacking”?). but that’s hard to prove if you’re remotely careful — usually we catch hackers by following the money to them, Al Capone style. If the money is legal, and you have to catch them for the technical exploit, that’s hard.

The moral of the story: business logic flaws are serious money, possibly much more than the syntax flaws we spend so much time worrying about. Test everywhere, profile users, detect leaks and aberrant behavior.

The final presentation of the day that I attended was one by Michael Slaviero and Haroon Meer of SensePost on getting data out of protected networks.

Long ago, once someone compromised a machine, they could simply enable a shell on some port, then telnet in. However, firewalls stopped that, so they began to do reverse tunneling with ssh and netcat (as well as more custom software like tcpr and fport.) Outbound filtering stopped that, too, and so we got web shells — pieces of ASP/ASP.NET/PHP/whatever-the-web-server-runs code that could be uploaded into a webroot and would provide remote control facilities and file transfers. However, there are now a host of mechanisms available for tunneling data out of a compromised machine.

For one, XP’s IPv6 support can be used as a port proxy. The netsh command can set up a proxy such that one port on one (internet-accessible) machine is redirected to a different port on another (internal, behind the firewall) machine. Thus, one compromised edge machine can provide direct network access to any machine it can reach on any port. The ssh -L and -R can be used to similar effect on UNIX hosts. This is a great reason for defense in depth — if an edge machine is owned, the firewall as a source of protection is largely eliminated.

There is also DNS2TCP. If an attacker can get this onto a compromised machine, it allows full 2-way tunneling of arbitrary TCP over DNS — the one protocol that is allowed everywhere. Once again, this bypasses the firewall. SensePost also demonstrated their own app (glenn.jsp) which encoded TCP over well-formed HTTP POST via base64 encoding. This is not just sending arbitrary traffic over port 80 (where an application-layer firewall will block it) — it’s true, valid HTTP requests against a real web page on the server, tunneling arbitrary TCP.

So with an edge web server under the attacker’s control, the firewall is bypassed in several ways, and your network is open to the attacker. But what if the attacker uses SQL Injection to get in? Then instead of a web server, they have a back-end SQL server with (hopefully) no access to the Internet, and thus no way to upload DNS2TCP or reach glenn.jsp. Well, it turns out that there are other ways that operate only on SQL.

Squeeza is an advanced SQL Injection tool. It separates content generation from return channel — you can have it return output via HTTP errors, via DNS tunneling (entirely in SQL!), or even via a blind timing channel (which is hideously slow — over a hundred milliseconds per bit — but works.) You can send all sorts of content through it — profile the version of the server, use existing OLE objects on the server in the server’s context (such as to write a working portscanner entirely in SQL), or (in many cases) take control of the machine.

SQL Server 2005 was the first SDL-developed version of SQL Server, and was intended to be far more secure by default than previous versions of SQL Server (which had over 1,000 stored procs enabled by default.) However, SQL Server is by its nature very hard to secure — it is very public, very capable, and highly targeted. What’s more, new features sell while better security doesn’t — so while most things are disabled by default, SQL 2005 has more “things” than ever before.

The downfall of a compromised SQL Server is in-band signaling. SQL Server’s configuration is controlled by stored procedures within SQL Server — so if you’ve gained sa access on a SQL Server, you can just turn all the disabled services back on. This includes the dreaded xp_cmdshell stored procedure (which runs shell commands as the server.) Using the new web service integration, you can write new SOAP endpoints entirely within SQL and place them on arbitrary ports — enable batch mode on those endpoints and they’ll allow running arbitrary SQL (thus getting you out of having to tunnel over DNS or use blind timing to get data out.) And if you enable the CLR, you can run arbitrary .NET code in the server (subject to CAS restrictions — unless you’re running as sa, in which case there are no restrictions at all.)

There are several interesting ways to get your arbitrary .NET apps onto the server. You can order the server to load them directly from a UNC path — if the server has outbound access to your server, which is unlikely. However, you can write SQL that creates the assembly in memory from raw hex and loads it. You leave no trace on the disk, and run arbitrary code.

All this talk really tells you from a defender’s perspective is the importance of defense in depth. A compromise of either the web server or the database server essentially takes down the firewall from the attacker’s perspective — they can reach anything the server can, and can run port sweeps to find out what’s within reach. Thus, it’s vital to do several things:

1. Run the web server and database server with least privilege. The attacker can’t get more access than the servers themselves have — both services should be running with only the minimal privilege required to perform their function. Web servers should only have access to the web root — and most importantly, only read access. Databases should never be accessed as sa — only as an account with execute access to needed stored procs and select access to needed tables. Don’t let a database INSERT or UPDATE — use stored procs for that.
2. Segment your network securely. The web server shouldn’t be able to hit any IPs or ports that it doesn’t actually need to hit to serve web pages. Likewise with the database server. Both inbound and outbound filtering is important.

Overall, it was a great conference, and there was a lot of good information handed out.  I’ll be posting a recap of DefCon 16 over the next few days as well (once I have a chance to boil a notebook full of notes down to an intelligible post.)

a

The keynote speaker was Ian Angell, of the London School of Economics, who was speaking, ostensibly, about risk. He is described as having “very radical and constructive” views on the subject. His primary point was that when you put together a bunch of parts into a system, it often goes off the rails — every action leads not just to a reaction, but a loop wherein the unintended consequences feedback into themselves. This makes control very difficult (he brought up Goodhart’s Law, “any observed statistical regularity will tend to collapse when pressure is placed on it for control purposes.) The IT industry is obsessed with providing more information, but omnipresent computer screens distract and cause errors in judgment — people come to rely entirely on the system, suspending independent thought and just blindly following the machine, while simultaneously missing details in the information overload.

Humans are obsessed with categorization — the attempt to treat the similar as identical. We deal with complexity by dropping less-significant relationships from our mental models — but those relationships still exist, and this creates uncertainty and risk. Not just computer systems have this problem; bureaucracy is the most effective way to deal with normal situations, but as anyone who has dealt with one knows, it is terrible at dealing with anything out of the ordinary.

However, for all this, I found Professor Angell basically useless. He’s comes across as very smart and amusing, but he points out problems without the slightest inkling of a solution. Yes, systems create complexity, from which comes risk. Shall we then abandon IT security in favor of a hunter-gatherer society? I don’t think I could get an answer on that from him.

The next presentation was by Billy Rios and Nitesh Dhanjani on the phishing culture and community. They observed some phishing code and noticed common strings, and thought to do a Google search on them with the intent of finding other places that phishing code was in use. Instead, they found thousands of credit card numbers, SSNs, and other identity information all over the Internet, in public forums, searchable on Google. The phishers throw around identities constantly, just to prove their authenticity. Meanwhile, they phish each other constantly — most of the phishing kits they found had back-doors in them or secret code to email a copy of all identities captured to their author. They’re not hackers at all; they generally know just enough to upload a kit someone else wrote to a site someone else hacked and collect the information. Also, ironically, the Google anti-malware blacklist turns out to be a fantastic way to find already-hacked sites to put phishing kits on — it’s full of Administrative logins and passwords.

This was followed by Dan Kaminsky’s DNS update, which I’m going to discuss in a separate post; for all its hype, I think it lived up to it. Faulty DNS is a Really Bad Thing.

Michael Ossmann had a presentation to give on software radio and the future of wireless security. Unfortunately, it was long on software radio and short on security. He mostly spoke about the USRP, a piece of open-source hardware (also available pre-built for $700) that gives full software radio capabilities to a PC. It can capture a significant amount of bandwidth in a range up into the 2.4 GHz band. Ossmann’s demonstration of this involved doing packet-capture on Project 25 radios, and a replay attack on a remote-control toy. Essentially, command-line tools can capture radio on most frequencies, and then (as it’s just a bitstream) DSP techniques can manipulate it arbitrarily.

While his speech had very little about security in it, the implications are significant in the long term. Making a good radio means either using very expensive analog components, or using cheap analog components and a lot of CPU power. In a few years, “a lot of CPU power” will be available on your phone, just given the rate at which CPUs improve. Wireless (802.11) security didn’t become a big issue as soon as it was possible to crack WEP (i.e. almost instantly) — it became a big issue when wireless cards with raw packet injection and monitor mode started to be cheap and ubiquitous. Wireless hacking takes a $700 USRP now; it’ll take a cell phone in 5 years (since as CPUs get more powerful, software radio gets cheaper than hardware, it’s only a matter of time until radios in phones and such are pure software, and thus reprogrammable.) You can see the beginning of this in THC’s GSM Project. If the cell phone network finds itself, security-wise, as badly off as 802.11 is today, it could be a frightening thing.

Alex Stamos and company from iSec Partners had a presentation on Rich Internet Application frameworks.  Rich Internet Applications aren’t well-defined, but they contain one or more of the following: AJAX UIs, local storage, an offline mode, running outside the browser, access to hardware resources, or the general appearance of a thick-client app.  Adobe, Microsoft, and others have created various apps and tools to help developers create these rich web apps.

Adobe AIR is the most full-featured of them — an AIR application runs in a full desktop runtime based on Flash.  There’s no sandboxing — a locally-installed AIR app has the full powers of the user, like an ActiveX control.  You can develop them in Flash, Flex, or JavaScript.  However, AIR apps can be launched from the web by ordinary Flash files (assuming the app is already installed on your computer.)  There is a remote mode, for running directly off the web with reduced privileges, but there’s a method for communicating and even passing objects between the local (full-trust) and remote modes.  Overall, it’s a scary thing, in the way that EXEs are scary (i.e. it’s insecure, but not any more insecure than everything else.)

Microsoft’s Silverlight is rather more restricted; it’s closer to Flash than to AIR.  Silverlight apps can be written in XAML with any .NET language, and use a scaled-down .NET runtime.  There is socket support, like Flash, but it is limited to certain sockets (4502-4534) and requires a policy file (clientaccesspolicy.xml) on the target server, even if the target server is the same site it came from.

Google Gears is even less functional than Flash and Silverlight; it’s essentially running HTML and JavaScript from the local machine.  There is local storage, and data sync with an API and SQLite for relational-database-like storage.  Also, it has the ability to run processes in a threadpool outside the browser, so as not to get shut down by the browsers’ tight-loop detection.  Bizarrely, it allows the app author to customize the installation warning dialog, making it quite easy to convince people to install weird Gears apps.  It would be good for distributed malware, like cryptanalysis.

Yahoo! Browser Plus is designed to make it easy to write browser plugins, which is kind of like making it easy to make bombs.  There are some things that shouldn’t be easy, because the less of them, the better, and browser plugins (almost all of which seem to be adware/spyware) are one of them.  BrowserPlus add-ons are initialized by an HTTP call to Yahoo!, and run with full trust.  It’s like ActveX with a built-in Ruby interpreter (an old, buggy one, even.)

Finally, Mozilla Prism is a site-specific browser with the browser UI stripped off.  Formerly known as WebRunner, it’s used to “desktopize” web apps.  The risk here is comparitively low, though the script has XPCOM privileges (basically, control over the browser itself, like a Firefox extension would have.)

You can also just use HTML5 for some rich functionality, like local storage.  There is DOM storage, allowing you to persist up to 5MB of data locally, as well as SQLite-based database functionality.  DOM storage is essentially the ability to save immense cookies that are subject to SQL injection attacks.  The W3C has had better ideas.  Also, unlike cookies, you can’t easily turn DOM storage off (there’s a Firefox about:config setting, but nowhere in the UI.)  As mobile devices bundle Webkit browsers (like Safari), they’ll be subject to this type of storage — it would be pretty easy to DoS a mobile device by writing dozens of 5MB cookies.

So, what does all this lead to?  A host of new security issues we never had to think about before, of course!   The RIA data stores are vulnerable to XSS — if your email or other personal data is in an AIR or Gears app, and someone gets an XSS on the sites the apps come from, they can steal your entire data store.  You can have SQL injection against JavaScript now, thanks to SQLite databases.  The same Flash-based XSS attacks we’ve seen now work on Silverlight and AIR as well.

On the bright side, they had some good prescriptive guidance for app developers:

1. Don’t use predictably-named data stores
2. Parameterize SQL, even on local SQLite stores
3. Domain-lock sites if possible
4. Don’t use AIR when Flash/Flex/Silverlight/etc. will do fine
5. Let users opt out of RIA functionality

Finally, Ty Miller had some shellcode to show us — reverse DNS tunnelling staged-loading shellcode, in fact.  The trend in vulnerabilities has been toward client-side exploits of late, now that socket-based servers have been hardened significantly.  However, if you do buffer-overflow a client app and get it to execute shellcode, the challenge is often getting a connection back to the attacker.  Clients are often behind firewalls, proxies, NATs, or all three.

Of the common shellcode techniques (port binding, callback, find-socket, address reuse, download & execute, and HTTP tunneling), only one (HTTP tunneling) works reliably with client apps — and Metasploit’s HTTP tunneling shellcode only works on IE6 with ActiveX enabled.  DNS tunneling (like Kaminsky’s OzymanDNS from 2004) would also get back — and even more reliably than HTTP, since it wouldn’t need to worry about authenticated proxies.

DNS gets through everything.  When you make a DNS request, it goes to your company or ISP’s DNS server, which forwards it on to a top-level server (like .com) and then to the DNS server that owns the domain name.  Practically everything makes DNS lookups (as Dan Kaminsky went into today), and nothing works if they’re blocked, so any computer is all but guaranteed to have DNS access.  With a malicious DNS server, you can actually tunnel arbitrary data through DNS.

Miller’s shellcode consisted of a tiny first stage which finds kernel32, creates pipes for STDIN and STDOUT, then makes an nslookup (yes, it shells out to nslookup) for a TXT record on the malicious DNS server.  The TXT record type can be extremely long, and the record it gets back contains the second-stage shellcode and a command to run.  The second stage shellcode runs the command, captures the output, and sends it back in fragmented DNS requests.  It then polls periodically for more commands to run.  The DNS requests all have a sequence number in them, guaranteeing that they don’t get cached and always get through.

He’s making his code available at projectshellcode.com, a site where he hopes to focus shellcode research and start a collection.  I think this is of dubious value (unlike exploits, shellcode is not really very useful to security folks on the “good guys’” side most of the time), but it’ll be interesting to take a look at what he’s come up with.

a

If I want to poison your DNS server, say, to redirect www.yourbank.com to my malicious web server, I can make a DNS request to it and ask for www.yourbank.com. Your DNS server either already knows the address (because it’s in the cache), or it sends a request to yourbank.com (the top-level DNS name for www.yourbank.com) asking where to find it. This request has a random sequence number, called the XID, from 0 to 65,535 on it, and the reply needs to match that number to be accepted.

However, DNS works through UDP, which is spoofable. That is, the way you know where a UDP packet came from is… to take its word for it. UDP packets have a sender address attached. So I can request www.yourbank.com from your DNS server, then send a reply claiming to be “from” yourbank.com answering the request and pointing to my malicious web server. The only thing stopping me is the XID — I have to guess which XID your DNS server used, since I didn’t get to see the request packet. Ten years ago, there were ways to predict XIDs, but that’s all fixed now. So all I can do is flood you with hundreds of replies with different XIDs, and hope I guess the right XID before the real reply arrives. Once the real one arrives, it goes into the cache, and I can’t ask for www.yourbank.com anymore (well, I can ask, but the server won’t do the lookup — it already knows where the site is.) So it’s a race — can I guess the XID faster than the real DNS server can respond? Since I only get to try once, it’s a race that, as the attacker, I will almost always lose.

A bit about DNS replies — they can contain multiple bits of information. This is to cut down on requests, because sometimes one server has many names. For instance, if I request “login.yourbank.com”, the DNS can reply with a packet that essentially says “login.yourbank.com is actually www.yourbank.com, and by the way, www.yourbank.com is 1.2.3.4″. I can’t, however, do this with a totally different domain — I can’t say, for instance, “www.evilsite.com is actually www.google.com, and www.google.com is 6.6.6.6″, because the DNS server wasn’t asking about Google, so it’s not interested in hearing my DNS server’s speculation about where it is. This defense is somewhat whimsically called “baliwick checking.”

Here’s Kaminsky’s exploit: if I query your DNS server about an invalid subdomain, and provide in my spoofed responses a reference to something else in the same subdomain, then I can attempt to poison your DNS cache all day long, until I get it right. Say I can get 100 spoofed replies in before a real reply. Now I don’t query for www.yourbank.com — I query for 00001.yourbank.com, which does not exist. I spoof replies that say “00001.yourbank.com is actually www.yourbank.com, and by the way, www.yourbank.com is 6.6.6.6″. If that doesn’t work within half a second, then I’ve failed. And since I’ve got time for 100 replies, and only a 1 in 65,535 chance of any of them being right, I probably fail — the odds are only 1 in 655 that I’ll succeed. So… I just try again 654 more times, with 00002.yourbank.com, and so on.  Since I’m rotating subdomains, I never run into the case where it’s already cached and I can’t force a lookup.

It sounds so simple — because it is. It’s by-design behavior of DNS. It’s exactly how DNS has worked for 20 years. And it’s completely devastating. Armed with this knowledge and a DNS server you control (which you can set up in minutes on any Linux box), you can reroute any vulnerable DNS server on the Internet, forcing all customers who use that server to your malicious sites. According to Kaminsky, 52% of DNS servers are still vulnerable.

There’s already a Metasploit plugin (called Baliwicked) for both the malicious DNS server and the attack client. You’ll need to sync them from the live tree if you want them, as they’re not in the main Metasploit package yet. However, it gets worse — today, a new Metasploit plugin called Evilgrade was released which uses this ingeniously. Evilgrade uses the Baliwicked exploit to remap DNS for the sites used by the auto-update functionality in eight popular software packages (Sun Java, WinZip, WinAmp, Mac OS X, OpenOffice, iTunes, the LinkedIn Toolbar, Download Accelerator, notepad++, and speedbit) to a malicious web site (itself.) What do those auto-updaters have in common? They all call home, look for updates, and if they find them, download and install whatever’s there without checking to see if it’s real. With the DNS being redirected, this means they download arbitrary Trojan horse code from the malicious site and install it, telling the user it’s a “critical update” to their software.

You might notice that no Microsoft software is on the list. This is because Microsoft’s updater technologies are all based on Windows Update, which checks a digital signature on downloaded updates before running it. Since an attacker can’t spoof the signature without Microsoft’s private keys (which are very closely guarded), the MS auto-update is useless for this sort of attack.

Unfortunately, as an end user, there’s very little you can do to protect yourself from this sort of attack. Your ISP needs to update their DNS server — most have, at this point, but only a bare majority; many, many sites and ISPs are still vulnerable. Any HTTP site can be spoofed right now — only HTTPS sites are safe (and even those only if you check the certificate and don’t access sites with SSL errors.) And auto-updaters could be installing any number of things — Evilgrade is particularly bad because you don’t have to pick a site you know the victim will go to to spoof, because the auto-updaters will go to their home sites automatically, whether the user wants to or not.  If you use any of the products spoofed by Evilgrade, it would probably be a good idea to turn off auto-update for a few weeks.

The lesson here is that the security community needs to stop trusting DNS – it is not a security technology, it never was, and it is not designed to be reliable. However, old habits die hard, especially when there is no viable substitute for many scenarios right now.

a

DNS has been around since the 1970′s, so people don’t expect it to change much.  And this wasn’t an ordinary patch, fixing a bug in the code where it was behaving in an unintended fashion.  In this case, Dan Kaminsky found something potentially extremely serious in the designed behavior of DNS and reported it to all the major DNS vendors.  As a result, it wasn’t just Microsoft that released a patch, but also Apple, Cisco, and the Internet Systems Consortium (makers of BIND, the primary DNS daemon of the UNIX world.)

Dan did this in secret, to prevent people from exploiting the bug.  This led to a lot of skepticism about whether it was a “real” vulnerability, or just Kaminsky (a ubiquitous figure in the security press and an amusing character by anyone’s measure) engaging in self-promotion by pointing out something already well-known.

If the linked blog post seems confusing, what he is implying is that all Kaminsky “found” was the fact that the DNS sequence number, used to match DNS replies with queries, is extremely short, such that if you can send 65,535 spoofed replies to a DNS server before the real server manages to reply, you can poison the cache.  While this is true, and a problem, it’s been known for a decade and is not interesting.  It’s exploitable in another way, too — you could ensure your forged response gets in first by forcing a user to make many queries (e.g. by giving him a web page with tens of thousands of embedded images) with while you spoofed a flood of responses with constant sequence numbers.  If you attached CNAMEs to all of those, and put the images on subdomains of the target (e.g. 1.google.com, 2.google.com, 3.google.com, etc.), you could potentially clobber the DNS record for a top-level domain on the end-user’s server.

The end result of which would be that if a user visits your malicious web site, you change the IP that, say, google.com goes to for everyone using that DNS server.

However, bad as all that sounds, it seems that Kaminsky found something even worse.  All of the skeptics of his discovery who have been let in on the secret have come around to his side, and all the DNS vendors issued a design-change patch.  Among other things, this patch broke ZoneAlarm — everyone running ZoneAlarm found themselves suddenly unable to use the Internet at all.  (At least, so it appeared — my guess is that they were actually just unable to make DNS queries, but to a normal non-tech-savvy user this amounts to a total loss of Internet.)

So, what is this exciting new DNS vulnerability?  Right now, heaven only knows (well, and Dan.)  But Kaminsky has promised to tell us all about it at BlackHat 2008, and I’ll certainly be there to post the results here.  For now… patch your DNS servers.  The only hint we have right now is that source port randomization (one of the mitigations in the DJBDNS secure DNS package) would have stopped it.

a

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

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

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

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

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

a

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

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

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

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

a

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

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

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

a