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:SSH Got Bjorked?

[ghmh]

And until now it was oh, so quiet!

Re: SSH Got Bjorked?

[Anonymous Coward]

Warner Bros. Records.

Re:SSH Got Bjorked?

[drinkypoo]

This is completely normal human behaviour.

Re:SSH Got Bjorked?

[Penguinshit]

It's a play on "Borked" (hint "Robert Bork" - Google it) and the native country of the artist Bjork.

Re:SSH Got Bjorked?

[Penguinshit]

you're a djerk.

If it weren't for the mention of Iceland

[93 Escort Wagon]

I'd think this was a story about Cisco gear from not that long ago.

Re:If it weren't for the mention of Iceland

[JWSmythe]

    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.

 

Re:If it weren't for the mention of Iceland

[pipatron]

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?

Re:If it weren't for the mention of Iceland

[maxwell demon]

Thankfully most script kiddies are exactly that, and their script left the source on the machine for me to review. Why?

Maybe it was an Open Source client, and they had to give you the source code to comply? :-)

Re:If it weren't for the mention of Iceland

[johnsie]

grumpy much?

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

[Nerdfest]

Poor passwords, other infected (non-repo) packages, exploits in services (like apache, etc) installed with too many permissions, etc.

Re:Tip

[19thNervousBreakdown]

You can never clean up a system. MD5s help, but you know what one of the first things I'd do when rooting a system is? After making sure my rootkit didn't show up in directory listings, I'd patch md5, shasum, perl, and ruby to return the exact MD5 I wanted for every file I defined a magic string for.

You gonna catch me on some systems? Sure. You gonna catch me on an extremely common distro like Debian without installing out-of-tree software? Probably not.

Re:Tip

[davester666]

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

Re:Tip

[NotBorg]

Yeah, I hate most Linux exploit articles. They always seem to be about what happens after the machine was rooted. Binaries changed out, configurations changed, permissions set, yadi yadi yada... They never seem to be about how they got rooted in the first place.

Re:Tip

[DarwinSurvivor]

Rule #1 of investigating a compromised system is you don't use the tools on the compromised system.

Re:Tip

[Ford Prefect]

I will ALWAYS find your rootkit. This is because you're trapped in a VM, and I can always checksum the files from another uncompromised system (LiveCD / USB).

This is, of course, assuming that you yourself are not running on another compromised virtual machine.

(There was one hack I was involved in where an investigator tried to get clever and started calculating MD5 checksums with a universal Turing machine operated using pencil and paper. Fortunately, I'd already trojaned base logic itself and managed to subvert alphanumeric characters to return the 'correct' values. Hacking the logical representations of arabic numerals? Now that's pretty advanced stuff. But then, there's always the worry that my own consciousness is running on something other than what I think is my own brain...)

Re:Tip

[bill_mcgonigle]

Rule #1 of investigating a compromised system is you don't use the tools on the compromised system.

Security is a process. Running a scanner on a compromised system has no guarantee of finding out that the system is compromised. But 98% of the time it will work just fine - these systems are usually compromised by script kiddie tools that don't spend a great deal of effort to find the rootkit scanners.

I suppose it would be better if somebody came up with a well-developed package for cross-scanning systems over shared storage (does it already exist?) but that's also only going to reduce your 98% to 98.5%. I suppose all you need to really do is to validate the integrity of the host system's scanner (or rpm or dpkg, etc.) but then again the remote system access method could also be compromised (today it's TLA stuff to compromise e.g. nfsd such that it will only return the wrong (but valid) md5sum and sha1sum and [randomhashsum] for only the scanners you might check for) but it's not likely.

Taking down every system on a frequent schedule for an offline scan would be a good idea but then again the BIOS could be compromised and you start to run into the collision of business needs and absolute security.

Re:Iceland? How hard could it be?

[AK Marc]

Check with Men and Mice, they are the only Icelandic company I know of that works with "security" and "Linux" in their company description.

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.

Re:Effective

[Gaygirlie]

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

I'm sure there are plenty of other such systems, but Tripwire ( http://www.tripwire.org/ ) is one of the more popular tools to keep a check on your system and warn you immediately if it detects tampering attempts.

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

AFAIK Tripwire handles this, too.

Define "wild"

[dalmor]

The article says "...discovered on compromised servers."

If they are not distro(i.e. ubuntu, redhat,centos, etc.) servers, or openssh servers, this is a non-story. I can create a random domain, compile a version of openssh to sends passwords to me and host it on my server as an official ssh binary.

If I install stock wordpress with access to the file, would that then count a compromised?

Re:Iceland? How hard could it be?

[JWSmythe]

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.

Breaking and decorating

[OwenT]

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

Bad advice because ...

[dbIII]

Personally I think a password is a very good idea if combined with a key. If a laptop gets stolen the thief can log in directly with the stolen key saved on the laptop. If they have to work out a password as well they only get what is on the laptop.

Re:Bad advice because ...

[Opportunist]

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.

Re:Bad advice because ...

[segedunum]

No - the above poster wrote "don't use passwords". Taken at face value that sounds like recommending not to encrypt your private key with a password - because that would mean "using a password" - thus bad advice.

No, it doesn't. Everyone with half a brain regarding SSH should know what 'not using passwords' with SSH means - and it doesn't mean *not* using a pass 'phrase' for your SSH key. He never said that. I'm afraid your splitting hairs here to have something to say.

No - that is called reading between the lines, adding something that is not there and making an assumption that somebody that doesn't know better will not make - thus it doesn't change that the post above is bad advice.

No. You have totally misunderstood the post, and please don't tie yourself in knots like that. It was very clear what he wrote and you were the one who added in 'I think a password is a very good idea if combined with a key'. It's also not called a 'password' but a 'passphrase'. It is not his fault that you or others don't know what he's talking about.

Gather passwords with ssh? Hah!

[Omnifarious]

I never use passwords with ssh. If ssh asks me for a password, I know something is wrong. I made this policy decision because of the endless attempts to log into my machine from all over the world. It was either something like a yubikey, or only using public key authentication. I went for the public key authentication.

Re:Gather passwords with ssh? Hah!

[maxwell demon]

So you don't password-protect your private key?

Re:Iceland? How hard could it be?

[Trepidity]

Maybe it wasn't a "who" but a "what".

Duh, run md5sum from external machine

[cheekyboy]

Man, you would run md5sum on the actual compromised box??

Why not do it from a ISO booted linux, and nfs share the whole box , so you can sum it from the outside.

What you really need is all binaryies libs running of a partition that is read only. Kind of like android.

Re:I use Gentoo

[smash]

Unless you're auditing said sources, you're no better off than installing binaries.

Re:I use Gentoo

[miknix]

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.

Re:Compromised system

[smash]

To clarify - you should be continually monitoring all your machines for unusual traffic. By unusual, i mean for example any traffic from a port that shouldn't be open. This is a good example of why it is safer to be fucking paranoid with your firewall rules on your edge, and do egress filtering as well as ingress - and be very specific with regards to what you open up and the source/destination as well as what ports you allow. If some daemon is running on a port that it shouldn't be running on, or connections are hitting your machine from unusual sources, you should be getting alarm bells going off.

That's why SSH - most compromised by the trojan

[raymorris]

That's why ssh is trojaned - it's how they got in. Once they get into one box some other way, the trojan gets them into every box a user connects to via ssh. So it spreads like a virus. At some point, an admin with access to a lot of machines, like a hosting company admin, uses ssh to rsync / scp to their main machine. Then the bad guys get access to every machine hosted there.

Re:I use Gentoo

[miknix]

Everyone replying here seems to be obsessed in comparing binary vs source and totally miss the point. The point is that
Gentoo users do not have the habit of installing binary packages at all, for that reason this trojanized sshd BINARY does not concern us.
Wooooooosh!