×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Trojanized SSH Daemon In the Wild, Sending Passwords To Iceland

timothy posted about a year ago | from the in-iceland-they-get-massages dept.

Security 171

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

171 comments

Iceland? How hard could it be? (1, Redundant)

cowbud (200323) | about a year ago | (#42698879)

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.

Re:Iceland? How hard could it be? (5, Insightful)

WWJohnBrowningDo (2792397) | about a year ago | (#42698915)

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

In all likelihood the server is just another compromised machine.

Re:Iceland? How hard could it be? (3, Interesting)

JWSmythe (446288) | about a year ago | (#42699063)

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.

Re:Iceland? How hard could it be? (2)

AK Marc (707885) | about a year ago | (#42698963)

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

Re:Iceland? How hard could it be? (0)

Anonymous Coward | about a year ago | (#42699169)

I am not him but let me look around for ya...........
Nope, I couldn't find him . Perhaps it was ólaugur, his eyes were kind of shifty

SSH Got Bjorked? (5, Funny)

Penguinshit (591885) | about a year ago | (#42698905)

Somebody had to say it.

Re: SSH Got Bjorked? (1)

Anonymous Coward | about a year ago | (#42698917)

So who's distributing the binary?

Re: SSH Got Bjorked? (2, Funny)

Anonymous Coward | about a year ago | (#42699549)

Warner Bros. Records.

Re:SSH Got Bjorked? (0)

Anonymous Coward | about a year ago | (#42699641)

it's virus as tty

Re:SSH Got Bjorked? (0)

Anonymous Coward | about a year ago | (#42699845)

That is pretty funny, even if one knows that it doesn't work due to the fact that it's pronounced "byerk."

Re:I use Gentoo (1)

miknix (1047580) | about a year ago | (#42699847)

I only install from sources you insensitive clod!

Re:I use Gentoo (1)

cheekyboy (598084) | about a year ago | (#42699919)

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.

Re:I use Gentoo (0)

Anonymous Coward | about a year ago | (#42699975)

woooosh!

Re:I use Gentoo (2)

smash (1351) | about a year ago | (#42700243)

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

Re:I use Gentoo (4, Informative)

miknix (1047580) | about a year ago | (#42700299)

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

Anonymous Coward | about a year ago | (#42699883)

WTF is "Got Bjorked" I know who Bjork is but what does that mean. I don't pay any attention to the retarted Popular Social life of our unevolved aspects of humanity. Such as Gossip and such useless things.

If it weren't for the mention of Iceland (2)

93 Escort Wagon (326346) | about a year ago | (#42698911)

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 (4, Interesting)

JWSmythe (446288) | about a year ago | (#42699093)

    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 (3, Insightful)

pipatron (966506) | about a year ago | (#42699131)

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?

Breaking and decorating (3, Interesting)

OwenT (2778847) | about a year ago | (#42699413)

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

they should have installed a java version of ssh (1, Funny)

cheekyboy (598084) | about a year ago | (#42699925)

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.

Re:they should have installed a java version of ss (1)

g0bshiTe (596213) | about a year ago | (#42700411)

Yes cause we all know how secure and well coded java apps are.

Re:If it weren't for the mention of Iceland (4, Funny)

maxwell demon (590494) | about a year ago | (#42699577)

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 (0)

Anonymous Coward | about a year ago | (#42700015)

I guess to compile on the machine to make sure it used the local libraries.

Better than some of the efforts I've seen. Like the time someone tried to install a 32bit rootkit comprised of a bunch of dynamically compiled replacements for things like 'ps'...on a 64bit machine that didn't have the IA32 libraries installed.

This was the same place where we ran a custom sshd anyway, so the one time someone got far enough to actually replace it with a backdoored version it was obvious within, ohhh, 3 seconds or so.

SSH daemon... (0)

Anonymous Coward | about a year ago | (#42698921)

So being compromised is the first condition to get "infected"? I'd say it's a non-issue, although it's always better to be acknowledged.

Exfiltrate? (0)

Anonymous Coward | about a year ago | (#42698925)

Please don't misuse silly words like exfiltrate because it sounds cool. You know, like saying it was cloud crowd sourced in the third inning of the ether space. It makes no sense in your context and your have blown all credibility in this story. You can replace "exfiltrate" (omg so cool) with "send" (omg..oh, so simple!).

Tip (5, Informative)

detritus. (46421) | about a year ago | (#42698929)

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 (1, Insightful)

MightyMartian (840721) | about a year ago | (#42698931)

So how is a compromised ssh binary getting on Debian?

Re:Tip (3, Informative)

Nerdfest (867930) | about a year ago | (#42699015)

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

Re:Tip (0)

Anonymous Coward | about a year ago | (#42699049)

Same as always. The attacker gets in somehow (0day, outdated, bad passwords, etc) and then ensures he'll still be able to get in after the flaw he used is corrected (in this case, by replacing local binaries with his own). The infected ssh daemon was not on Debian's repositories (if the repositories are infected you're screwed), but on a user's server.

Re:Tip (2)

NotBorg (829820) | about a year ago | (#42699301)

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 (1)

GameboyRMH (1153867) | about a year ago | (#42699627)

Mostly weak passwords/lack of anti-brute-force, Apache vulnerabilities is probably the second most common. Nothing new.

That's why SSH - most compromised by the trojan (2)

raymorris (2726007) | about a year ago | (#42700403)

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:Tip (1)

flyingfsck (986395) | about a year ago | (#42700415)

All the machines I cleaned up got hacked due to some wise guys who thought that using 4 letter passwords were kewl.

Re:Tip (1, Insightful)

Anonymous Coward | about a year ago | (#42699377)

Must have come from a Windows machine, coz Linux is so secure... ;)

Re:Tip (1)

shipofgold (911683) | about a year ago | (#42700057)

Same way any Windows box gets compromised...two most common:

-- A security flaw is found in the distro and the patches are not up-to-date.
-- Someone installs some other program as root which contains the trojan.

Linux is just as vulnerable as Windows to these attacks....

Re:Tip (4, Insightful)

19thNervousBreakdown (768619) | about a year ago | (#42699155)

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 (4, Insightful)

DarwinSurvivor (1752106) | about a year ago | (#42699371)

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

Compromised system (1)

phorm (591458) | about a year ago | (#42699741)

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.

use a PPC mac. (1)

cheekyboy (598084) | about a year ago | (#42699953)

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.

Re:Compromised system (1)

smash (1351) | about a year ago | (#42700271)

You do network inspection and verify what the machine is doing over the wire matches what it SHOULD be doing over the wire.

Re:Compromised system (2)

smash (1351) | about a year ago | (#42700375)

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.

Re:Tip (2)

bill_mcgonigle (4333) | about a year ago | (#42700301)

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:Tip (0)

Anonymous Coward | about a year ago | (#42699409)

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

"You gonna catch me on an extremely common distro like Debian without installing out-of-tree software?" WTF do you mean by this? Straw-men can't find your rootkit? People who aren't looking won't find something!? Well, OK, man. FYI, I periodically create a list of all files from within a system, then compare it to one without. DIFF and LS are fucking "in-the-tree" software. Do you even hack? Stop fronting you lamer.

Re:Tip (0)

Anonymous Coward | about a year ago | (#42699459)

I will ALWAYS find your rootkit. This is because you're trapped in a VM

Hmm... I think I hacked both your hypervisor and bios yesterday, but please keep on assuming that you are safe. Much better that way.
Only trouble coming from people that are always suspicious.

VMWare sales staff are my best friends. Their brainwashing on the advantages of virtualized servers works great!

Re:Tip (0)

Anonymous Coward | about a year ago | (#42699655)

Pfft... I hacked your mom last night.

Re:Tip (1)

cheekyboy (598084) | about a year ago | (#42699965)

I can always have a real hardware PPC or MIPS based linux or even old Solaris machines used as 'screeners, scanners' to verify the VMs.

Oh and I could use 2 identical machines that do a complete scan and compare results.

Re:Tip (4, Funny)

Ford Prefect (8777) | about a year ago | (#42699471)

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

Duh, run md5sum from external machine (2, Insightful)

cheekyboy (598084) | about a year ago | (#42699945)

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:Tip (0)

Anonymous Coward | about a year ago | (#42699315)

man debsums:

"debsums is intended primarily as a way of determining what installed
files have been locally modified by the administrator or damaged by
media errors and is of limited use as a security tool.

If you are looking for an integrity checker that can run from safe
media, do integrity checks on checksum databases and can be easily
configured to run periodically to warn the admin of changes see other
tools such as: aide, integrit, samhain, or tripwire."

Iceland needs the help (0)

Anonymous Coward | about a year ago | (#42698981)

I always post my passwords at linuxrepository.org with our without a trojaned sshd

Effective (5, Interesting)

Anonymous Coward | about a year ago | (#42698999)

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 (3, Informative)

Gaygirlie (1657131) | about a year ago | (#42699115)

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

Re:Effective (0)

Anonymous Coward | about a year ago | (#42699141)

It does. It is the first thing that came to my mind. A problem I have with it is there really is no outstanding tripwirealike for Windows so I wrote my own simplified version. Such a simple thing as checking the hash of important files does wonders for security. It even detects data corruption.

Re:Effective (1)

DarwinSurvivor (1752106) | about a year ago | (#42699375)

Also, don't use passwords for ssh.

Bad advice because ... (2)

dbIII (701233) | about a year ago | (#42699421)

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 ... (3, Informative)

Opportunist (166417) | about a year ago | (#42699497)

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

Anonymous Coward | about a year ago | (#42699503)

You're talking about different things.

You're talking about encrypting your private key with a password. Everyone agrees that's a good idea.

The only legitimate exception is automated scripts, and in that case, you'll want to add 'command=...' to your authorized keys file to restrict what it can be used for to limit the damage if it gets stolen.

The parent is talking about logging in with password authentication, rather than public key authentication. The only protection offered here is the encrypted tunnel. The SSH daemon running on the server gets to see your plaintext password, which is kind of a bad thing if it was put there by an attacker.

Re:Bad advice because ... (1)

dbIII (701233) | about a year ago | (#42699537)

You're talking about different things

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.

The parent is talking about logging in with password authentication, rather than public key authentication.

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.

Re:Bad advice because ... (2)

segedunum (883035) | about a year ago | (#42700031)

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.

Re:Bad advice because ... (1)

quannah (2785809) | about a year ago | (#42700067)

No, the poster wrote "don't use passwords for ssh", not "don't use passwords [in general]" nor "don't use passwords for your private keys".

that is called reading between the lines

No, it's called adhering to Gricean maximes [wikipedia.org], which you are apparently not doing.

Re:Bad advice because ... (1)

smash (1351) | about a year ago | (#42700283)

Passphrases on SSH keys are not the same as SSH passwords. They don't go over the wire.

Is this for real or just buzzword pizza? (1)

dbIII (701233) | about a year ago | (#42699407)

Do not allow write access to any essential binaries

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.

Re:Is this for real or just buzzword pizza? (0)

Anonymous Coward | about a year ago | (#42699509)

On *BSD you can go beyond permissions and set flags on the files that disallow changing them. The flag can only be removed under a lower security level. You can only increase security levels while the box is running. To remove the locks (on files including kernel) you need to reboot to single user dropping the external network connection you try to break in with.

Re:Is this for real or just buzzword pizza? (1)

dbIII (701233) | about a year ago | (#42699629)

So? You have root, write a script to change those flags, have it run on startup in single user mode, and reboot in the middle of the night to single user mode so nobody notices. Of course your script could then change the box back to the right runlevel when it's finished and let you back in.
Once somebody has root (or full physical access and a screwdriver) they own the box, and about all you can do is make sure they can't easily get into other ones.

Re:Is this for real or just buzzword pizza? (1)

smash (1351) | about a year ago | (#42700321)

So? You have root, write a script to change those flags,

Except you can't. The securelevel [wikipedia.org] feature in FreeBSD (maybe others) disables the ability to write to files with the immutable bit set. The only way to write to these files is to reboot the box into single user mode, before the kernel securelevel is raised. Single user mode = no network running.

Setting securelevel is a one way thing, once it has been raised, you can not lower the securelevel.

Re:Is this for real or just buzzword pizza? (1)

segedunum (883035) | about a year ago | (#42699987)

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.

Quite right. Binaries are already write protected from users but if you're root you can do anything.

Re:Is this for real or just buzzword pizza? (1)

Junta (36770) | about a year ago | (#42700215)

It might be reasonable to map most system binaries to an nfs share where root is mapped to nobody...

Re:Effective (0)

Anonymous Coward | about a year ago | (#42699595)

anon, can you descibe the port redirections are you talking about? I think what you mean is you have a laptop on the internet in a cafe, and it connects to your router then it port forwards to another server inside your home network. from server 1 you ssh to server 2? If thats the case you are suggesting that you jusy portforward to one node and then do something with the ports on that node?? of course i always use password and key and i change the password often.

Re:Effective (0)

Anonymous Coward | about a year ago | (#42699765)

I wonder if this is how Leviticus was written. A list of proscriptions for practices identified to prevent certain problems... religiously followed until the end of time.

Define "wild" (2)

dalmor (231338) | about a year ago | (#42699025)

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?

XOR Conspiracy (0)

RedHackTea (2779623) | about a year ago | (#42699037)

It seems odd to me that a recent /. article [slashdot.org] (read link in summary) also mentioned XOR style code that could identify the SQL Slammer perpetrator. It could just be coincidence... but the same guy that made this tojanized version of SSH could also be the same guy that made SQL Slammer. Both have an infatuation for XOR. Both Trojan and Slammer are sexual terms. SSH, SQL, and XOR are 3 letter-abbreviations. Conspiracy! 3^3^3=3! And it is the year 2013! OMGZ! Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh! This was also posted by timothy. Arrest TIM O THY!

Re:XOR Conspiracy (1)

Raenex (947668) | about a year ago | (#42699273)

That's funny, but for those that don't know: XOR is a well-known, poor man's encryption/obfuscation trick.

Re:XOR Conspiracy (0)

Anonymous Coward | about a year ago | (#42699307)

XOR is part of practically all cryptographic systems, because it's how the clear-text and the key material are combined to form the cypher-text. XOR is the only mathematical operation in the only provably unbreakable encryption, the one-time-pad.

Re:XOR Conspiracy (0)

Anonymous Coward | about a year ago | (#42699353)

ADD, SUB (the way they are normally implemented in hardware) also work with one time pads. XOR is simpler.

Gather passwords with ssh? Hah! (2)

Omnifarious (11933) | about a year ago | (#42699473)

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! (3, Funny)

maxwell demon (590494) | about a year ago | (#42699585)

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

fail2ban (0)

Anonymous Coward | about a year ago | (#42699801)

fail2ban solves the remote login attempts.

Giggle (-1)

Anonymous Coward | about a year ago | (#42699747)

So where is the linux is perfect and windows is inherently insecure crowd now? :p

Re:Giggle (1)

EzInKy (115248) | about a year ago | (#42700013)

They have thousand of eyes looking at the source and working on ways to improve things. What are the Window's folks doing?

Re:Giggle (1)

smash (1351) | about a year ago | (#42700337)

You'd like to think so, but when things like this [debian.org] 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.

Which Distro? (1)

Lawrence_Bird (67278) | about a year ago | (#42700241)

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?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...