When it comes to online banking, sub-optimal encryption isn't our biggest concern

Posted by   Virus Bulletin on   Jan 6, 2016

Malware authors and scammers won't attack the crypto.

Under the headline "no zero-day necessary", Xiphos has published a rather scary blog post on the state of SSL security within the UK's finance industry. It concludes that more than 50% of UK-owned retail banks have weak SSL implementations on their online banking sites, with 14% of them getting the lowest grade on Qualys's SSLLabs service.

This isn't good. Banking is largely based on trust, and getting IT security right should play an important role in being trusted. But we should be careful not to confuse sub-optimal security with a likelihood of this leading to actual attacks.

Of the vulnerabilities Xiphos mentions, CRIME and POODLE are the most serious. They make it easy for an attacker with a man-in-the-middle position to steal secure session cookies, thus allowing them to hijack a browsing session. This simply should not be possible on a site where people manage their finances.

However, cybercriminals rarely use man-in-the-middle attacks. For them, the fact that they often don't scale well and can't be performed remotely, makes such attacks rather uninteresting. Moreover, most banks mitigate session-hijacking attacks by requiring the user to authenticate transactions through a second channel. Hence it isn't surprising that there have been no known instances of CRIME or POODLE having been used in the wild.

The other weaknesses mentioned, such as the support for RC4, the lack of support for TLS 1.2 and the use of SHA-1 certificates, can only be abused in a purely theoretical setting (in the case of RC4), or not at all.

Interestingly, the blog post doesn't mention the fact that many banks — including the four main UK retail banks — don't use HTTPS by default on their main site. Given that this is how many users browse to their online banking service, an attacker with a man-in-the-middle position, or malware running on the user's system, could trivially modify the link to a site they control. After all, no encryption is infinitely worse than sub-optimal encryption.

Still, this isn't the thing users should be most concerned about. It would be far better if they concerned themselves with becoming more aware of the various ways in which malware and scams try to steal their money — none of which attack the encryption protocols the bank uses.

It is good to hold banks accountable when it comes to security on their websites. But we have to be realistic about where the actual risks are. They are not in the crypto.

In March, I will give a talk, "How Broken Is Our Crypto Really?", on this subject at the RSA Conference in San Francisco.

Posted on 06 January 2016 by Martijn Grooten

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2020 localhost call for last minute papers: a unique opportunity

Why VB2020 localhost presents a unique opportunity for you to share your research with security experts around the globe.

VB2020 localhost call for last-minute papers now open!

The call for last-minute papers for VB2020 localhost is now open. Submit before 17 August to have your paper considered for one of the nine slots reserved for 'hot' research!

Announcing... VB2020 localhost

Announcing VB2020 localhost: the carbon neutral, budget neutral VB conference!

VB2019 paper: APT cases exploiting vulnerabilities in region-specific software

At VB2019, JPCERT/CC's Shusei Tomonaga and Tomoaki Tani presented a paper on attacks that exploit vulnerabilities in software used only in Japan, using malware that is unique to Japan. Today we publish both their paper and the recording of their…

New paper: Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

In a follow-up to a paper presented at VB2019, Prismo Systems researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting (XSS), and server‑side request…

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.