Anyone know what are the reasonable steps that d-link failed to take?
I see no mention of it in the article.
I see no mention of it in the article.
1. “hard-coded” login credentials integrated into D-Link camera software -- such as the username “guest” and the password “guest” -- that could allow unauthorized access to the cameras’ live feed;
2. a software flaw known as “command injection” that could enable remote attackers to take control of consumers’ routers by sending them unauthorized commands over the Internet;
3. the mishandling of a private key code used to sign into D-Link software, such that it was openly available on a public website for six months; and
4. leaving users’ login credentials for D-Link’s mobile app unsecured in clear, readable text on their mobile devices, even though there is free software available to secure the information.
There are pretty common-sense mitigation techniques for all of these.
For 1,
* Don't ship with default credentials (change credentials per-device and slap a sticker on the device with user/pass)
* Force credentials to be changed on first login.
* To avoid attacks targeting specific devices via crafted search engine queries, add a robots.txt and/or use HTTP authentication.
For 2, sanitize user input
For 3, don't publish private keys on your public-facing website
For 4, encrypt stored credentials (or don't store credentials at all)
None of these are particularly difficult to implement. In fact, they're all pre-Freshman-level, obviously boneheaded security mistakes. That we've known about and how to prevent since at least the 90's...
One old example: fetchmail
One new example: kodi/xbmc
Assuming attacker has root while the customer is logging in. But what if the attacker only has access to the file system (e.g. in the case of a stolen phone, or a broken jail/sandbox)? In that case, requiring a password/PIN to unlock the stored credentials does provide some protection to the user.
Storing passwords in the clear is always a terrible idea. If you must store credentials, at the very least they should be encrypted when at rest, and the system should require a sufficiently strong password/pattern/PIN to unlock the key chain. That way the attacker has to intercept and/or brute force, rather than merely gain access to, the device.
Ultimately, the answer is very simple: if you can't store credentials securely, then don't store them at all!
So you may be correct that DLink should not have stored those credentials at all. But just because there's no secure way to implement a convenience feature doesn't mean it's reasonable to go ahead and store passwords in the clear.
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.
No, that doesn't make it OK to store credentials or other sensitive data in the clear.
> Has such a case ever occurred? I can't think of one.
Stolen encrypted drive/stolen drive with encrypted passwords on it? It's happened to me, personally (a usb key with my .password_store on it).
> 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.
First, I'm not aware of any tech giants who store passwords in the clear.
Second, just because the heavy weights do it doesn't make it reasonable.
> Of course, if you have filesystem access you can replace the application on disk, patch it to steal the password easily.
There are a lot of plausible scenarios in which an attacker gets RO/RW access to a portion of a file system but doesn't have the root or the capability to MITM/replace a binary.
> There's just no secure way to do this on today's computers
I think FTC's issue is this: "look, there's this really really simple thing that you could have done. Obviously it's not perfect, but doing this would have cost you basically nothing and would have at least made attacks a little bit harder. And even though it's basically free to implement and a very common practice, you didn't even bother."
Now, perhaps DLink had this discussion internally and decided that they agree with you. In that case, I'm sure those internal discussions will come out during the lawsuit, and a lay jury will have the difficult task of assessing some variant of the argument we're having here.
(Also, regardless of this one issue, shipping with default credentials w/o requiring a password change, and publishing a private key on a public website, are pretty egregious breaches of known best practice at time of sale. All while describing the device as "secure"...)
Mozilla, Microsoft and Google all effectively do this in their browsers. Don't believe me? Run the nirsoft webbrowserpassview. With just the files in your profile directory someone can dump your passwords. Sure, they're not "in the clear" but in practice it's just as bad if not worse. The number of accounts stolen with things like istealer is ridiculous. You can literally grab someone's entire lifetime of accounts in a fraction of a second.
I'd argue this isn't something a good developer would even attempt as it provides little more than a false sense of security to users. Good developers should be safe to absolutely refuse half measures like this as I do.
This won't work if the user sets a master password (which I do).
> Good developers should be safe to absolutely refuse half measures like this as I do.
Yes, I mentioned this as a reasonable alternative in my original post.
>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 yet millions of people use password-protected password managers.
Including FireFox, which DOES encrypt your passwords, and which DOES allow you to optionally set a master password. And if you do set that password, it DOES use that password as an encryption key. And in that case, if someone gets physical access to your device, they'll need to install a keylogger or brute force your master password. Which requires a lot more effort than simply copying a file, providing more opportunities for the attacker to fail, for you to detect the attack, or for investigators to track the source of the attack.
And no, that won't save you if there's a critical security bug in your OS's kernel. Which there probably is. But that doesn't mean you give up on a sensible and easy to implement security policy.
The calculus is very clear here -- encrypting the passwords costs the developer and the user almost nothing (maybe 10 minutes to 2 hours of time for a competent developer; maybe a penny or two of electricity across the lifetime of the device). And there is a definite benefit to the overall security of the system -- the attacker needs to clear one more hurdle to get device passwords, and security-sensitive consumers can make that hurdle a rather large one (rooting the device and installing a keylogger).
No, it's not a silver bullet.
Yes, it is strictly more secure that the alternative.
Not true, they can simply dump the RAM on your browser while your passwords are decrypted, which is probably the case when you run their malware anyways. It's a completely pointless half measure to encrypt those passwords. Worst case they have to patch it or hook it with something like Frida to do it next launch cycle. Keyloggers just ain't targetted and automated enough for me at least, but it's fairly trivial to just grab what you need from memory and run.
In fact according to this bug, the master password is stored in cleartext in RAM when your firefox is logged in so a simple string search on a memory dump could potentially do the job for someone without even the smallest RE capability:
https://bugzilla.mozilla.org/show_bug.cgi?id=539608
If you have the RE capability to do one, it's not really any more than is required to do the other. It's not another hurdle. Just doing it at runtime instead of purely on disk.
Phones/laptops are stolen. When they're stolen, they're turned off -- often by yanking a battery -- to prevent lockout/wipe/locating features. That wipes RAM. And after they're stolen, they're rarely returned for use.
Also, file system access doesn't imply access to a RAM dump. Especially on Android/iOS. And on a server, there are whole classes of vulnerabilities that provide RO access to certain files but can't be trivially exploited to provide access to a RAM dump.
So on many relevant platforms, I don't think it's true that access to portion of file system == access to RAM dump for particular process.
I agree that nearly all password storage mechanisms have serious problems, and that storing passwords is not ideal. However, if you're going to do it, then encrypting at rest is one small, extremely cheap security mechanism that does prevent out certain attacks.
I think maybe you're arguing that we shouldn't store passwords in app-specific password managers at all, which I don't necessarily disagree with. But I do disagree that encrypting at rest is "not another hurdle". For many attack profiles, it is.
No, it doesn't. If I have filesystem access in the sense you're talking I can just replace the application's executable with a malicious or modified one for example, which will allow me to steal your password still.
Correct me if I'm wrong here and there is some exploit class which might allow reading of but not writing to private application data and executables? I certainly haven't seen one and this would be the only scenario in which what you're saying has an impact.
As for the theft scenario - you could just as easily prevent the theft risk by setting a password on your device which would protect it at the platform level - where it should be. It'd also prevent other private data leaks which I'd say are higher risk than your router password which is useful only on your internal network, like your SMS messages, email accounts, authenticator tokens, etc. None of which I might add ask for passwords, dumping Google Authenticator tokens is as simple as running a SELECT on the sqlite database, they're not encrypted at all.
This precedent creates unlimited liability for so much software and hardware that gets created.
It is the abiilty to warranty against this type of stuff that has let OSS take off. I expect this to have a chilling effect.
In my opinion we should be against this the way we were against software patents and CISPA.
Just because as devs we are mad when our bosses make stupid security decisions, doesn't mean this is the way to handle it.
I believe this is a very different situation than product liability we are used to. In these cases damage is the result of malicious attack by criminal actors.
An elected congress gives agencies regulatory authority and provides over-sight. If Congress chooses, it can dismantle the FTC or pass a law stating that DLink cannot be held liable.
Congress enables regulators to do things you don't like, because it's impossible for Congress to micro-manage the entire Federal bureaucracy and military. Congress is well within its Constitutional rights to empower third parties to enact enforce certain classes of regulations.
I understand why you find that frustrating, but it's dishonest to characterize that situation as an "unelected government". The government is elected, and regulatory agencies must answer to those elected governments.
> This precedent creates unlimited liability for so much software and hardware that gets created.
You know what? Tough luck.
Most people who build things professionally and sell those things are held liable for their work. Take a look at what DLink actually did, and tell me that their engineers/management was behaving in a responsible and reasonable manner.
Maybe it's a good thing that the gov't is forcing software and hardware companies to start taking ownership of their craft. The market is certainly failing to price in security.
> It is the ability to warranty against this type of stuff that has let OSS take off. I expect this to have a chilling effect.
On the other hand, I highly doubt this case or any resulting precedent (if any) will have a noticeable chilling effect in OSS.
I guess time will tell which of us was correct...
> damage is the result of malicious attack by criminal actors
And yet, those attacks were completely foreseeable since at least the early 00's... I could've told you the day that DLink released these webcams exactly what would happen. I'm sure plenty of DLink's engineers tried to tell their own management...
> Just because as devs we are mad when our bosses make stupid security decisions, doesn't mean this is the way to handle it.
Perhaps this is the best jumping off point for a productive conversation -- what's your proposed solution?
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.
But what if this course of action -- investigation, enforcement, sanctions, etc. -- ends up costing substantially more than the effective cost of device manufacturers giving a damn?
All of DLink's issues (maybe aside from command injection, but I'd argue even that) could've been trivially prevented. I could've identified and fixed these issues in a week or two of time.
So basically, you're saying the country should suffer millions or billions in lost business opportunities (via sanctions), in addition to paying tens or hundreds of millions for increased investigation and law enforcement activities. All of this, to save DLink from having to hire even a single half-decent PM or SE who knows that default passwords are a bad idea and maybe we should not post private keys on a public website?
How is that even remotely fair?
> And ISP's could stop this DDOS activity. We should police this at that level.
This doesn't address other forms of harm. If botnet owners can't use their farms for DDoS and spam services, they'll turn to identity theft and ransomware. Most already have.
> And punish companies that perform bad security in the marketplace
Isn't that exactly what the FTC is doing here? Or do you mean that the marketplace should punish them? Because the latter clearly isn't working...
> Lets be clear, this is selective enforcement
Well, yeah. Literally all enforcement is selective enforcement. From speeding tickets to illegal gambling, drug distribution, and tax fraud. Police and regulators choose which cases are most egregious, and make an example. Even in murder cases, police sometimes choose to stop investing resources in a tough/cold case.
All investigation and enforcement is selective.
> No one who created these devices was ever told that these practices were illegal, or would result in sanction
With all due respect, a lot of us have been calling on the FTC and other regulatory agencies to sue these companies under existing consumer protection laws for a long time now.
And the FTC themselves have been making some noise since at least 2013 about following best practices, together with wording that specifically points out to major companies (like DLink!) that the FTC already has the legal tools needed to pursue punitive actions.
Perhaps DLink didn't know there were already laws on the books that could be used punish particularly incompetent software engineering. If they were a small company, I might be more sympathetic. But they aren't, so IMO, that ignorance is entirely on them.
> 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... So startups will have to buy security insurance. And that will be expensive.
I doubt it. They might have to start following best practices and designing secure software. And yeah, that means they can't "move fast and break things" when it comes to security. Cry me a river...
If those projects are being run by people who are incompetent and unable to consider the importance of protecting user privacy through competent security, maybe that isn't such a bad thing. If FAA rules stop people from crowdfunding new passenger aircraft and leave it to the companies who actually have the skills, expertise and responsibility to build a plane with the relevant safety measures, as an airline passenger, I'm okay with that.