SSHD and Trojans

[WKAFC]

Have any of you all ever had a problem with Adore sshd or the Shaft Trojans? I hear they are a common threat and was wondering if it is worth my network to run sshd? (Slackware Linux currently on three of my boxes.) (10.0, 9.1 and 8.1)

[Tiger Shark]

There's numerous recent reports of an ssh worm or tool running around trying some basic username/password combinations in the last couple of weeks....

Other than that, being a Win32 type I can't help you....

[WKAFC]

ic.. well, my knowledge is weak on trojans. I don't even know how they work. I'll read up on them. But i would still like to know more about trojans w/sshd on a unix platform! i suppose ill search google a bit more.

[slarty]

There is definitely something which crawls around trying to log in as test, admin, root etc recently. I wouldn't like to say whether it's a worm.

I don't doubt that a worm could be moderately effective, particularly in large hosting pools of poorly patched systems, a lot of which exist.

Slarty

[HTRegz]

Hey Hey,

I just wanted to drop some more info here on the events that TS and slarty are mentioning. You can find more information about it, as well as links to the software involved in the Logwatch thread that steve.milner started.

As far as the Shaft Trojan, Blackcode.com has some info on it. As far as I can gather it's just your standard DDoS trojan that listens for connections on port 22... That won't be an issue for you using an sshd in *nix.

Name: Shaft
Aliases:
Ports: 22, 5002, 18753 (UDP), 20432, 20433 (UDP)
Files: idle - 28,969 bytes tcp.log - ??? bytes pp.pl - 2,795 bytes sniff.pid - 6 bytes s - 7,654 bytes chattr - 7,656 bytes vi - 437,428 bytes tcsh - 262,756 bytes ps - 31,312 bytes shaftmaster - 25,123 bytes shaftnode - 15,184 bytes shaftnode.c - 19,806 bytes hitlist - ??? bytes
Created: Oct 1998
Requires:
Actions: Distributed DoS tool / Steals passwords. Is able to either send UDP, TCP or ICMP floods, or all three at the same time.
Versions:
Registers:
Notes:
Country:
Lenguage: Written in C.

Adore seems to be another story. Saint Corporation has a write-up on it, but makes no mention to it using SSH.

The Adore worm, also known as the Red worm, is similar to the Ramen and Lion worms. It spreads itself by exploiting vulnerabilities in LPRng, rpc.statd, wu-ftpd, and BIND. After gaining access to a system, it performs the following actions:

* Replaces the system binary ps with a Trojan horse version and moves the original to /usr/bin/adore
* Installs files in /usr/lib/lib
* Sends e-mail to four different e-mail addresses containing the contents of /etc/shadow (the encrypted system passwords) and other sensitive information about the system
* Runs a backdoor program called icmp which opens a root shell on a pre-defined port after receiving an ICMP request of a particular length.
* Sets up a cron job to remove all traces of the worm's existence, except the backdoor, and reboot at 4:02 A.M.

There is also a variant of Adore which performs several other actions in addition to the above, such as adding two new system accounts and sending out e-mail to two more e-mail addresses.

Adore SSHD Trojan only brings up a few results, mostly replies to a questioned posted to the SLUG Mailing List. There's really no confirmation that it uses SSH... just an assumption that updating SSH fixed the problem, and since this post is almost 3 years old I don't think you'll have to worry about having a vulnerable version of SSH.

There are risks involved in running any server, the important thing to do is to stay up to date and limit the chance of these risks causing problems.


Peace,
HT

[Spyder32]

In reference to that "worm": To my belief and studies about it, it goes to random ssh servers/etc and like mentioned, tries different password's for root, admin, etc. It tries a commonly used password format that the apparent "creator" or whatever has assembled for it to follow. Then from there (again, according to my research) it goes back to the creator with the information gathered. Not sure on whether or not it goes back with both unsuccessful and successful attempts at a connection.