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
A vigilante trying to improve IoT security
221–230 of 242 posts
Re: A vigilante trying to improve IoT security
#222Earlier 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.
Re: A vigilante trying to improve IoT security
#223Earlier 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…
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
#224Earlier 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.
Re: A vigilante trying to improve IoT security
#225Earlier 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.
Re: A vigilante trying to improve IoT security
#226Earlier 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?
Re: A vigilante trying to improve IoT security
#227Earlier 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…
Re: A vigilante trying to improve IoT security
#228Earlier 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?
Re: A vigilante trying to improve IoT security
#229Earlier 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?