Taking a Look at #RefRef – The Latest Denial of Service Tool From Anonymous

The hacking group Anonymous recently released a new denial of service tool called #RefRef.  Previously the tool of choice for Anonymous supports was Low Orbit Ion Cannon (LOIC).  LOIC is basically a brute force denial of service application that floods the target with TCP or UDP packets.  Unlike LOIC #RefRef uses an SQL injection vulnerability to take down the target server by using resource exhaustion.  I decided to download the new tool and take a closer look into how, and why it works.

Taking a look at the source

#RefRef is written in Perl making it platform independent.  Perl is included with most Linux distributions but it is not installed on Windows by default, it’s fairly trivial to install Perl on Windows 7 though.

The entire program only contains 51 lines of code, it’s pretty simple but very powerful.  The meat of the exploit can be found in the subroutine below.  The code injects the select benchmark command to the remote server.

sub now {
print "\n[+] Target : ".$_[0]."\n";
print "\n[+] Starting the attack\n[+] Info : control+c for stop attack\n\n";
while(true) {
$SIG{INT} = \&adios;
$code = toma($_[0]." and (select+benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f))");
unless($code->is_success) {
print "[+] Web Off\n";
copyright();
}}}

What does this payload do?

The benchmark function is a legitimate MySQL command that instructs the server to evaluate an expression X number of times.  This is useful for benchmarking a server to find out how long it takes to execute a query.

The command below instructs the remote server to evaluate the expression “0x70726f62616e646f70726f62616e646f70726f62616e646f” 99,999,999,999 (100 trillion) times, this takes a lot of CPU time to do.

select benchmark(99999999999,0x70726f62616e646f70726f62616e646f70726f62616e646f)

Looking deeper the expression 0x70726f62616e646f70726f62616e646f70726f62616e646f is in hex, if we convert this to ascii we get “probandoprobandoprobando”, which is probando repeated 3 times.  Probando translates to “testing” in English.

So in short the code is asking the server to evaluate the phrase “testing” 100 trillion times.  This results in the server using it’s own processing power to become overloaded, the more power the server has the faster it will crash.

Testing #RefRef

I don’t recommend testing this program out on anything besides a test server that you own, plenty of people were arrested last year for blindly running LOIC against public targets.

I tested running #RefRef on a Windows 7 x64 box, the target machine was running MySQL version 5.5.83.

When you run the perl script without any parameters it outputs the syntax usage which isn’t very helpful.

The basic usage of the program is perl ./refref.pl Target_URL.  The script cannot just be blindly pointed at any target server, it must be targeted against a URL which runs a database query on the remote system.  Not all servers are going to be vulnerable to this type of attack.

Once started RefRef will continue to connect to the server and send the injected SQL commands until it is terminated with CTRL+C.  These queries can stack up very quickly on the remote server and cause the database to stop responding.

It only took about 25 seconds before the remote MySQL server stopped responding.

The CPU core that MySQL was running on , (#4) became very busy as you can see below.

Looking at the Exploit in Wireshark

Looking at #RefRef in Wireshark shows that it only takes a total of 10 packets to connect to the remote server, send the exploit, then disconnect.  It looks like a normal HTTP GET request until you notice the request being sent to the server.

If you want to filter a packet capture for the injection packet then use a display filter of “frame contains 0x70726f62616e646f70726f62616e646f70726f62616e646f” and you will see only the packets which contain the payload.

Below you can see the entire conversation between the client and the server.

• Frames 1-3 –  Standard 3 way TCP handshake
• Frame 4 – HTTP GET request with the SQL injection appended to the end of the request.  (0%20 and 0%20(select+benchmark)
• Frame 5 – Server sends an acknolegement to the attacker
• Frame 6 – Web server sends a response code of “200 OK”
• Frames 7 – 10 – TCP connection is gracefully terminated.

Protecting Servers Against #RefRef

There are a few different things that can be done to protect servers against exploits such as this one.  The most important thing to remember is that web code should be hardened against SQL injection.  All input received from the client side should be sanitized to make sure nothing extra is being passed to the database.  PHP.net has a useful article that talks about SQL injection avoidance techniques which can be used.

Another method of protection is to block SQL commands from being inserted into HTTP requests using a .htaccess rule.  I wouldn’t recomend soely relying on this method but it’s never bad to throw in some extra security where you can.

RewriteEngine on
RewriteCond %{QUERY_STRING} .*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC]
RewriteRule .* - [R=406,L]

If you have a Snort IDS setup on your network make sure you’re rules are up to date.  There are a couple of different rules which are designed to detect #RefRef attacks on your network.

 * 1:19870 <-> ENABLED <-> DOS Anonymous Perl RefRef DoS tool (dos.rules)
 * 1:19869 <-> ENABLED <-> DOS Anonymous PHP RefRef DoS tool (dos.rules)

The concept of SQL injection attacks is not new but this exploit demonstrates that they are still alive and well!