In my last post in this series, I introduced Approov, the app authentication solution, and described how it tackles the problem of API protection in a novel and proactive way. In this post, I want to focus on the reasons API publishers need app authentication as part of their mobile security defense, and specifically why it should work alongside user authentication. In our discussions with new customers we often find that we need to explain the difference between the two as well as the contributions that each one provides.
To illustrate the problem, I want to talk about games like Clash of Clans, by Supercell, the leader in a large group of really popular strategy based mobile games. I will first briefly describe the business model for the games, then move on to the way the APIs are misused to cheat the business model while using legitimate user accounts and costing the publishers real money. Finally I want to show how Approov can be used to block the scripts and bots and therefore restore a lost income stream. (Note that I am only picking on Clash of Clans because it is one of the most popular in the genre. There are many alternatives that exhibit the same problems and yield similar results if you amend the linked searches.)
From a high level, these strategy games are about collecting resources, and players earn resources in exchange for repeatedly using the game (or for avoiding the wait via in-app purchases). App developers add various incentives to increase the $ spend, or add advertising to ensure a revenue stream even when the player doesn’t spend money directly. The cash opportunity for an attacker is to undercut the app developer by legitimately selling accounts that have been illegitimately populated with resources. Note that, the accounts are all valid and require a login, but developers cannot typically prevent accounts being transferred from one owner to another.
Some early versions of these games had API vulnerabilities which permitted resource stealing, however even with those vulnerabilities fixed there are still viable attacks. Instead of manually progressing an account, attackers can use a script or bot to drive the API. The scripts first onboard a new player account and then continue by accumulating resources for that account by investing large amounts of time instead of money (the second part can be accelerated by using stolen credit card numbers which will likely cause chargebacks). Because bots use the API directly, they can be constructed to run multiple sessions in parallel, thereby accumulating resources for many accounts before the attacker cashes out, selling the account on one of the many online account marketplaces. (Of course, while doing this, bots will ignore any adverts that the API may serve.)
Approov blocks this attack vector by preventing access to the API from all but legitimate app versions. The authenticity of the active app is checked regularly with Approov prior to API accesses. In a similar vein to user authentication, the app is issued with a time limited Approov token which is passed to each accessed end-point for quick verification by the server. If the provided token is valid, then all continues as normal, otherwise, the request can be rejected with no further work.
In brief, Approov verifies what is using your API while user authentication verifies who. Both these aspects help protect access to your API in different ways and what can be just as important as who when it comes to protecting your revenue stream. Automated API usage, like the attack described here, increases the cloud bill for the app and may introduce performance overhead for legitimate users. Before using Approov, our customers have had up to 15% of their API activity driven by scripts and bots. After switching on Approov, unauthenticated traffic typically diminishes quickly, until it reaches an insignificant level, as attackers’ bots and scripts stop working.
WANT TO KNOW MORE?
This series of posts focuses on aspects of Approov that are sometimes misunderstood. If you have any issues you want qualified then why not ask me a question from the contact us page. Otherwise, here are some links that you may find interesting:
