Slashdot Mirror
SSLStrip Now In the Wild
An anonymous reader writes "Moxie Marlinspike, who last week presented his controversial SSL stripping attacks at Black Hat Federal, appears to have released his much-anticipated demonstration tool for performing MITM attacks against would-be SSL connections. This vulnerability has been met with everything from calls for more widespread EV certificate deployment to an even more fervent push for DNSSEC."
I guess the question then is, what do we use as an alternative? What can we even do?
Bored at work? Play Game!
can anyone care to explain this for the unwashed masses? I was just starting to use SSL for my home server hoping to learn to use it for my clients servers. Is this so bad as it sounds? ty
Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the https:/// in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK... the padlock should be down in the statusbar area where it always is.
Out of reflex, I always check that my URL starts with https:/// and I check the cert when I'm dealing with someplace new. Now, I'm just always going to check the cert... even if I'm connecting to a site I use all the time.
If Moxie really wanted to make things tougher, they could maybe add a cert to their tool. THAT would make it so you'd only notice if you read the cert and realized it wasn't what it was supposed to be.
THAT's scary.
The Digital Sorceress
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
Public key crypto-systems.
Not buying anything online via the web-browser.
OK, that last is crazy talk.
Best Slashdot Co
"for more widespread EV certificate deployment"
That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.
Extended validation? When I pay for a digital cert, I expect a high level of validation anyways. Makes you wonder, what level of validation they've been doing for the past few years.
SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.
Wearing pants should always be optional.
Please don't get me wrong, this will make a nice addition to a toolbox. However, the hype I have seen tied to this tool is overwhelming. It seems like conferences have become more reliant on over-hyping items like these to promote the conference name more than anything else.
Is this porn for the security researcher? I guess I should RTFA.
Zhrodague.net - I do projects and stuff too.
prior to them inserting login information safe? For instance, for the business application I develop, I check to see if the user accessed the login page via ssl, and if not, I user header('Location https://blah/ to get them to the ssl login page. To me that should be good, but the site above seems to indicate even that is not safe since a person could spoof the cert as soon as the site is accessed. Or perhaps I'm not quite understanding it clearly.
UPI - Crow Agency, WYOMING - The Federal Environmental Protection Agency has issued a crackdown order on a traditional method of communication and possible free public access to the Internet. The method utilizes traditional Native American techniques with a modern twist. Computer signals called packets are translated into smoke signals and released into the atmosphere. The first message sent using this technique contained the message, "The casino is now open. $3 Black Jack and Texas Hold 'em. Smokey Robinson for 3 nights starting next full moon."
EPA spokesman Harvy Jamal Foshizelmeyer explained the crackdown, "This is hardly a carbon neutral means of communication."...
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
It's completely different. He's had SSLSniff listed on there for awhile now. All requests made to SSLStrip now redirects to the index page. Maybe he doesn't want to exceed his bandwidth?
Holy crap, looking at the source to sslstrip, this was written in 2004! I wonder if the anarchist underground hacking scene has had access to this for all that time? Why release it now I wonder?
For a time, Bank of America's main page was http://, even though you entered your account information into a secure form. Some people raised a stink and they changed it. Before that occurred, I decided to use one of NoScript's features to force the entire domain bankofamerica.com to use https://.
For a while it worked great until a few months later when I signed up for another service on their website that monitored your credit report activity. For about a week, every time I clicked on the link to take me to the login page for that service, I would get a page that told me the link was broken. After calling customer support a few times to see if the site was functional, I realized that the redirect script/server didn't support https, and that I was getting a dead redirect as a result.
I think forcing https on domains is a good idea, but it can be easily undermined by one link in the chain not playing nice.
VeriSign provides Warranty Protection to consumers to reimburse them for exposure to these types of risks. It can be found here http://www.verisign.com/repository/netsure/netsure2.html
But half of American banks forced HTTP login http://blogs.zdnet.com/Ou/?p=201. Then there's the fact that people never manually type in HTTPS and they rely on an auto redirect, but the redirect could be intercepted and changed to HTTP. The solution requires a modification of web browsers and DNS to automatically enforce HTTP policy because people will ignore HTTP 100 out of 100 times and they will ignore fake certificate warnings 199 out of 200 times. EV is not the solution to this problem because it still relies on the human to make the decision on security.
See http://www.circleid.com/posts/20090219_https_web_hijacking/
The real problem is the browser makers do not care about security. They only care about the appearance of security.
For example, browsers don't do the SSH style thing where they warn you if the cert changes for a previously recognized site.
Go look at all the built-in CA certs in your browser sometime. Count them if you can.
How sure are you that none of the CAs there won't be tricked/bribed into signing a cert for *.mybank.com ? Who has audited them?
All it takes is just one CA, and AFAIK, none of the popular browsers will warn you that the cert for mybank.com has changed.
In fact, you might be safer if you removed all the CA certs from your browser, and just got your browser to recognize certs from the few https sites that you actually use, on a per cert basis rather than per CA basis.
Then when someone tries to trick you to going to https://www.mybank.com|.cgi-bin.co/ you will get a prompt for the https cert, and then you might notice something strange going on...
Which do you think is a bigger threat to your security? Your bank server using the same ssl cert for years, or someone pulling a cert swap or MITM or XSS trick on you?
But guess what, your bank probably has to renew their cert every year or so and pay $$$ to do so. Is that really for security reasons? Maybe for the CA's financial security, but I doubt it's for yours or the bank's.
The browser makers fill their browsers with certs from dozens of companies. They don't blacklist companies that have been known to screw up and do dubious stuff (like issuing Microsoft certs to people who aren't microsoft, and do naughty DNS stuff).
It's all just a show to make the sheep feel safe.
I'm going to stick my neck out and say that SSL is a false security. Any twit with $29.95 can buy an SSL cert. The mere fact that a page is encrypted via SSL seems to convince people that they are dealing with a reputable site.
I'm much less worried about packet sniffing, and more about fake sites like I see every day in the steady flow of spam. There are many ways to steal someone's private data, all much easier than being on the right network, at the right time, sifting through gbits/sec of garbage for a vulnerable SSL connection.
Say you have an account at the First Bank of Fnarg, and the real web site is "www.firstbankoffnarg.com", what's to prevent an amateur from setting up "www.firstbankofnarg.com", copying the templates, and buying an SSL cert from any registrar ? Send out a legit-looking email with the link, a this will fool a staggering number of people.
It doesn't matter how often you tell them "Don't click on email links", people will do it anyway. They do it because they are lazy, inattentive and hurried. There is no technological cure against human nature.
-Billco, Fnarg.com
Funny, I went to high school with this guy, and he made a small cameo appearance in a dream I had last night, for no apparent reason. I remember visiting http://room101.thoughtcrime.org/ back in the early days -- '95 or so.
http://hackademix.net/2009/02/19/more-https-troubles/
There's a browser safer than Firefox, it is Firefox, with NoScript
As far as I understand the subject, using https bookmarks would be sufficient.
That's what I use for any serious https site, like banking.
I bookmark the https login page and only use this.
That of course makes my bookmarks the next point of attack.
about:config
browser.identity.ssl_domain_display
Set it to 2 to see the Common Name of the cert in the address bar. Very helpful to see side-by-side with the URL. EV certs will still show the Organization and Country, but it makes non-EV certs a little more obvious.
Comment removed based on user account deletion
Comment removed based on user account deletion
I'm not exactly a security expert, but how is this different from regular HTTPS hijacking? Specifically this seems to be the same as what I read in the dsniff FAQ years ago. It was written in 2001. I'm apparently missing something.
You can use a separate browser to do your banking with more secure settings, so even if it is not really more secure software-wise, it can be more secure in configuration. I do that actually.
/profile /user:COMPUTERNAME\_www_vellmont "C:\Program Files\Internet Explorer\IEXPLORE.EXE"
If you're using windows use "run as".
e.g.
Say you have an account called vellmont.
Create an account called _www_vellmont and make its home directory fully accessible by your vellmont account.
Then in your vellmont account, create a shortcut:
C:\WINDOWS\system32\runas.exe
After that you can lock it down a bit more, so that only the bank site works and nasties on other sites might not work - if you are using IE on windows you can put all sites except the bank site on "High Security" settings - so that javascript, downloads etc are disabled on nonbank sites. Unfortunately I don't think you can have separate CA certs on a per user account basis on IE.
Not sure if you can do that for firefox either, but the trouble with firefox is it's hard to run multiple instances of firefox on windows at the same time - even with the "run as" stuff.
If you could change the theme used by that browser so you can tell the difference between the bank browser windows and the other windows that would help.
This is not a new threat or attack. Its been well known for years (http://blogs.adobe.com/stateofsecurity/2007/11/dont_be_ssly.html for xample). Hence proposals like ForceHTTPS (https://crypto.stanford.edu/forcehttps/) or some sort of DNSSEC related solution.
It is worth noting that sites that use client certificates are not affected by this, as SSLStrip cannot sign the CertificateVerify TLS message due to it not having a client certificate that would be accepted (you hope), therefore the exchange between SSLStrip and the real site would fail.
Granted you can still downgrade the session to HTTP (if you start from a HTTP site), present a fake site, and possibly obtain a password or other form of authentication token, but a valid client certificate would still be required for the authentication tokens to be of any use (assuming this is the only site where said authentication tokens get used).
Faking the real site would be difficult though, as you wouldn't be able to see it as the web server would never serve it to you as you don't have a valid client certificate to view the page.
www.sixt.de uses http to display the login page but supposedly transfers your login information via https. I never actually checked this, but just assumed they know what they are doing. Now I am no longer sure...
I am pretty ignorant of what goes on in the security world and things along the nature of vpn, certificates, etc etc, so perhaps this is over my head.
Its funny, I guess I would consider myself a somewhat saavy user, but really, I have never understood certificates, or found a place to explain how they worked. Watching the presentation linked above, makes me even more doubtful of them. I guess ultimately I feel that I can't really trust anything that comes at me over the internet. I don't spend any time knowing where my network traffic goes once it enters my comcast network. I don't know the "usual" hops it should be taking. It's gone once it comes out.
So I guess being ignorant of their workings, has always led me to believe that, if a computer is sitting between me and my destination, it can do whatever it wants to that traffic, including sending me a 'certificate'.
Ultimately it's all bits right? Just 1's and 0's. It's all sitting there in an ip packet, waiting to be pulled out. Encrypted or not, its still voltage on the line, or light, or whatever. What makes this set of data coming down more "real" then that set of data?
I guess if I knew more, I could answer that with question by saying things like HTTPS , SSL, public/private key, VPN, or whatever other technologies exist out there. But I guess in my head I know that ultimately, they are bits, and you'll never really know where its going from. Just kinda cast the die out there if I use say online banking, and see what happens, and just trust that if I see that my bank account is going haywire, I can call the company and fix it.
But this whole SSL attack seems based on the fact that via arp poisoning or whatever, it is trivial to plug into a network in which you understand the routing protocols, send out some stuff, and start parsing traffic.
That is really where the security work should go, but again, ultimately, there probably isn't a good working solution there, and like anything, would be an arms race again.
Anyway, pretty interesting presentation and vulnerability demonstration.
A lot of people are speculating what it all means.
How about just watching the talk and deciding for yourself?
https://media.blackhat.com/bh-dc-09/video/Marlinspike/blackhat-dc-09-marlinspike-slide.mov
Interview:
https://media.blackhat.com/bh-dc-09/blackhat-dc-09-marlinspike-interview.m4v
Just read wiki and the following paper (2002): http://cr.yp.to/djbdns/forgery.html
Two most secure implementations of DNS servers Djbdns and MaraDNS are not even bother to implement this until they see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment.
Every time I read about a new SSL exploit I always come away with a sense of 'duh' and a deep feeling of disappointment because the expliots are always just obvious social engineering experiments that require zero crypto knowledge and zero creativity to implement.
Running a proxy, changing URLs adding fake padlocks...etc.etc are all obvious attack vectors that really work for most users. End user gullability is the central reason we have spam and botnets.
Yes security concious institutions stab themselves in the heart by inventing cute padlocks and proclaiming security when their reassurances are in fact a dangerous diversion from the only things the user should actually be focusing on to ensure their security online.
The attacks that he presented in the talk boil down to the following:
0) There used to be an egregious bug in certificate verification that blew up everything (you could create certs for whatever you want). That's been fixed in most cases and so he moves on.
1) For everything that follows you need to get into a position to do a MITM (man in the middle) attack. He claims that this is really easy via ARP spoofing, etc.
2) You exploit the fact that most secure sites either redirect from unsecure (http) servers or blatantly start from an unsecure page and post login over https from there. Since you are a MITM you just rewrite the pages to strip out the https.
Most of his talk is about #2, which I agree is serious, but basically obvious stuff stemming from being a MITM.
3) He discusses ways to make #2 appear more secure to the user by:
a) putting up fake lock icons on the page
b) using international domain name lookalikes to put up your own https secured fake sites
c) using a nasty IDN lookalike for https:/// that lets you shove the true domain name off the address bar.
Point a is blah.
Point b seems to have been taken care of to some extent in Firefox by not displaying international character sets for some domains like .com.
Point c looks *really* nasty but seems to have obvious fixes in the browser. i.e. stop displaying things that look like http(s):// as part of a subdomain.
People asked many questions at the end: About half just missed the point that you're a MITM and can rewrite anything the site puts in the page. The other half wanted new kinds of auth mechanisms supported either by DNS or the sites. The speaker points out that as long as not all sites implement the new features client browsers can't rely on them and can't even "test" for them properly because of DOS attacks.
Basically it sounds like the only solution is browser side list of sites that you should only hit via https.
I remember getting flamed something terrible when SSL was first announced and I said at that time there was no way to stop a Man In the Middle Attack.
All sorts of irrelevant counter arguments were made at that time too.
Certificate and DNSSEC are also useless.
Why, because if your using your PC from 1 ISP or your employers fire walled Intranet, then from the time you install a browser on your PC there, nothing can be trusted.
Certificates and DNSSEC would also come from MITM servers.
There firewall could send you bogus certs and then give you valid connections as if they were the real web site. In turn there fire wall could unwrap your encrypted traffic, then repack it in to the real cert for connection to the SSL'ed web site.
Unless you are going to manually install your keys that you brought from a second clean source there is nothing your going to be to be able to even tell that you've been compromised.
So SSL's largest problem is when your sitting at your office in your big corporate job, and it's got the SSL lock, your lulled in to a false sense of security!
I worked for a German Multinational. All net traffic from my US office went through Germany to get on to the net.
I'd find it impossible to believe that if they had wanted to, that they couldn't do a very complete MITM attack.
My solution was to do SSH over SSL, where I'd bring my own SSH keys in on USB Stick.
then I could run X over that SSL to a Firefox running on my own Personal CoLo running Linux.
I could also have done a VPN over SSH over SSL.
Nice thing about these are canned large corporate attacks wouldn't be geared to deal with it.
Problem is everyone arguing about security it thinking hackers and not corporate spying of employees or government spying of foreigners or it's citizens.
I just remember that German Citizen while in the USA had to be given special internet and phone because under German law they weren't allowed to be monitored and because it was a German company they had to be given the same rights as if they were in Germany.
So I'd say it was safe to assume, I wasn't given that special privilege of not being monitored.
On the subject of recorded IP traffic logs, if it's an after some incident, they can put lots of time and money into cracking your encrypted traffic. Some of these Intellectual property law suites can go on for 10 years. You are a fool to think that they wouldn't crack your keys and see everything that you ever viewed over the web while at work.
It's for this reason why I love one time pads, it's a real loss that security people keep dismissing them.
for some interesting reading:
http://iang.org/ssl/
https://www.financialcryptography.com/
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
http://hackaday.com/2009/02/23/sslstrip-hijacking-ssl-in-network/