The ‘SSL strip’ exploit

The Secure Sockets Layer (SSL) is one of the world’s most important forms of commercial encryption. It is the public key system generally employed by e-commerce websites like Amazon, in order to prevent payment details from being intercepted by third parties. At this week’s Black Hat security conference in Washington, details were released on an exploit that takes advantage of the weak way in which SSL is implemented in secure (HTTPS) websites.

The tool – called ‘SSL strip’ – is based around a man-in-the-middle attack, where the system for redirecting people from the insecure to the secure version of a web page is abused. By acting as a man-in-the-middle, the attacker can compromise any information sent between the user and the supposedly secure webpage. The author of the exploit claims to have used it to steal data from PayPal, GMail, Tickermaster, and Facebook – including sixteen credit card numbers and control of more than 100 email accounts.

This kind of vulnerability has always existed with SSL because it is difficult to be certain about where the endpoints of communication lie. Rather than having a secure end-to-end connection between Amazon and you, there might be a secure connection between you and an attacker (who can read everything you do in the clear), and then a second secure connection between the attacker and Amazon.

To some extent, the problem can be mitigated through technical means (as described in the linked article). Beyond that, the question arises of what constitutes adequate precautions, from both a legal and a personal standpoint, and who should pay the costs associated with data breaches and fraud.

[Update: 23 February 2009] The slides from the original presentation about SSL Strip are available here and here. Both servers are under a fair bit of strain, due to all the popular interest about this topic, so it may be tricky to access them during the next few days.

[Update: 5 November 2009] One thing I think these SSL exploits (and others described in comments below) demonstrate is that we cannot rely completely on technical means to avoid fraud and theft online. There is also a role to be played by laws on liability and other means.

If it could be implemented at the level of the routers or servers of an ISP, someone might be able to harvest millions of credit card numbers or email accounts with this. All sorts of attacks might be possible, such as taking over people’s GMail accounts, changing the passwords, and then offering to sell back access.

“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.”

Greetings slashdotters. Apparently the demand for this has been so great that someone went to the trouble of wardialing for the unpublished URL where sslstrip was being staged on my webserver. Then having guessed the correct URL, and not content to merely have access, they also slashdotted it.

So, here is the actual release. If you’re feeling generous, know that I mostly do security research out of personal interest, and that I only very occasionally publish my findings. If you like what I do publish, you might consider clicking on that donate button, which could motivate me to publish more (and dissuade me from trying to sell stuff to the Russian mafia instead).

With that tool in the wild, I am not feeling terribly secure about using HTTPS web banking, etc.

Hopefully, though, this public disclosure will lead to a more secure architecture for encrypted transactions. That outcome is dramatically better than the one that could have occurred is this tool had been quietly used by some organized crime group to collect confidential information over the course of weeks or months.

It may be justified to avoid using SSL on open wireless networks or in internet cafes for a while, however.

Not an original ideia of Moxie Marlinspike himself. In fact you can implement the same trick by using a Reverse Proxy (locally) and launching your MITM attack using ARP spoof to fool the victims machine into thinking you are the local gateway.

“Two researchers, Dan Kaminsky and Moxie Marlinspike, came up with exact same way to fake being a popular website with authentication from a certificate authority. Wired has the details: ‘When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com.badguy.com, using the null character in the URL. The CA will issue the certificate for a domain like PayPal.com.badguy.com because the hacker legitimately owns the root domain badguy.com. Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker’s certificate, they stop reading any characters that follow the ” in the name.'”

I just want to test the ssl working to my leader and ask he to update network switch setting.
I test http is working, but -f option is not work for SSL.
And I don’t understand -k option means
I am not have test working of “pаypal.com”

And the 0.5 version is some error on Centos5.2 with python2.4&2.5
I remember sslstrip.py line 21

“Nine weeks after Moxie Marlinspike presented at Defcon 17, null-prefix certificates that exploit the SSL certificate vulnerability are beginning to appear. Yesterday, someone posted a null-prefix certificate for http://www.paypal.com on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows. What’s worse, because of the OCSP attack that Moxie also presented at Defcon, this certificate cannot be revoked.” Update: 10/06 23:19 GMT by KD: Now it seems that PayPal has suspended Marlinspike’s account.

“People still don’t understand SSL. This isn’t much of a surprise… no one expects that grandma and grandpa know what SSL is and what it does. What is surprising and downright scary is that most IT professionals don’t understand SSL, and many consider it to be the be-all, end-all of security in their organization. With all the tools out there to manipulate SSL connections, and the browser vendors unable to settle on a single method of showing if a site is secured by SSL or not, is it any wonder that no one gets it?”

“The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an ‘authentication gap’ exists during the renegotiation process, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS.”

Last month, researchers found a security flaw in the SSL protocol, which is used to protect sensitive web data. The protocol is used for online commerce, webmail, and social networking sites. Basically, hackers could hijack an SSL session and execute commands without the knowledge of either the client or the server. The list of affected products is enormous.

If this sounds serious to you, you’re right. It is serious. Given that, what should you do now? Should you not use SSL until it’s fixed, and only pay for internet purchases over the phone? Should you download some kind of protection? Should you take some other remedial action? What?

If you read the IT press regularly, you’ll see this sort of question again and again. The answer for this particular vulnerability, as for pretty much any other vulnerability you read about, is the same: do nothing. That’s right, nothing. Don’t panic. Don’t change your behavior. Ignore the problem, and let the vendors figure it out.

“Moxie Marlinspike, who recently published new attacks on SSL at Defcon 17, seems to have released the new version of sslsniff which supports these attacks. While the release appears to coincide with a patch from Mozilla, every product that uses the Microsoft CryptoAPI is still vulnerable, including Internet Explorer and Outlook. The new version of sslsniff also supports built-in modes for hijacking software auto-updates that depend on SSL, and apparently includes techniques for defeating OCSP as well — making the elimination of existing null-prefix certificates difficult.”

“Is SSL becoming pointless? Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data. According to these hypothesized attacks, governments could compel certificate authorities to give them phony certificates that are signed by the CA, which are then used to perform man in the middle attacks. They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers’ private data to US government law enforcement. The researchers are developing a Firefox plugin (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens.”

A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don’t even do that much.

Scary research by Christopher Soghoian and Sid Stamm:

Abstract: This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals’ secure Web-based communications. We reveal alarming evidence that suggests that this attack is in active use. Finally, we introduce a lightweight browser add-on that detects and thwarts such attacks.

Even more scary, Soghoian and Stamm found that hardware to perform this attack is being produced and sold:

At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications — without breaking the encryption — by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.

[…]

The company in question is known as Packet Forensics…. According to the flyer: “Users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity.” The product is recommended to government investigators, saying “IP communication dictates the need to examine encrypted traffic at will.” And, “Your investigative staff will collect its best evidence while users are lulled into a false sense of security afforded by web, e-mail or VOIP encryption.”

“With news that it is rather simple to mimic authority with many webmail providers in order to coax an SSL certificate authority into creating one for the domain, a Canadian security expert has decided to take it upon himself to see who out there is actually vulnerable and provide information to the public on how prevalent this issue is as we speak. Out of eleven webmail services chosen at random and without prejudice, just under half of them permitted him to register with credentials (ssladmin) that allowed him to create an SSL certificate in their name. In most of these cases, there was a pre-existing, legitimately-acquired certificate.”

“Whenever you’re sending sensitive information online—say, your credit card number to Amazon or a message over Gmail—the content is encrypted before being sent and then decrypted by the Web site you sent it to. (Sites using this secure mode have URLs that start with “https,” and browsers add a padlock icon as well to demonstrate you’re communicating securely.) Every vendor has its own rules for how to scramble information so that only it, the intended recipient, can decode it. If anyone intercepts the message along the way, it will appear to be a meaningless digital jumble.

To overcome this deficiency, the Web’s security relies on the idea of “certificate authorities”: organizations that independently verify the identity of the Web site you’re communicating with and provide a digital confirmation that it’s authentic. A certificate authority’s digital endorsement decides whether your browser believes a site when it claims to be GMail, Microsoft, or even the New York Times, which has a secure version. Middle men can’t fake this authentication without getting a similar endorsement. These certificate authorities are supposed to conduct due diligence in ensuring that only the real Web site gets their stamps of approval.

Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft’s software trusts more than 100 private and government institutions.

Disturbingly, some of these trusted certificate authorities have decided to delegate their powers to yet more organizations, which aren’t tracked or audited by browser companies. By scouring the Net for certificates, security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors—and a UAE mobile phone company called Etisalat.”

Electronic Frontier Foundation staff technologist Peter Eckersley has a good, in-depth analysis of the revelation that Iranian hackers acquired fraudulent SSL certificates for Google, Yahoo, Mozilla and others by spoofing Comodo, a major Certificate Authority. CAs are companies that are allowed to sell cryptographically signed certificates that browsers use to verify their network connections; with these spoofed certs, the hackers could undetectably impersonate Yahoo and Google (allowing them to read mail even if it was being read over a secure connection), the Mozilla certificate would allow them to slip malicious spyware onto the computer of anyone installing a Firefox plugin.

It appears that the fraud was detected before any harm could be done, but Eckersley explains how close we came to a global security meltdown, and starts thinking about how we can prepare for a more successful attack in the future.

SSL/TLS, the protocol that protects security of e-commerce, has taken a beating lately, with news items ranging from the violation of certificate authorities to the discovery of an exploit that beats the protocol itself.

With all the noise about SSL/TLS it’s easy to think that something is irreparably damaged and perhaps it’s time to look for something else.

But despite the exploit — Browser Exploit Against SSL/TLS (BEAST) — and the failures of certificate authorities such as Comodo and DigiNotar that are supposed to authenticate users, the protocol has a lot of life left in it if properly upgraded as it becomes necessary, says Taher Elgamal, CTO of Axway and one of the creators of SSL.

The death knell for SSL is getting louder. Researchers at the University of Texas at Austin and Stanford University have discovered that poorly designed APIs used in SSL implementations are to blame for vulnerabilities in many critical non-browser software packages. Serious security vulnerabilities were found in programs such as Amazon’s EC2 Java library, Amazon’s and PayPal’s merchant SDKs, Trillian and AIM instant messaging software, popular integrated shopping cart software packages, Chase mobile banking software, and several Android applications and libraries. SSL connections from these programs and many others are vulnerable to a man in the middle attack.

This SSL Stripping technique is very easily done. Anyone who can just connect to a network (either wireless or wired) can easily implement a MIM attack, then use SSL stripping to get the information. I have successfully done this in practice (never illegally) and it takes maybe five minutes to setup. This kind of attack can be done on any computer, with any OS, running any anti-virus. The attack does not focus on the Host, but rather the packets being sent back and forth between the host and the default gateway. Key things to look for if you are afraid of this: whenever logging into ANYTHING (i.e. gmail, paypal, facebook, etc) always check that the URL starts with HTTPS and not HTTP. If it does not have the “S” at the end, then it is not secure and potentially has listeners on it.

This is an extremely clever man-in-the-middle timing attack against TLS that exploits the interaction between how the protocol implements AES in CBC mode for encryption, and HMAC-SHA1 for authentication. (And this is a really good plain-language description of it.)

This kind of workplace surveillance is often hand-waved away by capitalist bootlicker apologists who say that you should expect no privacy while using employer-provided equipment (I think this is bullshit: you’d be pissed if discovered that your private lunch break parking-lot conversation with your spouse about your cancer diagnosis was secretly recorded by your employer’s hidden mics; your employer’s man-in-the-middle attack on your personal Gmail traffic during your lunch break is no more acceptable).

But even if you’re OK with the idea of your employer spying on you, there’s the matter of overall security: man-in-the-middling browsers significantly reduces their security.