This latest blog from ScotlandIS member, PACE Anti-Piracy, emphasises the need to enhance API Security to protect your critical infrastructure.
API Security is critical to protecting the IT infrastructure of any organization. If a cyberattacker is able to abuse APIs, they can breach an organization through the front door.
This is why CISOs (Chief Information Security Officers) and their teams are increasingly spending on API Security. According to Future Market Insights, demand is estimated to grow at an incredible CAGR of 26.3% between 2022 and 2032, and is expected to reach US$10B by 2032.
API Abuse
APIs (application programming interfaces) allow software to talk to the back-end services it consumes, without exposing all the internal details of the service or how it works. For example, a mobile banking app will talk to the banking systems through the bank’s API to get account information and make transaction requests. This makes APIs highly attractive to a cyberattacker, and high risk from a cybersecurity perspective.
API Abuse falls into two categories:
- Unauthorized access. This is when APIs are used as designed but by someone that should not be allowed to use them. With unauthorized access to an API, an attacker can maliciously access services and data.
- Vulnerability exploitation. APIs are software; and like all software are prone to defects (bugs). Attackers try to identify bugs that open up unintended functionality. If they can make an API behave in a way that is useful to them, it can give them a means to breach the organization.
The traditional approach to protecting APIs is to build defenses into the server. These defenses monitor the traffic coming through the API—making go/no-go decisions based on the data passing through the API. If the data looks right, it is allowed to pass. If an attacker can craft messages that look right, then they can get access to the API and the services behind the API.
This doesn’t mean these defenses are inherently bad. Quite the opposite: they are an important—and often very sophiscated—part of the cybersecurity puzzle. The challenge they have is that they only see part of a much bigger picture.
Our Director of Product Management, Neal Michie, spoke about how to “Become a hero to your DevSecOps team” at droidcon London 2023.
Client Authentication to enhance API Security
One important piece of the picture that server-side defenses do not see is who is sending the data. Security can therefore be greatly enhanced by adding authentication of clients that are connecting to an API. Limiting traffic to only legitimate and known clients goes a long way to stopping API abuse.
The classic approach to authenticating clients is an API Key. This is a shared secret (effectively a password) that the client will pass to the server when connecting. As only an authorized client should know the API key, only authorized clients should be allowed to connect to the API. All other connections will be immediately rejected.
The Replay Attack Danger
The challenge with this approach is the same as with any password: once an attacker knows the API key, they can “replay” it back to the server as many times as they like. This allows them to authenticate any device or script as if it was a legitimate client application.
API Keys can be exposed in a number of ways. Common approaches include reverse engineering (more on that later) or simply sniffing the key off the wire. Tools like Burp Suite allow an attacker to run a man-in-the-middle (MitM) attack against an application instance they control. A MitM attack enables a threat actor to see all the network traffic, including the API Key.
Using cryptography to protect against replay attacks
The proven solution to replay attacks is a cryptographic challenge-response. This ensures that every authentication request is unique.
In practice, this means:
- The server generates a unique and unpredictable challenge and sends it to the client.
- The client cryptographically signs the challenge with a private key and sends the response to the server.
- The server validates the response cryptographically using the public key associated with the private key held by the client.
Therefore, there is no longer a single fixed secret sent to the server every time. Instead, the client sends a dynamic response value that only the server can validate.
The Reverse Engineering Danger
So far so good, but let’s look at the case where the client is not another server, but instead is software running at the edge, e.g., a desktop application, mobile app, or IoT device. In this situation, the software containing the private key can be easily accessed by an attacker.
Software is not a locked box. It can easily be opened and analyzed by an attacker using a process known as reverse engineering. Tools are freely available to extract software from a range of devices, decompile the code back to something readable, and instrument executing code to fully understand exactly what it is doing.
Using reverse engineering, attackers can quickly and relatively easily extract a cryptographic key from the software. They can then generate valid responses to the server’s challenge, authenticating themselves and tricking the server into granting access.
This is why, in the 2024 edition of their Mobile Top 10, OWASP recognize Improper Credential Usage as the number one threat to mobile apps; with hardcoded credentials the top scenario described. Of course, the risk doesn’t just apply to mobile apps. It exists anywhere that software is running at the edge and so at risk of analysis by threat actors.
The need for white-box cryptography
Cryptographically, this is the correct solution for authenticating a client with the server. The trouble with this in-app cryptography is that there is still a secret value in the client-side software: the private key. Just as with the API Key, the private key can be easily exposed. This is the danger of in-app cryptography.
To tackle this danger, it is essential to incorporate cryptographic key protection. White-box cryptography, a proven solution employed in various real-world contexts from mobile payments to video DRM, effectively prevents the discovery of cryptographic keys within the code.
PACE has developed a 3rd-generation white-box called White-Box Works. This is a software development tool that PACE’s customers use to protect their high-value algorithms and data wherever their software is running.
Traditional white-box library products are monolithic and inflexible SDKs. This means they force developers to bend their architectures to the white-box SDK. In contrast, 3rd-generation white-boxes like White-Box Works empower the developer, allowing them to design software architectures that are sympathetic to their use case.
To learn more about using white-box cryptography to get in front of API Security, contact PACE to talk with our experts.
This article was updated on March 20, 2024 to include details of the OWASP Mobile Top 10 2024.