FTC sues D-Link over router and camera security flaws

That's the problem.

Ah, hello, every manager that has ever made a decision causing the problems people further up are grousing about.

The point of defense in depth is there IS no "one perfect layer."

Strong passwords, two-factor auth for privileged services, access control policies (ACLs/firewalls), access logging, etc. are all requirements of any secure network. And that was just "off the top of my head on a Friday" kind of stuff.

A security design that takes advantage of multiple layers and compartmentalization is your ally against attackers. They love networks with hard shells and squishy insides. Once they are in via a service, no matter how innocuous, they can move laterally to the real targets with impunity.

But ultimately this kind of stuff is a culture issue. Culture issues are hard to fix but it's usually the root cause of bad blood between operations and development. It generally needs to be addressed on both sides though. It's really easy to think it's just a bunch of grumpy and possessive ops people but those behaviors are often rooted in how the dev teams interact with them. Things like punting releases over a wall and calling it a day, not participating in oncall duties despite causing many outages and a disparity between how credit (for releases) and blame (for outages) are assigned are often cited as issues that create what devs think or irrational BOFHs.

If not, you have relatively little to complain about.

And, I'll add, if you're a developer, we'd all prefer you just crank out perfect code. That way we never have deployment issues, get paged for outages, never have to work around poor architecture or assumptions that don't scale or aren't load tested. thanks!

Remember, smart phones are literal bridges from one network to another.

Not because the URL is in the list directly – but the way the list is created seems like public shaming, and I’ve seen unknowing managers go "I’ve read somewhere on the internet that there’s a list of open servers, and I found ours on it, everyone can hack us, remove it now!".

So, that’s the problematic effect – with the way the list is presented, especially the way it seems to publicly shame them (and the "fix it to get off the list" statement, too), can be counterproductive.

Well, yeah, in any case, even a defunct subsidiary (of GM, not Ford) is getting recalls decades later.

High-tech has different standards than the rest of the world.

> Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

I agree here. Your first sentence can be entirely removed and your point will still stand. Except now the receiver won't have to be in a defensive position about their reading comprehension.

In other words, a better safety analogy might be the prompt when you do "rm -rf".

I'm not opposed to introducing standards here; I am just saying that it's adofferent problem.

I'm struggling think of a good analogy, but it seems more like suing Ford because thieves can easily steal their cars for use in robberies.

In essence, the device is being used by an unauthorized 3rd party to harm a 4th party. The device owner in some cases is never harmed or even inconvenienced, and neither is the manufacturer.

It's a shitty situation, and I don't personally know where the line should be drawn, but IMO it should be drawn clearly.

Being honest with yourself, would you have certified something as secure if it used OpenSSL correctly (assuming such a unicorn could exist), before you knew about Heartbleed? If your answer is no, what would it take for you to be willing to certify something using SSL? (I assume "not using SSL" is an obvious certification black mark.)

What I mean by "put your business hat on" is that I am not trying to make the point that this is impossible. I don't think it is. What I mean is, think business, think risk, think risk management, think about how your business is basically made out of black swan events, think about what it would take for you to put yourself out like that, and put some real numbers on the money and at least mentally come up with a sketch of what it would take.

Speaking for myself, it doesn't take me long before I notice that my certification standards would simply annihilate the entire IoT industry as it now stands, on even basic stuff like "Since you're using C, are you using best-practices static analysis? Can you update your firmwares? How secure is your firmware update process?" Those three questions alone and I've probably tipped nearly the entire industry into a negative cost/benefits analysis. Does that solve the problem? Again, I mean that question more honestly than it probably sounds on the Internet; a case can be made that an industry that is currently basically only able to survive by extensive offloading of what become negative externalities really shouldn't exist, even in a bootstrap phase. Perhaps nuking the industry as it now stands is the best thing we could do in the next couple of years. Pour encourager les autres if for no other reason. Let the industry come up with some best practices, form some "sell shovels rather than dig for gold" companies around building more secure IoT platforms, come back at the problem after that.

A real certification process that really solves this problem is probably unsustainably expensive for the industry as we now know it, xor the certification will be a useless rubber stamp that doesn't solve the problem.

This is a very one-sided read of the situation.

The typical Blitz can lawsuit went something like this:

A 3-year old toddler knocked over a blitz can in a basement[1]. Vapours from the can reached the water-heater, which then flashed-back into the can, causing the can to explode, severely burning the child. This would not have happened had the can's nozzle been built with an industry-standard 10 cent flame arrestor, which federal regulators STRONGLY advise all gas can manufacturers to include, but which Blitz had for years refused to take the simple precaution of adding to their product.

It's the "ignoring simple, industry-standard safety precautions" that will get your ass nailed to the wall by a liability judge. Engineers who had worked for the company testified at trial that they were ordered to destroy documentation showing that Blitz was aware of the problem, had done internal testing, and had designed flame-arrestors for their nozzles, and that management killed the project after a change-of-ownership.

[1] http://www.recordonline.com/article/20030919/News/309199995

No (or at least, not to my knowledge), instead people just had to buy new things. Standards change. New security vulnerabilities are discovered. Liability doesn't stand in these cases.

If you can't possibly find every security vulnerability in your product, you shouldn't be held liable for the inability to do so. You have to disclaim that, as I'm sure D-Link does.

>Nobody will blame you for bad crypto if you released software in [the 80s and early 90s].

So you are 100% agreeing with me.

Security expert Bruce Schneier expanded upon what I said back in 1998:

>Cryptographic algorithms have a way of degrading over time. It's a situation that most techies aren't used to: Compression algorithms don't compress less as the years go by, and sorting algorithms don't sort slower. But encryption algorithms get easier to break; something that sufficed three years ago might not today.

>Several things are going on. First, there's Moore's law. Computers are getting faster, better networked, and more plentiful... Cryptographic algorithms are all vulnerable to brute force--trying every possible encryption key, systematically searching for hash-function collisions, factoring the large composite number, and so forth--and brute force gets easier with time. A 56-bit key was long enough in the mid-1970s; today that can be pitifully small. In 1977, Martin Gardner wrote that 129-digit numbers would never be factored; in 1994, one was.

>Aside from brute force, cryptographic algorithms can be attacked with more subtle (and more powerful) techniques. In the early 1990s, the academic community discovered differential and linear cryptanalysis, and many symmetric encryption algorithms were broken. Similarly, the factoring community discovered the number-field sieve, which affected the security of public-key cryptosystems.

https://www.schneier.com/essays/archives/1998/05/the_crypto_...

The ironic thing is this article also said "I recommend SHA-1"... SHA-1 was broken 7 years later.

But aren't we (and the NSA) discovering new attacks all the time? So hence, their de facto security decays.

We do have companies already making a stand on security, using it as a competitive advantage. Apple, for one, has staked their name on their security in the past few years. That's their competitive advantage, is how secure TouchID and their secure enclave is. You're right that consumers don't see security as entirely necessary yet, but it took a long time for seat belts and airbags to become standard in cars, and even longer for them to be appreciated. Even today, many people refuse to wear seat belts.

But bear in mind, automotive security is a moving target too. Seatbelts, then airbags, then roll cages, then crumble zones, then backup cameras, then backup sensors, then automatic parking, then self-driving. There's very little that's new in the world, it's almost always been done before.

Has such a case ever occurred? I can't think of one. Of course, if you have filesystem access you can replace the application on disk, patch it to steal the password easily.

> Ultimately, the answer is very simple: if you can't store credentials securely, then don't store them at all!

Many users want it anyways, and it's secure enough that unless you have remote attacks or the security level of Windows desktops with people downloading executables and running them constantly, it's unlikely to be an issue.

It's a trade-off, of course, but I don't think that means it's an unreasonable one to make.

Of course, you should probably go ahead and tell this to browser vendors. Script kiddies are running around selling accounts because of how they store passwords - encrypted, but in a total half measure way. Personally, I don't think it's reasonable to hold D-Link liable for a trade-off that even the biggest companies in tech make all the time. And one which is much more costly in those cases too!

There's just no secure way to do this on today's computers, we must rely on the security of the platform here. If storing passwords in this way is a problem, it's a platform security issue or a user issue, not an application issue.

TPMs have the potential to solve this, but at some scary costs which may adversely impact security in other ways, like preventing reverse engineering.

>requiring a password/PIN to unlock the stored credentials

defeats the purpose of a feature built to not require a user to remember a password. "Save my password" features are very common. I use that feature of Firefox all the time. I fully understand if someone gets access to my filesystem, then they get my passwords. (And they also get all the other important stuff on my filesystem like my photos and documents.)

And ISP's could stop this DDOS activity. We should police this at that level. A system where when a DDOS is reported by a reputable web hosting company or service provider to a system that ISPs belong to, could stop DDOS in its tracks.

Enable 2 factor auth at the ISP level. If a report of DDOS comes in, send an SMS to the authorized user of the account.

And punish companies that perform bad security in the marketplace. We are getting more tech literate as a people, as a society. The market might not be fulling pricing in security right now, but the issue is new and awareness is just beginning.

Lets be clear, this is selective enforcement. D-Link is one operator, using what were very common practices at the time, and still are.

No one who created these devices was ever told that these practices were illegal, or would result in sanction. And now we are fining them. D-Link will weather this as it is big enough. But small operators wouldn't.

So the result of this government action is that startups and crowd funded projects are less viable. Now, startups and kickstarter projects need to have a line item in their budget for security insurance. And an insurer has to take on this risk. Because it wont be policed or litigated evenly. And thers no telling what the security standards of tomorrow will be.

So startups will have to buy security insurance. And that will be expensive.

Big companies will survive. They will be able to pay the protection fee, the extortion fee. The status quo will remain. We won't be more secure, because the real actors making us insecure are nation-states and Chinese manufacturing.

Back to my point, singling out DLink when every other vendor has similar practices smells fishy.