Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.
Website Security Solutions

EV SSL and iFrame attacks

Created: 15 Jul 2009 • Updated: 18 Dec 2012 • 9 comments
Tim Callan's picture
0 0 Votes
Login to vote

We're seeing active discussion online about the possibility of hijacking a single frame in a production site to steal logins or PII. The scenario is that a criminal gang would redirect this frame (through DNS poisoning, let's say) and populate it with its own content from servers under its control. Presumably this content would involve form fields asking for information the criminals want to receive and which you would be willing to share in this context (such as your bank account login or social security number).

Now, the recent dialog is around the scenario where this proposed attack happens on a site with an Extended Validation SSL Certificate. The certificate identifies the controller of the top-level frame and does not report on the sources of any internal frames in that page. That is in keeping with near-ubiquitous practices in consumer Web applications. Sites that offer complex and varied services in large production environments (such as a popular bank, portal, or e-commerce site) have no other practical choice if they want to offer the applications, performance, and uptime their customers demand. Often the sources of content for these frames originate outside the company operating the actual site. Many of these businesses mash up content from partners and specialized service providers in order to meet their product online needs. By way of example, any site using an ad network or content acceleration service is accepting content from another party.

So what should we do with EV SSL? The answer is we should do exactly what we are doing. It's still an incredibly valuable piece of information to know whether or not the operator of this site is who you think it is. This information is indispensible for consumers to protect themselves against the classic phishing attack. This attack is still the most widespread and damaging social engineering attack in history, and it still represents the greatest risk to consumers engaged in transactions online.

At the same time, we need to address the vulnerabilities that make these iFrame attacks possible. We need to lock down DNS security and beat malware and provide tools for laptop users to distinguish between rogue and benign wireless networks. These are the ways the security of the ecosystem is compromised. These are the weak points that this attack exploits. Think of SSL as a secure lock on the front door of your house. If the front door is secure but it turns out the back door is wide open, you might still find a stranger in your living room. So let's go put a lock on the back door, too.

Comments 9 CommentsJump to latest comment

Andy Gambles's picture

Many browser security settings allow for warnings to be presented to the user over mixed SSL and non-ssl content.

Provided these warnings are not disabled by the user then this problem will not occur. Unless of course one of the CA's issues a certificate to the phishing website.

+3
Login to vote
Allen Kelly's picture

Thanks for the comment, Andy. The proposed attack gets around this protection by using a DV certificate on the destination server for the hijacked frame. DV certificates simply ensure that the domain for the certificate matches the domain it is on. DV authentication simply ensures that DV certs are issued to the people actually in control of the domain. Therefore the phisher can use the DV certificate, get around the problem, and never raise a flag about an identity mismatch.

-1
Login to vote
Ravi Ganesan's picture

I am willing to bet that in the not so distant future, that the 'parent' web sites that require EV-SSL for their own web site (the 'mashup canvas' if you will), will ONLY allow iframes, widgets, etc., from partners who also have EV-SSL certificates. The user will of course not see a flurry of green bars all over the place, but it will happen behind the scenes. Rather the parent web site will ensure this using the soon to be open standard called MashSSL. See Nico Popp's quick summary in his March blog http://blogs.verisign.com/innovation/2009/03/ or if you want to see the white papers, spec, etc., visit us at www.safemashups.com

+1
Login to vote
Andy Gambles's picture

Tim,

I can actually see this as being more plausible as the DV certificate could be for an innocent looking domain since the user will never actually see the URL in the browser address bar.

So this raises a question. Should browsers respond differently to pages loading mixed SSL source content? Basically if some of the content loaded is not EV SSL then do not display EV address bar (Perhaps something for the CAB forum to discuss).

I also feel some responsibility falls on the site owner/developer. They should not rely on iframe content from external providers instead they could proxy content server side to avoid client side / access point DNS spoofing.

-1
Login to vote
Allen Kelly's picture

That was Opera's idea in the beginning, and that browser backed away from that stance, presumably because green address bars weren't showing up on very many sites and therefore weren't doing what they needed to do to help users. As I mentioned in the main post, if you're relying on a major ad network or outside analytics or any of hundreds of other services that help your Web site provide the basics you need to give your customers, you can't rely on those vendors to provide you with EV. I hope in the long run for that situation to change, but we're going to have to get there.

In the mean time, perhaps there's a less severe penalty to be applied to the site in question. Maybe there's a warning similar to that warning you see in, let's say, IE7 when you go to a Web site with mixed SSL and non-SSL content. When you go to an EV page, there could be a warning telling the user that some content on this page is coming from a non-EV site. (And then presumably the user could easily see which frames we're talking about. Form fields in these frames would be an obvious thing to suspect.) Interface conventions like that could give users tools to fight attacks like the one described here while still letting the green address bar do its work.

+1
Login to vote
Andy Gambles's picture

I do believe that the way forward is only to display the EV where the entire page content is EV protected.

This will probably however cause huge problems. Especially when you look at the vast number of web "widgets" and "mashups" used on websites.

Even Google Analytics would then need to consider EV for it's tracking code.

+1
Login to vote
Allen Kelly's picture

Could be. In the long term that probably would be best. The rub is what do we do between then and now? Are we really willing to give up the added protection that green address bars provide to users against that so-common brain dead phishing attack today? I think we shouldn't.

I'm sure some kind of interim step is possible, and I hope the smart interface people at Microsoft and Mozilla and Apple are working on this problem right now. There surely are lots of options, and I can imagine several scenarios off the top of my head that are at least worth checking out. I'd like to see what they come up with.

-1
Login to vote
Andy Gambles's picture

I have been thinking this over in my mind and I am still not sure how this would work.

If the attacker is to load data via an iframe they need to be in control of the iframe destination.

To do this they can poison the DNS records via man in the middle but how would they obtain a DV certificate for this domain?

To complete the DV approver process they have to verify ownership of the domain which they clearly can not do because they have no control over the domains email accounts.

They could implement a redirect from the poisoned domain to their own but this would set off browser warnings about non-ssl redirects or invalid ssl certificates.

This could actually only work if the attacker could convince a CA to issue the DV certificate without confirming they own the domain.

+1
Login to vote
stine's picture

All ssl certificates perform the same function: they allow for encrypted transmission between end-points. The only reason for EV certificates is if the standard certificate process was broken and politically untenabe to fix. The only thing the 'green bar' tells me is that someone paid more money for the certificate. If CA's will issue improper standard certificates, what's to keep them from issuing improper EV certificates? The answer is: nothing at all.

+1
Login to vote