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!
Future Prevention
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.
If using SSH maybe consider disabling password login altogether. SSH keys are much harder to crack than passwords. On the client they can be locked with a keyphrase. Newer servers can allow requiring both key and password, giving a sort of 2-factor.
I agree SSH should only be on if it is essential, Two factor security is much better too, This is mean’t as a security essentials and I have left out a few bits and pieces as the article would be very long. There are so many different things that could be done. I wanted to get the essentials across.
There are far too many IoT products out there without even the most basic protection.
Absolutely this. If you’re going to use a bizarro multi-character password, you might as well just use keys and be done with it. While you’re at it, move ssh off the default port. This doesn’t really increase the security any, but it reduces the amount of logging and wasted CPU effort from the script kiddies just rattling knobs on port 22 constantly.
Changing the port in use makes no difference. Kiddies are going to knock on all the ports and once something responds it’s pretty easy to figure out what kind of service you’re talking to.
Don’t agree, most automated scans scan 1-1024 or nmap default scan modes which don’t cover all ports. If you pick a port that doesn’t get scanned unless someone explicitly specifies the port or uses a port flag -p1-65535 on their nmap etc scan, the amount of noise in the logs goes down exponentially.
Implement port knocking and drop the packets on the floor until its knocked, drops again.
Implement key auth only, turn off root login, and sleep even easier.
https://en.wikipedia.org/wiki/Security_through_obscurity
The rest are good ideas though
Could be it is security through obscurity, but if you have done everything else to secure it, why not move it to a different port at the same time?
Also, I know it makes a huge difference. I have a Linode running a small business website, and with SSH on port 22, it gets hundreds to thousands of failed logins a day…Moving it to a high number port >1024, I haven’t seen a failed login yet. :) None for months. So…if I *do* see a failed login now, I know it is someone serious that I need to pay attention to. So far, hasn’t happened yet. :)
If you go back and read what I actually wrote, I said that it didn’t increase security to move the port (so it’s not security by obscurity), but it cut down on the amount of logging (not to zero – but almost). I have experienced this exact phenomenon on multiple internet-facing hosts.
I would like to suggest using fail2ban if you’re opening up ssh to the outside world…
That’s what my EC2 instance was using (or a similar tool with a shared blocklist).
There was a device vendor that used SSH keys for a root login. But every device had the same keys, so once you got the other key it was trivial to get root on thousands of other devices.
Security is about designing for security and proving it to be secure, and not about blanket statements.
I forgot to mention that. I meant to put in “unique”. You might need to have the device accept a battery-staple password printed on the bottom until you register a key and then go into key-only mode. Or maybe some reasonably-secured registration system that links a device ID to your account then coughs up the associated key.
If they were foolish enough to leave the private ssh key that went with that public key, then yes… utter stupidity.
Otherwise, it’s basically a problem of how carefully do you store the private key.
It seems the target audience is those implementing their own servers directly facing the internet, however most IOT devices sit on a LAN behind a firewall, are not user designed, or particularly configurable in terms of security. They do “phone home” or maintain a persistent TCP connection sending unknown data, somewhere. It would be good to include a discussion on how to best secure or wall off these types of devices such that they can continue to function, but are unable to snoop or interfere with other traffic on the LAN. Additionally if they do become compromised, how can it be detected.
+1
I installed PiHole (which has been fantastic) on my network recently and got the unexpected benifit of seeing a chunk of my IoT products phoning home. I’ve since blocked a lot of the host names and AFAIK all of my devices are still working great locally (and over VPN). Food for thought if you’re looking for a way to approach this problem. It ain’t great – but its a start.
Can’t vlans or a iot mothership device that handles access and encryption on a private subnet be developed?
Yes. I think the original article kind of missed the boat on the biggest security issue people face with IOT. Since most IOT devices are not internet facing, but phone home either periodically or via persistent connection, they can not be configured in the ways suggested by the article. They must be walled off via network means such as a separate VLAN which wasn’t even mentioned.
Consumer routers should make this easier to accomplish without requiring an understanding of VLANS. Something similar to “guest access” that creates a separate Wifi AP on a separate VLAN, with no ability for that VLAN to initiate connections to the protected VLAN, but allow the protected VLAN to initiate connections to the IOT VLAN (perhaps with the ability to limit even this to certain ports).
There are additional things the firewall could do. Without going into a lot of detail, the firewall could learn the patterns of the IOT device to the internet and deny any traffic that is out of the ordinary. Most IOT devices only communicate with a small number of destinations and on somewhat regular intervals. This could help prevent DOS at the source.
And it’s not like many routers would need new hardware to make a separate DMZ V-LAN. It’s pretty common to only have one NIC on the router chip and give it VLAN tagging and use the software-configurable switch to split the VLANs onto different ports.
I enjoy watching the outsourced labour exploitation come back as karma.
People can’t fix the stupidity packaged with blind greed, and even now people still want more from the kids overseas.
:P
Hehehe, well put. :D
I really wish there were more artciles like this on the web.
Yes I agree. There is a movement towards micro services where the team that builds each module also ‘owns’ it. No disbanding of teams because the project has been delivered. Domain and system expertise is not lost, the team that wrote it maintains it. :)
https://martinfowler.com/articles/microservices.html
HAD has the facility and ability to provide a white hat proof of concept example right here that is thoroughly convincing and educative.
Wendy’s, of all places, said it best; “Where’s the Beef?”
bleh… example of cross site scripting
Inre: Joe’s picture at the top of this posting.
I now realize it is supposed to be the reflection of an astronaut onto HAL 9000’s red light,
But at first I thought it was a man trapped inside an IoT enabled front loading wash machine!
B^)
I have some ideas for security SOPs to put in place if I ever start a business…
Nice big folder/file labled “usernamesandpasswords-backup” and have it filled with usless gibberish thst looks like a legitimate copy. Basically just pure salt and if the file is accessed then I know someone got past the firewall and need to add even more security.
The cash register computer with the USB ports just sticking out there in the open, free for anyone to plug anything in. Obviously not connected to the target system…
All passwords will have to pass the ‘dumb password’ test. There will be no “12345678”, “pa$$word”, “(favorite sports team goes here)(birthdate goes here)”. And no ‘password managers’ allowed near my systems.
No biometrics allowed period.
No ‘smart’ TVs or wireless printers. No WiFi LEDs. No IoT toasters. No wireless thermostats anywhere.
NO WIRELESS CAMERAS. Hardwired and checked for tampering weekly.
Connect those cash register USB ports to mains voltage instead. See if you can bag a couple of fried Bad USBs. :D
Maybe I would install thousands of text files, MP3s, and GIFs all with “own your base” and RickRolls. And on normal SDcards you can make it (almost) completely read-only, bwahahahaha. :O
What happens if you attach a usb killer to mains?
Open source everything!
You surely have no bugs someone could exploit and even if you did the community will report them quietly to you before someone exploits it….right?
Your statement is naive. A lot of software companies can not do this, all value in the company will be lost. I work for a games company, software piracy is hard enough to fight, open sourcing the code will just kill all development.
My lawn needs cutting, when you coming round to do it for free????
+1
Except we’re talking about physical products specifically designed to connect to the internet. Open-sourcing the software isn’t going to reduce sales because you need the hardware to use it.
PoPToP is an open-source PPTP VPN implementation. Guess what, it’s just as vulnerable as Microsoft’s offering.
netkit-telnetd… no more secure than the telnetd in SCO.
If you have busybox telnetd open on port 23, giving root access with a simple password (I’m looking at you, Netcomm), open sourcing the firmware does nothing to secure it.
If however, you have done your job properly, then open sourcing does nothing to harm your security.
Piracy though is a completely separate issue.
Just disconnect these Evil IoT devices. If they stop working as a result of being disconnected, then there you go – a big Danger Sign. It’s simple: Use the Internet with care, the opportunities are boundless. However, Never let the Internet use you!
>IoT Security is Hard
No.
The first problem is that people want to connect everything from the toothbrush to their toilet to the internet just because it’s cool or i don’t even know why. Stop this. For things where an internet connection has a real use there is the second problem: Companies that only look at the price, people implementing protocols, writing firmware and apps etc that don’t have the knowledge about this (an EE can be an excellent EE but he is not the right person to do internet related stuff!), no pentesting/security-audits because $$$, whitehats reporting problems threaten with legal action, no updates, …
Sorry, the breaches we see on all this IoT-crap are not highly complex exploits, they are (most of the time at least) BASIC STUFF like shell command injection, SQL-injection, no encryption, no authentification, buffer overflows, directory traversal and so on. All these things and the solutions are known for a long time. Even i (that is really not an expert for all this stuff and won’t try implementing apps/protocols/… because of my lack of knowledge) understand this!
oh and i forgot an important point: Customers that are too lazy (or stupid) to even acquire BASIC KNOWLEDGE about all this (like what is an ip-address, what is a router, a firewall, what is WPA2-PSK, where to enter a key, …) and that want everthing to be automatic and work out of the box, so companies are inventing auto-config-stuff that just drills a hole in your router-firewall to make things work, … (yes, here on HaD they is a different type of customers)
@some guy: smashed it. Every hack or loss of personal privacy has been standard known stuff, that anyone with an ounce of sense would have remedied.
Yeah basically.
Moving to some 3rd world country to help dig wells and milk goats and get tortured by warlords seems kinda interesting.
??
because everything would be high stakes and real. because no internet means no buzzwords and no solutions searching for problems.
I honestly can’t tell if you’re mocking the other guy or being serious.
Yeah or whether it’s one of those creepy weird fantasy things like on 4chan, that starts off something like.
/be a 4 year old Ethiopian kid with aids…
If you don’t know what I mean, just don’t ever let your kids search for Shrek with safe search off, just don’t.
Nah just mocking the glorious digital future which is upon us. I like servers and workstations but pretty well despise anything with the audacity to call itself “smart”.
Maybe it’s just me, but what is this article doing ok a site like this? Did anybody learn anything? If you answered yes then move on to instructables ????
There are a lot of brilliant Hardware orientated people out that struggle with software/security and vise versa Yes it’s going through the basics and it may seem extremely trivial to you. But whats wrong with pointing people in the right direction and giving them a basic run down on securing their devices since it seems open game for exploiting anything IoT these days.
oriented. what’s wrong is that none of this is really necessary unless you work for someone like Atmel and you want to keep doing that indefinitely. It’s all contrived.
I’m British we spell it orientated over here. Anyway you don’t need to work for atmel to learn basic server security, I personally have made a few home-brew IoT devices and I keep them secure.
I’m admittedly preaching against what to me is mindless nonsense. The title should have been “Computer Security is Hard” because that is what everyone is getting into, no matter what buzzword is tacked on. I have a thing that is often called a smartphone. It is in fact just a crappy pocket computer with piss-poor external peripheral support and integrated mic, speakers, and 4G modem. A push toward “enhancing” everything (down to bog-roll holders) with a TCP stack is only another stupid marketing campaign. Just call things what they are, is all I ask of anyone, anywhere, ever.
Well said. I’m a hardware person and my eyes glaze over at this endless software talk, like install software 2 to fix software 1, and software 3 to update 1 and 2, and 4 to check for errors ….
This “fence and thief” battle has been going on for centuries, and will continue.
As someone smart said recently, just stop putting sht on the internet. Or put a big switch on Ethernet cable, like this:
https://en.wikipedia.org/wiki/Knife_switch
Software your way through that.
Exactly right it will be cat and mouse forever but if you can learn at least the basics then you stand a good chance of keeping your thing secure. I tried to keep it simple for people who don’t want an information overload but could still keep themselves relatively secure. I like your knife switch idea.though no ones getting past that haha.
IOT Here’s what you need to know.
Nothing Don’t buy into this gimmickware.
On a side note, the internet is a weird place. It’s where the victim is blamed and sociopathy is rewarded. Imagine if when we walked in the streets a constant stream of strangers would come up to you and stick their hands in your pocket trying to grab your wallet and then people pointed their fingers at YOU for being dumb enough to walk on the street. And this is every street.
You bring up an interesting point. It’s a fundamental lack of civility, and the symptoms are at every level from the low level (port 22 being continuously probed, endless buckets of spam) all the way to the top (twitter feuds, comment section trolls, etc).
Getting people to understand what they are using is essential. Imagine an uneducated untrained person with an electric chainsaw. Gauranteed eventual carnage. Reminds me of the americans who sued an iron manufacturer for Not telling them to take the clothes off before ironing them…
Over here in the UK we’ve been required to bang on about cookies on all websites, but I wonder how many people who use a piece of software read anything it says…They all have manuals for frigs sake, and popup messages/warnings are scanned and ignored, not read. Cookies have been explained for anyone who cared to read it since the dawn of the web browser…
Imagine if the manufacturer of your front door lock came around for a visit to tell you that it was no longer secure, had a major vulnerability where someone could spit in it and it would open with a paperclip or any other object. They immediately offered you an upgraded spit-proof lock…. Would you accept their offer or continue to use the broken device?
We bring it on ourselves.
In my professional opinion….
… a lost cause…
YOU did not step up to stop it.
If all of use were YOU, and we, it would be different.
Collective, distributed, responsibility.
Are you telling me that all the best hacker minds cannot find a solution that will beat the criminal hackers minds that abound and threaten us so? You are too weak to secure us from they? The only answer is to shut it all down or accept grandma being ripped off her millions you were to inherit?
WTF kinda people are we? Sheep?
The anger should be universal….
… the action should be worldwide…
… the success will alas be at best 50/50 as they, are we… reading all the same articles.
I love telling you we fail if we do not prevail. Someone had to tell you.
it’s not that hard.. most of these devices have a TEE. crypto acceleration, and memory mitigation. None of the firmware uses it and is typically written by the lowest bidder with very little QA.. Those make it expensive enough so that most people don’t try.
Nice article but what happened to punctuation please fix
Nice article, but what happened to punctuation?
There! I fixed it for you!
HAHA! Beat me to it.
IOT is the concern topic for the world because as per Cisco study https://www.clickssl.net/blog/iot-a-rising-curse-inside-the-light-of-technology 50 billion devices will be connected by the 2020 year. So as per growth in IOT devices, growing in security also needed. So basic awareness tips are needed to fight for IOT security.
So more items that need to be talked about:
1. Cryptographically signed SW/FW images
2. Security of the web server used to manage the device – This could be a whole series of articles. Just look at the issues with webcams. Rapid7 has been finding and reporting webcam vulnerabilities for years.
3. No hard coded passwords. The end user needs to be able to change every password.
4. Don’t use the same default password for each device. Use default passwords that are different for each device or no default passwords at all. Have the end user pick a new password as part of the initial turn up.
5. Sample code is the Devil! Sample code is a guide. Don’t copy and paste it as is. Don’t use it unless you really understand the communication and control environment that goes along with it. 100’s of routers used Intel’s sample code for UPnP. UPnP was only supposed to be implemented on the LAN side of the router, but routers had it active on the WAN side allowing remote attackers to open a port into your network at their leisure.
6. Secure wifi configuration. Once set up, don’t let the device share the wifi password
7. Encrypted protocol between the device and the user management interface (HTTPS, BLE encryption, etc.)
8. and more
How about the server side? Lets just say security in the “Cloud” is like a clear day, attackers can see for miles and miles and miles….
1. Don’t use the device serial number as a direct link/lookup to server data. If a user logs in and views his baby monitor serial number 1004623 and that sn is in the web link, they’ll probably be able to view video from serial number 1004624, ..25, …xxx.
2. Don’t let someone else register the same serial number if it’s still registered to another user.
3. User authentication …
4. Don’t test with live user data…
5. Encrypted protocol between the server and the device (HTTPS, etc.)
6. Secure your server installations. Don’t just use the default set up for your server SW (APACHE, MONGODB, etc.). Usually the default installation is designed to get you up and running quickly and INsecurely.
7. and more
.
/be a 4 year old Ethiopian kid with aids…
If you don’t know what I mean, just don’t ever let your kids search for Shrek with safe search off, just don’t.
Hey Jack,
thanks for this good summary: Hopefully it’ll be read by as many people as possible (especially decision makers).
Besides considering security at all, I go with “If You Don’t Need It, Why Keep It?” (only you need the expertise to decide this…).
Best Wishes,
SBartsch
.
Best Wishes,
SBartsch
.
Best Wishes,
SBartsch
.
Best Wishes,
SBartsch
. Don’t use it unless you really understand the communication and control environment that goes along with it.