Today was the first day of this year’s BlackHat Briefings in Las Vegas. The biggest security conference of the year, it’s always an interesting place to be and often involves the release of new and previously unknown exploits.

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.

Blizzard Entertainment, makers of the phenomenally-successful multiplayer game World of Warcraft, have introduced two-factor authentication for logging into the game.  For $6.50, they’ll sell you a dynamic password keychain token called the Blizzard Authenticator, which looks much like the RSA keyfobs many in the IT industry use to log into their corporate VPNs.

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.

HexView has an article about tracking vehicles with RFID tire pressure monitors. The devices are found in tires and transmit tire pressure to the engine control module, which sounds innocuous enough, but to prevent modules from reading neighboring cars’ tires by accident, they also transmit a unique ID. Thus, you can follow a car around town based on its ID, turning tire pressure monitors into tracking devices.

RFID devices are becoming more and more common, and this trend will continue — they’re too convenient for many purposes for the security risks around them to stop them. You may not want every consumer good you buy to be tagged with an ID that lets people watch your shopping from 100 yards away, but the scenario of being able to check out at the grocery store by instantaneously scanning every item in your cart simultaneously is too compelling for people to resist.

Bruce Schneier has a post on the ineffectiveness of security cameras, but while calling them ineffective it does note that criminals moved their crimes to somewhere the cameras couldn’t see. This may be “ineffective” for a government camera system designed to deter crime, but it’s precisely what privately-owned security cameras are meant to do — make a target unappealing so criminals go elsewhere. This actually shows that cameras do deter crime… but only where they can see it.

However, both of these technologies can have pernicious effects, too. The HexView article points out that you could use the RFID tire monitors to commit murder — set a bomb with a radio trigger that goes off when the “right” car drives over it. It would also be just as useful to private investigators spying on citizens as it is to law enforcement chasing down criminals. And speaking of law enforcement, these cameras create a dangerous imbalance in their favor — the camera evidence is all under their control, and thus can come up when needed to prove a perpetrator’s guilt yet be conveniently lost in cases of police brutality, abuse of power, corruption etc.

This is an interesting time for surveillance — police and government surveillance ability is skyrocketing (London is practically blanketed in cameras at this point, as the British seem much less uncomfortable with them than Americans are) but it is still largely in the hands of authority figures. This is dangerous because of how fast the change is coming — our criminal laws and sentencing structures are based on the principle that most criminals get away with it. A $75 fine for speeding seems pretty reasonable, but what if that fine were levied every time a car hit 1 mph over the speed limit? Most of us would get fined a dozen times a day, every day, despite not even meaning to speed, because our behaviors are based on the idea that we probably won’t get caught and that even if we are police are unlikely to punish us for very minor transgressions. If people were caught for speeding every time, and fined every time, a $75 fine would be absurd — the fine could probably be under $1 and still bring in a few hundred dollars a month from every citizen. What is the right legal structure here? I can see two possibilities:

• Raise the speed limits to the speeds we really think no one should exceed, and continue to fine every time.  Maybe you should get charged every time you exceed, say, 85 on a highway or 55 on a city street.  Set them high enough that there’s no leeway required.
• Leave the speed limits where they are but set the fine really low, say a $0.25 per minute of speeding.  This makes speeding discretionary — you can obey the law, or not, but if you choose not to you pay a penalty.  This is a fundamental change in the whole idea of crime and punishment, and itself has some pernicious consequences — it means that a certain income level can render you “above the law,” which is not a good thing.  Obviously some crimes (such as murder) should not be treated as discretionary, but for traffic violations it could make sense.

It’s not just traffic laws that are like this; consider the War on Drugs.  If every person who ever smoked marijuana went to prison, we would have a nation of felons — there’d be few people left who could vote, get security clearances, hold most jobs, etc.  The RIAA lawsuits against file-sharers are a good example of what happens when technology that catches everyone gets used to enforce laws designed under the assumption that only the worst and most flagrant criminals will be caught — people being hit by millions of dollars in fines for using technology to do something that wouldn’t even raise an eyelash if done by old, physical means (e.g. posting a song on BitTorrent vs. handing it to a friend on a cassette tape.)

A surveillance society needs a different kind of jurisprudence — one that sets punishments that fit the crime even if applied every time.  On the bright side, actually doing this would lower crime rates tremendously due to the psychology of criminals.  Escalating punishments does little to deter crime because criminals are risk-seekers — they do not expect to get caught.   Even a small punishment can be a strong deterrent if applied every time — if criminals are usually caught, such that all criminals have some first-hand experience with being caught and punished, it would break this idea.  On the not so bright side, a surveillance society must have very liberal laws to avoid being a police state — our current legal system, applied to everyone every time, would result in tyranny.  We all break 10 laws a day, it’s only sloppy enforcement that allows us to live our lives.  Unfortunately, the technology for ubiquitous enforcement will come well before the legal system changes to make it livable do.

What’s interesting to me is what will happen when surveillance becomes even more common: that is, when it is no longer monopolized by authority.  This has already started with cellular phones.   Almost everyone carries around a device which, while primarily for communication, contains a camera and often a voice recorder and videocamera as well.  Everyone is equipped to carry out impromptu surveillance at any time.  Devices like these glasses from ThinkGeek (found via BoingBoing) coupled with the rapidly falling cost of storage capacity will change this to everyone actually carrying out impromptu surveillance all the time.  This will have a chilling effect on human behavior at first — would you act differently if you knew everyone around you was videotaping everything you did?  Everything you say will, indeed, be able to be used against you, and not just in a court of law.  However, look at what young people put on MySpace and Facebook these days — the next generation does not have the assumption of privacy.  They’ve grown up in a world where they know everything goes on a permanent record, and have simply accepted it.  Sure, they’ll be occasionally shocked by it (e.g. the first time their party photos on MySpace disqualify them from a job), but the knowledge of permanence has not stopped them from sharing themselves, and eventually the rest of us will adjust, too.

Consider what the democratization of surveillance does to government power.  When we’re all recording, someone is watching the watchers.  Corruption, abuse of power, etc. all rely on the fact that authority figures can get away with crimes because they are more reliable witnesses in court than their victims are.  When everything is on the record — and not just the official record, but everyone’s record — police and government officials become compelled to act within the law.  While this may not be much of an impediment in truly totalitarian societies like China where the courts are as corrupt as everyone else, it’s a very strong bulwark of freedom in any society with an independent judiciary and a liberal tradition like the Untied States and Europe.  This is the next generation of surveillance — everyone sucking in light and sound from their glasses, or lapel pens, or even contact lenses, recording every moment of their lives on multi-terabyte devices that fit in their pockets.  It’s probably only 5-7 years away, and it washes away the current problems of a surveillance society and replaces them with new ones.

I think this cycle will continue for some time.  After all, once we’re past the era of democratized surveillance, computer graphics and artificial intelligence technology will improve to the point that ordinary people can modify their recordings to create perfect video of events that never happened, indistinguishable from the real thing.  What happens to recordings in law courts then, when they cease to be reliable evidence and become hearsay?  Tapes will become the new eyewitnesses, known to be unreliable and requiring corroboration from others.  When it becomes truly easy to make forged video, perhaps we will have emerged from the surveillance society from the other side — why bother to record anything when there’s no way to tell if it’s real?  Sometimes the only way out is through.

Early this week, some researchers at Princeton University’s Center for Information Technology Policy released a fascinating video of whole-disk encryption being cracked quite quickly and easily.

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

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

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

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

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

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

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

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

For makers of whole-disk encryption software:

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

In my last post about finding a job in information security, when discussing application security, I off-handedly mentioned several mitigation technologies — GS, DEP, SAL, and ASLR. These are technologies developed by OS vendors to provide system-wide protection against common attacks, and are things every application developer should know about when dealing with native (unmanaged) code.

The scourge of C and C++ apps for the last decade and a half has been the stack buffer overflow. This is an attack wherein the attacker discovers that an application is trying to fit some piece of user input into a spot in memory without first checking to see if it will fit. In the most common scenario, the spot in memory is a local variable, which means that carefully-crafted input can overwrite the return pointer on the stack with a user-selected value. If this is done, when the function finishes it will transfer execution to the user-provided input, which can then take control of the running process and do anything that that process’s owner is capable of. If the process is an OS service, running with a privileged account like root on a UNIX/Linux system or Administrator/SYSTEM on a Windows system, it may be able to take full control of the system. I first learned this attack in Aleph One’s classic Phrack article, Smashing the Stack for Fun and Profit, written in 1996.

Application developers have been told for many years now to be very careful when allocating memory and copying data, especially strings, to prevent these exploits. However, it’s relatively difficult, so developers continue to make the same mistakes. In addition, the attackers get more creative, and have found variations on this attack that are even harder to avoid. Luckily, OS developers have also been busy trying to find global mitigations for these attacks, so that developers can’t make these mistakes, and the whole computing ecosystem becomes safer.

Stack Canaries

The first common OS-based mitigation technology is the stack canary. On Windows, this mitigation is activated via the /GS compiler option (for Guard Stack); Solaris also incorporates a similar mechanism called StackGhost, while the latest GCC compiler on Linux has a stack protection feature called PPC. Of the major OS’s currently in use, only Mac OS X is missing a stack canary feature.

Whenever a function is called, a stack frame is created in memory for the function call. The stack frame is arranged as follows:

Each portion of the frame is just large enough for its contents. EIP is the instruction pointer — whatever EIP points to, the processor executes. The Saved EIP is the return pointer — when the function returns, that saved value is placed into EIP.

A buffer overflow occurs when the attacker tricks the application into placing something into a local variable that is too large to fit. It thus overflows its bounds, overwriting the saved registers. Since the saved EIP has been overwritten, when the function returns, execution jumps to whatever value the attacker wants. However, in a /GS-compiled binary, this is much more difficult, as the stack frame instead looks like this:

The canary is basically an arbitrary random number. However, the system remembers what it was when the stack frame was entered, and before returning to the saved EIP, it checks to make sure the canary value hasn’t changed. This poses a problem for the attacker, because it’s in the way! Any value large enough to overwrite the saved EIP will also overwrite the canary, and the attacker doesn’t know what the canary value is. In order to get it, he would need to execute some code to read it… and he can’t execute code with the canary in the way. Thus, stack buffer overflows are prevented.

Some creative attackers figured out that you could still sometimes do some damage by overwriting not the saved EIP, but the function arguments. If a function makes use of delegation and receives function pointers in arguments, you could sometimes still execute code this way, because they would be used during the function, and /GS only checks the canary when the function returns. Thus, in recent versions of Visual Studio, /GS also causes the system to make a copy of the arguments when a stack frame is created, placed before the local variables. The copy is used until the function exits; thus, overwriting the arguments does nothing until the function returns, at which time the canary is checked, and any corruption is detected.

Hardware Data Execution Protection

Another mitigation added for buffer overflow prevention is what Microsoft calls Data Execution Protection (DEP), which makes use of Intel and AMD’s NX (No-Execute) flag on recent CPUs. On NX-enabled CPUs, each memory page is marked as either code (executable) or data (not executable,) and a fatal error occurs if EIP ever points into a data page. A compiler flag in Visual Studio 2005 and greater (/NXCOMPAT) enables this feature on an application; Linux compilers have also added a similar feature.

The entire stack is marked as a data page, which normally prevents stack overflows. While the attacker can overwrite EIP, he can’t make it jump execution into his own input, so he can’t execute his own code — only code already in the process. However, once again, enterprising hackers have found a way around it — what is called the “return to libc” attack. They overwrite the saved EIP with an address pointing to kernel32!VirtualProtect(), the function that marks pages as code or data! With carefully crafted arguments, they can actually instruct VirtualProtect to mark the stack as code, then return into their code. On the bright side, this is very difficult, and won’t work if the exploitable buffer is a string, because the required arguments are full of null bytes.

A more elaborate attack can call into ntdll!NtSetInformationProcess and disable NX for the entire process. The advantage to this is that it can be done without null bytes (though it’s very complicated), so it can go through strings. The disadvantage, though, is that it won’t likely work on a securely-configured production server. If NX is set globally enabled in boot.ini, ntdll!NtSetInformationProcess is unable to override it.

Though I’ve mentioned Windows-specific function names here, there are Linux equivalents that can be used in attacks. (Indeed, it’s called the “return to libc” attack because of the name of the UNIX/Linux C runtime library.)

Address Space Layout Randomization

All of these evasions of NX protection require being able to instruct the system to jump directly into system functions. Doing this requires address prediction – you have to know where in memory the system functions are so you can jump to them. Even in the simple stack-smashing exploit, the attacker still needs to know where the stack is in order to place that value into the saved EIP. Address Space Layout Randomization (ASLR) is a relatively new technology that makes address prediction nearly impossible by making libraries load into different locations on every reboot. If the attacker doesn’t know where the libraries are, he generally cannot jump to them with any reliability.

ASLR is enabled on Windows using the linker flag /DYNAMICBASE. OpenBSD has ASLR by default; Linux implementations have a weak form of ASLR but can be upgraded to full ASLR using various popular kernel patch. Once again, Mac OS X is the only major OS missing this mitigation, though changes in OS X 10.5 imply they are preparing to add it in a future version.

ASLR randomizes where libraries are found, so that it is very difficult to predict where they are. It does, however, have a few weaknesses:

1. In many cases, executable files themselves are not randomized. Thus, attackers are prevented from jumping to system functions, but can still jump to functions in the executable file.
2. Only the high-order bytes of addresses are randomized; the attacker can still jump to anything within 16 memory pages of known address space.
3. It may be possible to brute-force the location of a library by simply trying all the addresses if you have a section of code that will permit this.

Case #3 is very difficult on Windows, since there are no forking daemons and if a service is made to crash several times in a row it will stop restarting (precisely to prevent this sort of brute-forcing.) However, on UNIX/Linux systems, this is possible, and it may be possible on Windows, too, if the code being exploited eats exceptions (i.e. it has an exception handler that discards errors and keeps the service running.)

Safe Structured Exception Handling

On Windows C++ applications, there’s another way around the stack canaries — exploiting Structured Exception Handling. When SEH is used, the stack looks like this:

Those SEH pointers are found before the canary, and thus can be overwritten.  It’s possible to craft values for those pointers that point into the stack, and then force an exception to occur.  When the exception happens, the pointers are followed and arbitrary code is run.  Stack canaries don’t help with this (and the canary can’t be put before the SEH pointers, because in a sense they are local variables, just not ones declared by the programmer), though NX still does.  However, since NX is not available on all processors (nor enabled on all processes), Microsoft also introduced the /SafeSEH compiler flag.

In a /SafeSEH process, when execution begins, the system asks all the libraries in a process to find all of their possible exception handlers and write them to a table.  Before ever jumping to an SEH Next pointer, it verifies that the pointer points to something on the table.  Thus, if the attacker overwrites this pointer, it does no good — he can’t run anything that isn’t an exception handler.

There is a problem with this, though — it only works if every library used by an application was compiled with /SafeSEH and records its exception handlers on the table.  If even one library didn’t, then the system can’t verify the pointers — they might well be pointing to an exception handler that just wasn’t registered.

There are no non-Windows equivalents to /SafeSEH, as the SEH method of exception handling is a Windows-specific construct.

Security Annotation Language

Ideally, we wouldn’t need all these mitigations because we wouldn’t be writing buffer overflows in the first place.  However, when writing complex code, they can be very hard to see.   We would prefer that the compiler just detect the overflows at compile-time, but the compiler doesn’t always know how our variables will be used, and thus cannot determine where an overflow may lie.

Microsoft’s Security Annotation Language (discussed in detail on Michael Howard’s blog here) allows the developer to “hint” to the compiler how all the arguments to a function are used.  The developer uses SAL annotations on each function declaration, specifying if arguments are input or output, if they can be NULL, how long their buffers are, etc.  These “hints” (actually compiler macros) allow the compiler to verify that no buffer overruns are being introduced.

It’s more work for the developer, as they have to put some thought into the annotations, and a company making use of SAL has to enforce its use (i.e. no checking in functions that aren’t annotated.)  However, while it’s work, it’s not difficult — unlike checking for buffer overruns manually, which is very difficult.  With properly-annotated functions, most buffer overruns can be caught at compile time, and fixed before the application is ever released.  Unfortunately, SAL has not seen much use outside of Microsoft itself, due to the extra developer overhead.  It’s easier to get people to add a few compiler & linker flags than to change the way they program.

A pair of companies called Innovative Card Technologies and eMue Technologies have put out a press release for a one-time-password token embedded in a credit card.

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

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

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

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

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

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

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

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

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

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

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

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

A company called Elcomsoft has just put out a press release promoting the newest version of their Distributed Password Recovery tool, which is now capable of making use of the GPU (graphics processing unit) on modern 3D video cards for breaking password hashes.

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

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

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

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

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

Forbes.com recently had an article called “America’s Hackable Backbone” regarding the recent surge in SCADA hacking. SCADA, Supervisory Control And Data Acquisition, is a truly ancient protocol, in use for over 20 years, which was not remotely designed with security in mind. At the time, SCADA was used only on dedicated networks that lacked any connectivity to a network to which you could attach a general-purpose computer. Thus, the security it relied on was a combination of physical security — you needed to tap a line to get in — and obscurity — if you did get in, you’d need to both know SCADA and know the particular “magic names” of the devices you were trying to control.

I saw Ganesh Devarajan’s presentation on SCADA hacking at DefCon back in August. The protocol is relatively simple — simple enough to figure it out just running a sniffer for a while. And the things controlled by these systems can be utterly critical — nuclear power plants, subway systems, pipelines, manufacturing plants, etc. Some of what Devarajan demonstrated was attacking through simple fuzzing — just throwing masses of junk data into the systems and seeing what happens, since the input (presumed to come from trusted sources on a private network) is seldom validated. When fuzzing makes something fall over, that’s almost certainly a sign that a buffer overflow vulnerability lurks there — so even if you can’t stop the subway with a SCADA command, you can probably execute arbitrary code with one, and that can do anything (though it is, admittedly, significantly harder.)

However, as Forbes points out, you don’t need to really know how to control the system to extort ransom out of someone — the mere threat of controlling, say, a water treatment plant may get you what you want.

Fixing these systems normally requires replacing them — they’re so old that updating to a more modern system is seldom an option. Likewise, encryption is a decade out of reach for these systems. At the very least, they need to be completely isolated — a computer that can access a SCADA system should not be connected to a computer that can access the Internet. This creates a potential path for an attacker. Unfortunately, companies are moving in the opposite direction — rather than replacing and isolating SCADA, they’re wrapping it in XML, so that modern applications can use web services to manipulate SCADA systems. This makes sense from a usability perspective — just because your oil pipeline’s valves use 20-year-old control software doesn’t mean your engineers have to be working on 20-year old green-monochome-screened DOS boxes to operate them. However, from a security perspective it makes things even worse. The machines running these apps are on corporate LANs with Internet connectivity — and hacking SCADA wrapped in XML is every bit as easy as hacking raw SCADA. Putting something in XML doesn’t render it more secure — indeed, the accompanying metadata often makes it easier to decipher.

The real worry of these systems is that as the SCADA networks become more integrated with the Internet (SCADA over TCP/IP is already normal, and SCADA over XML is growing), we come closer to a world in which those action-movie scenarios where a hacker breaks into a computer and starts blowing up power plants, manipulating traffic lights, etc. are actually possible. Right now, “hacker terrorism” is mostly a financial threat — there’s little you can do to life safety from an Internet terminal most of the time. It would be preferable to keep it that way.

At Crypty 2007 in August, Eli Beeham, et. al. presented a paper called “How to Steal Cars,” describing how they have bypassed the KeyLoq remote keyless entry system — the system used in the majority of the remote keyless entry key fobs. These systems are supposed to be secure — they use a 32-bit block cipher to transmit a 64-bit key from the key fob, which, if it matches, unlocks the car. The key consists of an XOR of a car identifier (not secret, can be eavesdropped on) and a manufacturer key (secret.) It should take 2⁶⁴ iterations to crack the key — not really practical.

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

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

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