9 ms·
Duplicate SSH Keys Everywhere
- astrocat 12y agoNot my domain of expertise; can someone explain why this is problematic?
- bbrazil 12y agoIf you can read the private key from just one of these machines then you can impersonate any of them.
- 4mnt 12y agoThat is: MITM SSH connections to these devices without getting any warning. Of course you first have to get in a position to MITM the person who connects to these devices.
- schoen 12y agoAlso if the underlying cryptography isn't forward-secure, anyone with the private key can go back and read your recorded SSH sessions, including any kind of secrets that you typed into them (or files that you downloaded with scp or rsync). I don't know under what conditions SSH uses or doesn't use forward-secure key exchange methods.
- jewel 12y agoI was surprised to learn that you can't man-in-the-middle an SSH connection if the client is using a key for authentication instead of a password: http://www.gremwell.com/ssh-mitm-public-key-authentication http://www.gremwell.com/ssh-mitm-public-key-authentication You'd still be able to impersonate the server, but that's less useful in the general case unless you can emulate the remote machine convincingly long enough to gather useful information.
- deleted 12y ago[deleted]
- jrochkind1 12y agoI'm not sure what you say is true. On it's face, it doesn't make any sense, if you have completely MiTM's the network connection, and can pass along traffic from each part to the other, I don't see how client key auth would prevent MiTM. Even the thing you link to actually says: > The algorithm itself does not protect against active MITM attack, but it makes it impossible for MITM attacker to influence the choice of the shared key (and by extension the session ID) by the victims. Does not protect against active MITM attack. It _does_ keep an attacker from influencing choice of shared key, but an active MITM attack is still in the middle and doesn't need to influence choice of shared key to mount many many kinds of attacks.
- mkj 12y agoThe pubkey authentication will fail because the signature is over the session key. If there's a MITM going on then each side will see a different session key. Check out the RFCs 4253 and the auth one (425?)
- deleted 12y ago[deleted]
- johnmaguire2013 12y agoI'm confused by this. I know that HTTPS is supposed to be fixing this problem too supposedly. But I don't understand how. If an attacker fully replicates a SSH server, and responds to all client messages with the victim correctly, while then relaying their commands to the real SSH server, and acting as a full SSH client, isn't there still an issue? The attacker just has to authenticate with the correct signature to each, but if it's an attacker, why would it just pass along the victim's data anyway? The whole point of an MITM is that you can modify data before it hits its target.
- deleted 12y ago[deleted]
- superuser2 12y agoOn the same topic, what are the other pitfalls of re-using OS images? I can think of: - Hostname conflicts - SSH key duplication - Driver issues if the hardware is not the same Are there more? This seems like a compelling argument for bootstrapping new instances with configuration management, rather than trying to re-use OS images.
- achillean 12y agoSpeaking of hostname conflicts: an ISP in Vietnam has configured all their devices to have a reverse DNS name of "localhost" https://www.shodan.io/search?query=hostname%3Alocalhost https://www.shodan.io/search?query=hostname%3Alocalhost
- JonRB 12y agoI've experienced this too - I seem to get a few people joining my gameserver from that ISP and I notice the DNS appeared as 'localhost'. Not ideal and I imagine it could break certain things. I always assumed it was a misconfigured internet cafe or something. 'Nice' to know it's a wider issue
- Xylakant 12y agoMAC Address duplication on virtual interfaces for VMs started from a template.
- warrenm 12y agoNever seen this in years of using VMs
- shitloadofbooks 12y agoNo (mainstream) Hypervisor does this and you'd run into networking problems pretty quickly if any of those VMs share a network.
- devicenull 12y ago
- feld 12y agoThis also applies to those of you building "template" VMs in VMWare or Xen -- before you save that template please delete the SSH keys in /etc/sshd/ so they are generated on first boot of the deployed template!
- 13 12y ago> generated on first boot of the deployed template! I've always been uncomfortable about that. How much boot time entropy can a VM have?
- korethr 12y agoIt would not surprise me if there are other bits of unique info on the template VM that need to be cleared before freezing the image, e.g. hostnames. This is a solved problem in Windows. The sysprep tool wipes out the hostname, security keys, user accounts and a bunch of other things one can configure, so the image initializes properly the first time it's booted. I am curious if there are similar tools for Linux & Unix that the image builders simply failed to use here, or if this points to an opportunity to build a useful tool.
- chubot 12y agoRelated: if you don't have enough entropy when creating keys, your public keys might not be identical, but they can share primes. Sharing primes allows this cool factoring attack by DJB and others. https://scholar.google.com/scholar?cluster=9203750458482965051&hl=en&as_sdt=0,5&sciodt=0,5 https://scholar.google.com/scholar?cluster=92037504584829650... This paper explains how an attacker can efficiently factor 184 distinct RSA keys out of more than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital Certificate" database. These keys were generated by government-issued smart cards that have built-in hardware random-number generators and that are advertised as having passed FIPS 140-2 Level 2 certification. These 184 keys include 103 keys that share primes and that are efficiently factored by a batch-GCD computation. This is the same type of computation that was used last year by two independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman; Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands of cryptographic keys on the Internet.
- abrodersen 12y agoThis is why we can't have nice things. And by nice things, I mean identification of people via cryptography rather than rectangular pieces of plastic.
- kordless 12y ago> rather than rectangular pieces of plastic Finally, the U.S. gets a mention.
- lifeisstillgood 12y agoTaiwan has a citizen digital certificate process - cool ! I mean that's a seriously big advance over anything I imagined a govt capable of. Estonia was the only other place I heard even close. And is 183 out of 2 million so bad? Just sign the next round of certificates with this lot and move on.
- pedrocr 12y agoPortugal also has a national ID card that's a smart card and includes a key. The last time I tried to use it in the justice ministry website it required accepting a self-signed HTTPS certificate. When I reported the issue I got a "oh, just accept it and it will be fine" response from a supposedly technical person. So yeah, these things are getting deployed in some places but I'm not too hopeful it will end up being much more than a gimmick. At least I hope not because the next step on the minds of some of these "technical" people is electronic voting and that won't end well...
- fvold 12y agoAnother implications of this is that if a security flaw is found in this re-used image, it's trvial to write a worm, as it can very easily seek out and find vulnerable hosts. Ooops.
- hannob 12y agoThis is not really news, this was already discovered by Nadia Heninger and others in a paper in 2012. From their faq about their research: "We found significant numbers of insecure RSA and DSA public keys in use on the Internet: we found that 5% of HTTPS hosts and nearly 10% of SSH hosts shared keys for reasons we considered a vulnerability." See here: https://factorable.net/faq.html https://factorable.net/faq.html Mostly embedded devices that auto-generate their key on bootup. There was a pretty interesting talk at ccc where part of this research is mentioned: http://media.ccc.de/browse/congress/2012/29c3-5275-en-facthacks_h264.html#video http://media.ccc.de/browse/congress/2012/29c3-5275-en-factha...
- maaaats 12y agoWhat about "personal" private keys? I find it a hassle to add new keys for every device to each host I ssh into, so I usually just end up copying them from device to device..
- ckuehl 12y agoAre you talking about SSH host keys? Those are normally generated automatically, and should be unique for each server. (These are the things you're asked to verify the first time you connect to a new server.)
- maaaats 12y agoSorry, meant my key, the one I use to connect with and have added the public part of to numerous servers.
- ckuehl 12y agoThere's nothing wrong with adding your public key to many servers, as long as you keep the private key secure -- almost everyone does this. The article is discussing sharing of SSH host keys, which allows impersonation of an SSH server.
- dlitz 12y agoSSH agent forwarding should eliminate the need to do that.
- iso8859-1 12y agoAll these questions have insightful answers. I'd say "use separate set of private keys for each originating device". http://superuser.com/q/189355/33303 http://superuser.com/q/189355/33303 http://serverfault.com/q/170682/80866 http://serverfault.com/q/170682/80866 http://security.stackexchange.com/q/40050/13510 http://security.stackexchange.com/q/40050/13510 http://security.stackexchange.com/q/10963/13510 http://security.stackexchange.com/q/10963/13510 http://unix.stackexchange.com/q/27661/14305 http://unix.stackexchange.com/q/27661/14305
- 12y ago
- jquast 12y agoThis is particularly problematic for virtual machines, which are starved of entropy (no sensors, audio device, etc.). I have VM images begin without ssh host keys and have a service dependency on haveged: http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/ and http://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines http://security.stackexchange.com/questions/34523/is-it-appr...
- atoponce 12y agoFor Qemu 1.3 and later, there is VirtIORand where you can have VMs attach to a HWRNG on the hypervisor, then food that into the kernel CSPRNG. This should be imaged by default, so on first boot, each VM has enough entropy for key generation.
- rlpb 12y agoOn Ubuntu, pollinate solves this problem: http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubunt...
- goalieca 12y agoDumb question, why not have all processors contain a new hardware RNG based on thermal noise or some such thing? That was even VMs can get some stable entropy.
- jamiesonbecker 12y agoGreat point. and Intel's and AMD's black box RNG generators (RDRAND etc) provide entropy... but they're thought to be compromised (which would be nearly impossible to detect). At least other firmware attacks would/should/might be detectable. By definition, RNG's produce unpredictable output -- detecting predictability is much harder than with other potential attacks (versus, for example, the sum of two numbers, which should always give the same result). So, FreeBSD and Linux both use hardware RNG's as entropy inputs and mix-in other sources of entropy as well (which hopefully mitigates any loss of available entropy and also adds in other believed-good sources of entropy such as timing, network traffic, etc). Ubuntu is using a new network-attached source of entropy which is itself constantly reseeded with the network traffic used to access it. (There's some inception joke there somewhere..) Of course, you may not be able to rely on the SSL/TLS connection that you're using to access it, so you might be seeding with an attacker's steady stream of 1's... Of course, getting access to real hardware entropy in a hypervisored or virtualized cloud server/instance is the second part of the problem. The third part is to make sure that SSH server and client keys are distributed properly. That's what Userify is for, but it really only helps with the client/user keys.. it doesn't help with server keys. (Yet?)
- mkj 12y agoI'd suggest that a larger security issue is that the 250,000 hosts are unnecessarily running SSH to the world. A MITM issue doesn't matter if noone's using the connection!
- cbsmith 12y agoGiven the purpose of the key, this doesn't necessarily seem like a security flaw. If individual owners ssh on to the system, then it is a flaw, but if the primary purpose is to allow system updates, this seems like a perfectly reasonable approach.
- jamiesonbecker 12y agoThis was also the case with Digital Ocean's droplets on Debian for a time (they were re-imaging without re-genning keys.) It's not as uncommon as it sounds. Userify (cloud ssh key manager) is getting a feature to force re-generation of server-side keys across an entire cluster remotely.
- andor 12y agoI'm not sure how I feel about Shodan. Their statistics are interesting, but apparently the primary use is finding vulnerable systems and matching exploits? This is the list of most popular searches: https://www.shodan.io/explore https://www.shodan.io/explore
- deleted 12y ago[deleted]