Tags: , ,
Posted by: peter

My Canary Smart Home Security device arrived yesterday and now that I’ve had 24 hours a play with it I thought I’d write up my impressions.

It arrived in a large box which had the smaller Canary box in it as well as a really cheap North American to Australian power adaptor rattling around loose in the box. Given that I’d pre-paid 200 bucks and waited just over 18 months for this device to arrive seeing a 50 cent adaptor (Which I’d never actually use due to the fire risk) as the first thing when you open the packaging was a bit jarring.

Having said that, the actual Canary box has a premium feel and was pleasing to open with the Canary itself sitting nicely visible once you remove the lid along with a couple of high quality cables. As expected the power adaptor was an American blade style but as the Canary itself uses a micro USB socket for power I just plugged it into a smart phone charger that I already owned.

The device setup procedure is via the Canary smartphone app which then transfers the configuration via a standard audio cable plugged between the smartphone and the Canary which is a nice touch.

This was where I hit my first snag. The Canary simply refused to connect to my Wireless LAN, so I had to arrange an ethernet cable for it before it would connect up to the internet. At this point it automatically downloaded an update (all the while keeping me updated via the smartphone app)

After the device rebooted it came up straight aware and started working. As part of the setup process you are asked to pick your location from a Google map so that Canary can set up a geofence around your home which it uses to sense when you leave home in order to automatically arm the security features of the device. Unfortunately this feature works particularly poorly and decides that I’m entering and leaving my home multiple times per hour even though I’ve been sitting on the sofa the entire time. It continued to do this several times throughout the night with status changes between 4 and 5 am when I was most definitely asleep and my phone wasn’t moving anywhere.

The app let me invite my wife to access the Canary device also which works as expected giving her full access once she created an account for herself. Unfortunately she is also experiencing the same geofencing issue that I experience which means that the device constantly thinks that one of us is away.

The environmental sensors are a particularly nice touch (and one of the main reasons why I backed this project rather than buying a readily available D-Link device 18 months earlier) however despite asking me my location in order to setup the geofence, the software wasn’t smart enough to figure out that like most of the world I have no idea what a Fahrenheit is. After poking around in the application I found the switch to convert to the Celcius temperature scale and the graph started to make sense. (The smart thing to do would be to have the app default to Celsius instead of Fahrenheit and select Fahrenheit automatically if you geofence a location in North America)

So far in the 24 hours that I’ve been using the device it’s spent about 6 hour “offline” which I assume means that something is wrong with the Canary server infrastructure. If it continues like this it wont be very useful as a security device..

Posted by: peter

I recently had to setup some openSUSE Linux boxes which will be used to capture add-hoc network traffic for debugging purposes. As there will be multiple users with the need to do this, I wanted to allow the use of tcpdump by non-root users. This is fairly straight forward to accomplish using file system capabilities, but as it’s not clearly documented anywhere else here is what I came up with:

  1. First install tcpdump and libcap-progs:

    zypper install tcpdump libcap-progs
    
  2. Then create a dedicated group called pcap for users who should be able to run tcpdump and add your user to it:

    groupadd pcap
    usermod -a -G pcap peter
    
  3. Modify the group ownership and permissions of the tcpdump binary so that only users in the pcap group can run it:

    chgrp pcap /usr/sbin/tcpdump
    chmod 750 /usr/sbin/tcpdump
    
  4. Set the CAP_NET_RAW and CAP_NET_ADMIN capabilities on the tcpdump binary to allow it to run without root access (These options allow raw packet captures and network interface manipulation):

    setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
    
  5. Optionally, check that the permissions are correct:

    # ls -l /usr/sbin/tcpdump
    -rwxr-x--- 1 root pcap 770776 Feb 19  2011 /usr/sbin/tcpdump
    
    # getcap /usr/sbin/tcpdump
    /usr/sbin/tcpdump = cap_net_admin,cap_net_raw+eip
    
  6. Optionally, symlink the tcpdump binary to a directory that is in the path for a normal user:

    ln -s /usr/sbin/tcpdump /usr/local/bin/tcpdump
    
  7. Optionally, configure the SuSEconfig permissions module so that it wont reset the file permissions next time you run it by adding the following to the bottom of /etc/permissions.local

    /usr/sbin/tcpdump             root:pcap       0750
     +capabilities cap_net_admin,cap_net_raw+eip
    
  8. Inform that Linux kernel that it should enable file system capabilities at boot by adding the following option to the kernel line in /boot/grub/menu.lst:

    file_caps=1
    
  9. Reboot to enable file system capabilities

Posted by: peter

Harald Welte, has written on his blog about operating an Open Source GSM network at the recent HAR2009 conference. Photographs and a description and of the setup, run under license of the Dutch regulatory authority, are provided; essentially the setup consisted of a pair of BTS’ (Base Transceiver Stations) running at 100mW transmit power each and tied to a tree. In turn these provided access to the Base Station Controller (BSC), in this case a Linux server in a tent running OpenBSC. The system authenticated users with a token sent via SMS; in total 391 users subscribed to the service and were able to use their phones as if they were on any other network. Independent researchers are increasingly examining GSM networks and equipment, Welte’s work proves that GSM is in the realm of the hackers now and that this realm of mobile networking could be set for a few surprises in the future.

I just discovered Pyrit which takes a step ahead in attacking WPA-PSK and WPA2-PSK, the protocols that protect today’s public WIFI-airspace.

Pyrit‘s implementation allows to create massive databases, pre-computing part of the WPA/WPA2-PSK authentication phase in a space-time-tradeoff. The performance gain for real-world-attacks is in the range of three orders of magnitude which urges for re-consideration of the protocol’s security. Exploiting the computational power of Many-Core- and other platforms through ATI-Stream, Nvidia CUDA, OpenCL and VIA Padlock, it is currently by far the most powerful attack against one of the world’s most used security-protocols.

I continue to be amazed by the widely varied uses that these hardware graphics accelerators can be put to!