Smart Locks

Earlier today I posted on twitter asking for some input on smart locks.  I’d read some, but didn’t consider myself particularly educated on the topic.

Screen Shot 2017-11-20 at 11.42.02 PM

I got a few responses and a helpful retweet, but not enough depth for what I was looking for.

So I started by googling things like “smart lock” and “best smart locks”, etc… to get an idea of the major manufacturers.  I was shocked by how many are out there.

I have a few things I was looking for to help narrow down the search:

  1. This is going on a front door so it should match a handleset (one of those long ornate looking handles on front doors).
  2. My wife just replaced all the other door handles in the house, so I’d like it to match those as closely as possible.
  3. I want to be able to lock or unlock the door remotely.
  4. It should allow me to add or delete user codes without physically touching the lock.
  5. I’d like it to be able to tell me if the door is locked or unlocked remotely.
  6. Battery life shouldn’t be horrible.

Like all other home automation projects I also look for:

  1. It should not be obnoxiously futuristic/stand out more than it has to.
  2. It should be backwards compatible with non-smart items, so I would like it to take a key.
  3. I would like it to be controlled by my home-assistant hub.
  4. I would like the home-assistant control to avoid using cloud services as a middle-man.  Even better if the device never talks outside the house at all.
  5. My preference for control protocols are Wi-Fi, with Z-Wave as a backup.  Zigbee/Bluetooth/others I’ve avoided successfully to date, but can be a last resort.

 

Reading through the google results made me start to realize that a ton of the locks are using BTLE.  This makes sense based on the lower power draw, but it made me start to think I might have to use Bluetooth for the first time.  My automation is hub is nowhere near the front door, so that was going to be a pain.

So I started by looking at how people attacked BTLE smart locks and found these two talks:

https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Rose-Ramsey-Picking-Bluetooth-Low-Energy-Locks.pdf

https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Jmaxxz-Backdooring-the-Frontdoor.pdf

These cover a mix of poor implementations or attacks on the cloud infrastructure.  Interesting reads.  Also, as I looked further I found that the BTLE locks are starting to include little devices that plug in near the door to pair the lock.  The device then bridges the lock to Wi-Fi.  Pretty cool, and might make a properly implemented one usable for me!

Screen Shot 2017-11-21 at 12.06.06 AM

Unfortunately, none of these seem to work over the LAN only with home-assistant, so I moved on with my search.

I focused in on Z-Wave locks next and found a few solid ones.

After some skimming through some Z-Wave specific shops I narrowed down to looking at Schlage, Yale, and Kwikset.  Yale immediately was removed for not matching aesthetics/handlesets, so I was down to the well known door lock companies Schlage and Kwikset.

Next on to the security of Z-Wave I came across a talk: https://github.com/AFITWiSec/EZ-Wave/blob/master/ShmooCon2016_presentation.pdf

Slides are pretty useless there, but they do have a video (I haven’t watched yet) and did an interview about the research.  They state in the interview that they were able to easily control Z-Wave devices that don’t use encryption, but they were not successful in attacking the door locks made by Schlage, Yale, and Kwikset that were properly encrypted.

However, diving deeper I found a more in-depth bit of research presented in 2013 that outlined forcing encryption key re-issuing to a rogue controller: http://neominds.org/download/zwave_wp.pdf

The device happily allows the rogue controller to tell it to re-issue a key, and the rogue device can now control the lock.  Their paper claims that Sigma Designs (owners of Z-Wave) have fixed the bug, but getting manufacturers to confirm that will likely be near impossible.  It’s IoT after all!

I decided that the risk of all 20 people near me with the skill and determination to do this stopping by AND defeating my alarm system and cameras was a low enough risk and dove more in to these two locks:

https://www.schlage.com/en/home/keyless-deadbolt-locks/connect.html

https://www.kwikset.com/products/styles/smartcode-916-touchscreen-electronic-deadbolt.aspx

Both meet all of my requirements above, with the Kwikset having an exact match to what my wife just put in the interior of the house.

I found that Schlage is based in Colorado (woo!) and that their lock received a BHMA grade 1 (longer lasting) vs the grade 2 that Kwikset got.  After reading some Amazon reviews I also found that the Kwikset lock has some fairly widespread issues with the touchscreen having lags, not responding, or even cracking.  Fairly universally people said that Kwikset’s push-button model was recommended over the touchscreen.

Lastly I read some lock picking items about each lock and found a pretty massive problem with the Kwikset’s “SmartKey” technology.  Apparently the lock cylinder can just be forced open with any flat tool.  I was happy to see this was fixed in the 2016 timeframe with a more up to date video explaining the differences in the new mechanism.

If anyone else wants to take this journey I would recommend the Schlage as it is currently $50 cheaper on Amazon, has a more traditional lock core, less touchscreen complaints in reviews, and is a higher grade of material.

Personally I took the chance on materials with the Kwikset lock to match the other handles we just replaced, but I’d be interested in hearing what others have done and what their experiences were.

Screen Shot 2017-11-21 at 12.56.44 AM

Hope this was helpful to someone!

 

Photo Sharing

I take a lot of pictures of my family.  For Christmas two years ago my wife gave me a Panasonic Lumix  DMC-FZ70 (https://www.amazon.com/gp/product/B00DY2Y28M/) and it has been great.  The low-light action shots remind you it isn’t a DSLR, but any other uses and 60x optical zoom perform exactly as advertised.  It’s been a great camera.

Unfortunately, I don’t always get off my butt and take the pictures off the camera and share them quickly.  So last year I added an Eye-Fi 16GB Pro X2 card to my wish list and my wife gave me one last Christmas.  I setup the card to use the WiFi network in my house and when that wasn’t available to tether to my phone to copy pictures off the SD card.  This meant that wherever I was pictures would be transferred off the camera automatically.

Eye-Fi offered a free service to get the pictures from the camera to my house as long as I left a client running on my home computer.  The Eye-Fi software also had a feature called “Endless Memory” that auto-deleted pictures from the card after it hit a certain fill point as long as they had been copied off the camera.  It even had a config to copy the pictures to Flickr automatically.

On Flickr I set all uploads to private and only shared them with my wife and other family members. Flickr allowed unlimited full resolution photos to be uploaded to my account, so I never had to maintain anything there.  The only issue I ever had with the setup was when tethering through my cell phone with poor cell coverage.  Other than that, it was relatively flawless and it meant that my wife had near immediate access to every picture taken.

Then… Eye-Fi decided to completely strand their customers and announce the complete termination of Eye-Fi X2 support (X2 Migration) starting September 16th 2016.  They had some misleading statement about not selling them anywhere after March 2015, although I’m positive they made no effort to remove them from Amazon when my wife bought me one for Christmas nine months after that.

So I was going to get less than a year use out of my card.  Pretty infuriating.

This left me in search of a cost effective method to wirelessly get pictures off my existing camera.  Over the summer I searched every option I could find and nothing really recreated the full solution I had before.  Eye-Fi was pushing their new mobi cards, and I could buy a new card for $70 and pay them $50/yr to use their cloud service.  If I bought the “pro” card, I could recreate what I had before short of the endless memory feature.  However, I stopped short of doing this since it was not a like-for-like replacement and my current card hadn’t broken yet.

Plus, I really had no desire to pay any money to the company that was screwing me in the first place.  Having procrastinated a few months that now looks like it was a very good decision. They ended up getting enough customer pressure to release a lightweight desktop client to allow camera transfer when on the same network.  Their company is clearly failing (What’s going on with Eye-Fi?) as more cameras are supporting Wi-Fi natively now.  And they possibly have some patent issues with Toshiba.  It looks like they’re trying to become a software company as well (Introducing Keenai.).  Given how badly they wrote software in the past this probably won’t end well for them.

Armed with their new desktop client (Download Eye-Fi X2 Utility) I resurrected the ability to wirelessly get pictures off the camera to my computer.  The client they released removed the Endless Memory feature, has no ability to share with third party services, and provides no outside-the-house capability.

To recreate the third party sharing part of the workflow I had before, I took a look at the Flickr desktop uploader app.  Unfortunately that app is only supported with Flickr Pro which is $50/yr.  Then I looked at Google Photos, which will charge me for the storage I use to store full resolution shots.  That would quickly add up to $120/yr.

Enter Amazon Cloud Drive and their brand new desktop sync client.  As a Prime customer, Amazon gives me unlimited photo storage for full resolution photos and the ability to have a “family vault” where I can share pictures with my family.  The pictures are easily viewed in their mobile apps, something my wife and I enjoyed with the Flickr app.  The latest update to the desktop mac app that was released this last week also properly looks for file updates, uploads the new files to cloud drive, and has an option to auto-add all pictures uploads to the family vault.  Perfect solution, right?!

Almost.  If I set my Eye-Fi desktop client to copy to my Amazon Cloud Drive folder, then importing the pictures in to Photos.app becomes difficult to manage what has been imported and what hasn’t.  Also, if I deleted the pictures after importing them, then my wife wouldn’t be able to see them in the Prime Photos app any longer.

So, I came up with a one-way copy from the Eye-Fi upload folder to the Amazon Cloud Drive folder as my solution.  This leaves every picture I’ve taken on Amazon and lets me delete them from the Eye-Fi folder after I import them in to Photos.app.

To do that, I either needed to watch the folders for changes, or just sync them on a periodic basis.  I chose the latter for simplicity.

First, I needed to write a short shell script to do the one-way synchronization with rsync:

$ cat ~/bin/photosync.sh
#!/bin/bash

/usr/bin/rsync -a /Users/mikeb/Pictures/Eye-Fi/* /Users/mikeb/Amazon\ Drive/Pictures/Eye-Fi/

… and then schedule it to run once a minute with launchd:

$ cat ~/Library/LaunchAgents/org.mikeb.photosync.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>org.mikeb.photosync</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Users/mikeb/bin/photosync.sh</string>
 </array>
 <key>StartInterval</key>
 <integer>60</integer>
</dict>
</plist>

and start it up:

$ launchctl load ~/Library/LaunchAgents/org.mikeb.photosync.plist

Looking at 800 files takes .016 seconds.

My only missing features are now Endless Memory and the ability to upload when outside of the house.  I can probably come up with a VPN solution for the latter if I need to, and I’ll just have to suck it up and click delete to free up space.

This should work for a couple years and get me a more appropriate lifetime out of the card my wife bought me last Christmas.  By the time this all falls apart it’ll be time for a new camera and I can buy one with native Wi-Fi support.  Let’s just hope Apple doesn’t change any of the API calls that Eye-Fi used in the desktop client and causes it to break prematurely.

GNOME Screensaver

I mentioned two posts ago that I had remaining issues with my Linux laptop around firewalld and the lock screen.  The last post covered firewalld, and this one will cover the lock screen.

When I close my laptop lid I like the machine to suspend.  This is controlled in Fedora 23 by /etc/systemd/logind.conf, with the line “HandleLidSwitch=suspend”, which is the default.  However, if the last focus was on my browsing VM (as it often is) the machine would wake up to a completely logged in desktop due to VirtualBox conflicting with gnome-screensaver.  Not good!

The specific error the GNOME desktop reports in the system log is:

gnome-shell.desktop[2189]: Gjs-Message: JS LOG: error: Unable to lock: Lock was blocked by an application

I am sure that there are really good reasons to let VirtualBox block the screensaver.  The most obvious being if the machine can’t detect that it has handed control to virtualbox and starts up the screen saver despite current activity in the VM.  It could also be that there is some resource contention around grabbing control of the keyboard/mouse when some other app has that full control.  However, all of this should go out the window when the laptop goes to sleep.  Whatever the reason, it is horrible and downright unacceptable for security.

After poking around a bit I found that this had been reported previously to the developers, but it was closed with a WONTFIX and a developer statement that “there is nothing we can do about it”: https://bugzilla.gnome.org/show_bug.cgi?id=736007

Awesome, so everyone in their right mind should stop using GNOME forever for security reasons, right?

Not quite.  After some poking around (man systemd-sleep) I found that all executables stored in /usr/lib/systemd/system-sleep will be executed when the machine is put to sleep.  There are a couple options for what can be done here:

  1. wmctrl – this is a handy cli tool which lists the currently open windows and lets you change the focus.
  2. xlock – other screensavers are not as *cough* unable to do anything about it as the GNOME project.

While using xlock was very easy (sleep a couple of seconds to let gnome fail, then run xlock & as a user), but it gives a truly 1995 feel to the lock screen which is completely inconsistent with the rest of the UI.

Instead I wrote a much more complicated shell script around wmctrl and put it in /usr/lib/systemd/system-sleep/lock

#!/usr/bin/bash

# have to grab the newest gnome-session so we don't grab gdm's d-bus session information by mistake
gsPid="`pgrep -n gnome-session | egrep '^[0-9]+$'`"
if [ -z "$gsPid" ]
then
 echo "gnome-session does not appear to be running" 1>&2
 exit 1
fi

export DISPLAY=:0
export DBUS_SESSION_BUS_ADDRESS="`grep -z ^DBUS_SESSION_BUS_ADDRESS= /proc/${gsPid}/environ | cut -f2- -d=`"

desktopUser="`id -nu \"\`egrep '^[0-9]+$' /proc/${gsPid}/loginuid\`\"`"

running="`/usr/bin/sudo -E -u $desktopUser -- /usr/bin/gnome-screensaver-command --query 2>&1 | awk '{print $4}'`"

# skip everything if the screensaver is already running
if [ "$running" == "inactive" ]
then
 newfocus="`/usr/bin/sudo -E -u $desktopUser -- /usr/bin/wmctrl -l 2>&1 | /usr/bin/grep -v VirtualBox | /usr/bin/head -n1 | /usr/bin/cut -f5 -d\ `"
 if [ -n "$newfocus" ]
 then
 # change window focus to a non-virtualbox window
 /usr/bin/sudo -E -u $desktopUser -- /usr/bin/wmctrl -a "$newfocus" 2>&1
 else
 # we have no windows open that aren't virtualbox, expose the desktop instead
 /usr/bin/sudo -E -u $desktopUser -- /usr/bin/wmctrl -k on 2>&1
 fi
 
 # lock the screen
 /usr/bin/sudo -E -u $desktopUser -- /usr/bin/gnome-screensaver-command --lock 2>&1
fi

I suppose complicated is an exaggeration.  It’s a horrible horrible hack though.  For the security minded, I did attempt to validate input, quote its use, and separate it from command arguments.  The window name can still contain arbitrary characters, but with how I’m passing the variable to sudo I’m comfortable with the risk on my local laptop.

Come on GNOME…  xlock can do it just fine, let’s be a little inventive and solve it properly.

At least my laptop will lock properly in the meantime.

firewalld

As a follow-up to my last post on the Linux desktop I thought I would write more about the firewall interface firewalld.

First I will share the good, it has a “panic mode” which blocks all network traffic in all directions.  Pretty funny.

$ sudo firewall-cmd --panic-on

Now the bad..  you essentially can’t tell what it’s doing.

I want a firewall that drops all packets inbound unless they are in response to an outbound packet, and logs the drop.

So I can take a look at the default firewall that Fedora ships with:

$ firewall-cmd --zone=FedoraWorkstation --list-all
 FedoraWorkstation
 interfaces:
 sources:
 services: dhcpv6-client samba-client ssh
 ports: 1025-65535/udp 1025-65535/tcp
 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

Is this default deny? Drop or reject? Any logging? Using iptables to print out the current rules (and nmap to confirm) shows that it is inserting a reject as the last rule in the INPUT chain. Great, how do we change that to a drop and log? Of course, none of the settings firewalld can modify directly for this zone will change it. It offers an odd interface to the chains directly (–direct) for additional rules, but not a way to modify what it writes.

There are a number of decent documents that outline how to use firewalld within its limitations, this being one of the better: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7

This article outlines that the zone “drop” will drop all inbound that isn’t part of a tracked connection. Funny that the man pages mention none of this, and the tool output doesn’t differentiate “drop” in any way with “block”.  Also, there is no user-friendly way to enable logging of dropped packets.

$ sudo firewall-cmd --set-default-zone=drop

So in the goal of improving user friendliness, Linux again is hurting functionality and configurability.  Ugh.  Of course, you can still switch it all back to the iptables way of functioning if you like.  At this point, I’d highly recommend it.

Linux Desktop

A few months ago I was working on learning more about wireless security and I found that MacOS just wasn’t cutting it compared to how all of the tools worked in Linux.  As one of my co-workers pointed out, there was always the option of an external USB antenna and mapping that through to Linux VM.  However, I really wanted to refresh myself on Linux more deeply and I knew a VM wasn’t going to do that.  Also, I didn’t own a laptop, and the idea of picking one up that didn’t include the “Apple Tax” was pretty appealing.

So I went out and bought an ASUS Zenbook UX305FA (I paid $690), and I’ve been very happy with it.  After quite a bit of playing, I’ve finalized on Fedora as my desktop distribution of choice and GNOME 3 as my desktop environment.  I’ve setup a separate VM with only a browser (fedora minimal install+x11+openbox), which virtualbox displays pretty nicely with seamless mode.

Overall it works pretty well.

BUT…  and I have to say it’s a big but, the Linux desktop environment really hasn’t progressed since the late 90s in terms of user experience.  I ran AfterStep and Enlightenment in Linux in the ’90s, and I remember using fvwm/blackbox for shorter periods.  I booted to console, typed startx, and my .xinitrc ran my desktop items.  Right about the time I switched to FreeBSD as my primary desktop, this new fangled thing called GNOME came out.  Rather than every config change being editing a text file it came with integrated settings panels, it had native apps, and it aimed to be more than just a window manager.  It was pretty impressive for an open source project, and I was excited to see how it would compete with Windows and MacOS over the years.  Except.. it didn’t.

Honestly, as I’ve configured things in GNOME recently, it is not only stalled on features from the ’90s, but it has managed to become more difficult to configure.  Now of course, I know it really hasn’t stalled on features, but take the basic configurability of the environment from a user perspective and it really feels like it.

One of the most obnoxious examples is the gnome-keyring.  Now I’m very familiar with the MacOS keychain.  One of the features it provides is auto-reading in SSH keys from ~/.ssh and setting SSH_AUTH_SOCK for OpenSSH to know it is acting as your ssh agent.  Each time I reboot the Macs I use, I go to a terminal window and type ‘ssh-add’, enter my obnoxiously long passphrases, and the keychain can now use those keys for ssh until the next reboot.  I was pretty excited to see that gnome-keyring would do the same thing!  Except it won’t.  My keys are not using default settings/types for creation, which apparently makes gnome-keyring fail to function.  It does not fail to load the keys and try to act as an ssh agent, it just fails to present the keys for auth.  Great, so I’ll just disable it and go back to .bashrc ssh-agent methods, right?  Not so fast.

First, we’re in a UI environment, but there is no setting for it in the UI..  No problem, there must be a simple script/setting where I can just comment out gnome-keyring, right?  HAH!  Not really..  The final solution was taking /etc/xdg/autostart/gnome-keyring-ssh.desktop file and copying it to ~/.config/autostart, then adding the line X-GNOME-Autostart-enabled=false

Of course, that’s actually not that complicated, but the problem I have is with how it just isn’t intuitive.  The Linux desktop and GNOME really isn’t that advanced.  Why is that not a more simple thing presented to the user?  Also, when searching the Internet for the answer, you’ll realize that with many revisions of GNOME and many distributions of Linux, there is 100 different ways people have solved this problem, many of them correct in their own little splintered world of Linux+GNOME.  My favorite was the guy who wrote a daemon that sent SIGKILL to gnome-keyring if it ever started, because he gave up figuring out how it autostarted.  A solid example of how badly documented and inconsistent this all is.

Clearly user-friendly is not a priority for the GNOME project and the Linux desktop.  Maybe in another 15 years they’ll get there.

A few other quirks of note.

  • I had to disable secure boot to load the virtualbox kernel modules with a kernel patched to current – this makes me unhappy
  • Nothing on extensions.gnome.org shows as supported with the current version of GNOME, but Fedora has rpms for a few of the extensions to make up for some of it
  • The screen brightness keyboard buttons on this machine (fn+F5/F6) don’t work, so I mapped windows key+F5/F6 to xbacklight -inc/dec 10.  This is the only unsupported item I’ve found for this hardware
  • Audio is very quiet at max, so I installed pavucontrol which supports going to 153% what the default ALSA mixer does

In any case, I have a Linux desktop that seems to be working pretty well now.  I have a kali and remnux VM setup, and the seamless mode browser VM.  Everything on disk is encrypted, and I’ve locked down the rest pretty well.

My only outstanding items to fix are:

  • when focus is on a VM the gnome-screensaver will sometimes be blocked from locking the screen, so even when resuming from sleep the machine may be unlocked
  • firewalld.  This seems to be regression of capability from the iptables CLI, but I’m giving it a chance and reading all the documentation before I rant too much

I’m sure in a few upgrades I’ll have to re-do half of this, because..  Linux.

 

network music storage and macos annoyances

For a long time I’ve kept my music on a network accessible drive in the house.  I started to do this because I had multiple computers I actively used and wanted to access it in a central location.  The FreeBSD machine served up NFS and SMB to the machines that needed it, and it worked fine.

Eventually I got a couple Squeezeboxes and needed it to stay on that server so I had place to run the server for playing music.  I even wrote a perl script that used MP3::Info to confirm various "minimum requirements" for quality in the music I stored, and even confirmed that the ID3 tags matched the filenames and directory structures.

More recently I decided that managing album art, ID3 tags, and synching the music quickly and reliably meant switching to iTunes.  BUT, I had no desire to switch away from the network share method.  This is because I still needed to host the music for the Squeezeboxes.  I have a 500GB drive hooked up to my iBook G4 that serves as my backup server (Time Machine / rsync depending on OS), so I just added a partition to that for the music and set it all up.

Things worked absolutely great.  Sure, I noticed some delay in big updates in the music or apps on my iPhone, but they were relatively minor in the scheme of things.  

I did have some problems with my laptop going to sleep though.  Sometimes my MacBook would wake up from sleep and forget the network share.  This meant a minor inconvenience of telling iTunes where to find its folders, and by navigating to the right location, remounting the drive.  It’s even pretty easy to create an alias to the mount point on your desktop and just double click on it to re-mount the share.  I wish MacOS would handle that better, but it was life..

That is.. except when I was actually running iTunes and I put my laptop to sleep.  iTunes would crash when it realized it had lost its data.  Not only would it crash, but it would spin out of control, eating massive amounts of CPU and make it a pain in the butt to even kill off.

I was finally able to solve the problem tonight.

First, I installed SleepWatcher from http://www.bernhard-baehr.de/&nbsp; – this application allows for the execution of commands from the cli on sleep or wake up from sleep.

I installed both the daemon and the startup package and rebooted my machine (needed to do some software updates anyways).

Next, I copied some basic scripting from this (mostly) unrelated blog entry;
http://rajeev.name/blog/2008/09/01/automated-osx-backups-with-launchd-and-rsync/

and came up with;

#!/bin/bash

function doMounts {
  vol=$1;
  mnt_cnt=$(/sbin/mount | grep -ic "/Volumes/$vol")
  if [ $mnt_cnt -le 0 ]; then
    /usr/bin/osascript <<EOT
    tell application "Finder" to mount volume "afp://myiBookG4/$vol"
EOT
  fi
}

for (( i=0; $i < 12; i++ ))
do
  doMounts iTunes\ Library
  sleep 5
done

exit 0

Since it will sometimes take the OS a few seconds to realize it has lost the share, or even more to reinitialize all the hardware if it actually hibernated, I told it to look to see if the mount was there on a 5 second interval for a minute.

I’ve tested it a few times, and it re-mounts the network share with great reliability..  Hopefully this solves all the annoyances above.

Now.. Apple.. I shouldn’t have to do this.  Please fix it!