When we say “hack” here we most often mean either modifying something to do something different or building something out of parts. But as we build more Internet-connected things, it is worthwhile to think about the other kind of hack where people gain unauthorized access to a system. For example, you wouldn’t think a remote control would be a big deal for hackers. But the Logitech Harmony Hub connects to the Internet and runs Linux. What’s more is it can control smart devices like door locks and thermostats, so hacking it could cause problems. FireEye’s Mandian Red Team set out to hack the Harmony and found it had a lot of huge security problems.
The remote didn’t check Logitech’s SSL certificate for validity. It didn’t have a secure update process. There were developer tools (an SSH server) left inactive in the production firmware and — surprisingly — the root password was blank! The team shared their findings with Logitech before publishing the report and the latest patch from the company fixes these problems. But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
In fact, that’s the most interesting part of the story is the blow-by-blow description of the attack. We won’t spoil the details, but the approach was to feed the device a fake update package that turned on a dormant ssh server. Although they started by trying to solder wires to a serial port, that wasn’t productive and the final attack didn’t require any of that.
We’ve looked at some ways to harden Linux systems like the Raspberry Pi before, but honestly, it is an ongoing battle. We’ve seen plenty of devices with cybersecurity holes in them — some not found by good guy hackers first.
> But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
I usually advise people not to put any of their Pi projects on the open internet unless they really know what they are doing. It sucks because Pi’s are good at things like hosting simple web pages, but it isn’t easy to secure things and there are so many automated scans being run that chances are good you’ll be hit eventually. There’s still some danger of attack from within your own network, but it’s considerably less.
Having a device be able to talk to every single computer in the world (what open Internet access is) should not be taken lightly by anyone, yet so many decide that this is necessary for the smallest of things that either don’t need wifi or only need an internal connection and don’t think about security in the slightest
Even in early stage of dev board spaghetti soldered to dev board hooked to a bench supply and on its own private wifi, I have never seen anyone use a passwordless SSH
But regardless of existing disabled SSH serves, if your product really has to have the ability to access the internet it needs a full audit and one really needs to learn the basics of secure coding and code signing as a first step to IOT design and should not be able too touch the project without it
One weak link is all your home or business needs to wreak havoc
And if a post attack audit finds some RGB lightbulb or smart light switch was the cause of gigabytes of customer data being stolen, I’d be beside my self
Still, the ssh server was off. It was just left on the image, requiring to write a file to the system to enable. If you can write a file, you could also just write a full dropbear installation. The HaD article makes the ssh server sound a lot more problematic then it really is if you read the article.
The main issue is the unsigned updates, just a dns-hijack or a man-in-the-middle attack is required to pretty much do anything with it.
https://www.computerworld.com/article/2487425/cybercrime-hacking/target-breach-happened-because-of-a-basic-network-segmentation-error.html
The worst thing for me was the complete inability to disable the internet-of-shit functionality on the unit.
When I asked about it to Logitech support, I was given a stonewall nope and basically told to pound sand. I guess the telemetry is just too juicy to pass up…
I ended up blocking it from WAN access in my router until almost every log entry was for access attempts (along with the single Amcrest camera, but that was ‘fixed’ in the last update – except it wasn’t).
I ended up unplugging it altogether as it was more pain than it was worth.
The other problem was with the app, you can’t define your own button layouts to match the real remote it is replacing, or personal preference, so everything is unintuitive to use.
It’s easier to just deal with 4 remote controls in the end.
The interesting thing is my Chinese sourced Dahua cameras haven’t made so much as a peep towards the WAN since they were installed a year ago…
Because they found your neighbor’s unsecured WAN?
B^)
Ha, nah, wired PoE connection only for me. :)
Turned off and blocked off. Most of the internet aided features can be done better elsewhere.
The real value in the Harmony line is in their hardware remotes. Unfortunately the latest ones require the hub.
I think we should leave these attack vectors in, until the manufacturer decides it’s time to allow firmware modification of your own device by, for example, using a hardware switch (no way will THAT get exploited over the internet)
Sometimes it is better to just turn on a light or turn up the volume yourself…still.
Interesting read.
IoT: people will spread their cheeks for hackers cause it’s too much of a hassle to get up and turn on the lights
MIPS Linux Kernele, cute.