DNS hijacking/poisoning effect on URL/URI and password manager autotype/autofill

Question

A benefit to password managers, at least some of them, is that they can look at the URL and only use autotype/autofill when on the correct site, which can help prevent pharming since if instead of https://www.example.com/ you go to examp1e dot com it won't autofill your credentials. What I want to know, and can't find anywhere, is whether DNS hijacking or poisoning, when taking you to a different site, will show to the browser, the user, and the password manager as the site you meant to go to or the fake one. That is, if you actually type example.com, and the browser thinks you're going to example.com because it's following the malicious DNS to maliciouswebsite dot com, does it show where it thinks you are or is it somehow able to resolve the actual URL and show that? I realize this is a very unlikely possibility, but I'm curious if the password manager would try to autofill on the malicious site because instead of example.com being resolved as x.x.x.x it's resolved as y.y.y.y, but as far as the browser and password manager know it's still example.com, or if it would go to y.y.y.y but since the actual URL for that is maliciouswebsite dot com that's what would ultimately be shown.

As a secondary, related question, if a public wifi router has been compromised for DNS poisoning, how and when does this affect your device when connecting to it, i.e. poisoning your DNS cache? Does it happen immediately upon connecting, or only for each query/entry as it's made?

Answer 1

If DNS is compromised in your location (i.e. DNS server changed to a malicious one like in DNSChanger malware or using DNS spoofing) then it can lead to visiting the wrong sites with the right name. Password managers cannot detect this.

But, today websites are usually on HTTPS and this is especially true when passwords need to be entered. HTTPS protects against this kind of attack - see Why doesn't DNS spoofing work against HTTPS sites?.

Answer 2

[Disclosure: I work for 1Password]

The scenario you describe isn't specific to password managers. If a bogus site can successfully pass itself off as example.com then people entering passwords on that site can be tricked into giving secrets to that bogus site. But in general, it is a lot harder to fool a password manager than it is to fool a human.

As Steffen Ullrich correctly pointed out that if your system (browser in conjunction with your operating system) can't tell that the site you are talking to isn't the legitimate example.com then the password manager can't either. He correctly added that an important part of what TLS does is provide ways for the system to not be fooled by mere DNS trickery or malicious network routing. Quite simply it is really important to pay attention to browser warnings about site certifications or insecure sites.

Quite simply the specific attack you describe is no longer a thing. But it does raise some points about password managers.

Disable automatic autofill

Ideally, a password manager should require some human action before filling a site. If a password manager silently fills pages without user approval, then a site that does manage to fool the password manager could capture credentials without the user being aware of it. This threat has been known and document for decades, but many password managers only recently started to require human action. If you are using a password manager that does silent automatic autofill turn that "feature" off. (I will add that 1Password never offered automatic autofill. A human must always be in the loop before 1Password will give a password to a web page.)

Defending against HTTP downgrade

One attack that was quite popular for a time was SSLstripping. When you go to https://example.com you have the assurances provided by TLS and the Certificate Authority system that it really is run by the bona fide owners of example.com. But when you go to http://example.com (without the S of HTTS) you are subject to the kinds of attacks you describe in the question.

For many years most password managers would happily serve up passwords you had stored for https://example.com to http://example.com. That is password managers treated passwords you saved for example.com as being for example.com irrespective of whether these were HTTP or HTTPS. That was a misdesign.

Good password managers today will not do that. If you have a password saved for https://example.com they will no longer fill those passwords into http://example.com, or at least they won't do so without warning you and seeking your explicit approval to do so. Additionally, browsers (and web standards) have improved to make that kind of attack harder to go undetected.

Anyway, these sorts of threats have been known to the designers of password managers for a very long time. There are (or at least there were) differences in how aggressively password managers defend against them.