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."
Would one of the 320k icelanders please stand up and make it known who decided to do this. I mean come on this country is smaller than most cities people know. I bet they find out who dun it right quick.
Somebody had to say it.
I have something in common with Stephen Hawking...
I'd think this was a story about Cisco gear from not that long ago.
#DeleteChrome
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.
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?
That's funny, but for those that don't know: XOR is a well-known, poor man's encryption/obfuscation trick.
This makes no sense. Once somebody has root and can write to those binaries you are already fucked and they can change access to anything they like, and then write over it to their hearts content.
Putting them on read only media sounds like a cool idea but is difficult to implement for anything other than the short term and can be circumvented if somebody roots your box anyway. There's the script kiddie toy of changing file attributes (and thus announcing to people that they've been rooted) which this AC may think is some sort of real security measure if sysadmins use it, but that's merely annoying to anyone that has root and isn't going to slow down even a newbie with access to google.
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...
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.
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.
Need a Python, C++, Unix, Linux develop
Obligatory.
Except how will you know it's compromised unless you're scanning from a clean system/media?
You *could* have another machine pop in and compare md5's or whatever, but that assumes that "md5sum" and a bunch of others machine being tested isn't compromised.
You *could* also run the SSH'able machine inside a VM and check from the VM host, but the host could still be compromised or other issues.
Another option is to routinely check by booting from secure media, but that involves downtime.
Investigating a compromised system is one thing. I believe the GP was more about discovering that the system is compromised in the first place.
I only install from sources you insensitive clod!
Or you could source two binaries from two diff repo servers in two diff countries, and only accept the install if they both are identical.
Liberty freedom are no1, not dicks in suits.
If they installed a java version of SSH, it would be ultra secure, but you need 750meg of ram for each ssh session.
Go Oracle, Larry is elite.
Liberty freedom are no1, not dicks in suits.
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.
Liberty freedom are no1, not dicks in suits.
No hacker can find the binaries to a PPC mac os 10.5
Duh, you can boot OSX from a DVD, if you are really that paranoid.
Liberty freedom are no1, not dicks in suits.
They have thousand of eyes looking at the source and working on ways to improve things. What are the Window's folks doing?
Time is what keeps everything from happening all at once.
I may have missed it but was this a binary package for a specific distro (on their own servers) or a binary on an untrusted server not attached to any specific distro?
Unless you're auditing said sources, you're no better off than installing binaries.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Because the source server that feeds both could NEVER be compromised.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
You'd like to think so, but when things like this happen, you can see that having thousands of unqualified people looking at code and sometimes modifying it is not really any benefit to security at all.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
Yes cause we all know how secure and well coded java apps are.
I am Bennett Haselton! I am Bennett Haselton!
Aw, I don't know why you were modded troll. That's funny. :)
And only ultra secure because it would work for a few days, and then hang, refusing all access. :)
Serious? Seriousness is well above my pay grade.
If your machine isn't supposed to be doing http or https, then this is a warning sign. And yes, running firewalls internally is required in case one of your machines inside is compromised.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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!
HTTP/HTTPS sessions will have a limited lifetime (the exception being some HORRIBLE streaming technologies you shouldn't be using anyways) and SSH should only have incoming connections from KNOWN sources with very few exceptions. If you can't block a "hacker" (read: script kiddy) using GoToMyPC, you need to find another profession.
I use denyhosts - fail2ban is good too, the basic idea is the same.
In capitalist USA corporations control the government.
if you have your servers compromised, the data on them, and login attempt into them may be keylogged, WOW! Is this the level of articles we want on slashdot ?
I'm not splitting hairs because ssh login with a key and no pass phrase is a frequent shortcut.
You don't know what he's talking about either - you are just adding things you think should be there but are not.. I'm making a comment on something that should be there if it's going to be good advice but is not, even if it was intended - neither of us know do we?
The trojaned ssh isn't the one installed from the repo, it's installed later by the bad guy, so it doesn't matter how you installed . Again, the trojaned ssh isn't the one you installed. The ONLY difference between source vs. binary packages in this case is that people who installed binaries could be alerted that the hash of the existing file doesn't match the correct binary. So binary installs are SAFER as far as this trojan.
How does the bad guy get the trojan on your system, if not from the repo, you ask? He gets access when someone else who is infected logs into your machine - your sysadmin, your hosting company, a vendor, etc.
The bad guys only had to compromise one machine, then the trojan spreads. Say for example my co-worker Jeff has him home machine infected. He uses ssh to connect from home to his office. The bad guys now haveaccess to infect his office machine. Jeff is a sysadmin at the office, so from his office desktop he logs into various servers. That spreads the infection to the servers. I then use scp (ssh file copy) to pull some files on to a server from my work desktop. Now my desktop is infected. Later, I ssh from work to my home office. Now my home office is infected.
For this reason, we have a rule. Always ssh FROM the more trusted machine TO the less trusted one, never the other way around. For scp and rsync, that means always PUSH files to a client's machine or any server on the public internet, never PULL to a less trusted machine from a more trusted one.
How does the bad guy get the trojan on your system, if not from the repo, you ask? He gets access when someone else who is infected logs into your machine - your sysadmin, your hosting company, a vendor, etc.
Dude, this does not make any sense at all!
If person X logs into my machine (which is not infected) and that X is infected with the trojanized daemon. Then the attacker will not be able to find out the X's account password in my machine because the connection was made to my uninfected daemon and not to X's infected daemon. Get it?
For this reason, we have a rule. Always ssh FROM the more trusted machine TO the less trusted one, never the other way around. For scp and rsync, that means always PUSH files to a client's machine or any server on the public internet, never PULL to a less trusted machine from a more trusted one.
How would that work? Honestly I don't know so don't troll me ;P. How would I connect to my local ssh server from a work resource (that uses rsa key concatination), from my house?
It would be nice if ssh could enforce this and refuse to connect if you try to break the policy.
Yeah, and other operating systems do hashes for their binaries, too.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Also, even compiling from trusted source is no good if your compiler is compromised.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I use denyhosts - fail2ban is good too, the basic idea is the same.
I use SSHGuard here. I'd rather block all IP traffic from them entirely.
It is a miracle that curiosity survives formal education. - Einstein
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?
Yes, but if you are hosting the sources, you also control whatever checksum also appears on your website.
Besides, hosting precompiled Windows binaries is a great way to trick lazy admins. First, a lot of open-source hosts / projects do not provide easy access to Windows binaries, and many admins don't have compilers (they don't program and so consider compiling out of their job description), and finally since there really is no automated way to check the checksums they avoid doing it. (Though automating checking MD5's etc. would obviate using them in the first place) So it's just easier to trust a host with their binaries.
Of course all this could be avoided by using only trusted sources. But I said they were lazy, not smart.
THINK! It's patriotic
He's saying the guy uses some zero-day exploit to penitrate your system, then installs the trojan as admin, edits the logs, and disappears from your system. Vala! Infectecado!
Hopefully your AV will catch it in a few days as the exploit is discovered elseware on the net. Though it could take longer if he is only installing them by hand.
THINK! It's patriotic
Denyhosts can be set to block all, not just ssh, if wanted. I decided not to because some might have ISP NAT and that would block many people from my webserver... Maybe unlikely though, and leaving them an option to find an exploit in apache or wordpress might not be that good idea...
In capitalist USA corporations control the government.
Denyhosts can be set to block all, not just ssh, if wanted. I decided not to because some might have ISP NAT and that would block many people from my webserver... Maybe unlikely though, and leaving them an option to find an exploit in apache or wordpress might not be that good idea...
Sorry it took a while to get back to you.
My point is I would rather have all traffic from an offending IP address be DROPped at the kernel by an iptables rule, than have the machine continue to receive packets only to have connections rejected by TCP Wrappers and the hosts.deny file.
Of course with TCP Wrappers you do have more fine-grained control. You can, as in your example, decide to block one service and not another. In my own use-case there is no scenario where I would want to deny SSH access to an attacker while still wanting them to have access to something else. For me, the more secure option of just having iptables DROP all packets from the offending host is a feature. Then I'm not accepting non-TCP packets from them, and like in your example they can't look for some unblocked service to screw with. The IPs around the world that want to hammer my little server and fill up its logfiles with failed login attempts (usually dumb shit like Username: root Password: root) have no redeeming value to me.
My own server is small-scale so ISP NAT concerns also don't apply to me. If I were running a commercial site with many potential customers, then I would have to think about that. Still, I really consider that the problem of the ISP in question, something they should have thought of when adopting that approach. Perhaps their customers should demand cheaper rates compared to ISPs that more freely assign unique IP addresses to offset this risk. Or maybe their customers don't care. Either way, my primary responsibility is to secure my own systems so they don't become spam-spewing zombie platforms used to attack others; compared with that, I can't be concerned with things beyond my control such as how certain ISPs do business.
It is a miracle that curiosity survives formal education. - Einstein
...yeah, I totally hear what you're saying...
Gotta hand it to you for really putting in the effort to explain all this :) Many would have done with a small percentage of words - and would have written a much more boring reply at that >:) So congrats.
In capitalist USA corporations control the government.