The banking industry is having a Meltdown over Spectre

Recently, the cyber security industry's attention was turned to two critical vulnerabilities discovered in Intel and other Central Processing Units (CPU). These vulnerabilities are being referred to as Meltdown and Spectre and have affected a number of computer processors around the world – namely those running versions of iOS, Linux, macOS and Windows – including devices used in the banking industry, and those very commonly utilised mobile banking applications. Despite having been paired together, the vulnerabilities can be distinguished from one another. Meltdown affects Intel whilst Spectre has the ability to affect Intel, ARM, and AMD. The vulnerabilities are also different in their methods. Whilst both use speculative execution, Meltdown additionally uses Intel privilege escalation, whereas Spectre uses branch prediction, and is much less likely to be reasonably patchable.

The patching efforts for Meltdown and Spectre have been inconsistent, and in the case of Spectre, what many in the security community are referring to as a dumpster fire. Meltdown patch availability has seen significant progress made, while Spectre remains a major issue. Intel for example, recently pulled-back their patches for Spectre.

The risks of the vulnerabilities

With regards to banking implications, it is likely that the main effects for the banking industry lie within the harbouring of, or access to, sensitive information including account numbers and user credentials. Nevertheless, these vulnerabilities also provide the ability to pull any data out of memory, meaning hackers could theoretically end up with access to an entire application. Through these vulnerabilities, attackers have the potential to target the bank itself by extracting decryption keys and API credentials. By accessing these cryptographic assets, attackers can effectively progress their efforts to gain access to all of the banking systems the application is connected to.

Where account numbers and user credentials come in is when a user logs into an application. Once they put in their details, that application will put their credentials into memory or CPU registers for use. What the vulnerabilities do is allow someone to flush that memory out, so they can be accessed, consequently exposing user credentials or authentication tokens. While this technique could be utilized to reverse engineer almost an entire application, in practice this is not particularly viable as it would take so long to flush every piece of memory in order to recreate it.

Defence for banks

The vulnerability that makes such an attack possible is below the application level so the usual protections that application and web developers are used to, do not particularly help here. The vulnerabilities exist in the architecture of underlying systems, enabling them to be extremely long-lived, giving attackers sufficient time to develop targeted attacks. The location of these vulnerabilities makes them harder to protect against as it is the processor, its registers, and its memory that are being manipulated.

Even with a well written application, mobile banking applications are still exposed and vulnerable. The most effective way to protect against vulnerabilities like Meltdown and Spectre is to maintain the encryption of sensitive data within the application, and only decrypt this data when it is needed. Once used, the data should then be re-encrypted as soon as possible. It is important to stress that data should be encrypted within the application, not just between the application and the data centre. Encryption and decryption key material can itself be protected through techniques like white-box cryptography, which can remove the actual key material from an application so that keys are never kept "in memory".

Additionally, banks and other financial organisations can protect themselves by monitoring and analysing the behaviour of the application itself. Measures such as anti-tampering and anti-reverse engineering are invaluable when it comes to detecting unusual behaviour within an application. By detecting such behaviour, we can then understand how and when to change it. Dynamically changing application behaviour and/or choosing execution paths that achieve the same results will help to reduce predictability of the app. This can then be supported by the manipulation of the control flow of an application to make targeting the correct registries or memory addresses more challenging for attackers.

Protection for banking customers and general mobile banking users

There are many recommendations we can give for general users or businesses to protect themselves from the risks caused by vulnerabilities like Meltdown and Spectre.

• We cannot stress enough the importance of normal security good practices, including only running applications you trust from reputable businesses.
• Shut down applications you do not need running, especially when accessing ones that manage sensitive data.
• Enable process isolation wherever possible, including browsers like Chrome.
• Disable JavaScript where feasible and use the browser's whitelist to trust reputable sites. However, remain cautious against seemingly trustworthy sites and consider an ad-blocker where ads are present.

As mentioned, despite attempts at patching Meltdown and Spectre, there have been issues with this process and even once patches are available, the threat remains as long as systems are not updated or protected. Furthermore, Spectre is still yet to be resolved. As a consequence, it is vital that both the banking industry and its customers remain vigilant and maintain their security. Equally, even when these particular vulnerabilities no longer pose a risk, security must remain a top priority to protect user's information and a business's reputation, especially with GDPR coming quickly. When it comes to application security and data protection, being prepared is fundamental.