Showing posts with label SSL-Security. Show all posts
Showing posts with label SSL-Security. Show all posts

SSL: Broken even more

Posted by John Asthlon on Sunday, 25 September 2011 / Labels: , , , , , , , , / Comments: (0)

Takeaway: Lately, security conferences have been bad news for SSL. The recently held Black Hat DC 09 was no different, with independent security guru Moxie Marlinspike explaining quite convincingly how he was able to completely bypass SSL security.
In January I wrote an article, SSL: Really broken this time, in which I described how forged certificates could be created if the signing Certificate Authority used the MD5 algorithm for signing. That wasn’t too difficult of a problem to rectify; it just required Certificate Authorities to use SHA-1 instead of MD5. Even so, most people in the know realized that it won’t be too long before SHA-1 has the same problem as MD5
SSLsniff
Well, I’m afraid that cracking SHA-1 is the least of our problems. You may remember Moxie Marlinspike, he’s the developer of a sophisticated hacking tool called SSLsniff. The application exploits vulnerabilities in Internet Explorer, allowing Man-in-the-Middle (MitM) attacks even if SSL connections are used. Microsoft eventually fixed the vulnerabilities by disallowing leaf certificates to act as signing certificates.
Even with the vulnerability fixed, SSLsniff is still a powerful tool. As evidence, SSLsniff was used to demonstrate MitM attacks by the group of cryptographers who discovered the MD5 exploit I mentioned earlier.
SSLstrip
Moxie Marlinspike’s new and improved tool is called SSLstrip. Quite simply, SSLstrip allows an ill-intended attacker to capture sensitive personal information without even worrying about encryption. Moxie Marlinspike decided to sidestep the encryption process once he realized that users almost always request Web pages using the http (unencrypted) prefix. That’s even the case for the more confidential Web sites like those provided by financial institutions as shown below:
After the initial portal page is brought up, https is enabled after some user intervention as the following image shows:
SSLstrip is simply a MitM proxy that advantages this flaw/oversight in the https process by stepping in between the user and in this case the bank’s Web server. Let’s look at the process using me as the guinea pig:
  1. I enter the URL http://www.usbank.com into the Web browser.
  2. I then type my user name in the appropriate box and hit enter.
  3. SSLstrip captures the URL and my username.
  4. SSLstrip connects to the USBank Web server and provides my username.
  5. SSLstrip then returns the new Web page provided by the bank Web server to my computer.
  6. I provide my password and hit enter.
  7. SSLstrip once again captures that information and transmits it to the bank Web server. As far as the bank Web server knows, I’m officially logged in.
  8. SSLstrip once again passes the new Web page provided by the bank Web server to my computer. I then go about my business.
Something is wrong though, how come the “s” is missing from http in the URL? I thought the bank’s Web site was secure. It’s not there because the SSL connection was setup between my attackers’ computer and the bank’s Web server. I was getting all the correct Web pages sent to my computer, but not over secure channels. Guess who now has my log in credentials?
I realize that an observant user would more than likely be aware of the sleight of hand taking place here, but then I suspect that many more will be fooled by this. For more details about the exploit, please view Moxie Marlinspike’s Black Hat presentation New Tricks for Defeating SSL in Practice(pdf). He did a great job explaining the entire process.
Even sneakier
In Moxie Marlinspike’s presentation, he points out a few other techniques that can be applied to make the unsecure Web page look more convincing. Most Web browsers display the favicon supplied by the Web server right next to the URL in the address bar. What SSLstrip allows you to do is replace the favicon with one of your choosing.
By doing this many more people will be fooled as they have been told to look for a closed lock and if it’s there then they can be assured that they are safe.
It’s even possible for the attacker to supply a real SSL connection to the requesting computer with a URL that’s almost identical to the one asked for. The difference being a few extra characters at the end. Moxie Marlinspike explains in the next slide:
Change the Web browser
We humans are creatures of habit; I doubt that anyone would argue that. Knowing that, I honestly can’t say that I’d catch the deception every time myself. One good thing is that this dilemma has been talked about by others. I was fortunate that TechRepublic’s managing editor Jason Hiner alerted me to George Ou’s article HTTPS web hijacking goes from theory to practice.
The article explains that developers need to give Web browsers enough intelligence to know whether the connection should be SSL encrypted or not and if encryption isn’t occurring to disallow the connection. George also mentions that Google is working on this very problem in their early versions of the Chrome 2.o Web browser. Hopefully other Web browser developers will follow suit.
Final thoughts
First, I’d like to thank Black Hat for the use of their logo and Moxie Marlinspike for the use of his presentation slides in this article. I also admire his wanting to make everyone aware of this potentially serious attack vector.
I realize that this exploit is one that requires inattentiveness on our part. Fortunately, most people I talk to mention that they wouldn’t get caught by this. Just to test that theory, think back to the last time you went to a Web site that used SSL. Did you check the URL? Were you sure that the traffic was encrypted? I didn’t.
Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

Google Search over SSL has an oops

Posted by John Asthlon on Friday, 23 September 2011 / Labels: , , , , , , / Comments: (0)


Takeaway: Google now provides SSL encryption capabilities for their search function. But, there is a problem that you need to be aware of.

Google now provides SSL encryption capabilities for their search function. But, there is a problem that you need to be aware of.

————————————————————————————–
According to Google’s Web Search Help blog, the search giant has decided it’s important to keep search inquiries from the prying eyes:
“With Google search over SSL, you can have an end-to-end encrypted search solution between your computer and Google. This secured channel helps protect your search terms and your search results pages from being intercepted by a third party. This provides you with a more secure and private search experience.”
TechRepublic’s Chad Perrin recently penned an article about the benefits of SSL-encrypted Web searches. He also advises caution as some searches are not protected by SSL Security encryption and under certain circumstances SSL is vulnerable.
When I learn that an application claims to use SSL, I like to check and make sure for myself. Sometimes there are surprises and when it comes to security; that’s not a good thing. I fired up Wireshark and, as stated above, the search traffic was gibberish as shown below:


That’s great. But I did see something in the packet traffic that I didn’t understand, so I went to Laura Chappell’s Web site. I have taken several of her classes and consider her one of the foremost experts when it comes to analyzing packets. I did not find what I was looking for, but I did come across quite a surprise.
Cached Link
In their search results, Google has what they call a cached link:
In theory, using a cached link makes sense, as explained by Google:
“Google takes a snapshot of each page examined as it crawls the web and caches these as a back-up in case the original page is unavailable. If you click on the “Cached” link, you will see the web page as it looked when we indexed it. The cached content is the content Google uses to judge whether this page is a relevant match for your query.”

To their credit, if the cached link is clicked on, you will know it. Google prominently displays a window explaining the loaded page is a snapshot of the actual Web page and may not be current:


Ms. Chappell found out that the cached link traffic is not encrypted. I went back to testing, and sure enough, if the cached link is clicked on, it reverts back to http. Notice the URL in the above slide.
Search query sent unencrypted
That’s to be expected, but what’s not expected is that the original search information is sent to the Google Web-cache server in the clear. Let’s see if we can capture that. The first slide below is the response to my DNS query for webcache.googleusercontent.com. That’s where the cache is located:


The next slide is that of the traffic my computer is sending to webcache.googleusercontent.com. As you can see, the highlighted packet contains my original search query:


Final thoughts
According to Google’s above statement, all search traffic is supposed to be encrypted between our computers and their servers. It’s not in all cases, and I felt it important to make sure everyone is aware of that.
  

Configure Apache to support multiple SSL sites on a single IP address

Posted by John Asthlon on Thursday, 22 September 2011 / Labels: , , , , , , , , , / Comments: (0)


Takeaway: With Apache 2.2.12 and support for the SNI (Server Name Indication) extension to the SSL protocol, you can configure name-based HTTPS sites, just as you can name-based HTTP sites. Vincent Danen introduces the new Apache feature.
As the Apache Web server grows and matures, new features are added and old bugs are fixed. Perhaps one of the most important new features added to recent Apache versions (2.2.12, to be specific) is the long-awaited support for multiple SSL sites on a single IP address.
Traditionally, it was only possible to have an SSL-enabled Web site if it was bound to one particular IP address. This has caused a lot of grief and frustration because if you had only two IP addresses, you could only have two SSL-enabled sites.
On two IP addresses you can have any number of regular HTTP sites strung out across them both or bound to a single IP, but for each of these, only one HTTPS site. What made this even more frustrating is that if www.example1.com and www.example2.com were on the same IP and example1.com had an HTTPS site as well, going to https://www.example2.com/ would, in fact, take you to the equivalent of visiting https://www.example1.com/. This meant that most people who wanted HTTPS sites had to restrict one site (both HTTP and HTTPS variants) to a single IP address to avoid this type of confusion.
With Apache 2.2.12 and support for the SNI (Server Name Indication) extension to the SSL protocol, this has changed completely. Now you can configure name-based HTTPS sites, just as you can configure name-based HTTP sites. The bottom line is that the five IPs that you needed today to run five SSL Certificate  sites can be reduced to one IP tomorrow (provided, of course, you use the newer Apache).
There are some prerequisites, however:
  • The server, obviously, must use Apache 2.2.12 or higher.
  • It must also use OpenSSL 0.9.8f or later and must be built with the TLS extensions option.
  • And Apache must be built against this version of OpenSSL as it will enable SNI support if it detects the right version of OpenSSL — the version of OpenSSL that includes TLS extension support.
Finally, as far as browsers go, not every browser yet supports SNI, but the most popular browsers do, and some have for quite a while. This includes Firefox 2.0 or later, Opera 8.0 or later, Internet Explorer 7.0 or later (unfortunately, only on Vista), Google Chrome, and Safari 3.2.1 (unfortunately only on OS X 10.5.6 or later).
In practical terms, this means that for a serious e-commerce Web site or one that needs to have broad appeal, this solution won’t work — yet. Expect in the next year or so for more people to upgrade and more browsers to support SNI.
For testing purposes or for internal sites where you can have some say over client browser installation (and also considering that such old versions of Firefox support SNI), using SNI can be quite useful.

For configuration, here is an example of what to put in your Apache configuration file:

Listen 443
NameVirtualHost *:443
SSLStrictSNIVHostCheck off
<VirtualHost *:443>
DocumentRoot /srv/www/example1.com/
ServerName www.example1.com
...
</VirtualHost>
<VirtualHost *:443>
DocumentRoot /srv/www/example2.com/
ServerName www.example2.com
...
</VirtualHost>
What the above does is enable Apache listening to port 443 and turns on listening for virtual host requests on all IPs. The new keyword SSLStrictSNIVHostCheck is disabled, meaning we will not throw a 403 error if the client does not support SNI; instead, they will be redirected to the SSL Certificate site defined first (example1.com in the example), so be sure to define your default site first.
That is pretty much all there is to it. The largest hurdle here is the client browser support, but that will come in time. The Apache requirements and configuration, by contrast, are very simple and straightforward.