Cloud: A boon or bane — Part I

SecurityGOAT
3 min readDec 13, 2020

Hello all, this is the beginning of my blogging journey to become the GREATEST of all time in cybersecurity!

Today I will be discussing about how Cloud tech can leveraged by the attackers to pull off some attacks :)

Sounds interesting? Sure it is ;)

Primer on API Gateway

Before I dive into the details, let’s take a quick look at what is API Gateway. This will come in handy later on when I explain about the attack.

Feel free to skip this part if you already know about API Gateway :)

From Redhat’s website:

An API gateway is an API management tool that sits between a client and a collection of backend services.

An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.

Most enterprise APIs are deployed via API gateways. It’s common for API gateways to handle common tasks that are used across a system of API services, such as user authentication, rate limiting, and statistics.

Here is an image for AWS API Gateway (but the flow can be similar for a generic API Gateway as well)

Source: https://aws.amazon.com/api-gateway/

So, clients send in some requests (via WebApps, Mobile Apps, etc) and these requests are sent to the backend via the API Gateway.

This way, rate-limiting and authentication can easily be dealt here instead of dealing it at the application level.

Now you know about API Gateway, let’s get to the juicy stuff :)

The Problem (for an Attacker)

As an attacker, the problems that you face in the modern infrastructure is that most of the attacks such as brute forcing or dictionary attacks don’t work quite well! Reason being that the backends are designed such that there is rate-limiting and IP based blocking, which renders these kind of attacks pretty much useless. Sigh :/

And with the advent of cloud, it is much more easier to have there controls in place. You can configure an API Gateway with rate-limiting and have the backend be configured to block IP addresses that seem to perform some attacks (say using Lambda function by maintaining the request count / IP address in a DynamoDB table). More on protecting your REST API can be read here.

Interesting! So if my infra is on cloud and all controls are set up properly, I am SAFE! Or am I?

The Solution (for an Attacker)

Well, cloud has your back ;)

You can bypass IP based blocking and rate-limiting by leveraging cloud.

How so?

It is pretty common for developers to use AWS API Gateway (in context of AWS services) to relay their traffic to internal services like AWS Lambda.

Each time a request comes to the API Gateway, it sends the request (either modified or unmodified) to the internal service and returns back the response back to the client.

Important point to note is that —
Each time the gateway makes a request to the any internal or external service, it will do so using an AWS IP. And these IPs would be cycled from a pool of IPs in the region where the API Gateway is located.

Great! But how does it helps me as an attacker?

Since cloud is becoming more feasible as it is very cheap, an attacker can easily spin up 1000s of API Gateway instances.

So when attacking a website’s password reset functionality, that requires a 6-digit OTP, you can reset someone’s password by just spinning up multiple API Gateway instances and relay your requests via those API Gateway endpoints.

So, all your requests get originated from the IP pool of the cloud provider and you can get away with the attack without getting blocked :)

Interesting right xD

Some real world examples

I would suggest you to check out this article by Laxman Muthiyah, where he explains how the vulnerability in Instagram’s password reset feature could have potentially allowed him to access any Instagram account without consent!

Related Readings:

In case you enjoyed reading this post, subscribe in to check out more of my content that will be coming soon!

Stay Safe and Happy Hacking!

--

--