Our first batch of business level attacks are Data Scrapers and Account Hijack. We also take a look at the lucrative business of Fake Account Factories.
Many of the threats to mobile APIs will be familiar to anyone involved in protecting websites from automated abuse. As mobile becomes the primary channel for more company's, the bots simply follow the data. Data Scraping is a classic example. This is where the content provided by an API is automatically harvested and reused or redistributed outwith the control of the owner of that data.
This is particularly bad news for any organization that needs to ensure its data is distributed through its own apps in order to monetize it. Scrapers can profit from direct use or resale of a companies data but due to the availability and ease of use of tools to enable scraping of APIs the economic motivation does not have to be very strong to make it worthwhile.
For example, Racing Post provides detailed and up to date form information for horse racing. Providing access to this comprehensive database is their core business and it is vital that they generate income from the use of the data by 3rd parties. In the consumer channel this is done by providing access to betting through their app. However, there is a large community of gamblers who make use of systems in an attempt to beat the odds and improve their winnings. These systems typically manifest as complex spreadsheets which require large amounts of racing form data as input.
This provides enough incentive for some to scrape Racing Post data and make it available to the wider community as raw bulk data. This results in Racing Post losing a large number of high value potential customers who are still benefiting from their data but without paying for it. Racing Post successfully deployed Approov to stop this and other API abuse issues.
Data scraping is often countered in the web channel by the use of reCaptcha but this proves unpopular on mobile where low friction usability is key to product success.
Account Hijacking is another unwanted import to mobile from the web. Any service with user accounts is at risk but it is particularly problematic if the accounts have access to payments capabilities or details. Essentially the attack is the automated playback of stolen user credential lists compiled from database breaches on other services. Based on the principle that people use the same credentials on multiple platforms, bots are used to attempt to login to your service using these lists.
A naive implementation of this abuse is reasonably straightforward to prevent (for example limiting the number of login attempts per minute from a given IP) however the increasing sophistication of bots, and the wide availability of open source bot implementations, means that behavioral defenses are becoming less effective.
Account Hijacking is a particular issue for large scale retailers where we frequently hear that attempts to use anti bot technologies such as reCaptcha have resulted in loss of customers and plummeting app store ratings.
The increasing prevalence of mobile only social networks has resulted in the development of sophisticated, specialized groups who reverse engineer the account creation process in order to automate it at scale. The resulting accounts are then sold on to third parties who go on to abuse the service in a variety of ways in order to make some sort of gain. Typically this is done to enable spam but is also used to game the system implemented by the service, such as artificially increasing someone's followers, or subverting it completely as is the case with "fake news".
The scale of the issue depends on how difficult it is to create fake accounts versus the potential upside of doing so. Simple economics makes it inevitable that high rewards for creating fake accounts will result in great effort being applied to working around verification procedures.
This was the scenario Nimses, a rapidly growing social network, faced as it began its expansion. The network is based upon a cryptocurrency which every account accumulates over time just by existing. However users on the network can freely transfer these Nims to each other and, crucially, can use them to buy real products. This made Nimses an attractive potential target to spammers, who would would have had a low friction way to take payments in Nims, and to individual users who could use fake accounts to multiply their own income. Nimses were very aware of the potential abuse and improved their API security by building strong account verification into the core of the network and then based this trust model on software authentication.