Shielding APIs that Service Mobile Apps: Part 1 – Why?

In this series of articles, we are going to explore the why, what, how and when of shielding APIs that service mobile apps. Increasingly, mobile represents a special case when it comes to security and we will make the case for some explicit steps you should take if you are working within a company that relies on mobile apps to conduct its business.

Through this blog series, you will learn:

• Recent real data on how bad actors think about preparing and mounting attacks on your API and mobile apps.
• The principal mobile attack surfaces and how bad actors move between them to achieve their aims.
• The security strategy you should pursue to achieve a balance between shift-left and shield-right initiatives.
• Tools and techniques to protect your mobile apps and APIs from attack.

In this first article we’ll dig into why protecting mobile apps and the APIs that service them is important. We’ll do this by examining what the bad guys are up to and how they leverage your mobile apps to attack your APIs.

Apps v Browsers

Looking at apps in general, a few years ago these had traditional interfaces where you have a browser making HTML calls into a server, fetching UI and presentation information mixed in with data and serving it all back to the browser. So everything’s  a bit jumbled up and most of the logic for making decisions is in the backend server, as illustrated below.

Image source: www.akamai.io

Contrast the description above with the trends in mobile apps and in single page web apps where much more of the business logic is now running on the device itself. In the case of mobile apps, the presentation is built into the app itself; it’s not being fetched each time with a browser call. The calls tend to be much finer grained and because the business logic is over on the app itself, many more calls are being made using structured APIs to get data over into the apps.

Additionally, most of these calls – for scalability reasons – are going to be stateless at the back end. If you’re a hacker trying to attack this type of app the lack of state means that there are fewer restrictions in terms of the order that you make these calls as you’re probing and experimenting. Unfortunately these are the easiest type of interfaces to hack if you’re trying to get into somebody’s back end because they’re well structured and stateless.

API Vulnerabilities

OWASP published their top 10 API vulnerabilities in 2019. The number one vulnerability on that list is Broken Object Level Authorization (BOLA). Let’s take a closer look at BOLA.

Image source: www.apisecurity.io

As shown above, an attacker would start by reverse engineering the API as best they can and make a legitimate looking call. They would log in using valid user credentials which they source by intercepting live API traffic or from an unrelated data breach and make a call. If it’s successful then they’ll take the object reference from the call – it might be a user ID reference or a resource ID – and try a second resource ID or user ID. They’re interested to know: “Can I extract information that I really shouldn’t be authorized to extract?”, for example in a patient database. Put another way, they may ask: “Can I get information about other patients by simply fooling around and randomizing that ID number that the API request requires?” This is an example of BOLA and it’s a very common type of vulnerability.

As an example, back in 2017 there was a vulnerability on Instagram where you could capture a password reset request – which was an API call – and you could simply replace the user ID that was attempting to be reset with somebody else’s user ID.  So you could pick a celebrity’s user ID if you wanted to and the back end would not actually check to see if the user ID that was being requested to be reset had been authorized with credentials from that same user ID.

People used this to hack into the Instagram accounts of celebrities and take them over. As a celebrity whose account has been hacked, when you tried to log in you would find out that your password didn’t work anymore . As that happens to all of us periodically, you’d probably just issue another password reset, take control of your account again with your new password and not worry about it. However, in the meantime whatever dubious photos there might be sitting up on Instagram could have been downloaded and published, as happened to several celebrities at the time.

API Abuse

The previous section described a good example of an API vulnerability and how it can be exploited. Now let’s look at something that’s classified as API abuse. Rashik Sahid is a big fan of the machine-produced ice cream at McDonald’s. However these ice cream machines are apparently very finicky and it’s not uncommon for them to be out of commission. After Rashik had experienced the disappointment of not getting his McDonald’s ice cream fix multiple times, he decided to become better informed, eventually sharing this useful data on the Internet.

Image source: www.mcbroken.com

In the image above the red dots represent machines that are not in service. So if you’re a soft ice cream fan you can see ahead of time whether the ice cream machine at a particular McDonald’s is working or broken. Rashik’s approach was to study and reverse engineer the API which the McDonald’s mobile app uses to order ice cream. He initially placed orders to every Mcdonald’s in the US and spent the equivalent of over $18,000 every minute to place these orders. What he was doing was establishing if the order went through because if it did, he knew the machine was up; conversely if the order was rejected then he knew that the machine was down. Before actually consummating the orders he would of course cancel them so no financial damage was done to either party. 

At the start Rashik’s activities were detected by McDonald’s because the volume of rapid transaction requests looked like a Denial of Service attack. These days he’s lowered that down to make a test transaction every 30 minutes. He probes the stores all across the US and it’s actually quite a popular app. 

The thing to notice here is that Rashik is not exploiting a vulnerability in the app or its API at all. There’s nothing wrong with the API design; he is just using it in a way that wasn’t intended to extract information. McDonald’s has a hot/cold relationship with this app so sometimes they’re promoting it and saying if you really love ice cream then this is an interesting app for you, at other times it feels like they might like to take it down since it risks slowing down the rest of the ordering process in the system with ‘useless’ traffic. This is a great example of API abuse – there’s nothing wrong with the API itself but the context in which it is used is questionable.

Another form of API abuse is credential stuffing, this is a very popular attack style across the whole Internet. Here the hacker uses credentials sources elsewhere; often from the dark web as a result of a breach at some other company. The success of credential stuffing attacks rely on the fact that most of us are pretty lazy; we tend to use our email as our username and we often reuse passwords .

An attacker simply takes as many of these username/password lists as they can get their hands on and sets up some scripts to try and log into the service they are targeting. Some percentage of these credentials will work and for those not only have they proven that the credentials are correct but they also may have gathered some additional information just by the return information on the login. These accounts are then ripe for being taken over. In this way they can build up a new list that is qualified for the company they are attacking and either exploit it themselves or sell the data on the dark web.

Image source: www.akamai.io

This is an amazingly popular attack style. You can see that Akamai did a study back in 2018 and they observed over 27 billion credential abuse attempts, just on their network in half a year. Credential stuffing is also API abuse because again it does not rely on the exploitation of API vulnerabilities.

Zoom rose in popularity during the pandemic and had a number of attacks directed at it. An attack in April 2020 was a by-the-book credential stuffing attack. Hackers collected databases containing compromised credentials from various unrelated attacks dating back to 2013. Those credentials were then tested against the Zoom service using multiple bots, with lags between attempts to prevent triggering the rate limiting which was there to detect Denial of Service attacks. The attackers were able to establish over 500,000 valid Zoom credentials which went on sale in April 2020 on the dark web. If you had acquired these credentials then you could potentially take control of an account and impersonate the person that owns the account. You could launch new meetings but perhaps more clandestinely you could eavesdrop on what was going on or review past recordings to extract valuable intelligence and data. This was a very standard credential stuffing attack and unfortunately there’s plenty more where this came from.

The Mobile Dimension

When your API is live in production, it is very important to consider security both from a vulnerability exploitation and an abuse point of view. If you have done a good job in earlier testing then hopefully you have squeezed out all of the vulnerabilities from your APIs, remembering that each API code change risks introducing new ones so vulnerability testing is of course an ongoing process. Beyond vulnerabilities, you need to also be verifying the context of each API request to ensure that your API is not being abused.

Image source: www.approov.io

In the diagram above, we have an app trying to call into a backend service. The app is legitimate and so it is going to be making a fairly low velocity of API calls and therefore will only be able to access or modify a few pieces of information per minute. It’s a very controlled situation and the sequence and frequency of calls is relatively predictable. In contrast, if you are able to make API calls with a script using a bot, you don’t have the restrictions that the mobile app naturally provides in terms of the order sequence and velocity of calls. You can set up many parallel calls and really accelerate the throughput and breadth of requests you’re making. In other words, APIs that service mobile apps are an attractive target for hackers because the apps give them very juicy information and a mechanism to efficiently crawl through back end databases and extract sensitive data, commit fraud or do whatever damage they have in mind. 

In this first article of the series, we’ve explained the two primary threat vectors at play against API-based platforms, namely exploitation of vulnerabilities and API abuse. We also covered some of the particular challenges which come with trying to protect mobile-centric businesses. It should now be clear why it is important to shield all of your APIs against these threats, especially those services mobile apps. In part 2 of the series, we will look at what API shielding is and how attackers equip themselves to uncover and exploit weaknesses in your defenses.

*** This is a Security Bloggers Network syndicated blog from Approov Blog authored by David Stewart. Read the original post at: http://blog.approov.io/shielding-apis-that-service-mobile-apps-part-1-why