Slashdot Mirror

See my other post just below.

For DNS rebind to work like that, the hacker has control of the DNS servers hosting your bank's domain.

Nope, sorry this is not how it works.

1) You would simply make the device connect to your fake DNS server.
2) In your fake DNS server, you would simply hardcode your fake web server IP to return when asked to resolve "www.mybank.com" so, there is no need to control the bank DNS server.
3) In your website virtualhosts config, you would simply create a domain "www.mybank.com"

This is not only limited to web attacks but it extents to anything trying to connect anywhere by hostname.

Some user will just enter mybank.com to connect to their bank. Normally, the website will redirect them to https://www.mybank.com/ (TLS site). Your fake website won't and will allow connections with plain http. No certificate needed.

Remember that for such an attack to pay off, only 1% of users falling for it is a lot!

Obviously, this isn't limited to banking sites and HTTP connections.

Ya.. Some of what I put up earlier was so others would question it.

I posted a link in another reply about gov't entities who are root CAs. In that, if you read a bit, it shows who you have to suck up to. Firefox, to be included in Firefox (all platforms). Microsoft to be included in MSIE. Microsoft for Chrome on Windows, as it uses the OS's root CAs. Chrome on Linux uses Firefox's CAs. And I'm sure Apple for it's various devices.

I haven't looked enough to see what the Android browsers use, but I'm pretty sure you'd have to get friendly with Google for that, plus any 3rd party browser authors who use their own.

I actually wrote up a quick and dirty page about 7 years ago, which goes through all the hoops of making the key, CSR, and self-signed cert. It was mostly for me, so I didn't have to type out all the openssl commands, but it's out there for the world to use, even though they shouldn't. I see hits to it all the time, so there are people using it, which means I could have been logging their key.

That is what got me thinking about it then. Why were my employers and friends throwing money at another company for their sites, when they could throw it at me and safe a few bucks.

It's really stupid if you think about it. Why does a SSL cert cost more than a couple bucks? Even at that, they'd be making a profit. Most CAs just send an email to a pre-determined address (whois owner, root, admin, domadmin, ssladmin, etc), to "verify" it's legitimate, and then send the signed cert over to the user. The obnoxious ones that usually charge more, want the D&B number, check the state's corporation filings, require blood and semen samples, etc.

End users are dumb. Most don't even know if they're punching in their credit card info on a SSL protected page or not. There are enough that look for the little padlock to believe it's trusted, but the rare exception checks to see who signed it. Why bother, it's trusted by the browser, it must be ok. At most, a few people catch irregularities like the one in the original story, and make noise about it. Do I care who signed Google's SSL cert? Not really. All that I've learned from the story is that Google might use different certs on different servers. That or the author was caught in a MITM attack and actually noticed it. .. and for giggles, I just went to my bank's web site. I'm replacing the bank domain name with "[mybank]" in this, and account access as [private.mybank].

https://mybank.com/ has a regular SSL cert for *.domain.com . Ya actually "domain". It immediately redirects to the next one.

https://mybank.org/ is a EV cert, signed by COMODO CA Limited, with a SHA1 fingerprint ending in 46:F6:C3, with an alias of www.[mybank].org

https://private.mybank.org/ is an EV cert signed by COMODO CA Limited, with a SHA1 fingerprint ending in 3C:8C:CA

That seems strange to me. They bothered to alias [mybank].org and www.[mybank].org, but didn't add the alias [private.mybank].org or [mybank].com. Well, whatever floats their corporate boat.

Why not have it be a shortcut (in Windows), or a list of command line options (in UNIX)? For example:

$browser --onlythisdomain mybank.com --lockstuffdown

The --onlythisdomain option would only allow anything in https://.mybank.com/* to be viewed. The --lockstuffdown option would disable everything else, bookmarks, browser extensions, the URL bar, and anything else that a user might confuse or mess up. The window would have a special border around it, etc. Once this browser instance is closed, it purges all data. Perhaps even having all data for the instance read/written to a different location and encrypted with a throwaway key.

Having dedicated apps is one thing, but that forces people to have to have stuff for each site instead of being able to access it via one universal tool. I don't miss the days of AOL or CIS when one needed either to log in via the terminal, or use their special client in order to access their services.

how can you currently tell if http://mybank.com/ is really your real bank?

you just know that it is because you trust the identifyer (mybank.com)

just as if you contacted your bank (or pinged mybank.com before abandoning the DNS) you would be able to find out a trustworthy IP address

Your browser sets of alarm bells when you go to http://www.mybank.com/?

You must love bells!

It's only more dangerous if you think it isn't. Browsers could display self-signed sites as if they were unencrypted; that would be better than the current situation, and no more dangerous.

Yeah, because when people go to https://mybank.com/ and someone sends them a fake certificate it's much better to just not put a lock icon in the status bar than to put up a huge warning page saying 'YOU ARE GOING TO BE PWNED!'

OpenSSH still works fine using the equivalent of self-signed certificates.

Until someone wants to commit a man in the middle attack on you and then you're screwed. The one way that SSH works better than SSL is that it tells you if the certificate has changed, which current browsers don't seem to do; that means they have to do a man in the middle attack before the first time you connect and SSH caches the key.

I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections.

And huge potential security holes which completely break signed key security. If I go to https://mybank.com/ I sure as hell don't want my browser to accept a self-signed key without warning me.

What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of?

Probably none, because I don't believe that any browser ships with support for StartSSL and hence will treat it as an unsigned key.

The problem with SSL is that browsers accept far too many 'authorities' not too few.

So, no error when the user connects to https://google.com/, https://mybank.com/ etc., that have self signed certificates? How is the browser supposed to guess when the connection needs a correctly signed certificate or not?

Aside from "branded consumer experiences" and all that stuff that gets the marketing guys excited, the one reason to make the disks bank-specific is that it makes security a lot easier.

If all the disk has to do is go to https://mybank.com/ you can do all sorts of draconian but secure stuff: Disable loading any non-SSL page or element. Trust only your own cert/CA. Remove any option to approve an exception. Configure the firewall to block any and all traffic that isn't either a DNS(SEC, preferably) lookup for mybank.com, or communication between the host and mybank.com

If you have to coordinate between a bunch of banks, things get harder. Either you take on a big institutional verification task, enrolling reputable banks in your list of trusted sites and cert/CAs, and hopefully not having some front group sneak one in there for some XSS action, or you throw up your hands and just build a generic "browser liveCD".

The generic browser liveCD is still a good bit safer than Joe user's computer, since it needn't be a general purpose machine, or capable of running Limewire, or have every infection picked up in two years of browsing(since the max lifespan of a liveCD session will probably be a few hours); but it is still substantially less safe than a dedicated one. If there are any available exploits for the browser used, the user has a nonzero chance of picking one up while poking around and having it still resident if they bank after doing that, and before rebooting. There would also be the basic issue of cross site/cross tab stuff. Exploits of those sorts of flavors are discovered all the time. If you give up on the goal of having a general-purpose browser, you can neutralize most of them without even discovering them or patching the browser. If your browser has to be general purpose, you have to do the security the hard way.

Or do you really believe that Joe Average actually types https://www.mybank.com? You're lucky if they even get the www. part in.

Good point. Firefox should assume https by default.

(anybody have a Bugzilla acount? please file this)

Still doesn't help if you can also find fake international characters to replace things like ?, & and =. Say the evil domain is 74h34.be, then your evil url could look like:

https://mybank.com/bunch/of/paths/banking.jsp?bunch=of&arguments=here&session=0WjEc.74h34.bE

Now it just looks like an innocent session hash.

"There is nothing special about secure sites. HTTPS doesn't mean "this site is super special and you should do special things with it". This same attack can be applied to non-secure sites, too." - RockMFR (1022315)

Well that's the thing - why not? They are superspecial to my browser already.. doing its certificate check and throwing a big fat "passport check" image at me (FireFox 3) if it think something's not quite up to snuff. I don't see why a page on anything other than https://www.mybank.com/ shouldn't be told to piss off.

"Quite a few sites are actually structured around the idea of cross-site linking. (e.g. The HTML may be www.mainsite.com while the images come from the web server media.mainsite.com.)" - AKAImBatman (238306)

That I understand - as per my post, for inlining things etc.

However, I think that in the specific case you mentioned - e.g. media.. presumably images - those images *should* either come from the same domain as the secure site *or* come directly from an insecure site. Yes, a browser will pop up a warning that there's mixed content.. it does that for a reason, I would think. But the way around that is not to stick your images on a completely different-but-still-secure domain (I've not actually seen this, so for all I know that throws up an error as well anyway), but by keeping things on the same domain. Any sysadmin worth their pay can easily offload resources to a different media server if there's some manner of capacity issue at play that would have them put the media on a different domain otherwise.

Maybe making things more strict would indeed break a few sites, but other than webmasters/sysadmins realizing they need to be more careful, I don't see the harm in that other than short-term mumbling and cursing from the aforementioned groups.

crossdomain directives sound like another security problem just waiting to happen, in my humble opinion, but I'm certainly not an expert on that topic.

So let's say that instead it's on http://www.malware.lol/ - why would a script on a page from malware.lol be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* https://www.mybank.com/ ?

There's a great deal of internet history behind this one. Originally, there were no barriers what so ever. Anyone could link anything from any page. Of course, as Javascript entered the scene and grew in sophistication, this was soon realized to be a problem. In result, most browsers adopted security behaviors for the really powerful stuff like XMLHttpRequest and locked out scripting across frames.

However, that still leaves a hole like this one. And it's not an easy hole to plug. Quite a few sites are actually structured around the idea of cross-site linking. (e.g. The HTML may be www.mainsite.com while the images come from the web server media.mainsite.com.) Interestingly, this sort of structure is actually a solution to the problem posed. So it's difficult to dispose of it out of hand.

Some of the web standards are moving toward highly restrictive models for HTTPS sites. e.g. HTTPS resources can only be accessed by pages whose origin is the same HTTPS site. More likely though, I expect to see more explicit security configurations along the lines of what Flash does. Flash uses a crossdomain.xml file on the target site to broadcast if a resource can be accessed or not. This scheme allows for situations like a media server separate from the primary site, but it also allows for those cross domain accesses to be tightly restricted.

Of course, the scheme is not without its problems. Nothing prevents an attacker from transmitting information he may have collected TO a server that he has configured with a permissive policy file. If he finds a vulnerability that allows him to collect the information in the first place, he's going to be able to make off with the info scott-free.

In result, web security is an ongoing area of research. It's incredibly complex due to the nature and history of the web, but standards bodies are working hard to find more reliable solutions that don't negatively impact existing sites and current usage.

so wait..
as you explain it, I guess the idea is that once the user logs into the secure site, the malware script can magically access the lock.gif because the site and browser tell them that.. yup.. the user is logged in and thus should have access.

however.. presumably, the script is not from a page that's actually -on- https://www.mybank.com/.. if it was, you and the bank probably have bigger problems.

So let's say that instead it's on http://www.malware.lol/ - why would a script on a page from malware.lol be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* https://www.mybank.com/ ?

Is there any valid purpose for allowing something like that? I can understand it for non-secure sites.. from inlining content that's hosted on another domain to allowing local applications to grab data off of e.g. websites that do not provide a nice API. But for secure sites? I'm baffled.

so wait..
as you explain it, I guess the idea is that once the user logs into the secure site, the malware script can magically access the lock.gif because the site and browser tell them that.. yup.. the user is logged in and thus should have access.

however.. presumably, the script is not from a page that's actually -on- https://www.mybank.com/.. if it was, you and the bank probably have bigger problems.

So let's say that instead it's on http://www.malware.lol/ - why would a script on a page from malware.lol be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* https://www.mybank.com/ ?

Is there any valid purpose for allowing something like that? I can understand it for non-secure sites.. from inlining content that's hosted on another domain to allowing local applications to grab data off of e.g. websites that do not provide a nice API. But for secure sites? I'm baffled.

Sorry, I fail at reading comprehension today, let me try that again.

Ok, so lets say you try to browse to https://mybank.com/ but there's a MitM intercepting your connection. When you first connect, the plugin should be able to get a fingerprint of the mybank.com cert. The plugin then asks the notary to verify that fingerprint. The notary connects to mybank.com and reports back the fingerprint. If they match, there's no MitB intercepting the secure communication (at least, not unless the MitB attacking from the network of mybank.com,) If they don't match, that means the two of you aren't seeing the same website, and something is *really* wrong.

Assuming that the first connect isn't a MITM is risky.

I guess this is a reasonable point.

But again, if you go to http://mybank.com/ and it turns out to be a phishing site, there is no warning whatsoever. Most users have no idea what the difference is between http and https; even when typing in URLs by hand they don't type the http:/// part.

In olden days users were encouraged to look for the padlock icon. Nowadays the connotation of trust that provides has been worn down by the CAs' sloppiness in handing out certificates, so the new user interface marker is the green glowing bar for an EV certificate. As long as the self-signed https website does not appear any more secure to the user than an unauthenticated site, I don't see there is a problem.

By all means have the scary warning appear for self-signed sites, as long as you make it appear for unencrypted sites as well! They are both equally likely to be fakes.

The ssl handshake process compares the dns resolved hostname in the url against the hostname in the cn of the downloaded cert. If you can't trust the dns server provided by your gateway, i.e. because you are using the free wifi access in the airport in Tel Aviv, then it is possible, and highly likely in some locations, that your https traffic is being watched.

Secure dns, and then ssl might be secure.

Watched? It doesn't matter if they watch or not, they can't do anything about it - can't spoof it, can't decrypt it. That is the point of SSL.

Let's assume I am using free wifi provided by a sniffer/spoofer. I go to https://www.mybank.com/ because I know that is the url for my bank. Let's say that normally that resolves to 1.1.1.1. The bad guy sets up fake DNS to report 2.2.2.2, where he runs his leet phishing site, and his phishing site looks exactly like the real web site.

When I go https://www.mybank.com/ it will to the phisher's website, not the real website, but I will get an SSL certificate warning, because the phisher is unable to spoof the SSL certificate. To spoof the SSL certificate, he would need a Certificate Authority to issue a certificate with the same CN name.

If:

1. Certificate Authorities are diligent in issuing certificates
2. the user is reasonably intelligent and notices the certificate warning in their browser

then SSL is unbreakable and unspoofable. Secure DNS is very useful, but it is irrelevant in this case.

Of course, #1 isn't always true, and #2 isn't always true either.

The ssl handshake process compares the dns resolved hostname in the url against the hostname in the cn of the downloaded cert. If you can't trust the dns server provided by your gateway, i.e. because you are using the free wifi access in the airport in Tel Aviv, then it is possible, and highly likely in some locations, that your https traffic is being watched.

Secure dns, and then ssl might be secure.

Watched? It doesn't matter if they watch or not, they can't do anything about it - can't spoof it, can't decrypt it. That is the point of SSL.

Let's assume I am using free wifi provided by a sniffer/spoofer. I go to https://www.mybank.com/ because I know that is the url for my bank. Let's say that normally that resolves to 1.1.1.1. The bad guy sets up fake DNS to report 2.2.2.2, where he runs his leet phishing site, and his phishing site looks exactly like the real web site.

When I go https://www.mybank.com/ it will to the phisher's website, not the real website, but I will get an SSL certificate warning, because the phisher is unable to spoof the SSL certificate. To spoof the SSL certificate, he would need a Certificate Authority to issue a certificate with the same CN name.

If:

1. Certificate Authorities are diligent in issuing certificates
2. the user is reasonably intelligent and notices the certificate warning in their browser

then SSL is unbreakable and unspoofable. Secure DNS is very useful, but it is irrelevant in this case.

Of course, #1 isn't always true, and #2 isn't always true either.