Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

"It's all fine and well until one of those improperly configured devices are a medical device or something critical. "

It would be their fault. High-assurance industry has been telling SCADA and medical industry to get their shit together for a long time. This included pentests showing it could all be destroyed. They even have people at conferences talking about it with products or basic advice to deal with it.

The reason it's all still vulnerable is that they... don't... care. They turn whatever small amounts of money the security would've cost into profit. I mean, in some cases we're talking about remote monitoring that operates one way that could be done with a data diode for nearly impenetrable security. Cheap as hell if you homebrew it on cheap, embedded boxes. Likewise for FOSS VPN if two-way is required. Instead, costly system connected to wide open Internet to save a few hundred dollars. They just don't care.

So, you have to make them care. The customers don't as much since they often don't know better. Those that do are apathetic since it will be someone else's problem. That's best moment for regulation to step in to force a solution. There's no regulation, though. Court's seem unreliable on this but still some hope there. So, your options are waiting for them to hit you, paying exhorbitant costs for DDOS mitigation due to problems others are creating (i.e. externalizing), or maybe a criminal just smashes the insecure devices until people stop buying them or manufacturers start securing them. So, I like what's going given nothing else is reducing risk as effectively.

I've brought this up to others, how would you feel if someone decided to brick / modify your car without you knowing? What would you do if that fix backfired and caused damage, hard locked the controls on your car, or worse, simply shut it off at the wrong time? We absolutely need to fix these issues, the governments of the world need to enforce standards on products, but vigilantism no matter how much you may agree with, has to be treated the same across the line.

Your counter and metaphor doesnt really apply here. Let's look at why:

1. A car is a necessity that cost a ton to replace. An internet-connected camera or TV isnt. They could just as easily not buy an Internet-enabled appliance.

2. These devices are being used as weapons when people leave them around insecure. Leaving loaded guns lying around is a bit closer but minus the lethality.

3. With cars, we have efforts on safety and security at user side, manufacturer side, and the law. There's no effort to buy secure IoT by these users, to do even minimum protections at manufacturing, or pass laws putting liability on users or manufacturers where it should be. Now, it's more like a car with defective parts that make it hit other cars. A city's worth are affected with nobody taking action but people are told armored cars are available for a fortune.

So, these comparisons to highly damaging thefts of legit goods on innocent people are nonsense. There's defective products damaging innocent people. Nobody with power to prevent or punish it legitimately is doing anything. Im happy that a vigilante is reducing risk to Internet hosts plus putti g cost on those responsible for that risk.

Whether the car is hijacked to carry out attacks, or bricked by a vigilante trying to prevent another attack, I'd be pissed. But the blame lies squarely on the manufacturer who decided "meh, securing our devices against attack sounds expensive".

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, almost like an illness jumps between species.

Damn it, the other day HN linked to an article on how VMs sharing hardware could talk to each other using the CPU cache.

> VMs sharing hardware could talk to each other using the CPU cache

That sounds similar to a paper I read ~20 years ago that described a way to move data from a high privilege process, bypassing mandatory access control (>= TCSEC B), using page faults as a covert channel.

> it happens to run on the same soc as feature y that talk to the can bus

I wonder how many people will have to die to teach car manufacturers the lesson that there shouldn't be any electrical connection at all from the internet to the breaks.

Yep. The TCSEC had covert channel analysis as a requirement. Actually, two of the products (GEMSOS, STOP OS) certified at A1 can still be OEM licensed today in some form with a third (SNS Server) only sold to defense sector. They have plenty of competition, too, in MILS space. Solutions exist.

> 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.

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

>how would you feel if

Feelings are irrelevant.

Some vigilantes hack that said "Turn the car off at 10mph or less" is a far better outcome than the attackers option of "Press the gas and turn the wheel left as hard as you can at 100mph".

> Feelings are irrelevant.

Thank you. I am tired of these so-called arguments that start with "how would you feel if". If we're going by my feelings, you're all in deep trouble.

Can a case be made that the Insurance companies can make this problem less severe? I.e. to deny insurance to unaudited companies or charge a lot more if they refuse.

Reply on news.ycombinator.com