HTTP Web Server Overload Attacks
by Scott RegisterCheck out our Rethink DDoS Testing Methodology for more information or to learn how to replicate a variety of DDoS and botnet attacks.
In my last blog post I discussed HTTP DDoS Flood Simulation and today I’m going to shift gears slightly and look at HTTP Web Server Overload attacks. We’ve spent a lot of time discussing validating the resiliency of individual network components; now, we’re going to take a slightly different approach and search for weaknesses in an application delivery infrastructure. Specifically, I will demonstrate how to produce application-level attacks on your web service infrastructure, including subtle attacks, which exhaust CPU resources on your servers through operations which request objects not in cache or making repeated and expensive changes such as shopping cart updates. We will review several options for generating these attacks and I invite you to modify these for use in validating your own web server infrastructure to understand how it will handle both positive and negative traffic. Let us know how it works in the comments section.
Let's get started.
Exercise 1 – Expensive Searches
You can use the BreakingPoint Storm CTM to validate your servers and critical applications before bringing them online, as I’ll demonstrate here. First, we’ll start by producing queries against Google, which is nice enough to provide response-time metrics. We can first experiment using a browser to find some fairly expensive results -- those with few results and which take a relatively long time to complete. For example, one I came up with is a search for “-dealer -computer -apple -software -games -OS -TV +steer +peas +reptile +jazz +leaf +Canada”, with search times (on an initial search) ranging up to 0.47 seconds, a long time by Google standards. I also see that although the initial request can take this long to resolve, subsequent requests for the same string are much quicker (down to 0.17 seconds), probably because the results are already in the Google cache. To test this repeatedly, I can either keep reloading the browser, or use a tool like wget. In this case, I didn’t really care about the results themselves, just how long they took -- so I pull out the time for the query from the results. I take the query string from the browser string, plug it into wget, and strip the response time out from the results. My command line looks like this:
wget --user-agent "Firefox" -qO- "http://www.google.com/search?source=ig&hl=en&q=-dealer+-computer+-apple+-software+-games+-OS+- TV+%2Bsteer+%2Bpeas+%2Breptile+%2Bjazz+%2Bleaf+%2BCanada&hl=en&sa=2" | perl -pe 's/.*(\(.*\..* seconds\)).*/$1/' | grep seconds
From this, I can see how long each query takes, and see that when I execute the same query repeatedly the time goes down. Because repeated queries are faster, I want to change my sequential queries so that they aren’t cached.
Next, I’ll assemble several of these queries with fairly high response times and put them into a file, Slowgets.txt.
File Contents:
www.google.com /search?source=ig&hl=en&q=%2Bski+-snow+-water+-games+-Vail+%2Bhamburger+- shores+%2Bpigeon+-dating%2Bwheat+-restaurant+%2BNebraska&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1 www.google.com /search?source=ig&hl=en&q=-animal+-rental+-new+-repair+-review+%2Bcar+-truck+- image+%2Bmats+-Celtics+%2BBoston+-rubber+-accessories+%2Bgarage+%2BPorsche+-sale+- dealer+%2BJeep&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1 www.google.com /search?source=ig&hl=en&q=%2Bschool+-book+-student+- learn+%2Bboard+%2BParish+%2BWashington+%2Bmedical&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1 hwww.google.com /search?source=ig&hl=en&q=%2BRussia+-travel+-geography+-energy+%2Bonline+%2Breligion+- society www.google.com /search?source=ig&hl=en&q=wireless+-radio+-phone+%2Btrombone+- instrument+%2Bmonitor+%2Bpizza+-Louisiana+-technology+&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1 www.google.com /search?source=ig&hl=en&q=pitchfork+-farm+-animal+%2Bjello+-biafra+- album+%2Bchainsaw+%2Bantique&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1 www.google.com /search?source=ig&hl=en&q=fern+-bluff+%2Boctopus+-herb+-plants+%2Bmenu+-sushi+- restaurant+%2Billegal+-animal&hl=en&ei=eMh_TKHwDMP98AbwrISFBA&start=80&sa=N
I’m going to test this first using the BreakingPoint Storm CTM Application Simulator (AppSim) component, or “two-armed” testing, to make sure everything is set up correctly. I’ll create an AppSim test called “Blog Post Cache Miss DOS”. For my Network Neighborhood, I’ll use generic client IPs but real IPs for Google web servers, 74.125.227.16-20 and label it “Blog Post Cache Miss AppSim”.
I’ll configure my test to run at a fairly low rate, with only one connection per second and one concurrent session. If I were testing my own infrastructure, I would set these numbers much higher.
A useful feature of the BreakingPoint Storm CTM is that we include a 2GB capture buffer on each port. I can apply filters to the capture buffer to limit what they store, but in this case my traffic volume is fairly low and that’s not needed. I can click Export on the Device Status screen and import the resulting PCAP file directly into Wireshark, a popular protocol analysis tool (speaking of which, check out Eric Reeves two-part post on protocol analysis).
To verify that things are working as expected, I’ll run this test and examine the results in Wireshark:
To verify the realism of our simulation, I’ll run the same query from my laptop and capture the results:
The user agent is different, but the queries are substantially identical, so I’m confident that I can point the BreakingPoint Storm CTM at the actual Google server.
Next, I’ll move over to the BreakingPoint Storm CTM Client Simulator (ClientSim) component and point my queries at a live server. We see that my queries are not at a distressingly high rate:
And, using Wireshark, I can verify that my queries are working correctly and I’m getting the answers I expect, complete with response time:
Exercise 2 - Shopping Cart Mischief
Repeated queries against a database for results not in cache are one way to stress web infrastructure. Another is performing expensive manipulations, such as operations on a shopping cart. In the next example, I’ll show how we can use the BreakingPoint Storm CTM to perform such manipulations. You could use such operations against your own infrastructure to see how well it performs under this common and potentially debilitating scenario. It’s important to validate your own application infrastructure against these types of attack, as they are subtle, dangerous, and growing in popularity relative to traditional network flood-based attacks.
For this example, I used a web site from a sporting goods store. I experimented using my browser to understand how shopping carts were manipulated, and I found a site where I could manipulate the cart just using the URL (as opposed to an .aspx site). And since I actually shop there and generally like to be a nice guy, I’m going to change the name of the site in this write-up.
I added a new domain to my External Interface in the Network Neighborhood for this site, “Shopping Cart Host”, which contains the IP address of the site I’m targeting.
The shopping cart I analyzed was available at http://www.[NAME_REMOVED].com/cart/.
Adding an item to the cart, I see the following URL:
http://www.[NAME_REMOVED].com/cart/addItem/?product_id%5B%5D=25&color%5B%5D=Army%3A5+- +%2422.50%236+-+%2422.50%237+-+%2422.50%23Medium+-+%2422.50%23X-Large+- +%2422.50&size%5B%5D=Medium+-+%2422.50&product_price%5B%5D=&qty%5B%5D=1
Notice how not only the quantity but also the pricing information are encoded in the URL? Modifying the item to put two of them in my cart, at a significantly reduced price, produces the following URL:
http://www.[NAME_REMOVED].com/cart/updateItem/?ci=1&product_id=25&color=Army%3A5+- +%2412.50%236+-+%2412.50%237+-+%2412.50%23Medium+-+%2412.50%23X-Large+-+%2412.50&size=Medium+- +%5C%2412.50&product_price=&qty=2
Using ClientSim and the new GetURIs feature, I’ll construct a series of URIs which populate a cart, modify the items (and their prices), then empty the carts and reload them.
Sure enough, using Wireshark to analyze the response from the site, I see the populated cart with my special discount:
And removing the items produces the following:
http://www.[NAME_REMOVED].com/cart/removeItem/?ci=1
I kept my query rate intentionally low, but looking at the report from the test, I can see the response times steadily creeping up throughout the duration of the run:
I didn’t want to risk damaging the site, but it would have been easy to overwhelm it, especially with the cart modifications. How would your site stand up to such queries? There’s only one way to find out!
Download the BreakingPoint DDoS/Botnet Methodology for more tips.
