Now that SSL has been cracked, watch out

Ever since rumors started to spread about Thai Duong and Juliano Rizzo’s BEAST attack against SSL/TLS, onlookers have fretted as to just how serious a threat it poses. In a nutshell, the attack is serious — though for the time being, it’s difficult to pull off because a would-be attacker has to work pretty hard to ensure that the target meets multiple preconditions. Unfortunately, the tools to pull off the attack are certain to evolve — and many IT organizations aren’t even taking the simple, necessary steps to protect themselves today.

The mere fact that the attack can be successful at all is significant. SSL/TLS is a VPN technology. VPNs are, by definition, supposed to keep your information safe even when it’s being transmitted via an insecure network medium and a malicious party can intercept your protected traffic. The BEAST attack somewhat breaks SSL/TLS’s VPN protections. In this sense, it’s fairly important. With the right preconditions, a cyber criminal can steal your protected HTTPS cookie, which then essentially allows him or her to highjack your active HTTPS session. Make no mistake about it: The BEAST attack works as claimed.

[ Download Roger Grimes’s new “” PDF expert guide today! | Stay up to date on the latest security developments with InfoWorld’s . | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]

Two important facts make the threat less serious, however: the aforementioned preconditions (which I’ll discuss a bit later) and the fact that defenses already exist for many scenarios. The BEAST attack can be successful against pre-SSL 3.1/TLS 1.1 VPN protocols, but many browsers already allow you to choose post-SSL 3.1/TLS 1.1 protection. Some of the browser vendors have even implemented custom fixes that don’t fix the holes in the earlier protocols — but that specifically defang the BEAST’s attack methods.

Microsoft, for example, has published a “cipher order” work-around for Internet Explorer that’s even effective for versions of IE that have the latest SSL/TLS protocols (for example, IE running on Windows XP). Unfortunately, because BEAST isn’t causing worldwide, prolific attacks now, many vendors and websites are going to ignore the warning or be slow in response. That’s plain wrong. There shouldn’t have to be more blood on the ground before we fix the problem. Unfortunately, that’s the way we’ve always solved problems as a society, especially when facing online threats.

What protects most of us right now is the series of significant preconditions that must be in place before an attacker can launch a successful BEAST attack against a given target. First, the attacker must have a man-in-the-middle connection in place between the victim’s client computer and the victim’s intended HTTPS website. This precondition isn’t that hard to accomplish. Several tools, including one of my favorite demonstration tools, Cain & Abel, make man-in-the-middle attacks truly as easy as clicking a button.

Two additional preconditions do severely limit the success of this particular attack: First, the attacker must be able to get a target user’s browser to run special JavaScript coding — and the coding must originate from the same “origin” as the targeted HTTPS site. Most of today’s browsers don’t allow JavaScript originating from one location to impact another HTTP/HTTPS stream.

But it isn’t impossible for the precondition to be in place. Attackers routinely run malicious JavaScript on websites that we fully trust. Often this is done by the attacker exploiting a weakness in the website or, even more common these days, by placing a malicious advertisement on the website that runs their rogue JavaScript code.

What makes it difficult is coordinating it all: The attacker must know what HTTPS websites the victim will be visiting and inject malicious JavaScript beforehand. Plus, the attacker has to establish that man-in-the-middle connection. That’s a fairly challenging set of preconditions to create and coordinate.

From there, the attacker has to hope that the user keeps his or her targeted session active as the BEAST conducts its crypto-attack against the HTTPS cookie. That doesn’t take long. Still, if the user logs out of the HTTPS-attacked website or closes the browser completely (and doesn’t simply close the HTTPS website, which is more common), the attacker may be able to decode the encrypted cookie, but it is unlikely to be useful in future, new connections unless the cookie is poorly implemented.

Again, this is not impossible. If I’m a bad guy trying to break into a particular company, I could hang out in coffee shops and watering holes that are near the targeted company’s main offices. You can figure out what sites the company employees are visiting by walking by their screens over a few days and learning where they surf. There’s a good chance that many will frequently many of the same websites, including popular social media sites and common company sites.

The attacker can then exploit one of those websites, including buying legitimate ads that they then inject their malicious JavaScript into. After that, the hard part is over: The attacker simply needs to launch a man-in-the-middle attack against the common public, free networks in the area and wait for one of the company employees to visit the exploited site. Alternatively, an attacker can use another browser exploit that circumvents the same-origin protection policies. After that, the BEAST attack can be launched and, if lab tests are accurate, is likely to be successful.

But far easier attacks that accomplish the same goals already exist. Attackers are in many, if not most, of the world’s networks already, and they didn’t need complicated attacks with multiple preconditions. They are already in deep without using the BEAST attack. They used social engineering Trojans, fake antivirus programs, or programs that took advantage of unpatched software. Right now, Adobe and Java products are heavily targeted.

Why care about the BEAST attack at all? There are a few reasons. Attacks only become simpler and more effective over time. Right now the BEAST attack tool requires separate tools or techniques to pull off the pre-conditions. No doubt someone will make it a single program with a single click of the button. It is also very plausible that some of the preconditions will no longer be required. Without those, we face a significantly easier attack method. The resulting attack may not be as immediately prolific as a buffer overflowing Internet worm, but it would make using a public network far sketchier.

More importantly, it is yet another exploited vulnerability that we have known about for years and we just don’t care to fix. Well, the fixes are out there, but we don’t care enough to simply click a single check mark to implement. It begs the bigger question of why society doesn’t care enough to implement important fixes that have been in existence for many years. Why do we usually wait for the pain before we implement?

Critics might argue that society is making the correct cost-benefit decision in putting of investments in security improvements, and it doesn’t make sense to implement before the pain occurs. But in the case of BEAST, the threshold is so low. We’ve had the fix for many years. Many browsers have had the newer protocols for a long time, but vendors simply did not enable them by default. Most websites have the ability to implement the newer protocols, but their operators haven’t. We didn’t need to invent anything new. In most cases, enabling an effective defense requires ticking a few check marks.

I know most of society doesn’t really care about computer security — until it impacts them. But we as computer security professionals have no excuse to be so cavalier as to forgo enabling a few check marks to fight this known attack vector. If this threshold of action (or should I say inaction) is too much, what would we do proactively to protect ourselves before the real pain hits? That’s the depressing part and bigger question posed by the BEAST attack.

This story, “Now that SSL has been cracked, watch out,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.