Security for anything you connect to the internet is important. Think of these devices as doorways. They either allow access to services or provides services for someone else. Doorways need to be secure — you wouldn’t leave your door unlocked if you lived in the bad part of a busy city, would you? Every internet connection is the bad part of a busy city. The thing is, building hardware that is connected to the internet is the new hotness these days. So let’s walk through the basics you need to know to start thinking security with your projects.
If you have ever run a server and checked your logs you have probably noticed that there is a lot of automated traffic trying to gain access to your server on a nearly constant basis. An insecure device on a network doesn’t just compromise itself, it presents a risk to all other networked devices too.
The easiest way to secure a device is to turn it off, but lets presume you want it on. There are many things you can do to protect your IoT device. It may seem daunting to begin with but as you start becoming more security conscious things begin to click together a bit like a jigsaw and it becomes a lot easier.
What are the problems and how do you fix them?
Passwords and Password Security
Before we start always remember to change default passwords for every package and device you use. This is the first thing you should do with any connected device. Web security hinges on two goals: keeping the unauthorized from gaining access to resources and ensuring the authorized have access to resources they need. If your device provides different information to different people you will need to have some way for your device to tell people apart, for example a login system. This can be achieved in numerous different ways like using session ID’s and secure cookies in conjunction with passwords.
It’s very important that you do not store passwords or session ID’s in cookies as these can easily be intercepted either by man in the middle attacks, malware or someone who has physical access to the end user’s computer. Passwords should always be hashed. This is a one way process and cannot be reversed if done properly using “salting”. Salting is using a string of characters so when you hash the password the salt is used to create a unique hash. This stops attackers using rainbow tables in order to crack your passwords if they got a hold of your database. Pedro Umbelino did a great job of detailing password security in his Hackaday article a few weeks back.
Secure Salting of password hashes is the way to go in this digital age click the link to learn more. Passwords are important and it’s best that even you don’t know your users passwords as they may use them for other accounts. If you just encrypted them then you have the means to decrypt them as encryption is a two way process encrypt/decrypt. This is why we hash and don’t encrypt.
Old Software with known Vulnerabilities
It’s obvious, but well worth saying. Avoid using old software with known vulnerabilities, never use older versions of software. Software is updated for a valid reason. Use the most recent versions, even if the changelog doesn’t mention specific security patches.
There are websites out there that document most known vulnerabilities and this is worth checking out for packages you plan to use. You may be thinking that listing all known vulnerabilities is helping the bad guys, but these are actually the good guys. Yes it does help a would-be attacker find a way to attack older web scripts or software but if you use the latest version from a trusted vendor they will hopefully have fixed any previous problems they had with their product. Listing the vulnerabilities gives companies a reason to get updates out the door and to stop attackers preying on software with bugs in it because your software vendor is lazy. It also helps developers avoid the worst offenders.
If You Don’t Need It, Why Keep It?
Lets assume your device is running some form of Linux. There are many protocols you can use to communicate with the device. For example you may have SMB, SSH, Telnet, FTP, VNC etc. but you need to decide which of these protocols you need and which you don’t. If you don’t use a protocol why have it enabled in the first place?
These are like doorways to your device the less doorways you have the less attack avenues a computer “hacker” has to gain access. It’s common sense really but is often overlooked. Another good bit of advice is to disable root login for SSH and create another account to use. Your root account is the most likely to be brute-forced. If you need remote login use at least 8 digit passwords and make it random and weird chars, capitals, numbers etc. If you use a word and perhaps 123 at the end, It would take a hacker literally minutes with a dictionary brute force attack.
Giving Away Too Much Info
Exposing information which may help an attacker form a more complicated attack is a big no-no. Your IoT server might be giving out more information than you thought or even information you didn’t feel was important.
For example, self-written websites may be linking directly to files on the server instead of hiding their actual location. This should be avoided. You have a “web directory” for a reason; your device software expects your files to be in this place and permissions are set up to prevent reach beyond this directory. Don’t open up the back end (non HTTP part) as this could lead to an attacker gaining privileges through a simple bug in a web script in what is supposed to be a secure part of your device.
Don’t worry too much about this as it is quite a trivial thing to fix. You still need to use your web directory but you can also hide URL’s using .htaccess with Apache HTTP Server. If you are using another HTTP server it will have a similar configuration system. To learn more search the net for “name-of-your-http-server url rewrite”.
You don’t want any would-be attackers having more information than the minimum your server needs to provide to function. Leaking information may help an attacker understand your file structure and what you have running under your HTTP layer. Most attacks are automated, designed to take your server down because they noticed you use a specific piece of software. Making discovery hard helps combat this automation.
In your website directory you will also want to make sure your files are not listed in directory indexes, putting a simple index.html file inside each directory will stop prying eyes. If your server has a database, keep it on another device (best practice), or if that is not possible make sure to keep it behind a firewall. Also don’t keep databases in your “web” directory. for more info on locking down your server check out the link.
Cross site Scripting
XSS or Cross Site Scripting attacks are one of the more common attack vectors. This is where the attacker exploits a script, for instance the Hackaday comments section at the bottom of this very page. An attacker may try to leave a comment with script tags in it. If successful this will publish malicious code in the comment which is run on a user’s browser every time someone visits this page. Of course Hackaday is protected from these type of attacks but the example holds for sites that do have XSS vulnerabilities. Will Sweatman wrote a crash course on XSS which is worth checking out.
Perhaps the most famous XSS attack was the Samy worm. Samy Kamkar found a MySpace vulnerability that caused everyone who viewed his page to add him as a friend and display a message on their profile page. It was self propagating, so anyone who then viewed a page with that message became a carrier to infect new visitors. Almost overnight everyone on MySpace was following Samy. He’s since become a security researcher and is a great friend of Hackaday.
When hosting your own web services that provide submission forms to control your hacked-together IoT thing, make sure you consider XSS. The solution to this is what we call sanitizing data. Of course you should restrict what your web form includes (scrubbing out “script” and other HTML tags). XSS attacks are very common so is the web interface for you IoT device will take input, now is a great time to go and learn as much as you can about XSS.
Physical Access Attacks
Physical access may also be a problem. You may have your device in a location that is public or easily accessible. You need to make sure no one comes along and shoves a USB Killer, or USB hacking tool for example one that shows up as a HID (Human Interface Device) like a keyboard and starts reeling off commands from a pre-configured script. If you don’t need USB make them inaccessible or turn them off through software. If you are really security conscious why not remove them from the board completely, or pour epoxy over them? Even PS/2 ports should be secured. You may see a pattern emerging here, A good security philosophy is, if you don’t need it why have it there in the first place.
Use Tried And Tested Security Measures
Security through obscurity is not a good idea either, there is always someone out there who is smarter or luckier than you. Try to stick to tried and tested security measures, don’t think for a second that because you have some weird device with perhaps a market size of under 100 people/companies that you will be safe. Nothing is 100% bullet-proof but if you think your device will never be attacked because “reasons” then think again. Re-evaluate your position and sort your security out.
If you follow this advice you should be pretty well secured as long as you remembered to change that default password and remember this isn’t a definitive guide there is always something else you could be doing to secure your device. The biggest problem up until now has been failure to think about security at all — we can do better!
Internet of Things devices are being ravenously hunted for sport right now. You need to be vigilant and make sure your devices don’t fall foul to attacks like brickerbot or become a part of the latest IoT botnet. There will be more attacks like this to come in the future. Get ahead of the curve by learning about security and keeping your devices locked down. If you are serious about cyber security, start reading up about the latest trends as there are new vulnerabilities found daily. If you make devices for others then you must become an expert in these skills. If you can’t say that about yourself, hire some professionals. You don’t want a lawsuit, you don’t want to lose customer trust, and you don’t want to be building hardware that threatens our connected world.