Phishing, Pharming, Social Engineering

Not all methods of attack are primarily of a technical nature. Human beings, the users, represent a key weak point, too.

What’s the security problem with classic phishing? The user trusts an email that looks similar to his bank's home page. He clicks on a link and then ends up on a site that also looks deceptively similar to that of his bank. This website is “authenticated” merely by the way it looks to the user, and, based on his experience in “real life”, the user trusts that this site is “real” (authentic).

The majority of banks have since informed their users that they never send links in emails and that the user should always use the familiar URL or his bookmark to log in to e- banking. Unfortunately, this doesn’t suffice; the user can also be lured to a different website by other means.

In the case of pharming, the user enters in the browser the correct URL of his bank, but is connected not with his bank’s server, but with the attacker’s server. This can happen if an attack has previously been carried out on the Internet infrastructure on the levels of DNS and / or routing protocols. In this instance, the user hasn’t done anything wrong.

To protect against such attacks, all websites that contain sensitive data use SSL. First, this encrypts the data, second, the server is cryptographically authenticated. This is usually shown in the browser by means of a small locked padlock. However, checking the authenticity of the web server has several weak points.

Weak point 1

One weak point being the user himself. He must check whether the address of his bank really is located in the URL line. With just a fleeting glimpse, http://www.yourbank.com.cc/ can be interpreted as the correct URL. The new umlaut domains don’t make the user’s life any easier either. With the possibility of using other character sets, you can now incorporate umlauts in the URL. However, for example you can also use the letter “a” from the Russian alphabet in a URL in the place of letter “a” from the German alphabet. This appears to be the same for the user, but, for the computer these are two different domains.

Once the user has checked the correctness of the URL, it’s the computer’s turn. If an error is established when checking the SSL certificate, the user is warned by the browser. But many users simply ignore such warnings and click them away.

Weak point 2

Secondly, the security is based on ensuring that all certification authorities that are recorded in the browser are also trustworthy and working correctly. In the past, this assumption hasn’t always been fulfilled by all certification authorities.

Weak point 3

A third potential problem is posed by cryptography. Significant weak points have been found in the hash functions MD5 and SHA-1, which are used to generate SSL certificates. You can no longer exclude the fact that “real” certificates can be generated by a malicious attacker. SSL is then no longer secure in cases of man-in-the-middle attacks.

So, in the end, all that remains is for the user to check the cryptographic encoding of the web server of the bank. This assumes that the bank informs the user via an independent channel and that the user then checks this each time. This would be too much effort for at least 95 percent of users.

Another method of accessing the PIN and TAN number of the user is by means of so-called trojan horses, which work as key logger; in doing so all the user’s entries are logged and sent to the attacker. A trojan that’s running locally on the PC of the user can log and also change all the entries of the user. The new generation of trojans can even change the recipient’s account data that’s actually entered in the online banking system of the victim, and disguise this manipulation with the real data by using a popup window on the correct position.

The simplest way for the user to protect himself against this is to carry out online banking and other sensitive transactions from his own independent PC. This doesn’t have to be a second computer; it suffices if the computer for these actions is booted by a non-infected medium, like, for example, a CD-based Linux distribution like KNOPPIX.

The phishing problem is essentially an authentication problem of the legitimate web server in view of the user. The user thinks he is communicating directly with his bank’s server, but is sending his entries to the attacker’s server. Defense must be the priority point here. The user must be trained. If the user is appropriately security aware, then he will be more prepared to consider the value of certain annoyances like booting from a CD for online banking.

iTAN

The big response of German banks to phishing was iTAN. With this, the user no longer uses any TAN from his list, he must use the random TAN “indicated” by the web server of the bank. The idea is that an attacker can’t do anything with an intercepted TAN, as a different TAN will be required for the next transaction.

Unfortunately, this just conveys a misguided feeling of security. First of all, there are often two access paths to online banking like HBCI+ (with PIN/TAN), which function with each TAN.

And, secondly, the iTAN doesn’t work with so-called man-in-the-middle attacks. In this case, the attacker acts as a kind of proxy between the bank and the customer and then passes on all the entries. It’s only when the user carries out a transfer that the amount and destination account are changed.

mTAN

The mTAN procedure is a truly elegant and functioning solution. After entering the transfer data on the bank’s website, a special TAN is generated for this very transfer; this is then sent by SMS to a mobile telephone number that has been previously set up by the account holder. Alongside the TAN, this SMS lists again the most important transfer data like the account number of the recipient and the amount of the transfer. The TAN generated is valid only for this transfer. If the user checks this data, he can be sure that even in the case of man-in-the- middle attacks, the money isn’t going to end up in the attacker’s account. Unfortunately, the banks have to charge an extra fee for this SMS, so this makes it difficult for the customer to decide.

HBCI

Another good solution is HBCI, under the assumption that the procedure is used with a chip card and a secure chip card reader. The problem of authenticating the bank in view of the user is transferred to technical levels. In this case, the HBCI client undertakes the task of checking the authenticity of the bank. Unfortunately, HBCI also has disadvantages: A special software and a chip card reader are used. This way, online banking can only be carried out from the computer at home.

A further option on the operator’s side is to quickly detect phishing and then immediately initiate targeted countermeasures. After successfully accessing the data, many phishing sites refer you back to the original site of the bank so that the user doesn’t suspect anything. This is where the website operator can intervene and assess the HTTP referer that has been sent by the browser and warn the user that he has come either from an already known phishing site or at least from a site that doesn’t belong to the bank. The user is then warned and can, for example, contact the bank by telephone and have the previously specified TANs blocked. vWAF also offers support here (refer to Anti Phishing Wizard).