In late 2013 CERT Polska received confirmed reports about modifications in e-banking websites observed on… iPhones. Users were presented with messages about alleged changes in account numbers that required confirmation with mTANs. This behavior would suggest that some Zeus-like trojan had been ported to iOS. As this would be the first confirmed case of such malware targeting the platform, and at the same time it targeted Polish e-banking users, it immediately attracted our attention. Internally we have come up with several scenarios of how it might have happened, but unfortunately were not able to gather enough first-hand data about the case to rule out any options.
The key to the riddle was in recent reports about vulnerabilities in home routers allowing attackers to remotely modify their configuration. After DNS servers settings are changed on a router, all queries from inside the network are forwarded to rogue servers. Obviously the platform of a client device is not an issue, as there is no need for the attackers to install any malicious software at all. How was the webpage content altered, then?
First, let’s understand the implications of DNS hijacking. The most obvious consequence is invasion of privacy, as miscreants can profile users based on DNS queries they make. However, this is just where the problem begins. Being in control of DNS serves, criminals can send arbitrary IP addresses in response, effectively redirecting traffic to hosts under their control. This is called a man-in-the-middle attack.
What does the attack look like?
It looks like criminals are primarily targeting e-banking users as they modify DNS responses for several banking domains, while resolving other domain names normally. As a result traffic to banks’ sites is routed through a layer of servers under criminals’ control, where the content is transparently modified with javascript injects well-known from popular banking trojans. Now this is where some of you might wonder “Isn’t it exactly what SSL should protect me from?” Indeed, it should, and it does. Well, to some extent…
| (1). Router requests IP address of bank’s website. Gets bank’s server’s address in reponse. (2). User connects to bank’s server. |
(1). Router requests IP address of bank’s website. Gets malicious server’s address in response. (2). User connects to malicious server. (3). Malicious server connects to bank’s server. |
Pic. 1. Flow of requests when visiting a banking site in normal conditions (left) and with man-in-the-middle attack (right)
Many users start their visit at e-banking service with bank’s home page, where they would normally click a button labelled “Sign In” or something along these lines. And while the target sign-in form is (as you would expect) SSL-encrypted, the home page is not. While criminals intercept the unencrypted request, they simply modify links to clear HTTP, adding “ssl-.“ string to hostname, apparently in an attempt to fool casual users (Note that the nonexistent ssl-. hostnames would only be resolved by malicious DNS servers.) While the connection is proxied through malicious servers, SSL is terminated before it reaches the user. Decrypted content is then modified and sent unencrypted to the customer. From the user’s perspective everything looks like a normal e-banking session, the only difference being the unusual hostname appearing at some point and lack of HTTPS indicators. In other words, users’ ability to recognize the fraud depends on his/her vigilance in spotting that an apparently legit bank website redirects to a phishy URL.
Users who have bookmarked (or typed directly) the SSL-encrypted sign-in page are in a better position. While their request would also be hijacked, the criminals are obviously not able to produce the proper SSL certificate. In cases we have seen, they produced a self-signed certificate for thawte.com domain, which causes a browser to complain about both domain name mismatch and lack of a trusted CA in the certificate chain. This should be a clear indicator of the fraud for most users.
To wrap up: the attack is possible due to several vulnerabilities in home routers that make DNS configuration susceptible to unauthorized remote modifications. The effects propagate to all users in local networks, regardless of hardware and system platform (provided they acquire DNS configuration from the router). In the resulting man-in-the-middle attack content of several e-banking websites is altered to include javascript injects that tricked users into giving up their usernames, passwords and TANs. Effectively, money is stolen from users’ bank accounts. While it is not possible for criminals to maintain SSL integrity throughout the session, several tricks are applied to lure users into clear HTTP connection to malicious servers. The attack can be spotted if users pay attention to the browser’s address bar and HTTPS indicators at all time.
How to tell if I’m affected?
The problem applies to users connecting to the Internet from local networks behind local routers. The most reliable way to verify whether your device is affected is to manually check DNS servers in the configuration. They should normally be acquired dynamically (with DHCP) from your provider or statically set to addresses known by you. You will find instructions about accessing your router’s configuration in the user’s manual.
An easier, but less reliable way is to check whether banks’ domain names are resolving to their proper IP addresses. Below is a list of domain names, addresses of which were confirmed to be spoofed in the attack, and their respective proper IPs. The list, however, is not definitive, as the attackers may change the set of domains affected at any time.
| mbank.pl |
<span class="text">193.41.230.73</span> |
| moj.multibank.pl |
<span class="text">193.41.230.82</span> |
| aliorbank.pl |
<span class="text">195.182.52.101</span> |
| ebgz.pl |
<span class="text">193.108.194.32</span> |
| kb24.pl |
<span class="text">195.20.110.163</span> |
In order to check how the names are resolved you may issue the following command in Windows command line or Linux terminal:
, eg:
1 | nslookup mbank.pl |
To open the command line in Windows, press Start and type
in search windows, then press Enter.
For a chosen name (1) the IP address (2) should be the same as in the table above. A mismatch (together with IP addresses) >>can be reported to us<<.
Orange Polska has created an online tool to check whether a router is vulnerable to the attack.
How to protect against the attack?
This particular attack (in contrast to ones where banking trojans are applied) can be spotted if users pay attention to the browser’s address bar and HTTPS indicators at all time.
In order to protect a home routers from the attack, any type of remote administration access from the Internet should be disabled. Default usernames and passwords should be changed to unique ones, not revealed publicly. Consult the router’s user manual for instructions.
Users should consider updating their routers’ software and firmware is possible. It should be noted that routers do not perform automatic updates, so the process requires appropriate patches to be manually downloaded and installed. Consult the router’s user manual for instructions.
Eventually, static DNS settings may be used in order to avoid propagation of malicious DNS settings from a router.
What should I do when I’m affected?
First of all, we kindly ask you to let us know about it (http://www.cert.pl/kontakt) – the information is invaluable in our research and operations. If the contact is not possible, we suggest reverting the router to its factory settings. Then, follow instruction from the paragraph “How to protect against the attack?”
