Trojanized SSH Daemon In the Wild, Sending Passwords To Iceland

An anonymous reader writes "It is no secret that SSH binaries can be backdoored. It is nonetheless interesting to see analysis of real cases where a trojanized version of the daemon are found in the wild. In this case, the binary not only lets the attacker log onto the server if he has a hardcoded password, the attacker is also granted access if he/she has the right SSH key. The backdoor also logs all username and passwords to exfiltrate them to a server hosted in Iceland."

Comments

SSH Got Bjorked?

[Penguinshit]

Somebody had to say it.

Re:Iceland? How hard could it be?

[WWJohnBrowningDo]

Just because the server is in Iceland doesn't mean the perpetrator is.

In all likelihood the server is just another compromised machine.

Tip

[detritus.]

I cleaned up an a backdoored Debian system after discovering md5 sum mismatches on all the ssh binaries from the original packages some time ago.

debsums is a nice utility to check this for you, granted that the attackers didn't modify the signing keys and installed their own package.

Re:Tip

[davester666]

If there is one thing I truly dislike, it's getting backdoored.

Effective

[Anonymous Coward]

I myself have set up modified versions of the sshd dameon/ssh client on various rooted machines in the past (mine was simply allowing root login without logging anything with a hardcoded password + writing logins/hosts/passwords, after encryption, deep inside a fake shared library on the system - this took less than an hour to implement in the openssh source).

In all cases, despite the extreme simplicity of this mechanism, it was very, very easy to then gain access to a lot of other boxes on the network, and eventually to all the network itself. Just wait for the clueless sysadmin to log in (dumping his pass), then wait for him to use ssh to log in to another box in the network (dumping his pass as well). Then install the modified version of the daemon/client on to this new box. Rince, repeat.

It is in a way terrifying to see how most sysadmins are clueless. So, IMHO, a few measures that should be compulsory on any network:

- Do not allow write access to any essential binaries (like sshd, ls, and so on). If you have to, make sure you have a stealthy daemon checking the hashes of all critical binaries at regular intervals to make sure they have not been tampered with.
- Never, ever, log in to a server in your network from another server in the same network. Use port redirection, then log in from your initial box.
- Always use a dedicated server for system logs (syslog handles that very easily - sending logs over the network). That way, the logs of the initial system compromise will not be deletable. Do not ever log in remotely to this dedicated machine.
- After the initial system install, make a dump of the syscalls table of your kernel. Check it regularly to make sure it has not been tampered with (kernelspace rootkits usually hijack this table).
- ...there are also other ways to implement an effective kernelspace rootkit, like VFS hijacking, so make sure you disable modules loading in the kernel before compiling (and check the hash of the kernel image itself regularly as well).

Those are the main sane measures that come to mind (this is all based on real life experience intruding into large companies/laboratories/university systems, without ever having been detected). Posting anonymously for obvious reasons.