Posted on Tue, Sep 27, 2011
A tool that cracks SSL cookies in ten minutes was recently introduced at the Eckoparty security conference. The tool is called BEAST, which stands for Browser Exploit Against SSL/TLS. It works only with TLS 1.0 and not with TLS 1.1; although, most of us are using 1.0, whether we know it or not. The 1.1 version is not widely used yet. Click here to read more about how it works.
While it is not simple to immediately achieve the exploit, the article mentions that the tool is a Java script which needs to be injected into the victim's browser - something we unfortunately see all too often: hackers have done it, know how to do it, will continue doing it. So, the attack is not necessarily easy, but it appears feasible.
Granted, this is merely research that is demonstrating the possibilities of cracking SSL cookies. This has yet to be done by hackers in a real-world application. How many times have we seen this before? How long will it be before this becomes a real threat?
Computers become more powerful every day; as a consequence, encryption becomes easier to crack. The 128 bits encryption used in VPNs was quickly replaced by AES256. AES256 was designed to last well into the 21st century because the computing power it requires to be compromised is such that no existing commercially available computer can crack it in a meaningful time. And that's, ultimately, what we want. It may never be possible to create encryption that cannot be cracked; but, if we can make it hard enough that no computer can crack it in a human lifetime with the current computing power commonly available, then we should be OK. Of course, in this constantly changing, fast-paced technology era, as computing power increases, the time it takes to crack an encryption algorithm decreases. That is why we went from 64 bit, at the end of the 20th century, to 128 bits, which we still use today. It has only been 11 years, but maybe it is time to move to 256, before someone comes up with a way to use the BEAST as a hacking tool and we start losing some serious data over HTTPS.
Posted on Mon, Sep 26, 2011
Ask someone what the difference between a private and public cloud is, and most will probably elicit a somewhat confused expression.
With that in mind, I thought I’d elaborate a bit on some of the key attributes and differences for each. Part 1 will focus on the private cloud. Next week’s posting will concentrate on the public cloud.
In brief, a private cloud usually means a reserved space in a data center, with lots of racks full of computers, possibly surrounded by a gate to isolate them from the rest of the datacenter.
This basically means that the company has moved its data center to a remote facility rather than keeping it on premise. The advantages are many - a data center requires redundancies for Internet, power, fire emergency and it requires adequate access control. Putting together a dedicated data center for one company is very costly. It is not just the cost of the infrastructure necessary to support the mentioned redundancies; it is also the cost of setting up the necessary access procedures and controls, keeping a log of such accesses, ensuring procedures are followed and protocols are met. Then, getting certifications (such as SAS70) adds to the costs.
Delegating this to a company that does it as its only business means sharing these costs with all the other customers, and obtaining a far stronger infrastructure for a fraction of the cost. You get multiple internet links coming in each on a separate pipe, and using BGP you are guaranteed an up time of 99.99% without too much effort. You get multiple UPSs, not just one, each fed by multiple, cross connected power sources. You get multiple power sources, generators always on standby, and guaranteed gasoline refills. Usually these facilities are on the emergency refill list just after hospitals and few other high emergency facilities. And they are hosted in bunker facilities not easily expunged. Finally, security is strict, adopting a mix of bio and badge technologies, keeping logs of who walks in and out and when; checking people’s bags for content; tracking closely which hardware is brought in or removed. Some of these facilities may also have DOD clearance.
The cost of hosting a company’s infrastructure in such a center is lower than building it from scratch, and the results are better. Today the cloud term is used and abused, and many companies have taken to calling this solution the private cloud. They are no different than they were a few years ago. Only the terminology has changed.
The introduction of virtual solutions has changed the way this private cloud is structured internally and probably allowed the reduction of space and increased companies’ savings; but the substance remains the same.
Posted on Mon, Sep 05, 2011
This morning, I was reading some comments on the Diginotar breach. The Dutch minister of internal affairs gave a press conference at 1:15 AM, Saturday, September 3rd. He announced that the Dutch government was revoking trust in Diginotar. News about this breach can be found here. If you "google" it, you will find plenty of information on the topic.
There is a lot of speculation on the source of the attack, though, at this point, many are speculating it to have originated from the Iranian government. There is plenty of information around, so I will not dwell on providing further insights. My main reason for writing this entry is to discuss "user behavior."
When you browse an HTTPS website, your browser and the server exchange a CA certificate. CA stands for Certificate Authority. There is a reason for this name - the entity who created the certificate is "authorized" to do so. It has the authority to create public certificates; it has an infrastructure in place to guarantee that such certificates are original, and to revoke them when they are not. Browsers take notice of this and when a certificate is revoked, your browser receives an update so it knows not to trust that particular certificate anymore.
These certificates usually carry the name of the website; for example, if you go to https://mydomain.com, you would expect the certificate to carry that domain's name in it. So, if you reach the same server via its IP address, instead of its name, the browser will issue a warning saying something like: "This certificate name does not match the URL you were trying to reach." Now, it is up to you to accept the certificate anyway - to trust it - or to move on and browse somewhere else.
The unfortunate truth, of which I myself have been guilty a few times, is that even though the browser gave us a warning, we tend to pay little attention to it. We click "get me there anyway", and keep going.
This allows a hacker to conduct what we call a "man-in-the-middle attack." That little and, apparently, insignificant warning your browser tried to give you might have been related to the fact that you didn't really reach the intended site, but another, rogue, server. And ipso facto, you have been attacked and your computer might have been compromised.
The same situation can occur if you are trying to VPN to your office with a clientless, browser based, VPN. Assume you are in a public place, a coffee shop for example, or at the airport. You attempt to logon to the VPN via your unprotected wireless connection; someone with ill intentions is in the same area, sniffing the airwaves with an automated tool (there are plenty on the internet, all free), and when it intercepts your attempt, it sends you a different certificate, conducting a man-in-the-middle attack. In essence, your computer "thinks" it is talking to the VPN server when, in reality, it is talking to the attacker's computer. Your browser will give you a warning, but you are too busy to notice, get annoyed by the warning, click OK and keep going. Now the attacker is talking to your computer pretending to be the VPN server, and it is talking to the VPN server pretending to be you. So all your communications back to your office, which you assume are encrypted and well-protected, are actually flowing through the computer of your attacker. He can record them and decrypt them (remember, you are using his certificate so he can open your conversation), and basically steal all the information that is going across your communication.
What can you take away from all of this? If your browser issues a warning about a certificate, don't ignore it. Read it, read it carefully, and if in doubt, abort what you were doing and call for help. It may be nothing; but it may be something very serious indeed!
Incidentally, this is also the reason why, at Network Box, we have been resistant to the idea of a clientless SSL VPN. They are easy to deploy and maintain, but they are subject to these risks (among other things); and therefore they cannot guarantee 100% true security. Additionally, since security is what we do, we have been cautious about this feature. The market wants it, and therefore we may eventually give in; but with the warning that such issues may occur because of the way browsers work and because of the way we all, as humans, tend to behave. After all, hacking is 90% exploitation of human behavior. But that's a topic for an entirely separate conversation.
A good week to everyone who reads this post.