No 0day Necessary - Bank SSL

Posted by: Mike Kemp | Posted on: 2016-01-04 00:00:00 +0000

In November last year we examined Cross Domain Policy issues within the Top 500 Internet applications in the United Kingdom (according to Alexa). Following this research we decided to turn our attentions to specific sectors that may be most at risk from attackers in the UK and low skilled attacks that could be utilised. One particular area of focus was the UK finance industry. The UK finance industry is one of the largest in the world, and so the logic follows should be one of the most robust from a security perspective. Sadly, our findings seem to contradict this.

For the purposes of this research we decided to focus on the websites (particularly the secure customer login components) associated with high street banks and building societies. We focused our attentions not just on British owned retail banks, but also upon those associated with foreign companies operating at a high street level within the UK. What we discovered was highly concerning from a security perspective.

It should be noted before we continue that this research is by no means a new thing. In May of 2015, noted security researcher Troy Hunt examined the security of the Secure Sockets Layer (SSL) certificates associated with Australian banking institutions. This was followed in August this year by an examination of the state of SSL certificate security pertaining to select Scottish financial institutions by developer and engineer, Bryan MacMillan. Taking an interest in SSL and financial institutions is not new and thanks to the SSLLabs service provided by Qualys is a trivial task. It is however revealing. With this research we wanted to focus upon high street banks and building societies within the United Kingdom and their implementations of SSL certificates particularly as pertaining to their security authentication mechanisms. It was our expectation that the majority would be secure (after all finance is a risk averse sector from a security perspective). Sadly this was not the case.

To conduct this research we examined the SSL certificate instances associated with the secure login functions for a variety of UK based financial institutions. This was done by anonymously submitting associated URLs to the SSLLabs service from Qualys. It should be noted that no invasive testing was performed to obtain the results of this research, and that no additional actions other than enumeration of weaknesses within certificate instances were engaged in. Without further ado here is what we found:

  • Of the 22 UK owned retail banks we examined, 50% were found to have insecure SSL instances.
  • Of the 25 Foreign owned retail banks operating in the UK we examined, 79% were found to have insecure SSL instances.
  • Of the 37 UK building societies we examined, 51% were found to have insecure instances.

Of the 84 SSL instances included as part of this research, 12 of them (or 14%) were rated by SSLLabs as F (the worst possible score they could have had).

That’s actually shockingly bad, when you consider that what we were concerned with was not the generic customer facing Internet sites associated with financial institutions but the URL instances associated with their login functions. So what do we mean when we say insecure?

POODLE

A number (8) of the authentication URLs associated with UK financial institutions were found to be impacted by the POODLE (Padding Oracle on Downgraded Legacy Encryption) vulnerability found by the Google security team in October 2014. This is a Man in The Middle vulnerability (meaning an attack would have to be interjected between the client browser and impacted bank servers) whereby the encryption of SSL is downgraded allowing for potential manipulation and interception of secure encrypted data in transit. This is a vulnerability about which there was much press coverage, and is over a year old (as of the time of writing) and one that in all likelihood would not be expected to be seen on sensitive client facing systems in the wild, albeit only on 9.5% of assessed SSL certificate instances.

CRIME

Xiphos found that of the SSL certificate instances, four (or 4.7%) were vulnerable to the CRIME attack. The CRIME vulnerability was first disclosed by researchers Juliano Rizzo and Thai Duong at the Ekoparty security conference in 2012. The CRIME vulnerability is a general attack that works against a number of SSL protocols. It is a security exploit that can allow an attacker to intercept secret web cookie instances over connections that use HTTPS and SPDY protocols that use data compression. If an attacker can successfully use this exploit to recover secure session authentication cookies they can potentially perform session hijacking of legitimate user sessions thus allowing them to take full control of data sets that are transmitted and received.

SSL Version 3

During the course of this research it was found that 9 SSL instances (10.7%) were operating using version 3 of the SSL protocol. Initially created by Netscape SSL is a cryptographic protocol stack to provide encrypted communications. Version 3 of SSL was officially deprecated as of December 2014 owing to the POODLE attack and the potential for an attacker to downgrade the encryption in use thus potentially jeopardising the security of encrypted communications in transit. It was recommended that when POODLE emerged that SSL version 3 be disabled on all public facing sensitive hosts and replaced with the most recent iteration of the more secure TLS protocol. In over 10% of the certificate instances assessed as part of this research, this has not been the case.

SHA1 Deprecated Hashing Function

Of the certificate instances assessed for this research, 36 (or 36% of all certificates) were found to be operating certificate instances that presently utilise SHA1 hashing functions. Originally developed by the NSA SHA1 is a cryptographic hash function for the purposes of acting as a message digest in relation to cryptography. Without delving into the inner works of the cryptographic arts, hash functions are those that obscure the encrypted data you wish to protect from prying eyes. The first cracks in SHA1 appeared over 10 years ago, and in 2013 Microsoft announced that it would not be accepting SHA1 certificates after 2016. Google stated as of September 2014 that it would be penalising sites that utilised SHA1 certificates that expire during or after 2016. Because of these changes it is thus necessary to ensure that certificates utilise SHA256 and thus avoid browser errors.

TLS 1.2 Unsupported

TLS (Transport Layer Security) is the successor for SSL and was first introduced in 1999. In April 2015 the PCI Council announced that no new secure applications (that accept or transact payments) should utilise older versions of the TLS protocol (the later iteration TLS 1.2 was released as of 2008). In 26 certificate instances (30.9%) Xiphos found that TLS 1.2 was unsupported. Both the BEAST and Lucky 13 attacks can impact on those sites that operate using TLS 1 in combination with RC4 and those sites that handle sensitive data should be moving away from deprecated and unsupported technical stacks.

RC4 Supported

The Rivest Cipher 4 (more commonly known as RC4) is a stream cipher used in cryptography. Again, without getting too involved in a cryptographic overview, RC4 is a cipher suite that allows for the encryption of plaintext digits that make up an encrypted communication stream. Attacks against the RC4 cipher have theoretically been possible for a number of years and when combined with older protocols such as TLS 1 it may be possible to degrade or negatively impact upon the security of data in transit (most notably the Lucky 13 attack detailed elsewhere in this post). The standard recommendation is that secure sites implement TLS 1.2 with the GCM cipher suites. Of the SSL certificate instances assessed as part of this research, 35 (or 41.6%) were found to support the RC4 cipher.

Contacting Banks

As part of this research cycle, we have attempted to reach out to affected banks and financial institutions. This has not been an easy task to accomplish. All the affected organisations do not have generic security contacts and sadly many public facing call centres are ill equipped to provide details. Faced with growing frustration, we reached out to the Financial Conduct Authority (on the 15th December 2015) which is meant to regulate financial institutions in the UK to share the results of this research, so they could share it with their members (and impacted parties). Unfortunately the FCA was unable to provide us with details of individuals (or generic email addresses) to report security concerns to because of “security reasons”. As a result, we have not been able as of the date of publication to contact any of the affected organisations – which is a concern in and of itself. That said we reached out to the UK National Crime Agency on the 18th of December 2015, so hopefully by this point, all relevant parties have been informed.

To conclude...

As things stand, over 50% of banks and building societies in the UK have weak SSL implementations associated with their secure login functions. And the impacted parties don’t seem to care. We have attempted to reach out to the FCA and as of the date of this article have yet to be contacted by anyone other than first line customer services staff. We have attempted to contact a number of the affected banks and building societies and not been able to surmount customer services. We have however passed details of our findings and the organisations they impact upon to the National Crime Agency (NCA) in the UK. As a result, we will not be publishing who is impacted (yet). This research was conducted in November 2015, and it is now January 2016 and we have attempted to reach out numerous times to numerous organisations. Until we have confirmation from third parties that they are mitigating the risks presented in this article, we can’t in good faith publish anything other than anonymised statistics (which as a science based organisation that prefers to present tangible proofs is highly irksome). It might not be the most PR friendly way to approach this (and one that has caused a number of sleepless nights as these findings are deeply concerning and have significant public interest) but it is perhaps the most reasonable and reasoned.

About the Author

Mike Kemp is the co-founder of Xiphos Research, which technically means he has to write things like this, and is increasingly familiar with discussing himself in the third person.