Enchanted Objects Design Challenge - Locking the doors

22 Jun 2015

Following lots of rude interruptions from the Wolf, Hans decided the Arduino Yún's security needed beefing up. After a bit of reading Hans realised that this could be a 16 week design challenge in it's own right.

Hans' plan of action for the lock down was as follows:

Users and passwords
Handle brute force attacks
Remove unused functions
Apply principle of least privilege

Passwords

Hans had already changed the default root password to something unique but realised if he was sending out lots of IOT devices it would make sense to have a mechanism where you could provide everyone of them with a unique default password. This could be printed on a label on the bottom of the device so if it was reset to defaults it would take this rather than something that people could google for.

It's possible to check the user accounts by looking at the passwords file.

cat /etc/passwd

Installed by default on the Yún are the following:

root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false

Given that there's no FTP then the FTP user is a candidate for removal, although it would make sense to check that is not used for the WebUI.

We can disable the accounts using

passwd -l username

Brute Force

The Enchanted Cottage has some protection against brute force attacks in that the Linino portion and hence the Wifi is turned off for most the the time hence there is no way to connect. However in the computer world the few seconds that the system is up and connected should sufficient for a break to be attempted.

The two areas that could be vulnerable to this are the Web Admin UI provided by Arduino and the SSH port. It might be possible to turn these off. Given that these are used to fix or configure the device that's maybe not a good idea. It's also possible to configure SSH to use certificates rather than password for login. To do this on the finished product we'd need to have some way of getting the keys back and forth.

This can be setup by following the instructions for setting up Drop Bear SSH for Public/Private Key authentication

The best method for handling brute force attacks is to use a intruder detection system such as Fail2Ban which uses the inbuilt firewall IPTables to lockout IPaddress that have strange activity patterns. The only dependency for Fail2Ban appears to be Python so for the cottage this seems like a good solution. The module is not yet available as a downloadable OPKG package but it can be installed manually. Fail2ban install on GNU Linux

The daemon file need tweeking to run on this platform, one from RedHat was used as a basis.

https://github.com/Workshopshed/EnchantedObjects/blob/master/Code/Scripts/fail2ban-initd

and this was tested with

/etc/init.d/fail2ban start

and

/etc/init.d/fail2ban stop

Removing features

Whilst Hans was researching security he had a visit from the Woodcutter who wanted to see how the build was coming on. Whilst they were wandering around admiring the structure the Woodcutter tripped on a stump and reached out and grabbed the nearest thing to him, a hanging basket of flowers. The chain supporting the basket broken and the basket and Woodcutter went crashing to the ground. The Woodcutter picked himself up and brushed off the soil and flowers. He looked at the basket on the floor and said "a chain is only as strong as it's weakest link". He picked up the basket, passed it to Hans and wandered off into the forest.

Hans realised that there were features on the Yún that were not being used. These could be removed to stop them being the weakest link.

Looking at the list of installed packages there seems to be some candidates for removal.

avahi - A Zero Configuration network tool.
cpu-mcu-bridge - The bridge, this is already swapped out so is not used.
spacebrew - A friendly wrapper for APIs
temboo - A friendly wrapper for APIs

Hans also wondered about avrdude, the tool for putting new sketches onto the AtMega. But removing that would stop the end user applying patches over the Wifi.

opkg remove temboo
opkg remove spacebrew
opkg remove cpu-mcu-bridge

Removing avahi raised a warning that it was used by depended on by other package so it was not removed at this time.

The other key feature to review is the Rest API, the uhttp webserver publishes data on the Arduino pins and can control the ATMega via a correctly constructed URL.

e.g.

http://<Arduino_Yún_Address>/arduino/mode/13/output

We can disable the Arduino specific end points by editing the /etc/httpd.conf file to comment out lines by putting an # in front of them.

#A:/arduino:/cgi-bin/luci/arduino%s
 #A:/data:/cgi-bin/luci/data%s
 #A:/mailbox:/cgi-bin/luci/mailbox%s

Principles of least privilege

This security concept is basically don't give more permissions that is needed to do the task required. Then if anything goes wrong or there's a security loophole then a hacker is less likely to be able to escalate their privileges further.

Again, swapping out the bridge code with the reduced functionality of the python script means that the ATMega has access to less of the Linino side. However, python is running as root, which is a bit much given that it only needs to read a configuration file and get a file off the network to process and send via serial the ATMega.

There are tools to help lock down these permissions such as SELinux but it would appear that these would need the Kernel patching which unfortunately means I don't have time to implement this process.

Next: Enchanted Objects Design Challenge - Tools