DNS Cache Poisoning as a Foil to SSL

Question

I recently learned a bit more about DNS cache poisoning, and my understanding of the basic way it works is by editing the DNS cache so that when the victim types in, say, www.google.com they get the attacker's IP instead of google's. So here is my question - is the following attack viable?

1) Take an address such as www.gmail.com, copy its HTML (or the HTML of its redirect) onto your machine, and change its IP in the DNS cache.

2) When a victim connects, they get routed to your machine. They probably get a certificate warning, but they ignore it because everyone ignores them... Anyway, you send them the HTML you already copied, but you edit it so that the username and password are sent to you (if necessary, I haven't parsed through the HTML of gmail's login)

3) Now with a bit of code, you can make it (I think) so that they establish an SSL connection with you instead of google. When they send their username and password to you you just edit the DNS cache back to the way it was and DeAuth them 20 times or so so they get a "connection problem." They log in again and everything is fine - no way for them to know that their password was stolen.

I think this attack is possible, except, perhaps, for establishing the SSL. I know how that works but wouldn't know how to program it -- but is it possible? Would you need to set up a server of your own or could your just route them to your local IP (I assume this would ring some bells somewhere). Thanks!

Answer 1

No, this attack is not feasible. Believe me, I've tried. Now when I say I've tried it, I was not writing a virus or something to steal passwords, I was writing software where the user was fully aware that they were using a custom DNS server which intentionally lied (based on their rules) in conjunction with a HTTP proxy. This is exactly what you describe, "poisoning" the DNS to basically lie to the software making the lookup and point it wherever you really want to the traffic to go. There are several issues that arise once you throw SSL into the mix.

1) Even if you have a custom DNS server or piece of software monitoring and modifying the DNS packets, there is no way inside this protocol to tell if you are dealing with requests for HTTP/HTTPS, or who knows what. So, you cannot tell what protocol the request is for. Even if you inspect the packet and look for the hostname, it will appear as "mail.google.com", not "https://mail.google.com", as an example.

2) In order to bypass the browser warnings, you need a few things. First, you need a trusted root certificate for your proxy or malicious server. Not gonna happen. Even if you manage to get the user to accept and install it (which windows basically makes sure to make the user feel like they're accepting an envelope with anthrax if they say yes), most browsers have their own trusted root authority certificate stores that they check against. So now you've gotta get the user to go out of their way to install your cert in whatever flavour of browser they're using as well.

3) Step two isn't enough. Now, if you've gotten that far, you have your malicious cert for your malicious server. Now you need to dynamically issue certs for every single host that a HTTPS connection is made or else guess what, the alarms still go off. These browser warnings aren't like the old days. Google chrome won't even let you proceed when it detects this going on, no matter how much the user wants to be careless with their own security.

Also, without doing any of this failed trickery discussed in 2 and 3, you get even less. All you can see on a socket level is the socket open from the app requesting the lookup, you see the host resolution happen over DNS, then a new TCP socket open attempting to connect to the host requesting a secure connection. The socket header doesn't contain anything except this basic request. As soon as the connection is made with the server, a handshake takes place and the HTTP connection becomes secured, at which time the hope of screwing with any of the data is lost.

The point is that the likelihood of this attack succeeding is basically non-existent. The user would have to ignore Windows' doomsday style warnings about certs, pass the Windows request for elevated administrator permissions (assuming you're using malicious software to directly poison the DNS cache or tell the system to use a malicious DNS server), then they'd have to ignore the giant red-screen, doomsday style warning in their browser (if their browser even allows it). It would be exceptionally difficult to pull of and would have minimal success even if you could.

All of this said, I really hope you're requesting this information for the sake of the good, not of actually attempting things like this. Tinkering around and learning these things can be fun and can aid in protecting users. Yes it would be perfectly ok to set up your own test network and hack it for fun and education, but doing and learning all this stuff to exploit people makes you a thug and a criminal and a disgrace to higher learning. I'm not saying you are this, I'm saying people who do that are. I hope you consider and weigh out these moral and philosophical questions in your adventure to obtain knowledge.

See also, for proof of browser protection from this issue.

Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "

Answer 2

The whole reason why SSL servers use certificates is precisely so that the kind of attack you are describing does not work. And, more generally, SSL does not rely on any security feature, or lack thereof, of its transport medium. This includes the conversion of names to IP addresses, i.e. the DNS. For all practical purposes, SSL remains secure even if all the data packets are transmitted by the attacker himself in both directions.

If you prefer, even with full control of the low-level traffic in both direction, you will not be able to make clients do a SSL connection with your fake server; the client will get a very visible warning about how the apparent server certificate is incorrect (either they will not be able to validate it, or the name in the certificate will not match what is expected, or both). If the human users "clicks through" the warning, then yes, they would connect to your fake server and fall under your control; however, modern browsers make it increasingly more difficult for the typical human user not to heed such certificate-related warnings.

Answer 3

Apart from the other answers, this attack from the perspective of an api call using curl with -k(insecure) option would imply it will goahead and connect to the malicious server, considering most developers love to use -k to ignore certificate validation often.