Non-Obvious Denial of Service

I was looking back at Computer Networking: A Top-Down Approach by Kurose and Ross, a textbook I used for CS145, (shoutout to Professor Yu who is a really excellent professor) and I noticed this excerpt from the chapter called "Networks Under Attack":

Most Internet DoS attacks fall into one of three categories:
  • Vulnerability attack. This involves sending a few well-crafted messages to a vulnerable application or operating system running on a targeted host. If the right sequence of packets is sent to a vulnerable application or operating system, the service can stop or, worse, the host can crash.
  • Bandwidth flooding. The attacker sends a deluge of packets to the targeted host―so many packets that the target's access link becomes clogged, preventing legitimate packets from reaching the server.
  • Connection flooding. The attacker establishes a large number of half-open or fully open TCP connections at the target host. The host can become so bogged down with these bogus connections that it stops accepting legitimate connections.

I feel like there should be a fourth category that should also be included... Maybe something with a name like the cash drain attack. As AWS Lambda and other "infinitely" scalable technologies (ex.: AWS S3, Cloudfront, API Gateway) become more commonly used by organizations, likely bandwidth flooding and connection flooding will become harder and harder to do. However, the curse of infinite scalability is that you also have the potential for infinite billing, and especially for a service that calls an expensive API, like GPT-3 or machine translation, attackers may have the potential to leverage a small amount of capital (via HTTP requests) to force an organization to spend a much larger amount of capital.

For example, let's consider using AWS lambda to attack an application using AWS lambda. Let's assume that the victim AWS lambda function is so trivial that it takes 0 ms to execute, so that we are only paying for the per-request price of 20¢ per million requests. Using the following code running on an AWS lambda function with 128 MB of memory, I was able to send 100 GET requests out to a webhooksite URL in an average of 2500 ms of billable compute time, giving us approximately 25 ms of compute per request, or approximately 0.00313 GB-s per request. 
const https = require('https')
const URL = require('url')

async function request(url) {
    return new Promise((resolve, reject) => {
        let req = https.request(URL.parse(url))
        req.end(null, null, () => {
            /* Request has been fully sent */
            resolve(req)
        })
    })
}

exports.handler = async (event) => {
    var arr = [...Array(100)].map((_, i) => request("https://webhook.site/0357ebd6-6031-4a70-8858-6da68425bd25"))
    await Promise.all(arr)
    return 'done';
};
Assuming the price of $0.0000166667 per Gb-s of compute, it costs us around $0.05 per million requests, if we amortize the per request cost of launching the AWS lambda function. For those following along at home, that's 0.00313 GB-s/request * 0.0000166667 USD/GB-s * 1 million requests = $0.0522. Now, that's a "cost amplification factor" of 4(!) even without taking into consideration the cost of the load balancer or API Gateway the victim might be running in front of their lambda function, and also it doesn't take into consideration how much more efficiency we could achieve if the attacker were to not use lambda to do this and actually use a botnet or dedicated machines.

Another interesting example is the use of bot detection software such as the PerimeterX Bot Defender, which sells on the AWS marketplace for a price of 20¢ per thousand ($200 per million) requests. While ideally you would be able to ban bots via IP address, this actually becomes incredibly disruptive in practice because many ISPs implement CGNAT, which allows multiple households to share a single IPv4 address, so by banning a bot at a specific IPv4 address you also run the risk of banning multiple households using that address as well. Thus, many organizations have found that they must forward suspicious traffic to bot detection services like PerimeterX Bot Defender, but at a substantial cost, like 20¢ per thousand requests. A malicious actor, knowing that their traffic will likely be labeled as suspicious, sent to Bot Defender, and then dropped, could take a cash drain attack approach and attempt to send millions of suspicious requests to force the victim to pay thousands of dollars to PerimeterX. Assuming the attacker generates requests at a cost of approximately $0.05 per million requests (approximated in the AWS Lambda example above), the cost amplification factor is around 4000!

These are just two examples of probably the tons of application layer cost drainage attacks that came to mind.

Note from the Future: Skimming through the literature, it seems like there is a very cool emerging field of low-volume DoS attacks as well as Economic Denial of Service attacks (a much better name than "cash drain"!). See this post on the morning paper as well as this paper from USENIX's WOOT '16.

Comments

Post a Comment

Popular posts from this blog

First-Principles Derivation of A Bank

What is a Bank? A bank borrows money from people with money but low-risk appetite, and lends money to people who need money to take potentially rewarding risks. Say we live in a toy society with $10 in circulation and 2 people (a farmer and a cook). In this society, the farmer grows vegetables and the cook processes vegetables for food – both activities essential for survival. Assume that both parties start with $5 each. The farmer sells vegetables for $1 per serving and can produce 2 servings per day. The cook prepares food for $2 per serving and also has the capacity to produce 2 servings per day. Every day, the farmer sells 2 servings of vegetables to the cook for a total of $2 . Then, the cook prepares 2 servings of food and sells 1 serving to the farmer for $2 . In this perfectly balanced society, everybody eats, and money never needs to “rest.” Let's break the above equilibrium by adding a time component. In this society, vegetables take thr...
Read more

A Play-by-play of the Mirai botnet source code - Part 1 (scanner.c)

Today I've decided to start learning something very new and unfamiliar to me, as someone who mostly works with very high-level languages like Python and Kotlin, and attempt to understand the source code behind the Mirai botnet that managed to control over 380,000 IoT devices at one point in its life. I'll likely get a lot of things wrong the first time around, and this may take quite a few blog posts to complete, but my goal is to document everything I figure out, so that in the future, someone else in a similar position will be able to use this blog as a resource to understand the C and Go that ran this ground-breaking botnet. To begin, I'll start by reading  scanner.c , which is the code that is in charge of the scanning for and infecting new IoT devices. I'll be taking my time with it, so this might take a few blog posts. scanner.c  has most of its logic in a function called  scanner_init , which is triggered either from  main.c  (which seems like how it is t...
Read more

You can control individual packets using WinDivert!

Image
WinDivert is one of the most interesting packages I've recently come across. What WinDivert allows you to do is apply a filter to grab some subset of packets that pass through your Windows computer, and then apply some logic to the packet to maybe modify, and then drop or re-inject the packet. Here's a great diagram from this website that sums it up: Using PyDivert , a WinDivert Python binding, we can specify the PROGRAM portion in the above diagram, which means that we can now capture whatever packets we want, change them however we want, and then either drop them or re-inject them to be sent out whenever we want. The big sell here is that WinDivert allows you to play with packets on Windows without writing code that modifies the core operating system components that run in the kernel! The drawback is of course speed and efficiency, but for a lot of blog-post-worthy applications, we don't need that much speed and efficiency. Stay tuned for more stuff if this piqued your ...
Read more