Stock Manipulation By Exploiting Serverless Cloud Services

10 min readJan 30, 2023

In this article, we will be trying to understand an infamous exploitation technique and how attackers can make companies potentially incur losses in millions for any organization using serverless computing with ANY public cloud vendor. This technique can also be leveraged by companies to cause a significant dip in their competition’s stock price, purely based on the potential financial damage caused by this attack.

Almost everyone has, at some point heard of DDoS (Distributed Denial of Service) attacks, wherein an attacker exhausts the victims computing resources leading to the victim’s server being overwhelmed by the incoming requests leading to business downtime for the app that is hosted. In this article, we are going to be looking at a variation of this attack.

Ideally, in any other environment, DoS can be prevented by simply placing the services behind a load balancer or using cloud-native services like AWS CloudFront that would load balance and route the requests to vacant servers. But with the advent of serverless technology, wherein cloud vendors charge the customers on an event-driven model, an adversary, intends to economically harm the target environment. I have split this article into two parts — the first part explaining the technical details of the attack and the second part discussing the financial implications of these attacks.

What is serverless cloud computing?

In the serverless model of cloud computing, the cloud provider is responsible for managing the infrastructure and allocating the necessary resources to run the code, while the user only writes and uploads the code. This allows for a more flexible and cost-effective solution compared to traditional server infrastructure.

The pricing model for serverless computing is usually based on the resources consumed by the code, including computing power, memory, and other necessary resources. Instead of paying for a set of dedicated servers, the user pays only for the exact amount of resources consumed. This means that the cost of running a serverless application or service is directly tied to its usage.w

Typically, the cost of serverless computing is divided into two main components: the cost of executing the code and the cost of storage. The cost of executing the code is calculated based on the number of requests made to the serverless function, and the amount of computing power and memory consumed. The cost of storage is determined by the amount of data stored, including both database and object storage.

In addition to these costs, some cloud providers may charge for additional services, such as data transfers and API calls. These charges can vary between providers, so it is important to review the pricing model carefully before choosing a provider.

Overall, the pricing model for serverless computing offers a more cost-effective solution for building and running applications and services compared to traditional server infrastructure. The user only pays for the resources consumed by their code and has the ability to scale the application or service based on usage patterns. This allows for greater flexibility and cost savings, making serverless computing an attractive option for many businesses.

Understanding AWS Pricing Regime

To understand, the financial losses made possible by this attack, it is prudent to understand the current pricing regime that Cloud vendors use for providing this service. We will be focusing on AWS for the purposes of this article.

As mentioned above, the pricing model for AWS Lambda is bifold —

Number of requests received at the API Gateway running the Lambda service
Amount of time taken per GB (or the higher memory limit set) for the service to execute

The formula for AWS Lambda pricing is as follows:

Cost = (Number of Requests * Cost per Request) + (Compute Time * Price per GB-Second)

Where:

Number of Requests: The total number of requests made to the Lambda function.
Cost per Requests: The fixed rate per request, depends on the region.
Compute Time: The total amount of time, in seconds, that the function was executed.
Price per GB-Second: The price per GB-second of compute time, which increases with the amount of memory allocated to the function

Attack Scenario

In this scenario, we have a VPC deployment that stacks the artifacts for hosting the client application, which in turn is using Lambda + API Gateway to route the correcting web page, and the attacker is trying to create a bottleneck in the services compelling the server to return a 502 to the end user.

For ease of understanding let’s consider a microservice that we know can be exploited based on this.

Consider an authentication API that offers a login page to the user. This microservice runs behind the API gateway. Now again, let’s presume that this service connects to an MSSQL server and the login page suffers through a SQL Injection attack. Refer to the diagram below to understand the application architecture of the service

While these parameters do change considerably at different times, Let’s assume for a pet project that we receive 500 requests per second, and for our login page, let’s anecdotally say that the memory allocated would be 2048 MB, even though a single service only consumes say 128 MB at a time, We would usually allocate marginally extra memory such that the same instance can handle multiple requests at a time. This is to avoid the cold start of each new Lambda instance.

AWS Charges incurred during usual non-malicious traffic

Hence, during normal usage —

Number of requests per second = 500
Cost per requests = 0.0000002$
Compute time = 2 sec
Price per 1ms= $0.0000000021, for 1 sec = 0.0000021

Cost per sec= $0.0001042

If the traffic remains consistent then the weekly cost (which is not likely, but this gives us a good idea of the costs) for our pet project would be 63$

Demystifying the attack

The adversary uses a tool like slurp to send repeated requests to the one endpoint hosted on the cloud, as represented below -

AWS Charges incurred during an attack

The default time limit set for catering the login request would be 2 sec. However, the attacker would now use the sleep()function available within MSSQL and extend the execution time to say 10 secs, and since an organization does not put a cap on the number of lambda instances that could be spawned, say that for the attack, the attacker would now send 5000 requests per second, also exhausting the 2048 MB of memory allocated for each instance by each request. Hence the parameters change to —

Number of requests per second = 5000
Cost per requests = $0.0000002
Compute time = 10sec
Price per 1ms for 2048MB of memoery = $0.0000000333, for 1 sec = $0.0000333

Cost per sec = $0.001333

If the traffic remains consistent then the weekly cost for a mid-size company would be almost 806$

To keep the numbers small and simple, and given that this was our pet project we realize that during an attack the cost incurred is almost 13x. However, in the real world, for a production service — the numbers would be exponentially higher, almost 100x for a real-world mid-size company’s deployment, given that we did not consider the overhead charge for MSSQL service, CloudFront Ingress charges, other AWS services dependent on one such service, such as S3, et al. which would all compound the costs for the services suffering the same attack example.

Based on our calculations made above, In a no-attack scenario, the usual expense for the IT teams would be roughly $6300, however, during a prolonged attack scenario the numbers rise up to as high as $80,600

Automated Detection and Mitigation techniques

Although security teams would argue that the developer is to be blamed for this attack, given the origin of the cause of the attack is SQL Injection. However, the attack could have been stopped in its tracks, had the configurations and limits been set by the Ops team, and for those reasons, it is prudent that all deployments are monitored and all alert metrics pertaining to the deployments are set. One such deployment example is depicted in the figure below —

Reference Cloud infrastructure using Serverless

To monitor such an attack, we have two options going forward -

In the reference architecture, we have two Virtual Private Clouds (VPC). The first one is for the complete production infrastructure and the second one is our monitoring setup based on the ELK stack. The ELK stack receives logs from services running under the Infrastructure VPC. Let’s consider that the Infrastructure also encompasses the Lambda functions which could be attacked, in the same subnet.
The Lambda + API gateway is the defense mechanism that would be invoked as post triggers after receiving an alert from the ELK stack. For the sake of simplicity, the following diagram doesn’t show our defenses in place for the ELK stack itself as that is behind a DMZ-locked firewall with only whitelisted services having access.
Once the defense Lambda is invoked, it is fairly trivial to set Webhooks for Infrastructure requests rate limiting and alerting via services like AWS SNS

Incurring Financial Loss

These types of attacks can have a significant impact on a company’s financial performance, including the potential for stock manipulation and bankruptcy. Here’s how a competitor company might achieve this:

Stock manipulation: The attacker could launch this attack on a company’s cloud computing resources, causing a sudden and significant increase in costs. This can result in negative financial reports and a decline in stock prices, allowing the attacker or their associates to profit by short-selling the company’s stock. The attacker might want to time these attacks toward the end of the Fiscal year, such that the financial hits, incurred due to the attack are part of the same year's expenses and the company’s stocks would take a dip due to this
Bankruptcy: A sustained and prolonged attack, as described above can put a significant strain on a company’s finances, potentially leading to bankruptcy. The attacker may target a company’s cloud computing resources for an extended period, causing a gradual accumulation of costs that may eventually become unsustainable.

For startup companies that suffer through these attacks — this could lead to bankruptcy. As a matter of fact, companies have almost been bankrupt due to this —

It is important for companies to be aware of the potential for financial loss through such attacks, and to implement security measures, as discussed above, to protect their cloud computing resources and financial systems. This includes regular monitoring of cloud computing costs and usage patterns, as well as implementing strong security controls to prevent unauthorized access to cloud computing resources. Companies should also be prepared to respond quickly to any unusual activity and take appropriate action to mitigate the financial impact of any such attacks.

Stock manipulation via short-selling

Short-selling is a type of stock trading where an investor borrows shares of stock from a broker and sells them in the hope that the price will fall. If the price does fall, the investor can then buy back the shares at the lower price, return them to the broker, and keep the difference as profit.

In the context of this attack, In theory, the attacker could launch the attack on a competition company’s cloud services, causing a sudden and significant increase in cloud computing costs. This increase in costs could result in negative financial reports and a decline in the company’s stock price. The attacker or their associates could then short the company’s stock, profiting from the decline in the stock price.

SEC (Securities Exchange Commission) in the US has put in several guidelines to regulate the short-selling of stocks, however, given the sudden fall (within a week’s time) of the competition’s stock price and the short-selling price does raise a lot of questions of stock manipulation. In the past FTC (Federal Trade Commission) has been known to prosecute companies such as Uber, In the matter of Uber for not enforcing sufficient security policies and measures in protecting the application and their userbase. In this case, the damages would be widespread since this stock fall, which would not only incur financial losses to the company but also to the public investors. This could be one such scenario wherein the company suffering the attack could potentially face prosecution and heavy penalties from Federal agencies like the FTC, where the decision, once made, is very difficult to appeal. Besides the application downtime, financial loss, and other monetary damages caused by this, the company would also lose face in a public setting, being under the spotlight.

Conclusion

Companies, in past, have either erroneously attacked their own infrastructure or have been subject to these attacks. In either case, per the cloud SLA by most of the public cloud vendors, the burden of security for such attacks almost always falls upon the company, and any such attacks would make the company liable for the damages and their repercussions.