On 02/05/06, jared r r spiegel <[EMAIL PROTECTED]> wrote:
On Tue, May 02, 2006 at 09:33:48AM -0400, jared r r spiegel wrote: > > i am not asserting that the compromise-pack did not have > a precompiled sshd binary for openbsd ( the prior hop > up the compromise chain in this case was a debianlinux ), > but if it didn't, it may not have rooted machine B.to clarify that (coffee), without a compiler on B, the autobot may not have been able to infect the sshd running on machine B like it did. naturally it still had root level access since the user whose UN/PW it got from the machine A had sudo on machine B, but whether or not the autobot was smart enough to do anything with is a different facet. i find it worth mentioning that not using common passwords between different hosts ( the user's password on A and B were the same, in despite of the UN being different -- but iirc it grabbed the right username for B out of .ssh/config ) would've made the autobot's attack unable to gain access to B at all. ... not using common passwords and also never using passphraseless keys for accessing a host on which that user has root/sudo... not having a compiler on B in this case, again, would not change the fact that we considered B to be compromised and planned to offline it and reinstall/etc, but it, from looking at the history file for the user and /var/log/secure for the sudo commands, didn't have it in its bag of tricks to be able to *infect* host B if B didn't have a compiler on it. ( and thus make B a further bastion for infection spreading because anyone who ssh'd into B and hit 'yes' after the "omg known host key changed" warning would have their password then "harvested" and if their .ssh/* had login info for other remote hosts on which they did have sudo, the autobot would have probably been able to gain access and possibly infect those hosts as well ). to emphasize, this appears to have been in no way a supervised attack targeted specifically at B; but rather a blind infecto-bot following its success-path. if we didn't have that little PIII/450 sitting next to the machine now, for the purposes of bringing live, getting patches onto, making .tgzs, and then copying them over to untar onto host B, what bob beck criticized about would be entirely accurate about me.
One thing I didn't follow in this story is why did this 'virus' change the host key? It's not like you can't use the old key with the new sshd install, is it? Another thing is trusting the updated hostkey. Imagine you are a sysadmin at a university. Do you keep the old hostkey when you reinstall the system on a specific host? What about when you upgrade a Sun workstation, but keep the old hostname? How am I as a student may know if the new hostkey is legitimate? Good thing if I have an entry of another Sun workstation in the destination network in my .ssh/known_hosts, to which I could ssh and see if the host in question shows the same signature 'locally', but what if I don't? Constantine.
