Live data from Hacker News

A vigilante trying to improve IoT security

gizmodo.com

221–230 of 242 posts

Re: A vigilante trying to improve IoT security

#221

Earlier quoted context omitted.

Not necessarily. If a consumer's device is bricked within the (usually 1-year) warranty period, then they're able to send it back to the manufacturer for a replacement, which pushes the cost right back to the manufacturer. Also, if the device is bricked very quickly after buying it and installing it, the consumer will very likely simply return it to the retailer as defective, which again pushes costs back to the manu…

I think that's actually the only solution to the IoT security problem: more people regularly scanning for and bricking these devices, until the return rates make it unprofitable to sell broken devices in the first place

In that case, I think for the vigilantes it's absolutely critical that they figure out how to brick these devices as quickly as possible when they come on the market, because if they're targeting devices that are a couple years old now, that means many consumers will be past their warranty period and may not be able to return them.

Re: A vigilante trying to improve IoT security

#222

Earlier quoted context omitted.

I experience something akin to this at work all the time. There's the real-world pragmatists and the software purity philosophers. Tell the family of someone killed that, "____ shouldn't have purchased a device without knowing how to secure it!"

Allowing a medical device that can kill or harm someone to be connected to the internet would be a dramatic failure of both the company that produced it and the government. Monitoring is one thing but it better be a one way street or air gapped. No one should be able to do anything to a medical device over the internet besides read information. Or even over a LAN. Even if it is much less convenient or practical.

One could make that argument in a hospital environment, but eventually patients go home. While they're at home, some telemedicine might save their lives. Should we expect e.g. pacemaker patients to know how to set up a VPN? Or maybe you're just saying that pacemakers must be controlled through direct contact only... that's on the device designers then, not on local network admins.

Re: A vigilante trying to improve IoT security

#223

Earlier quoted context omitted.

What would your perspective be if I took a stance to secure your vehicle, or the power company, or any myriad of others simply because I chose to? What do you do when I change my logic to, well this is a ZERO DAY exploit, but you need to be patched, without understanding the complexities of your device or network. Which we all know QA takes a while because of variables. Look at any microsoft patch for evidence of tha…

> What do you do when I change my logic to, well this is a ZERO DAY exploit, but you need to be patched, without understanding the complexities of your device or network. I'd say you are changing topics. The topic at hand is about devices that are designed to be insecure, because the involved parties just don't care. The manufacturer KNOWS yet doesn't care because the issue doesn't cause him any harm, and the user ju…

Ok, lets switch this around. You just rented your new apartment, they didn't change the locks from previous tenant. Now, by default everyone knows you should change locks to include the owner, manager of property, and renter. I, the previous tenant decided to stroll by the house one day, I realize that the doors are still easily unlocked by my key, so I walk in and poke around. Realizing that this is a security risk, so following your logic, it's completely sane for me to destroy the house and prove that it's a risk. Before you say, that's different, MFG will replace a device, i'm going to argue ok sure, they'll replace it, by that same virtue isn't that what insurance is for? They'll replace the property.

Bottom line, vigilantism has a cost and picking and choosing morality of ideals based on your sole opinion is neither appropriate or legal. laws exist for a reason.

Re: A vigilante trying to improve IoT security

#224

Earlier quoted context omitted.

The point is how do you know the vigilante's fix won't have adverse side effects? EDIT* I agree with the bulldozer analogy.

> The point is how do you know the vigilante's fix won't have adverse side effects? While you have raised some valid issues, this is not one of them. Having an unsecured device on the internet has some very definite adverse side-effects.

So does taking a vigilante approach to addressing these devices. It's no different than saying, there is crime in the inner city and It's my duty to handle it.

Re: A vigilante trying to improve IoT security

#225

Earlier quoted context omitted.

That's totally besides the point. The idea here is that no engineer would knowingly sign off on something bad.

A rather optimistic idea, I'd contend.

I concur, in fact, how many IT professionals make bad SECURITY decisions because they in fact are trained to build and maintain an working infrastructure first and foremost.

Re: A vigilante trying to improve IoT security

#226

Earlier quoted context omitted.

I think the problem is as often not about careing, and being unaware of anything outside their little subsystem. You used to have what was essentially airgapped and self contained. But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom. Neither of the teams responsible for the features considers that something can jump from x to y, al…

> But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom. So then the question becomes: How are we going to educate engineers about this class of problems?

I think the first step is integrating secure design practices into curriculum. I was surprised to see how little emphasis was put in in both Traditional CS and Engineering courses at the universities I work with.

Re: A vigilante trying to improve IoT security

#227
post #219

Earlier quoted context omitted.

> What they get is irrelevant It's actually the main relevant part of the analogy. It goes to veracity. There's a person who gave a public talk about manipulating Bitcoins with weak private keys in order to alert the owners that they were vulnerable. But he did it in a way that verified to the owner he hadn't in fact stolen the coins (moving small portions around or maybe signing with the key, I can't remember). He a…

You're probably talking about me. I actually screwed up when I was moving coins around, and ended up emptying someone's address out, however I put everything back within a few minutes. I haven't had anyone whose coins I touched accuse me of anything unseemly, but of course there are random posters on internet forums who talk shit. Your point that I couldn't have given a public talk had I stolen the coins is completel…

Oh, hey! Glad to hear you talked to a lawyer beforehand.

Re: A vigilante trying to improve IoT security

#228

Earlier quoted context omitted.

> What they get is irrelevant It's actually the main relevant part of the analogy. It goes to veracity. There's a person who gave a public talk about manipulating Bitcoins with weak private keys in order to alert the owners that they were vulnerable. But he did it in a way that verified to the owner he hadn't in fact stolen the coins (moving small portions around or maybe signing with the key, I can't remember). He a…

So what's gained by bricking, disabling, or modifying devices, that couldn't be proven with a simple these devices are vulnerable announcement?

Bricked devices can't participate in a DDOS attack.

Re: A vigilante trying to improve IoT security

#229

Earlier quoted context omitted.

I think the problem is as often not about careing, and being unaware of anything outside their little subsystem. You used to have what was essentially airgapped and self contained. But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom. Neither of the teams responsible for the features considers that something can jump from x to y, al…

> But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom. So then the question becomes: How are we going to educate engineers about this class of problems?

It's not the engineers, it's our managers.

Re: A vigilante trying to improve IoT security

#230
post #188

Earlier quoted context omitted.

Yes, no engineer has ever made a bad design or decision, ever.

That's totally besides the point. The idea here is that no engineer would knowingly sign off on something bad.

Which is a silly assertion
Post reply on HN