6

Alice wants to login to her account at https://www.bobsbank.com/. However she clicks on a malicious link in an email and instead gets sent to the malicious site https://www.charliesbank.com/. The malicious site has a secure SSL relationship with Alice. Alice sees the "this site is secure" padlock icon in her browser. When the malicious site (Charlie's Bank) receives Alice's request, the malicious site decrypts the request using the SSL certificate which it owns. It then re-encrypts the request with the public key for Bob's Bank. It has established an SSL relationship with Bob's Bank. Bob's Bank has no way of knowing that Charlie is not, in fact, Alice, as Charlie can provide all of Alice's information. Charlie can then listen in on, and even tamper with, Alice's subsequent browsing session.

Does this attack work and is there any way to prevent against it?

5 Answers5

4

This is exactly why I got so pissed off at Bank of America when they sent out a link to myfraudprevention.com when they thought my account was compromised. SSL only works to verify that some trusted third party has validated that the website being visited belongs to the name of the URL being visited. If you sent someone to your own website and that website had a certificate, you could still make the site look like whatever you wanted, including a phishing site pretending to be some other organization.

All SSL would care about is that you are actually the owner of charliesbank.com. Bank of America was literally training their users to fall victim to phishing in an e-mail designed to help stop fraud...

User training is the only way to prevent this currently. If you actually check the details of the certificate being presented, it should tell you more details about the organization that the certificate is issued to. If the SSL certificate has Extended Validation and is the organization you are wanting to talk to, then it means that some certificate authority has looked in to them and determined they are the organization they claim to be, but currently it is on the user to understand how this process works and do the verification themselves. It is also on the user to check the URL to which they are connected.

There probably isn't a whole lot that can be done to improve this either as there is no way for the computer to know that the user really wanted bobsbank.com but visited charliesbank.com. The icon could be replaced with something that shows more details about the certificate, but in general, this just causes more confusion for most users that don't understand how SSL works.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • 2
    It gets a lot hairier too when you take all the credit card handling companies into account. They seem to love redirects and HTTPS sites with really stupid names. This does not do anything to earn my trust, and lets users build up confidence in trusting sites that they don't know. – Maarten Bodewes Jan 25 '13 at 22:31
3

The attack is avoided by the use of certificates, namely the names. Alice's browser will reject Charlie's certificate, because the browser wants to talk to www.thebank.com and thus expects to see that exact name www.thebank.com in the purported server certificate. Charlie's certificate contains www.evilcharlie.com, the name of his own Web site.

To enact his attack, Charlie would have to bribe a CA (one of those trusted by Alice's browser by default) into issuing him a certificate containing www.thebank.com. Of course, good CA will not do accept that (when they do, it makes the news; such mishaps happen about once per year worldwide, which is not that often).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Most of the time it is probably Alice that doesn't notice that the website is on a server with a different URL. In that case there are no issues with certificates, and the attack works. There will always be CA's willing to sell a certificate for a site whose name is close to that of another site. – Maarten Bodewes Jan 25 '13 at 22:26
  • But how does the browser know it expects to see `www.thebank.com`? If the user clicked on a malicious link then the browser address bar will contain the malicious URL and the browser has no way of knowing this is not a legitimate action, right? Of course, all savvy people will check the address bar to see what site they are connecting to, but I am thinking of the majority of people who don't do that and are caught out in these kinds of attacks, and if there is any way to prevent it. –  Jan 25 '13 at 22:28
  • @owlstead beat me to it by 1 minute!! –  Jan 25 '13 at 22:29
  • 2
    I think the OP is asking something different. His question reads to me like this: "If the malicious bank has a legitimate SSL certificate (through normal acquisition measures) and the the HTTP listener on evilBank's port 443 is a **proxy** that creates a session with https://www.thebank.com. This would make a MITM possible, and is orthogonal to the attack you describe – makerofthings7 Jan 26 '13 at 15:37
3

Does this attack work

Yes, in fact there are commercial solutions for doing exactly that. Ostensibly not for malicious purposes.

and is there any way to prevent against it?

Yes, don't use an Internet connection that has such a proxy in place. Most commonly, these installations are found on corporate networks, campus networks, or other places where the network operator wants to examine all traffic, including SSL traffic.

Typically these installations require you to install a "fake" SSL root authority certificate in your browser which is used to sign the certificates generated to do the man-in-the-middle attack. So... don't do that. Though if the attacker already has a CA certificate installed on your computer that wouldn't be necessary.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 1
    To elaborate on what Tylerl said, Websense does this. On a corporate network it's a GOOD thing so you can inspect the payload of SSL enabled sites. The CA trust is not an issue as the intermediate and root certs from the corporate CA are pushed to the machines once they join the domain. – k1DBLITZ Jan 25 '13 at 16:54
  • To be honest, I'm interested as to how to prevent this myself as a security architect, not as a user!! It sounds like you are saying the attack is completely possible and there is no real way to prevent it for someone who doesn't know how to protect themselves online. –  Jan 25 '13 at 22:31
  • @Kidburla the lynchpin in the whole PKI system is trust in your certificate authorities. If every certificate in your authority store is someone you can trust, then no attack is possible. But if there is just one that has been compromised or is there illegitimately, then your security infrastructure is effectively neutralized. – tylerl Jan 25 '13 at 23:16
  • I can trust the certificate authority as it relates to my interactions with them, but I can't trust them as it relates to a completely different certificate, site, and system!! What you are effectively saying is that Alice's trust in them should extend to the fact that they should never issue certificates on behalf of malicious websites. However there is no obvious automated way of knowing that the website is malicious - from a technical standpoint it looks fine, and only when a human manually investigates it would they see that it (Charlie's Bank) is trying to imitate Bob's Bank. –  Feb 22 '13 at 21:45
1

Does the attack work?

Yes the attack would work. And in contrast to a few other answers here, no special modification is needed in the local CA certificate store of the device I want to attack.

Is there any way to prevent it?

The only way I can think of addressing this issue is to use client certificates/mutual auth TLS, or an "app" that connects only to the trusted site.

..the attack

A "Phishing Proxy & Certificate Substitution" would work like this:

Suppose I wanted to attack a bank called www.contoso.com, and I purchase the DNS name www.contos0.com. I then purchase a standard domain control validated certificate that simply verifies that I own control of the domain. No EV certificate is needed, though I suppose one could be acquired.

Then the attacker obtains TCP software that essentially echos the data and forwards it on to the next server. The process happens in reverse as well and a duplex session is made.

The phishing attack that looks like this:

Browser  <---->  contos0.com:443 (decrypt and rencrypt) <----> contoso.com

..the mitigation

For regular websites/desktops

Since your webserver can use any CA to generate client certificates you can:

  1. Enroll users the certificate using the HTML5 KeyGen element
  2. Or enroll users by simply offering the entire certificate (public and private key in a combined PFX) for download.

I've tested the UI for various browsers, and see the Keygen as easier for the end user to manage, even though it needs improvement.

For mobile apps

Mobile browsers almost never show the browser bar, therefore most users won't know if they are on a phishing site, a HTTPS site, or a site with an EV certificate.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • Thanks for your detailed response and I think you one of the only users here who understood my original question!! I don't understand how this keygen method would work though? Surely it only affects the trust relationship between the real website and whatever system is accessing it (in this case it's the malicious website). I have not come across this keygen before, but it may be similar to a "CSRF Token" method we currently use where the user has to provide a unique token in the request, that we provided them with in the first place. Unfortunately, the attacker will also have it in this case. –  Feb 22 '13 at 21:52
  • It isn't a CSRF Token... actually it's a way of authenticating a user (or browser) that is somewhat complex and not at all intuitive for the end user. Every web browser does client certificates differently. Keygen is just a way to give a certificate to a user. It doesn't work in IE. Once the user has the certificate (on a drive,or smart card) then it can be used to protect your site. – makerofthings7 Feb 23 '13 at 05:31
  • The difference between "enrolling using a keygen certificate" vs CSRF is that they address different attacks. Even with mutual auth TLS (what keygen allows) you can still have a "Confused delegate" situation where the browser is hijacked through several different means from a 3rd party site. – makerofthings7 Feb 23 '13 at 05:33
  • I still don't really understand what it is that you're proposing. But in any case, if this is not intuitive to the user, then it doesn't work as prevention because I'm assuming here that my user is relatively non-computer-literate, otherwise they would have been savvy enough to check the address is correct in the address bar. –  Feb 27 '13 at 09:56
0

Basic SSL certificates and basic human awareness should be enough to protect again this. But modern business has degraded the process of issuing an SSL certificate, and new technology is confusing people.

In the past, getting an SSL certificate involved verification from the Certificate Authority and a hefty fee. The commercialization of the process has driven the verification quality down and the introduction of "domain validation only" SSL certificates for which minimal verification is performed. And so, SSL certificates have become so popular that people started regarding them as a basic given, not something that should be checked for. Browsers didn't help either by clearly identifying high quality certificates.

So Extended Validation (EV) Certificates were introduced to provide confidence that the owner of the website runs a trustworthy business and has a verifiable identity. An expensive and tedious vetting process discourages evildoers to purchase EV certificates. These certificates come with some improved visual security, that long green bar with the name of the business.

But EV certificates do not solve the confusion problem. According to a 2006 Stanford University and Microsoft Research usability study of the EV display in Internet Explorer 7:

Participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group.

whereas

Participants who were asked to read the Internet Explorer help file were more likely to classify both real and fake sites as legitimate.

Cristian Dobre
  • 9,797
  • 1
  • 30
  • 50