API Abuse in 2017 (Part 3)

Two particularly challenging forms of API abuse are Aggregation and Cheating as a Service. In both these cases your own users are enabling and sometimes funding the individuals and organizations abusing your APIs.

Aggregation

Aggregation apps present their users with data scraped from multiple companies offering competing services or products in markets such as retail and mobility. This form of API abuse is an issue for anyone who wants to control how their users interact with their product or service. Aggregators not only scrape the data provided by an API but can also make requests through to the backend service in exactly the same way as the real app, meaning that your customers potentially only experience your services as presented in the aggregation app.

For smaller companies aggregation may seem like a good thing. Cooperating with aggregators can bring new users to your service, however you will never have control of either your data or your income stream. Aggregation apps offer little guarantee about how your service is presented in relation to your competitors which dilutes your brand and potentially costs you customers.

Aggregators are particularly active in the Mobility as a Service sector where they bring together all of the car and bike share services for a particular city. For various reasons, not least that many of the companies involved are actually owned by competing car manufacturers, most car share operators do not willingly cooperate with the aggregators. This results in an endless game of cat and mouse where operators must continously increase the security of their apps and APIs to counter the ever more intense reverse engineering efforts of the aggregators.

This battle can usually be seen in the aggregator apps themselves where the degree of integration varies with each release. Some operations require you to install the operators app while others are entirely integrated. Most worryingly for operators is when aggregators work out how to enable car unlocking and engine start from within their app.

Cheating as a Service (CaaS)

This form of API abuse rapidly becomes widespread on any platform where users interact with apps to earn rewards and is particularly damaging where this mechanism is a core part of the business model. Typically, mobile games are the most visible platforms open to this sort of manipulation where users take advantage of scripts or websites to automate the collection of points which the user can then translate into in game rewards or power ups. Clearly this is bad for other players of the game, who may just leave the service, and reduces the amount of in game time spent by those cheating, potentially reducing advertising revenue.

For other types of apps leveraging gamefication the practice can have more direct consequences. Social networks, such as Nimses, discussed previously, use a virtual currency, which can be exchanged for real world goods and services, to encourage interaction between users.

Location based marketing apps provide rewards for users physically walking around retail outlets. Websites are available which allow users to login with their own credentials and then send spoof data to the API making it look like that user is walking around stores. Moreover they also make use of entirely fake accounts to further accelerate a user's accumulation of rewards through referrals or transfers depending on what the platform supports. When this practice gets out of hand it is bad news for the marketing service as their customers will not see the footfall they are expecting for the number of rewards that are being redeemed.

Wrapping Up

Throughout these API abuse case studies we have seen a well established trend of accelerating sophistication in the tools available to would-be API abusers. These include:

• Scripts / Bots to operate mobile APIs.
• APK Unpackers.
• Network Analyzers with easy to use UIs.
• Debuggers and Frameworks. Many now support push button device rooting and off the shelf modules bypass common app security techniques.
• Fast Emulators capable of avoiding in-app detection.
• Easy access to hard to trace, highly scalable, server resources in the cloud.
• Apps enabling Device ID rotation, IP Spoofing / Proxies, VPNs etc.

This means that the technical effort threshold required for these attacks, even against well protected APIs, is dropping rapidly. Therefore, more services will be vulnerable as it becomes worthwhile to reverse engineer and abuse them even for relatively little gain. 

When considering defensive approaches for bot mitigation keep the following in mind.

• Business level attacks look like normal users. So do not rely on User Authentication alone. You must build a chain of trust including the device state and the authenticity of the app communicating with you API.
• Difficult to see abuse in real time. Web Application Firewalls will struggle to see the traffic associated with business level attacks as malicious. Typically it will only become apparent by explicitly looking for it in the logs after the fact. This allows you to block IPs, accounts and devices involved but you will always be playing catch up as the attackers simply move to another client profile.
• Consider your business model in terms of potential and detected API abuse. Ideally build in prevention from the beginning assuming that someone will be trying to game your system. This may result in difficult trade offs between user experience and security however. If you do see abuse occurring, particularly if it is being enabled by your users, it may be that this is a subsection of your market that is not having its needs met yet. Consider if a slight tweak to your offering could nudge these abusers into being paying customers.
• Ensure you have technical solutions in place to raise the effort level required by abusers. Use certificate pinning on the API connections, authenticate the app before you trust anything it sends, lockdown the device as far as possible by detecting root, frameworks etc. and monitor for suspicious patterns in user accounts in the backend.

Taking these steps will dramatically reduce the API abuse you can expect in addition to securing your API and app against more traditional network attacks.