The thing with 0-day Java Vulnerabilities is…

A few days ago, KrebsOnSecurity published a very well written article discussing a new 0-day Java vulnerability, and its effect on the Bit9 Hack. now lets be honest – Java Vulnerabilities are the hottest thing in security news right now.. if a week goes by without a new 0-day, someone is slipping or sleeping.

I would like to look at this from a different angle for a second, the threat landscape angle and the trending.

It is very interesting to see the changes in Hackers approach from reversing protocols and platforms for vulnerabilities that are usually platform dependent, and relying more and more on overarching architectures such as Java and Flash etc, which are platform agnostic.

This creates an interesting threat landscape that has the multiplatform effect. It is very common to mistake reports that say that Microsoft platforms or others are now less vulnerable than in the past. I believe that its just a matter of Hackers changing focus.

Taking a deep look into industrialized hacking, it fits the model well, by hunting for the latest and greatest vulnerabilities and perhaps buying them from a vulnerability broker that deals with 0-days, Hacker groups are able to leverage indirect campaigns and hit large numbers of infections or data theft. just look at the latest Attack that hit Facebook, Twitter, Apple, Microsoft and others. it was defiantly not a directed attack but an attempt to hit numbers. interesting enough it used a Java 0-day as vector of infection. this hit many organizations with different platforms and methods of securing themselves.

Java is the thing that everyone now blame, but yesterday it was the Microsoft platforms, and tomorrow it will be something else. its not about what’s more secure, its about what Hackers focus on.. at the end of the day, we should always look at the shortest funnels to cash, just like Hackers do. until then… keep your cup of coffee clean.

Looking into

I had some time finally to play around with Refref ( originally written for Anonymous ), and i really liked it. for those of you who are unfamiliar with Refref, it is an application denial of service tool, which uses an interesting vector of attack making it very effective. to my knowledge it exists as either a perl script or a javascript flavor in the wild.

the interesting thing about the javascript flavor is the ability to then run it off simple devices such as mobile smartphones or tablets, rendering it more effective for the ease of getting one hacktivist on board with using it without running perl or downloading software.


The way that Refref works, is by exploiting an SQLi in the front end web server, it injects an SQL command that effects an unprotected database server and exhausts if from its resources. as far as i know, it effects only mysql servers, however, they seem to be the majority of the backend db servers for many of todays websites, and least as the most upfront database tier.

the SQL command in use is the benchmark() function in mysql, that basically evaluates input for a number of times. normally that command should not be allowed to be executed by the database user that the application server is using, but in many many cases it remains unhandled and is in fact a vulnerability.

The payload code snippet out of (source can be found here) :

sub now {
  print "\n[+] Target : " . $_[0] . "\n";
  print "\n[+] Starting the attack\n[+] Info: Control+C to 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";

Looking at the payload we could easyly identify the function that is being injected as payload is


So basically, evaluating the Hex term presented, 99999999999 times. converting Hex to Ascii will render the term 0x70726f62616e646f70726f62616e646f70726f62616e646f into “probandoprobandoprobando”, which translates to “testingtestingtesting” in english.

The evaluation CPU time that is required to run the function is what generates the denial of service on the mysql server. When I tested this on a Mysql ( latest community version available today ) has brought my server to its knees in 2-3 seconds, rendering 99-100% CPU utilization and effectively denying it from serving any information to the client. so very very effective.

My Take

although refref in its current form is quite effective, the payload implementation works in a way that old DOS tools usually work which is to knock on the door until it breaks, but im uncertain if that is neccesary in an Application DOS attack, since refref is based on deploying a command to the server and making it busy.

I therefore have altered the payload function to the following form and ran the test again :

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

All I did here is really just taking the loop out and making it into a single request attack.

The result was the same, the server got to 99-100% utilization on evaluating the request. I guess that the reason to include the original loop is to generate a normal traffic jam, to be added to the payload, but if used in the way that I have, you get to have a nice run-by attack, killing the service with just a single request. My guess is that when author wrote the original tool, he/she/they had either different experience or a larger environment where it mattered.


  • (Frontend) So, my take is that a Web Application Firewall should be able to handle this tool using standard SQL Injection mitigation techniques, since the vector of attack is in fact SQLi to inject the function payload.
  • (Backend) I would suggest hardening the Database by not allowing non-dba users to run the benchmark function, and also harden the user configured on the web front end to not be able to run any database function that is not necessarily for its operation.