EXIF Cross Site Scripting, PHP Fun

As most security folks know, there are numerous ways to infect computers via infected image files, that contain binary viruses which are read/invoked by different image readers or the libraries that render them.

From my perspective, looking into web application security, I had an idea..

Many websites and applications nowadays, look into the picture’s EXIF information in order to extract valuable data such as the size, date, exposure, geo location, and basically any meta piece of information. well, some of the attributes are writable :)

I decided to design an experiment that will check if we can inject code directly into an EXIF tag and see if the application interpreters will execute on it. Even though I am sure that this sort of experiment has already been done in the past, but learning through experimenting is what I live for.

The Experiment

The experiment breaks into 2 sections:

  1. Will a standard JPG accept characters that are required for a simple Cross Site Scripting attack
  2. Will industry standard interpreters execute on the EXIF tags when read

First thing I did, was to install exiftool and reading the metadata off a picture that I took with my smartphone, and looked for an updatable EXIF field. For sake of this experiment, I went for the “Comment” tag, and simply wrote “barry” in it.


As you can see, the field was updated. Now, to conclude the first part of our experiment, I updated the field with a simple XSS test string to see that its accepted. It was.

We can conclude that the EXIF field accepts any character, and in specifically a string that is required for a XSS attack.

To check the second part of our experiment, I used a PHP server on a commercial hosting service (which is running what they consider their best practice PHP deployment), uploaded the manipulated image, and created the following code to display the EXIF information:



It is important to note that exif_read_data is a standard PHP function that reads the EXIF information into an array, and I used the “echo” command to loop through the output.

Here is the result:


We have therefor proved the second test in the experiment, there was no problem displaying an unchecked string from EXIF and running it as standard script. the XSS vector is valid.

Who Should Care?

With many websites accepting image uploads (some through mobile interfaces), and analyzing EXIF information to determine resolution, location, owner and other pieces of data – there is a risk of a web application attack. In this case we have achieved an XSS (Cross Site Scripting) attack, but this information could have been extracted/inserted into a database – enabling SQLi (SQL Injection) attack on the database.

The underlying problem does not reside in a simple echo of the malicious string.  Meta data is usually saved within the application database, on an application that parses through this kind of information (lets take any image broker including some of your favorite mobile apps). they keep this kind of meta data for indexing and search purposes. this effectively means that one could inject a Persistent XSS or an SQLi string into the database, and have it execute under certain conditions. not a good thing.

I believe that it is important to run filter engines on EXIF metadata just as if it is a normal web attack or a script injection vector.


CMS Hacking, Risks and Trends.

cmslogomeshYesterday, I presented in Imperva‘s monthly webinar (my employer and source of joy) the results of a trend analysis that i recently completed, which includes the research results in detail.

We explored through the trends of CMS adoption in the market, a threat analysis of hackers trends with 3rd party code/software and CMSs specifically, and we went on to show how does a hack campaign looks like either by an individual or by a botnet for industrialized cyber crime.

Today Imperva has uploaded the presentation for those of you who weren’t watching the live webinar but still interested in the presentation, Here it is. also check Imperva’s website for the live recording of the webinar.

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.

HULK, Web Server DoS Tool

Introducing HULK (Http Unbearable Load King).1-twitter-dos-data

In my line of work, I get to see tons of different nifty hacking tools, and traffic generation tools that are meant to either break and steal information off a system, or exhaust its resource pool, rendering the service dead and putting the system under a denial of service.

For a while now, I have been playing with some of the more exotic tools, finding that their main problem is always the same… they create repeatable patterns. too easy to predict the next request that is coming, and therefor mitigate. Some, although elegant, lack the horsepower to really put a system on its knees.

For research purposes, I decided to take some of the lessons I’ve learned over time and practice what I preach.

Enforcing Python’s engines, I wrote a script that generates some nicely crafted unique Http requests, one after the other, generating a fair load on a webserver, eventually exhausting it of resources. this can be optimized much much further, but as a proof of concept and generic guidance it does its job.

As a guideline, the main concept of HULK, is to generate Unique requests for each and every request generated, thus avoiding/bypassing caching engines and effecting directly on the server’s load itself.

I have published it to Packet Storm, as we do.

Some Techniques

  • Obfuscation of Source Client – this is done by using a list of known User Agents, and for every request that is constructed, the User Agent is a random value out of the known list
  • Reference Forgery – the referer that points at the request is obfuscated and points into either the host itself or some major prelisted websites.
  • Stickiness – using some standard Http command to try and ask the server to maintain open connections by using Keep-Alive with variable time window
  • no-cache – this is a given, but by asking the HTTP server for no-cache , a server that is not behind a dedicated caching service will present a unique page.
  • Unique Transformation of URL – to eliminate caching and other optimization tools, I crafted custom parameter names and values and they are randomized and attached to each request, rendering it to be Unique, causing the server to process the response on each event.


Basically my test web server with 4gb of Ram running Microsoft IIS7 was brought to its knees under less than a minute, running all requests from a single host.

In the pictures below you can see the tool in action, where it first ( #1 ) executed against a URL, and then the tool starts generating a load of unique requests and sending over the target server ( host of the URL ), and second ( #2 ) we can see that the server at some point starts failing to respond since it has exhausted its resource pool.


Note the “safe” word is meant to kill the process after all threads got a 500 error, since its easier to control in a lab, it is optional.


File : hulk.py ( via Packetstorm )

The tool is meant for educational purposes only, and should not be used for malicious activity of any kind.


[ Edit 25nov2012 : changed download link to packetstorm ]

Looking into Refref.pl

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 refref.pl (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.