
Duplicate SSH Keys Everywhere - achillean
https://blog.shodan.io/duplicate-ssh-keys-everywhere/
======
chubot
Related: 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=92037504584829650...](https://scholar.google.com/scholar?cluster=9203750458482965051&hl=en&as_sdt=0,5&sciodt=0,5)

 _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._

~~~
lifeisstillgood
Taiwan 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
Portugal 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...

~~~
vbezhenar
There's similar problem in Kazakhstan. egov.kz is their e-government site.
They issued their own root certificate and they use it to sign all users
certificates. And they signed their SSL certificate with that certificate
which causes it to show alarm.

Not very smart move if you ask me. If you teach users to ignore HTTPS errors,
then MITM attack becomes easier because user don't see anything suspicious.

~~~
lmm
It's a dumb move from browser makers (self-signed certificates really
shouldn't be the same kind of error as outright fraud). Maybe they can get the
Kazakh root certificate incorporated into major browsers? But until then what
other approach is possible to bootstrap it? There are obvious reasons the
Kazakh government infrastructure wouldn't want to be dependent on e.g.
Verisign.

------
hannob
This 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-
factha...](http://media.ccc.de/browse/congress/2012/29c3-5275-en-
facthacks_h264.html#video)

------
feld
This 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!

~~~
korethr
It 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.

~~~
pliu
cloud-init

[https://cloudinit.readthedocs.org/en/latest/](https://cloudinit.readthedocs.org/en/latest/)

~~~
kordless
+1

------
superuser2
On 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.

~~~
Xylakant
MAC Address duplication on virtual interfaces for VMs started from a template.

~~~
shitloadofbooks
No (mainstream) Hypervisor does this and you'd run into networking problems
pretty quickly if any of those VMs share a network.

~~~
devicenull
Libvirt has serious issues with this [https://www.redhat.com/archives/libvirt-
users/2014-November/...](https://www.redhat.com/archives/libvirt-
users/2014-November/msg00009.html)

------
fvold
Another 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.

------
jquast
This 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-
appr...](http://security.stackexchange.com/questions/34523/is-it-appropriate-
to-use-haveged-as-a-source-of-entropy-on-virtual-machines)

~~~
atoponce
For 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.

------
astrocat
Not my domain of expertise; can someone explain why this is problematic?

~~~
bbrazil
If you can read the private key from just one of these machines then you can
impersonate any of them.

~~~
4mnt
That 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.

~~~
jewel
I 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.

~~~
jrochkind1
I'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
The 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?)

~~~
johnmaguire2013
I'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.

~~~
asdfaoeu
In the hypothetical scenario the attacker doesn't have the client's private
key so it can't authenticate to the server. It can pass along the session key
from the server but then it won't be able to read the data.

~~~
jrochkind1
Ah, I get it now. It's not just the authentication step, it's the fact that
the data is encrypted so only the original client can read it? That's right?

------
maaaats
What 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
Are 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
Sorry, meant my key, the one I use to connect with and have added the public
part of to numerous servers.

~~~
ckuehl
There'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.

------
andor
I'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)

------
cbsmith
Given 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
This 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.

------
mkj
I'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!

------
goalieca
Dumb 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
Great 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?)

