Slashdot Mirror
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."
Somebody had to say it.
I have something in common with Stephen Hawking...
Just because the server is in Iceland doesn't mean the perpetrator is.
In all likelihood the server is just another compromised machine.
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.
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. ...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).
- 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).
-
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.
Yup. There are actually several reasonably priced hosting services in Iceland. I was shopping for international homes for some of my data, until I thought about it and none of my data is worth spending money to hide. :) Iceland was pretty high on the list though.
Serious? Seriousness is well above my pay grade.
I was asked to clean some exploited servers in the wild that had compromised SSH binaries in them. This was about 10 years or so ago, so this is really a not current news story.
Thankfully most script kiddies are exactly that, and their script left the source on the machine for me to review. Why? I guess to compile on the machine to make sure it used the local libraries. They generally didn't have passwords hard coded though, they used SSH keys. The passwords they stole were usually stored locally in a file, and sent to somewhere in eastern Europe or Asia. I have no idea if that was by the script kiddie design or the person who rolled it up. It's a pretty slick trick though. You get the script kiddies to gather intel from compromised machines, and feed it back to you. Now you have access to every machine the script kiddies compromised.
The funny part about most of the cleanups was, the version of SSH they put on was newer than the remotely exploitable version they got in with.
Serious? Seriousness is well above my pay grade.
I was asked to clean some exploited servers in the wild that had compromised SSH binaries in them. This was about 10 years or so ago, so this is really a not current news story.
Someone got murdered about 10 years ago, so there's no point reporting about current murders.
Or what is your point exactly?
c++;
Apparently it's quite common for attackers to actually patch the security holes they used to get in, once they've installed their backdoors. Don't want someone else getting in the same way, after all...
Security is usually one of three things: Something you know (password), something you have (key, token) or something you are (biometry). Alone, none of them is really a big security obstacle, at the very least you should combine two of them. If you're paranoid, require all three.
Using two of the same class is patently useless, as practice has shown. If one password can be sniffed, so can two and more. And people tend to store their keys and dongles and other work related gadgets in similar places (if you get their keys, you usually also get their ID dongles), so if one is gone, usually they are all gone. And I guess I needn't explain why fingerprinting and retina scans aren't really a sensible combo either (aside from the cost).
And preferably request them through two separate and independent channels. It's amazing how rarely this rather essential minimum of security is enforced.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Maybe it was an Open Source client, and they had to give you the source code to comply? :-)
The Tao of math: The numbers you can count are not the real numbers.
So you don't password-protect your private key?
The Tao of math: The numbers you can count are not the real numbers.
Unless you're auditing said sources, you're no better off than installing binaries.
You know that Gentoo checks the SHA256 SHA512 and WHIRLPOOL digests of the downloaded sources before compiling right? You also know that the digests stored in Gentoo's repository are signed using a PGP key of the package maintainer, right?
So can you please explain me again why I need to audit such sources? Sure sources can be compromised at upstream's servers and Gentoo maintainers can also make mistakes but this is not what TFA is about.