Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Hardware

Million More Devices Sharing Known Private Keys For HTTPS, SSH Admin (theregister.co.uk) 54

Posted by msmash from the Immensely-Obvious-Threat dept.
Millions of internet-facing devices -- from home broadband routers to industrial equipment -- are still sharing well-known private keys for encrypting their communications, reports The Register. From the report: This is according to research from SEC Consult, which said in a follow-up to its 2015 study on security in embedded systems that the practice of reusing widely known secrets is continuing unabated. Devices and gadgets are still sharing private keys for their builtin HTTPS and SSH servers, basically. It is not difficult to extract these keys from the gizmos and use them to eavesdrop on encrypted connections and interfere with the equipment: imagine intercepting a connection to a web-based control panel, decrypting it, and altering the configuration settings on the fly. And because so many models and products are using the same keys, it's possible to attack thousands of boxes at once. SEC Consult senior security consultant Stefan Viehbock scanned the public internet and found that the practice of using known private keys has increased over the past nine months, with the number of net-accessible vulnerable devices ballooning to more than 4.5 million network appliances, IoT devices, and embedded systems around the world. That's up 40 per cent, or 1.3 million, from November, according to SEC Consult.
This discussion has been archived. No new comments can be posted.

Million More Devices Sharing Known Private Keys For HTTPS, SSH Admin More

Million More Devices Sharing Known Private Keys For HTTPS, SSH Admin

Comments Filter:

  • This is just as good as it is bad. App and device makers are just as much if not more malicious than what we normally consider malware. Our devices and software are flat out being used against us. I agree that encryption should be as near perfect as possible to man in the middle attacks, but there simply MUST be a future way for the owners of endpoints to be able to tell what traffic their apps and devices are TRULY sending out. The biggest spies on the planet are the creators of so called TRUSTED software

    • I want to know what is leaving my systems and I should have total control over that as owner of my devices.

      Roll your own ( software)

      • When possible I surely would, but it still should not be possible for software and device owners to hide communications even from the device it is leaving (and thus its owner).

      • Roll your own ( software)

        That's sort of difficult when makers of networking appliances Tivoize their hardware in order to comply with national radio regulators' requirements for robustness of the radio against user modification to use frequencies or power levels not authorized in a particular country, and hardware makers aren't eager to advertise how locked down a networking appliance is against user-made software. See the TP-Link case [arstechnica.com].

  • Free and Easy. (Score:5, Insightful)

    by jellomizer ( 103300 ) on Wednesday September 07, 2016 @11:33AM (#52841211)

    The biggest problem I see is the following.
    1. Certificates are expensive
    2. They are hard to Setup.

    I am mostly an Application developer type of guy. I may setup a Secure site once every few years. However this process for Apache, and IIS seems to be overly complex. I am sure if I did it every day it would be second nature, but for the guy who does it every once in awhile, it takes a while and some trial and error.

    There hasn't been much of a thought on making this process easy to understand for the non-Administrator/Security personnel to setup.

    Now many of these devices that we use are made by companies whose main concerns are the following.
    * Getting the product out fast
    * Having the customer like the product
    * Saving money in making the product

    Security is one of those long term features if they can find "good enough" level they will not have many problems. For the most part "Good Enough" is to make sure the data is encrypted not necessarily encrypted well.

    • Re: (Score:2)

      by ledow ( 319597 )

      Certificates are free.
      Good certificates are cheap.
      Better certificates are far from prohibitive for a one-off cost for a major commercial product.

      And certificates for such things are NOT REQUIRED to be signed by a well-known CA. Almost all routers, switches, etc. have admin interfaces that aren't when you first get them.

      And if my £50 home router can let me generate certificates, including roots, for SSL, IPSEC, RADIUS, SSH, etc. etc. etc. then there's really no excuse.

      It's LITERALLY two lines of

      • And certificates for such things are NOT REQUIRED to be signed by a well-known CA.

        True for a router's administration interface, not so much if you want to allow friends and family to browse the files on your home NAS. Most are unlikely to be technical enough to install your private CA's root certificate.

        Generate a CSR

        Against what domain?

        • Re: (Score:2)

          by ledow ( 319597 )

          It doesn't matter, no domain required.

          Your home NAS doesn't need to be signed at all. It just needs a cert.

          Your family will get a warning, you just tell them to press okay.

          If you're smart enough to activate a NAS on a DNS entry that resolves to it, with port-forwards into your local network, you're smart enough to sign a cert on that domain if you really want to.

          Hell, Let's Encrypt makes it a matter of downloading a program on Windows, Linux or Mac and running it. You could do that for a subdomain.dyndns.

          • Re: (Score:2)

            by tepples ( 727027 )

            Hell, Let's Encrypt makes it a matter of downloading a program on Windows, Linux or Mac and running it. You could do that for a subdomain.dyndns.org if you could really be bothered.

            As described in this post on Let's Encrypt forums [letsencrypt.org], trying that would produce the following error:

            Error: rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: dyndns.org

            Only five customers of a particular dynamic DNS provider can obtain certificates from Let's Encrypt in any 7-day window unless the provider applies to join the Public Suffix List, which can take weeks and can be refused.

  • Most IoT developer are in races to get their product through their particular niche's window of opportunity. First gadget-X through the window gets the bulk of the market share, and the biggest chance of being the 900-pound-gorilla after the niche's evcentual shakeout.

    Doing security right is extra effort and time consuming. So the Invisible Hand is giving a back-pat to those who get to market earlier by ignoring it or doing a slap-dash job and spanking those who take time to do it well up front.

    Later, whe

  • The shocking truth is that it is trivial to do MITM attacks on HTTPS if you have access to the network like you would need for this type of attack. There is no good way to connect securely on a public network. Networks were designed to share information. Security was tacked on later.

    • Re: (Score:2)

      by ledow ( 319597 )

      Is it? Really?

      Please describe how you intend to fake a certificate that signs Facebook, say, from a CA that my browser will recognise without warning?

      Although there have been instances of that, the CAs in question have basically hate their roots REVOKED from major browsers for doing such things, and with certificate pinning and modern browsers, there's no way to fake your way around HTTPS even if you can sniff and interfere with every single packet.

      Those "MITM" things that workplaces and schools use to see

      • HTTPS is fine. Just use a modern browser and make sure the sites you're using are pinning their certificates. If you're paranoidly worried, remove all the trusted certs from your OS before your start and only trust the individual website's after you've checked it's the real cert from another machine.

        That sounds like a lot of work just to check my email.

  • This ad brought to you by SEC Consult (Score:2, Interesting)

    by Anonymous Coward

    I've never heard of SEC Consult, but they're mentioned 3x in the summary.

  • Ha Ha Ha Ha, err, I mean, that's terrible!!

    Signed,

    Hackers Everywhere

  • I've seen this across numerous companies and network device vendors.

    Too many operators who manage these things don't even have a basic grasp of PKI.

    Device vendors don't bother providing even basic operations to manage certificates - generating key pairs and CSRs. They expect the operators to handle it themselves OOB.

    The result is "test" and "demo" certs the engineers who created them know full well are worthless get put into production because device vendor support doesn't want to deal with the support hea

    • Re: (Score:2)

      by tepples ( 727027 )

      Usable trust already exists in the form of username/password... why not just use it? All that is really necessary is for browser vendors to get off their collective asses and apply the TLS-SRP patches wasting away in their ticketing systems

      You appear to refer to Bug 405155 in bugzilla.mozilla.org, which hasn't had significant activity in the past five years. The biggest issue they found is that TLS-SRP still sends the username in the clear where the MITM can snoop it, and if username is an email address, that could leak personally identifying information.

      • You appear to refer to Bug 405155 in bugzilla.mozilla.org, which hasn't had significant activity in the past five years. The biggest issue they found is that TLS-SRP still sends the username in the clear where the MITM can snoop it, and if username is an email address, that could leak personally identifying information.

        This is as unavoidable as clients belching SNI and servers belching subject name in the clear when you connect to a secure site. And lets not forget each and every time I connect anywhere on the Internet the same old IP address I've had for years gets tagged right along with my communications.

        This seems like quite an arbitrary excuse for inaction because the alternative is (what exists right now) is in fact much worse.

        You can provision pseudonyms if leaking "admin" is a big deal. I don't see why it would

  • I write software for custom embedded systems and I generate the ssh key pairs manually before flashing. It's time consuming but OK when you have just a few devices. But how would a manufacturer of a million device do it ? I understand it's so much easier to generate it once and flash all your devices at once. So what's the solution to do it properly ?
    • We build M2M devices, usually using low power micro controllers (read: no Linux, no SSH). However, each device has a unique 256 bit AES key to encrypt its data (that's every single device, not product). The key is generated when the micro controller is flashed on the production line in a fully automated fashion. If you integrate it into the production line like this it's just like adding a test point along the way.

    • As others have mentioned if the OpenSSH daemon notices that there are no host keys it will automatically generate them when it's started so all you have to do really is to make sure that you do a

      rm /etc/ssh/ssh_host_*

      Before you create the image that you flash, and if you upgrade your embedded systems by flashing your image then you have to either move these keys to a location where they are not overwritten (i.e deleted) by your upgrade image or move them out before upgrade and then move them back after ot

Slashdot Top Deals

If you do something right once, someone will ask you to do it again.

Close