The number of devices connected to the internet has exploded in recent years as everyone becomes permanently attached to their phone or tablet. As the number of mobile users has increased, there has been movement away from websites towards mobile apps. Large companies can gain more information about users when they use their app, and can also provide a more fully featured experience by offering offline functionality or by making use of the phone’s camera, accelerometer or GPS. Users tend to prefer them as well because they offer a richer experience.
There has been significant progress in detecting and blocking suspicious access to websites by bots, known as bot mitigation. However, as more and more developers move away from the mobile web and into custom apps and APIs there are significant challenges to identify and prevent malicious traffic.
Standard solutions exist to authenticate users and provide app developers with confidence that they are talking to a real account but not all use-cases require a user to log in. Perhaps a more fundamentally important question for all API developers is:
What software is being used to access my API?
If you are developing a mobile app of any sort using such an API you should be interested in making it difficult for other people to create unofficial or malicious versions of it. One of the most common mobile attacks is to repackage your app and publish it to an app store. This creates a way to deploy malicious code onto a device as people mistakenly download it thinking it is the genuine article. This can be used to gain access to private information, or to set up the device as a bot in an ad farm, constantly draining the user’s battery by viewing ads and clicking on links, perhaps even installing more apps. The user may not even realise that the app is not the real deal and may blame the genuine app developer for their phone’s problems. Alternatively an attacker might reverse engineer your API protocol and build new software that impersonates the real app and makes arbitrary API calls. To prevent this you need to block API access to anything other than the official app.
We call unauthorised or inappropriate access to your servers “API Abuse” and it can result in theft of valuable intellectual property and significant server costs. Modified software is almost always required to make fraudulent use of APIs, so by checking the validity of it, you greatly reduce the potential attacks that can be mounted on your API. You help protect the users of your apps and most importantly you protect your API.
Mobile is an important area, and within that apps are becoming an increasing attractive target for cyber criminals. It is in the interests of both users and app developers to make sure that APIs are secure against attack, and a key step is ensuring that the software used to access the API servers is known and verified.
But how can you check what software is being used to access your APIs? Part of the point of developing an API in the first place is to decouple the server from the client. By exposing the API over the internet you make it possible for any piece of software with an http stack to try and talk to your servers.
The simplest way to protect your API is to embed a secret within your official app. You can sign any of your messages with your secret (to avoid sending the secret across the connection to the server) and the server can check that the communication was correctly signed when it receives the message.
This is a good approach as it is simple and provides you with some confidence that the app used to communicate with the server is the one you uploaded to the app store. It does have a serious flaw though. By embedding the secret into the app you distribute the key to your API with every release. If a hacker can decompile your code, they can extract the key and use it in whatever code they like. If you naively create your app without any obfuscation it can be embarrassingly easy to extract supposedly secret keys embedded there. Obfuscation slows down the extraction process, but a suitably motivated individual will probably still be able to get the key..
Approov from CriticalBlue makes it very difficult to connect to a protected API with malicious software without exclusive reliance on embedded secrets.
CriticalBlue provide a client-side SDK which communicates authentication information to a cloud service. This service checks the validity of the app using a challenge-response cryptographic protocol. Crucially, the information the client app sends to the server allows it to check that none of the SDK code itself has been tampered with in any way and also that the overall app is genuine. The client app can then use a token it receives to prove it is genuine when talking to its own backend APIs.
By incorporating sophisticated self checking methods that verify the integrity of the app and the code we use to do the checking, we prevent attackers from creating scripts or bots to flood an API with bogus requests or connect with unauthorized clients. Our knowledge of binary analysis and code optimization gives us a wealth of experience to draw upon to make our solution secure and effective.
The problem of API abuse is a growing one, as hackers turn their attention to the mobile app channel as a means of attacking APIs to disrupt service or steal information. It is orthogonal to the problem of secure user authentication and presents particular challenges. The essential question is: What software is being used to access my API? To protect your API you need to verify that the client software has not been tampered with or replaced completely with a malicious script. DIY solutions to this tend to be easy to break and simply slow the attacker down. Approov from CriticalBlue uses our expertise in binary analysis and low level optimisation to present a solution which allows you to protect your API by incorporating sophisticated and strong anti-tamper mechanisms.
