RE: Compromised host keys
From: Jim Cheetham (jim.cheetham_at_ecosm.com)
To: email@example.com Date: Thu, 13 Nov 2003 08:37:39 +1300
On Wed, 2003-11-12 at 09:50, Michael Young wrote:
> Are these machines in a high availability/clustered environment?
In this case, no - although in the past I've only run clusters with
separate host keys on each node, under the theory that as the admin, we
should know which node we're operating on :-) It's the "users" that
should see the cluster as a virtual machine ...
New keys have been made on those machines, of course, and I suspect that
will have some impact on the service provider's user access to the
machines. But they should be able to cope :-)
The impact of compromised keys seems to be twofold :-
Total vulnerability to man-in-the-middle attacks, assuming that the
attacker can subvert your DNS query, or re-route your connection. In
this case, I'd expect that to occur at the hosting centre, but I doubt
they have the ability to detect it. It's debatable whether they should.
Increased vulnerability to offline cracking of a recorded session. The
session key seed is passed back to the server by the client, encrypted
with the host key first, then the server key. In our case, we assume
that the server key has not been compromised. Therefore, in order to
find the session key, this has to be cracked. Server keys are often
short (768 bits), but the job is complicated by the fact that the
message contents are (probably) essentially random, and difficult to
recognise. On the downside is the fact that the initial encrypted
packet-stream is more predictable.
The cost of a successful attack is a rooted box, which is difficult to
recover from, especially remotely. I've asked the hosting company
whether they have something like checksums of what a clean install
should be, but had no response.
In fact, we've had little response from them over this issue. I'm
considering revealing their name and details to various forums, so that
other customers of theirs might become aware of the potential for abuse.
However, that is not a step which should be taken lightly.
-- Jim Cheetham Systems Administrator, eCOSM Limited. Phone +64 3 365 4176 | Mobile +64 21 314 158 http://www.ecosm.com/