Here's a great idea: Why don't we hardcode the same private key into all our smart home hubs? Smart home company Zipato hardcoded the same private SSH key into every one of its hubs, leaving its system open to hacking, researchers revealed this week. The eggheads at security shop Black Marble demonstrated in a blog post how that flaw, combined with two related vulnerabilities, allows them to access the hub and devices …
This post has been deleted by its author
No, dropbear is the name of the ssh daemon, and /etc/dropbear is the default config directory.
Now, "dropbear" https://matt.ucc.asn.au/dropbear/dropbear.html was written by an Aussie, but that says nothing about the hub.
"I am genuinely staggered that this kind of shit still happens."
I'm genuinely not. People need to stop buying this crap, while the security is an afterthought. Car security for keyless entry to Jaguar Land Rover vehicles has been shit for over 10 years and yet people still buy them too. It's been common for people to turn up with cheap Ebay equipment to airport car parks and unlock hordes of cars with a transmitter and a signal from said equipment, yet people keep buying the cars... >>INSERT WTF GIF HERE<<
Related disclosure: I have a friend who lives in a rather nice area and her partner has had 2 Land Rover Discoveries stolen from outside their house. Their next vehicle to replace it - Yep! A Land Rover Discovery. Some people don't learn.
I see your point Mr Monstr, but IoT is not marketed as an aid for people with impairments. IoT is marketed as convenience. I can see IoT being a quick fix for some people, but the people I know with long term disbilities are more likely to use a tried and trusted approach.
If you're going to be permanently in a wheelchair, do you a) pay for the light switches in your house to be moved to a lower level or b) get someone to fit a smart hub and some bulbs? You're more likely to go for option a) because there's going to need to be a metric fuck-tonne of work required for everything else as well.
But the IoT devices make it much easier for people to get assistance, in that most of the people on here could now set up something with COTS IoT parts for a friend or relative.
In the past you would have needed to call in a specialist company and the kit was significantly more expensive.
While this seems like a good idea, it's a road down which people who need assistance have to put up with compromised security (because why should they receive support to have things done properly when they can be done cheaply?), while the rest of us get to have a choice. When viewed from that angle it seems less enabling.
As usual, there's a sliding scale, not everyone who needs adaptations to help with everyday living needs their whole home modified. And some of this technology can help, but it needs to be secure for all our sakes. Which is where lazy (using something assistive to make life easier for whatever reason) is being conflated with lazy (consumers being averse to the small additional amount of effort to set up properly secure devices).
You are always going to be somewhere in the Security/Convenience/Cost triangle - you can minimise any two, but only at the expense of the third.
I understand that the latest generation of keyless entry key fobs only transmit when movement is detected, so they are relatively immune to the amplified relay attack, especially when the keys are left on the hall table overnight. No doubt it won't take the bad guys very long to discover a new way to steal cars, though.
Too many people simply don't give a stuff about security of any electronic devices (that includes cars). All security is an inconvenience and computer/phone/car security even more so because it is so easily bypassed.
The manufactures of all this crap are equally to blame because the only things left to differentiate one boring thing from another is software features that add little (no!) value.
Why the hell a car needs to be keyless entry just defeats me. For most is it the next most valuable piece of property (or the bank's) after their home. But then I supposed the same people put electronic locks on their doors because getting the key out whilst clutching their phone and takeaway is too difficult.
Consumers (i.e. not Reg readers) assume that when they buy something that says it's secure, it will be secure. They don't expect to have to understand every nuance of the technology. And they don't take additional steps to enforce it because (a) they don't know where to start and (b) most people assume the world of sales and marketing isn't full of lying, cheating arseholes, despite all evidence to the contrary.
The problem is that there's no regulatory environment to enforce their assumption. We should be passing laws (like California) to ensure a minimum level of security and establish a regulatory authority to enforce it (or task an existing regulator, while giving it sufficient resources to do so). Instead, we're wasting time on Brexit, endlessly, and so failing to tackle this and a thousand other more pressing problems.
I have to say that I'm not at all surprised.
If I *did* ever desire this kind of useless home automation, I'd do it with a proper access control system. If I desperately needed voice control, etc. that's not available, I'd interface to that access control via one of the many Open Source home automation things, that work offline, without DRM or centralised control, and off my own hardware (so you can limit this sort of thing to a closed-off VLAN).
The commodity nature of this trash is what's making it insecure. "Plug n Play" is just another phrase for "Anyone can do stupid stuff".
Honestly, I'd rather manage a bunch of Raspberry Pis with some interface circuitry and do it myself. The management burden would be huge but a lot less to worry about in the end that putting this stuff on my Wifi / Ethernet networks.
I discovered the same problem in an open-source intrusion detection system distribution a year or two back as well. Every installation from the ISO they provided would include the same SSH private key. I notified the author and in less then a day they had a new ISO posted with a modified installer that generated a new key during installation.
he company has put out a software update that should fix the API holes and has scrapped the single hardcoded SSH private key.
How are they contacting people who have purchased their dodgy boxes?
How many of their boxes will remain unpatched as the people using them don't know about the patch?
In general terms, without any claim of knowing the specific circumstances here, the very first thing absolutely all of these boxes do is either nag or outright compel you into registering with their cloud. Once they have the associated email, it's really up to them whether they feel like contacting you (or just throwing up an "uh-oh, must update right now!" page instead of your regular one at your next login).
As a side note, they can also very well do that without any registration at all, much as Firefox or any software can - simply by having the hub call home and check for updates whether you asked it to or not. But make no mistake, they usually prefer to have you registered nonetheless...
Until there is an industry standard protocol for this IoT stuff to conform to, along with a full, independent certification and rating system which covers all aspects of the various devices' operation with explicit attention focused on security, I am not interested. Leaving this to the individual vendor to figure it out is not even an option. Having an agreed protocol to cover these things also - in theory - means you can mix'n'match stuff from different vendors with minimum fuss, as well as potentially reducing the need for updates to be pushed out to the devices.
Mind you, tying yourself into one vendors kit still leaves you open to subsequent abuse from them when they decide one or all of your current devices are no longer going to be supported by them after a certain date, meaning you have to replace them. And that is not cheap.
Not that I disagree, but it should be noted that in this _specific_ case we're talking about z-wave devices, which is a globally interoperable standard. So even if everything you bought is branded "Zipato", you're free to chuck out just that hub at any moment for any reason and simply start using any competing manufacturer's hub (or even roll your own based on open source software, a Raspberry Pi / Orange Pi / whatever and a USB z-wave dongle) and pick up pretty much exactly* where you left off.
*yes there will be minor advantages in integration with a manufacturer's own kit, but no functionality of significance is supposed to be lost by switching to anything else. As with everything else in practice, ultimately the devil is always in the details - when in doubt, ask first...
That's a good point and to be honest I don't actually have an issue regarding the functionality and interoperability of these devices and their respective hubs themselves. What I do believe is sorely needed is for it all to be encapsulated within an inherently secure and robust protocol so that the hard part - the security - is already done for you and neither the vendors or end users then need to be concerned about enforcing security as it is already there.
As it stands the obvious lack of concern around security in these devices from the vendors makes this a non-starter for me.
The article says:
"The key was extracted by simply imaging the hub's SD card: in appeared in the '/etc/dropbear/' folder and was called 'dropbear_rsa_host_key.'"
dropbear_rsa_host_key is just that, a HOST key. While sharing host keys is frowned upon as it can open up MITM attacks, it is NOT the same as a user private key can that be used to login to something!
That part of the article doesn't make sense!
I was also a little confused, but it turns out that in SSH, you can use a private/public key pair to log in instead of a password, if the key is authorized.
They used the same private key on all devices.
This same private key is also authorized for remote logins.
Conclusion: The private key on my device can log into your device.
It's like default passwords.
What's the difference? Both receive unique AI databases. Absolutely unique! Which identifies you by itself, into an automatic mode, for instance asking questions. And your status remains in this database, which is also a blockchain database, i.e. cannot be faked in no way.
Sorry I cannot demonstrate and sell this miracle... Only patents.
Currently, the "smart" home product manufacturing 101 manual is as follows :
1) Find some everyday thing and make it more complicated, and need batteries
2) Definitely do not do any sort of penetration testing whatsoever
3) Hype the shit out of whatever it is and flog it off at the highest possible price
4) Cash in and never change anything until your customers are readying their torches and pitchforks
Security ? They've heard of it.
To be honest even manufacturers of old-fashioned mechanical locks can turn out some astonishingly crap devices. The American manufacturer Masterlock is the most famous of these; their padlocks are normally very robust against the standard "Ape with big hammer", but the moment said ape grows a brain and uses even a modicum of intelligence, their products often fail and fail badly. For instance, if one puts tension on some of their padlocks then taps gently and repeatedly with a hammer, the locking pawls creep open and the lock fails.
Masterlock locks are also noted for not using any of the many techniques available to frustrate bump key users and novice lock pickers. They have even included the classic "one key-like device opens everything" on some models, by leaving a bypass vulnerability open.
Like all the Internet of Things makers, they are relying on thieves being uncommon and generally spectacularly stupid, so even a little security will defeat them.
It's not that they don't do penetration testing they just think that by employing devs they are covering themselves without realising that pen testing can be a whole other field, plus it's about costs, do you want to pay x for experienced competent developers that think of all issues or do you want to pay y for cheap devs just out of HTML school that can just about do the job using the internet to write the code? y < x by a magnitude.
You forgot :
5): make it dependent on some “cloudy stuff” so that it won’t work anymore when the company gets bored, goes out of business or the network goes down.
6): leverage #5’s connectivity (pardon the corps-speak) to slurp up all the data you can.
Cf: Nest thermostats.
Or "Shub" for short. Because they do for your home security what H.P Lovecraft wrote might (fictionally) happen to your peace of mind.
Interestingly, Wikipedia contains this sentence on the subject of Shub-Niggurath: "in a letter to Willis Conover, Lovecraft described her as an "evil cloud-like entity".
Ah yes reminds me of my early noughties custom 'gaming' laptop. Badass for its time, it had about the size, thickness and weight of a paving slab. Still have the thing somewhere. Power brick the actual size and weight of a house brick. On of those dark blue/purple damp-proof ones. Those were the days...
It happens because its actually really very hard to produce unique keys, and burn them into the non-volatile memory of a CPU/microcontroller, or a Flash/FRAM device or an SD card, as the devices fly down the production line in QianDong or wherever they are being made.
Producing secure devices in a mass-production environment and keeping them secure is actually really really really hard. If I am manufacturing 250,000 devices, am I going to generate 250,000 unique SSH keys, give them to my (Chinese) manufacturer, and expect them to ensure that each device is programmed with a unique key, and correlate the devices to the keys (so that I know which device has which key) AND keep all that from leaking to ______ (insert name of dodgy hacking outfit here)?
I think not. It's really fucking hard.
So that's an excuse, is it?
If I am manufacturing 250,000 devices ... >> is that all?
am I going to generate 250,000 unique SSH keys ... >> yes!
give them to my (Chinese) manufacturer, and expect them to ensure that each device is programmed with a unique key ... >> absolutely
and correlate the devices to the keys (so that I know which device has which key) ... >> that has to be a MINIMUM expectation.
AND keep all that from leaking to ______ ... >> whyever not?
It's really fucking hard ... That's exactly the way it should be!
Also, @Sean, to further your comment.
When I buy a bright new shiny thing, it has a serial number on the bar code label on the box.
It has the same serial number on a sticky label on the bottom (in especially difficult to read typeface) of the shiny thing.
The same serial number can be viewed in the badly designed, insecure, web page that laughingly passes for an admin interface for the shiny thing.
So, IMHO, it really cannot be difficult to generate SSH keys and install them on the production line.
If I am manufacturing 250,000 devices, am I going to generate 250,000 unique SSH keys, give them to my (Chinese) manufacturer, and expect them to ensure that each device is programmed with a unique key, and correlate the devices to the keys (so that I know which device has which key) AND keep all that from leaking to ______ (insert name of dodgy hacking outfit here)?
No. You're going to have the device to generate its key on start up if one does not exist.
Why would you need to know the device's key? If it is for some ill-adviced clody paltform, the device can tell the platform its key when it registers itself.
correlate the devices to the keys (so that I know which device has which key)
Why in $deity's name would you want to do that? So you can have some database of backdoors to all those devices? When someone buys your bit of kit, why would they want you to be able to access it via its baked-in key?
When someone buys your bit of kit, why would they want you to be able to access it via its baked-in key?
Because they expect me to log in remotely and troubleshoot their problems.
When I was maintaining the code for an expensive appliance (didn't design it, mind you), all those boxes in the field would connect via VPN to a central vendor server. Every firmware version had a different hardcoded root password, that was deemed secure enough.
Customers could disable remote maintenance but hardly anyone ever did.
Sorry, I'm the only one who knows what AI is and who can tell you how to use it.
Here's a great idea:
AI database is a blockchain system where each personal device had a synchronized copy of AI. Therefore, AI becomes a private key: AI can just talk to you and determine who you are and what your rights are.
Insert historical comment about this being 2019 and no manufacturer hard codes the SAME default public/private keys into all their devices. Yet again.
I hope the baying mob that went after me on el reg's comment sections for suggesting this happens regular as clockwork in devices I test are by now, after multiple stories detailing this exact issue, actually starting to get just the tiniest of glimmers of a inkling of how completely clueless they were.
"The key was extracted by simply imaging the hub's SD card: in appeared in the '/etc/dropbear/' folder and was called 'dropbear_rsa_host_key.' The folder was password protected but easily cracked with some readily available software."
How does one password protect a folder/directory on presumably a *nix system (that the device in question is running on)?
One doesn't, the description in the article is incorrect. According to the blog post:
The SSH key was found by removing the SD Card from the device and imaging the SD Card. SSH key was found in '/etc/dropbear/' with the name 'dropbear_rsa_host_key' which is password protected when using this format but you can still extract the Private and Public key.
It's a password-protected private key (openSSH format). However the default for this is no longer secure and now vulnerable to brute-force attacks: https://www.digitalocean.com/community/questions/is-the-password-on-my-ssh-keys-really-secure and [wayback link to ref.d details]
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
