Slashdot Mirror
Million More Devices Sharing Known Private Keys For HTTPS, SSH Admin (theregister.co.uk)
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 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 and devices. I want to know what is leaving my systems and I should have total control over that as owner of my devices.
Digital is, by definition, imperfect. Analog is the way to go.
I'm no crypto expert, buy why are all these things net-accessible?
I wouldn't (for the sake of this argument) care if my router was all http because it doesn't answer on the WAN port. Same for everything on the LAN side, since I only open specific ports I care about.
How are these things being configured that they can be attacked on the net?
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You keep using those words. I do not think one of them means what you think it means.
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, when the vulnerabilities are exploited, it MAY apply a big chopping axe to the limbs or necks of those whose backs it previously patted. Or they may, once they have the market share, also have the time, and the will, to improve the situation - with fixes, retrofits, field upgrades, rearchitected newer models, etc. But for now many PHBs are focused on getting through the first stage, so their company is alive to work on the second.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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
Just cruising through this digital world at 33 1/3 rpm...
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.
I wouldn't (for the sake of this argument) care if my router was all http because it doesn't answer on the WAN port.
The web interface presented by a cleartext HTTP server cannot use any APIs that are restricted to secure contexts. (A secure context contains only scripts from potentially trustworthy origins, particularly hosts that resolve to 127.0.0.1, the file: scheme, and the https: scheme.) The spec lists several web APIs that it encourages browser makers to restrict to secure contexts. Examples of such APIs that a web server inside an appliance on a home LAN might want to use include Service Workers, Geolocation, Media Capture, and especially Fullscreen.
For example, consider a router with a network attached storage (NAS) feature. If you connect a mass storage device to its USB port, it shares the files on the LAN through SMB, SFTP, and HTTP protocols. If you load videos onto this device, the user may want to watch them on the full screen. But because the Fullscreen API can be used to spoof browser UI, the spec encourages browsers to restrict it to secure contexts. This means the NAS feature will have to support HTTPS.
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 headache or the operator doesn't want to run a bunch of exotic bullshit from the CLI when they can just use what is already there and works.
Ultimately none of these devices actually require PKI for security. 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... then you can do secure authentication to these devices without having to provision any PKI. Excuse for failure is reduced from ... wahhh PKI is too hard... to ... WTF dude can't even change a default password?
Short of this inclusion of "test" and "demo" certificates needs to be straight out banned yet there is no mechanism other than shame to enforce such a ban.
Better technology (which is readily available but sits unused) to make it easier for people to do the right thing is a much more productive approach than betting against human nature.
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?
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 ?
Non-Linux Penguins ?
I use telnet
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.org if you could really be bothered.
Spread the meme.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
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, trying that would produce the following error:
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.