APIs: The Trojan horses of security
At the moment, within the cybersecurity industry the emphasis tends to be on securing networks with perimeter-based protection, however, leaving an application endpoint unsecured means an application programming interface (API) can serve as a gateway to the data centre by which attackers can effectively attack the backend via bots, and compromised or impersonating applications. With banks having to share their APIs due to recent PSD2 regulations, keeping applications and APIs secure is more important than ever.
PSD2 and the sharing of APIs
In January 2018, APIs began playing a big role within the banking industry as the new Payments Service Directive made open banking mandatory. The PSD2 regulation was introduced to battle against what the bureaucrats see as a bank monopoly. It was hoped that introducing third party access to customer account data would bring about some competition as well as reduce the reliance everyone has on banks when it comes to handling our finances.
Due to requiring the banks to share their APIs with third parties, PSD2 enables customers to access particular banking services through other mobile applications.
APIs open the backdoor
As current security trends tend to focus on the network layer, it is often overlooked that published apps can provide a roadmap for an attacker to target APIs and, as a result, a backend data centre. Without having full visibility into what the callers of your API are doing, your business can be exposed to serious risk.
Cybercriminals have realised that API calls that originate from inside an app are a blueprint for the infrastructure inside a data centre. What’s worse, they can use those same API calls to hide their malicious purposes – like a Trojan horse gaining access through the front door.
Apps are the new emerging threat vector
The attacks mentioned above can be used to probe defences or enumerate and exfiltrate data right through your perimeter defences. Ground zero for these types of attacks are mobile apps operating “in the wild”, outside of secure corporate perimeters.
However, hackers can circumvent perimeter security solutions anyway. To do this, sophisticated attackers will focus their efforts on targeting a single application. By compromising web or mobile apps they can emulate the behaviour of an unmodified application to establish a baseline of legitimate access to the backend. This pattern of behaviour can then be widened to slowly exfiltrate data over time and find subtle violations of the data access control, often using methods that the “normal” application already uses — rendering noisy, detectable exploits unnecessary. These seemingly innocuous requests essentially become the attacker’s most effective tool.
Hackers vary in sophistication
Less sophisticated attackers try to compromise app APIs by simply injecting malicious content into API request fields. This is a relatively low-effort method to uncover vulnerabilities when the requests are processed. This basic technique can be carried out through a tool called WARDroid. It analyses mobile apps retrieved from the Google Play store, and creates a data model of the API as represented by the client-side app code identifying how an app communicates with a server. This communication model is subsequently tested against the backend server to find behavioural inconsistencies between the client and server—exposing server-side vulnerabilities.
Although injection attacks can be used to identify numerous exploitable app APIs at one time, the practicality of this method is limited. This is predominantly because Web Application Firewall (WAF) devices and server-side Runtime Application Self Protection (RASP) solutions are able to quickly identify and generate alerts for these types of attacks.
More savvy attackers, however, are able to target a single app by taking a more sophisticated approach, which is designed to circumvent both WAF and RASP security methods. They can establish a baseline of legitimate backend access by mimicking the behaviour of unmodified applications.
Can we protect our APIs?
One of the best approaches banks and third-party providers can take is to stop attackers from getting to the API. But, unfortunately, the majority of mobile and web-based applications today lack the protections necessary to prevent app level attacks. These attacks all are based on a common attack vector – reverse engineering of an app to discover its operation, how it communicates with APIs and to exploit encryption keys used to communicate with APIs.
The foundation of addressing risk exposure is to assume all apps are running in a zero trust environment. This means assuming that all the data and functionality inside and communicated to browser and mobile applications can be compromised and available to any attacker — API request generation, API response interpretation, encryption and decryption routines, authentication procedures, and more.
This functionality can be utilised unchecked unless that endpoint app is hardened. If the code is properly hardened, it is significantly costlier for an attacker to reverse engineer and emulate the behaviour of the application from the outside. The attacker might then resort to more invasive techniques such as code lifting, code modification, and dynamic analysis of the application during runtime. These are all detectable with the proper protection.
In addition, there are data exfiltration threats. If there are cryptographic keys being used to access an encrypted API, they will be resident on the device. These keys should be secured using white-box cryptography to defend against attempts to lift and distribute these keys and tokens.
Lastly, the most effective defense is one that can complete the app protection cycle by providing security telemetry from apps running in the wild. This kind of feedback can be used to understand if apps are running on compromised devices and to identify emerging attack vectors. This helps developers and business stakeholders make crucial decisions regarding how often and when to adapt their app’s security — creating a closed-loop, continuous security improvement process.
On a final note
Application endpoints are extremely vulnerable and are becoming more and more attractive to attackers due to financial institutions like banks using applications to make things easier and more convenient for their customers, alongside having to comply with recent the introduction of the PSD2 rules and regulations. As hackers can use an application and API to enter the network, organisations need to ensure all access points to critical backend systems are protected, encrypted and obscured so that they can’t trivially be tampered with, reverse engineered, and used as a gateway into the infrastructure.