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. 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.