4

I just finished reading a Wired article about a DNS hijack where the attackers redirected all bank traffic to servers they hosted on Google Cloud. What I thought was interesting about the story is that they redirected to valid HTTPS websites with certificates for some legitimacy:

But the Brazilian bank attackers exploited their victim’s DNS in a more focused and profit-driven way. Kaspersky believes the attackers compromised the bank’s account at Registro.br. That’s the domain registration service of NIC.br, the registrar for sites ending in the Brazilian .br top-level domain, which they say also managed the DNS for the bank. With that access, the researchers believe, the attackers were able to change the registration simultaneously for all of the bank’s domains, redirecting them to servers the attackers had set up on Google’s Cloud Platform.2

With that domain hijacking in place, anyone visiting the bank’s website URLs were redirected to lookalike sites. And those sites even had valid HTTPS certificates issued in the name of the bank, so that visitors’ browsers would show a green lock and the bank’s name, just as they would with the real sites. Kaspersky found that the certificates had been issued six months earlier by Let’s Encrypt, the non-profit certificate authority that’s made obtaining an HTTPS certificate easier in the hopes of increasing HTTPS adoption.

My question is how did they do that, if you attempt access a website using https then can an attacker who controls the DNS for the hostname redirect your request to another https website without any certificate warning? For example if I type in to my browser https://www.santanderbank.com and an attacker has taken over that DNS, can they redirect that to a valid https://www.santanderb4nk.com without the browser warning me? Assume the attacker has the certificate to www.santanderb4nk.com but does not have the certificate to www.santanderbank.com.

1
  • 3
    I wonder how the bank name could be displayed next to the browser lock, given the certificates were issued via Let's Encrypt. AFAIK Let's Encrypt does not deliver EV certificates - what am I missing here ?
    – niilzon
    Apr 5, 2017 at 10:45

3 Answers 3

1

This type of attack is not new and can simply occur from something as simple as the use of a bad password with a DNS registrar and no two-factor authentication in place. It's also important to note this is DNS redirection and not https redirection.

In a nutshell, there are two parts to this attack.

  1. Setting up look-alike website with valid https.
  2. Accessing the bank's DNS registrar account to redirect their traffic.

Note: a similar scenario could also occur if an attacker can compromise the bank's DNS servers, replacing access to the DNS registar in step 2.

Looking a little closer at Step 1 above when someone sets up a fake website they typically aim to mirror 3 things:

1A.) The look and feel of the site (easy to just download the real Html and images from the bank's real website and change the form entries to do what you want). It will be identical to what users are used to seeing and requiring almost no work on the attackers part. Note: If registering a look-a-like domain name first the attackers will likely make it look like a new bank getting a website up until the moment they launch their attack at which point they switch everything to the look-a-like site.

1B.) Optionally they can register a similar domain name. This isn't actually required at all for the attack you mentioned and since so few people look closely at their browser if SSL is established (showing green) almost any domain name would work but you could easily get a similar looking name if needed.

1C.) Register an SSL/TLS certificate for whichever domain is used in step 1B above. Again it could be for a website for notabank.com and that's a legitimate domain name to request an SSL/TLS certificate for. Alternatively, and as was the case in the situation you describe, they can simply use Lets Encrypt.

2.) For accessing the DNS registrar's account similar attacks have occurred against companies that simply used a bad password (or their companies name as the password). That being the case a simple set of brute-force attempts would give someone access to this account. Similarly, this could have been compromised by finding similar passwords used by the administrator of the bank's DNS either on another system or via a public password dump from when passwords were lost at another site. There are lots of ways someone could have lost a password here. Given most DNS registrars don't require mandatory two-factor authentication in a lot of cases just having the username and password is all one needs to access this account.

Once logged into the DNS registrar's site as the target account the attackers can literally change the DNS settings for www.bank.com to ANY IP ADDRESS IN THE WORLD. So naturally, they point it to the fake banking websites they created in step 1 above and start harvesting credentials.

If credentials are all they want they can easily grab these as people try to log in and use them to gain access to accounts one by one. More elaborate attackers or attacks against sites which implement two-factor authentication will allow the attacker to authenticate via a proxy running on the fake site which redirects the use of the logout function to a fake exit page. This allows an attacker to be authenticated by the user, including use of the end users two-factor authentication system, then gives them access to the account as soon as the unsuspecting client chooses to log out. This is more work for the attacker but it can get the attacker past two-factor authentication requirements and also will go on longer before being reported where in the case of just grabbing credentials it may appear to users that the banks' website is not working (and likely to get reported faster).

I'll also mention that there are systems in place at many banks to help detect this type of fraudulent activity and typically as soon as multiple users start authenticating from a single IP address that may warrant a security check to see if this type of attack is occurring and then action will be taken by the banks security teams to contact the ISP hosting the fraudulent site to get it taken down.

There are LOTS of other similar scenarios but this is typically how it works.

In regard to the Certificate warning. If I type www.bank.com and I get redirected to a valid website using a valid certificate why would I get any warning? Think of it as if I meant to go to www.bank.com but my browser redirected me to https://security.stackexchange.com when the browser loads the new site all it's checking for is certificate validation on the new site. The browser has no knowledge of your intentions to visit www.bank.com so if the user isn't checking the URL in the browser either bad things can happen. You can play with this yourself by setting a line in your /etc/host file (or it's equivalent) so that www.bank.com resolves to the IP of anything you want and get the same effect locally.

3
  • Thanks but can you clear this up about the IP address. If I put a line in my hosts file to resolve foobar.com to the ip address of test.com for example then when I go to foobar.com it blocks it and says "The certificate is only valid for the following names: www.test.com, test.com". So it does warn me. And what I would like to know is, is it possible that can happen without warning me?
    – newguy
    Apr 22, 2017 at 4:24
  • The redirection has to go to the non-https site first. I'm assuming the attacker also has HSTS enabled which will effectively redirect the connection to the HTTPS website. Doing it this way will produce no warning. The line in your hosts file will work (I just verified this again against two sites that have EV certificates and HSTS enabled) but you need to have the browser request www.bank.com (port 80) and not https www.bank.com (port 443) explicitly for this to work. HSTS will redirect the browser instantly, show no errors, and show the certs validity. Apr 22, 2017 at 4:49
  • but you need to have the browser request www.bank.com (port 80) But if HSTS is enabled on bank.com, then it will not use http, but will use only https. So HSTS protects against this attack?
    – Alex78191
    Sep 14, 2022 at 7:39
3

For example if I type in to my browser https://www.santanderbank.com and an attacker has taken over that DNS, can they redirect that to a valid https://www.santanderb4nk.com without the browser warning me? Assume the attacker has the certificate to www.santanderb4nk.com but does not have the certificate to www.santanderbank.com.

For a redirection a HTTP request has to be made which results in a redirect response (i.e. HTTP response code 302 or similar and a Location header). When redirecting away from a HTTPS site to some other site the browser first has to make a successful TLS connection to the original site in order to send the HTTP request and get the HTTP response which contains the redirection. To make a successful TLS connection the certificate for this original site needs to be valid, i.e. signed by a trusted CA and matching the name of the site as visible in the URL (i.e. DNS CNAME attacks will not help).

This means the scenario you describe, where the attacker does not have a valid certificate for the original site, will usually result in a warning inside the browser. But the attack might work silently if the user is using some SSL intercepting software (like certain Antivirus or Adware) which does not properly validate certificates, as described in this paper.

But I think the Wired article describes a different scenario, in which the attacker successfully got valid certificates for the real domains. In this case no warnings will occur since the browser usually does not care which CA issued a certificate as long as the CA is trusted. HPKP can help against this kind of attack.

2

My question is how did they do that, if you attempt access a website using https then can an attacker who controls the DNS for the hostname redirect your request to another https website without any certificate warning? ... Assume the attacker has the certificate to www.santanderb4nk.com but does not have the certificate to www.santanderbank.com.

That sounds like an incorrect assumption, from my reading. Here's what I got:

Servers do not naturally belong to a website domain. They have IP addresses that point to them, and if you visit them they can optionally return a website. DNS is merely a pointer to an IP address.

If the attackers changed the IP addresses in the bank's DNS records, then their servers are now "the site".

One of the two ways Let's Encrypt validates ownership of a domain is by querying for a requested DNS record. If the attackers had control of the bank's DNS, then they could add the record, and as far as Let's Encrypt could tell, they were the official owners of the domain. So they were issued a certificate for www.santanderbank.com.

You must log in to answer this question.

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