[BreachExchange] APIs: The Trojan horses of security

[Destry Winant]

https://www.helpnetsecurity.com/2018/09/10/api-insecurity/

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.