Last week, there was large scale cyber attack on Polish internet users that specifically targeted online banking activities. By modifying the DNS settings on victim's routers, the attackers were able to redirect users to malicious servers and intercept online banking traffic to modify and steal it during transit. This resulted in account credentials being compromised and potentially huge losses for those involved. Whilst vigilance is required from the user, it's possible to mitigate this kind of attack on a considerable scale with a single line of code. The HSTS header.
The Attack
CERT Polska published their findings just last week. Malicious attackers modified the DNS server settings of victim's routers allowing them to take control of their internet traffic, the same vulnerability I disclosed on the EE BrightBox a few weeks ago. By controlling the DNS servers used by the victims, the attackers can change the IP address that a host name resolves to. When the victims entered the web address of their bank, instead of being resolved to the IP address of the bank's server, the malicious DNS server would resolve it to a server controlled by the attacker. This server would then fetch genuine content from the bank on behalf of the user and serve it to them via HTTP. To the untrained eye, everything would appear to be working as normal. You could login, carry out your business and log out without interruption. To the trained eye, what was happening was a disaster.
The malicious server had to serve traffic to the victim over HTTP to avoid any nasty SSL warnings. This is the first clue that victims had that something was wrong. To try and get around this and offer some false sense of security, the attackers were forwarding traffic to the user with a sub-domain pre-pended to the address, 'ssl-'. This meant that if the user did check the address bar, they would see something like ssl-.mybank.com, which seems to have been enough to fool most despite it being served over HTTP.
Mitigating The Attack
Fortunately, there is an opportunity to mitigate attacks like this on a large scale with nothing more than a single line of code, all thanks to HSTS. You can read my previous blog about HSTS for the details, but simply put, it provides the ability to tell the browser that a site only ever wants to use SSL/TLS to communicate. As long as the browser is compliant, HSTS will completely mitigate attacks like this and here's why;
The first part of the attack is to take control of the victim's DNS configuration and force them to resolve host names with a malicious DNS server. This malicious DNS server will resolve the host name to the IP address of a server controlled by the attacker. When the browser tries to communicate with the IP address provided, the HSTS policy will force it to establish communications via HTTPS, even if the user specifically stated HTTP or used a link/bookmark that stated HTTP. In normal circumstances, without HSTS, the browser would default to HTTP if no protocol was specified or continue on happily using HTTP if the bookmark or link so specified. With HSTS however, it's a different story. When the browser attempts to establish secure communications with the malicious server, there are only 2 possibilities. The most likely is that the server doesn't even answer on port 443 because the attackers have no use for it. This results in a failed connection for the user and no information can be compromised. If the server does respond on port 443, the browser will then begin it's standard routine of verifying the certificate provided by the server. Does the certificate bear the host name we were expecting? Possibly, yes it could. Is the certificate signed by a trusted root authority? No. That's the end of that then. Whilst HSTS hasn't directly resolved the issue of your DNS configuration being hijacked, by forcing the use of HTTPS on the client side, you can prevent attackers spoofing your host name because there is no valid SSL certificate present. All the server side redirects in the world wouldn't help prevent this attack because the victim has no knowledge of whether or not they are supposed to be using HTTPS and would most likely connect using HTTP. That's exactly the issue that HSTS addresses.
Conclusion
Attacks like this go to show just how costly it is when organisations don't keep up to date with the latest security threats and how to mitigate them. SSL stripping attacks have been around for years, literally. Moxie Marlinspike first demonstrated his SSLstrip tool in 2009 and whilst it might not have been used here, the concept is exactly the same. The specification for HSTS was officially published in 2012 and since then has been available for sites to mitigate attacks such as this. Not only that, but this also goes to show how much the end user still doesn't take the most basic of security precautions like checking the URL and checking for HTTPS when browsing the most sensitive sites like online banking. Furthermore, users need to ensure they are using a modern and updated browser to get features like HSTS. Main stream banks and financial organisations can even go one step further and request that their host names are added to the pre-loaded HSTS lists found in browsers like Google Chrome and Firefox. For an attack of such a huge scale with such serious consequences, it could have been dealt a crushing blow with just a few keystrokes.
The following line of code from my nginx configuration would have mitigated this attack for any user using a modern, updated browser that is HSTS compliant:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";