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!

  • Questions asking us to break the security of a specific system for you are off-topic unless they demonstrate an understanding of the concepts involved and clearly identify a specific problem. Commented Jan 18, 2014 at 21:46
  • @LucasKauffman I am asking if the attack would work in general, not if it would work on my neighbor's 32 bit installation of Windows XP SP3 given that he uses a WPA2 secured network. I will rephrase: Is any part of this attack unfeasible? If not, the attack is possible. Thanks, and let me know if my conception of "specific" is different from yours.
    – KnightOfNi
    Commented Jan 18, 2014 at 22:31
  • The only way I see that works is by taking out "SSL" from the equation. There is nothing new in that. That kind of "password" stealing technique has been used since a long time ago: If the "victim" types "google.com" (without specifying https), then its easy. In your side, you display that login page (http), they send the login info, then you redirect them to the real login page. The victim will think something went wrong and will try again without knowing what really happened. That only works if the victim is naive and don't realize its not connected through https.
    – lepe
    Commented Jul 21, 2015 at 1:16

3 Answers 3


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. "

  • Thank you so much. Exactly the type of answer I was looking for, and this is purely educational :). Just a couple questions. 1, I was thinking about this as more a targeted attack (as I only have one computer allocated as a victim on my network...), so it seems like your number 3 isn't such a problem for me... 2, mail.google.com always makes an SSL connection, so number 1 seems pretty simple too. And 3, can't they click through the browser warnings without installing the cert (ie, just click "add to trusted sites on Firefox?) Seems to me I'm missing something, but I don't know what. Any ideas?
    – KnightOfNi
    Commented Jan 19, 2014 at 23:59
  • You're missing that you really ought to be running a forwarding proxy as your malicious server. Then you'd be basically doing a classic man in the middle attack. Google that, you should get more documentation than you care you read. :)
    – user7933
    Commented Jan 20, 2014 at 4:59
  • Also I think you're missing that you can't just issue a cert. Once you issue a cert for the domain, the browser will use root/authority certs to verify the cert you've issued. Of course this will come back as a fail and the browser will set off the danger alarms. This is why a root authority cert must be explicitly installed.
    – user7933
    Commented Jan 20, 2014 at 5:20
  • I must have phrased my question really badly... :) I was trying to say that I don't particularly care if it doesn't recognize the cert because most users just click through all of the warnings like that anyway. Installing a new cert is hard, but ignoring an invalid one isn't too challenging (or at least, as a Firefox user it isn't).
    – KnightOfNi
    Commented Jan 20, 2014 at 16:26

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.

  • For Firefox it's like 3 clicks... And in the attack I presumed that they did click through it, because almost everyone does. And only in step one does my computer ever connect to Gmail, the SSL connection would be negotiated between myself and the victim (it's more to make them feel secure than to serve a true purpose).
    – KnightOfNi
    Commented Jan 19, 2014 at 3:33

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .