3 ms·

Here are the things the FTC faults D-Link for (https://www.ftc.gov/news-events/press-releases/2017/01/ftc-charges-d-link-put-consumers-privacy-risk-due-inadequa

Here are the things the FTC faults D-Link for (https://www.ftc.gov/news-events/press-releases/2017/01/ftc-charges-d-link-put-consumers-privacy-risk-due-inadequate https://www.ftc.gov/news-events/press-releases/2017/01/ftc-c...): 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...

nitrogen 10y ago
#4 is very widespread and used to be standard practice, under the excuse that you should use chmod to control access, and that access to the encrypted file probably comes with access to the key since they both have to be present on the same device. One old example: fetchmail One new example: kodi/xbmc
problems 10y ago
Correct me if I'm wrong, but isn't #4 just encouraging security through obscurity? If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc. Not encrypting the credentials on the device is not a security offense as it's not a valid security mechanism. Go ask Mozilla, Google and Microsoft about how well their encrypted credential stores work against freely available NirSoft tools or actual malware like iStealer.
- throwaway729 10y ago
  > If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc. 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.
  - problems 10y ago
    > 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. 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.
Illniyar 10y ago
Thanks! :)
willholloway 10y ago
You are right that these aren't difficult to implement, the problem is that we now have unelected government dictating coding standards by fiat, and ex post facto fiat at that. 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.
- throwaway729 10y ago
  > unelected government dictating coding standards by fiat 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?

nitrogen 10y ago

#4 is very widespread and used to be standard practice, under the excuse that you should use chmod to control access, and that access to the encrypted file probably comes with access to the key since they both have to be present on the same device. One old example: fetchmail One new example: kodi/xbmc

problems 10y ago

Correct me if I'm wrong, but isn't #4 just encouraging security through obscurity? If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc. Not encrypting the credentials on the device is not a security offense as it's not a valid security mechanism. Go ask Mozilla, Google and Microsoft about how well their encrypted credential stores work against freely available NirSoft tools or actual malware like iStealer.

throwaway729 10y ago
> If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc. 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.
- problems 10y ago
  > 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. 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.

Illniyar 10y ago

Thanks! :)

willholloway 10y ago

You are right that these aren't difficult to implement, the problem is that we now have unelected government dictating coding standards by fiat, and ex post facto fiat at that. 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.

throwaway729 10y ago
> unelected government dictating coding standards by fiat 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?