S: ssh worms FAQ

On 2004-09-15, Innocenti Maresin <av95@comtv.ru> wrote:
> Hello!
>
> There is many ssh worms in the Internet since this summer.
> These worms often try to access
> "test", "guest", "admin", "user" and "root" accounts.

These aren't "worms". "worm" as it's used today is a mis-nomer for
virus (I'm not going to argue this point again, see the alt.virus
groups for many of my posts about that and my references). These are
are straight-up attacks from other people. I'm sure there's an
automatted script or two, but by and large they are people sitting
down at another machine running attack tools. I've been following this
and have studied it in depth, and have recoverd quite alot of the
evidence off machines compromised in this way (logs, history files,
shell histories, downloaded tools & archives, tgz's, two different
viruses download and placed on the machines, several version of the
linux ptrace exploit, etc). Most of the machines that get nailed had
weak passwords with BS accounts like "test" and "guest". The first
copies of the tools to appear were crude, and only tried several
combos of those logins, and "root", in pairs, like "test:test",
"guest:guest". They generated IP lists (like you can do with nmap) and
sometimes wrote shell scripts to try ssh at the listed IP's with
several sets of those logins. Letting this run overnight, sometimes in
the morning the script kiddies would get lucky. Then they'd use local
exploits like mremap, do_brk, kmem/ptrace- all recent and semi-recent
kernel bugs to try for root. If they could get root, they compromised
the system further, installing rootkits. I've pulled copies of SucKit,
T0rn, and couple others off those systems. Some of the original URL's
are still up in Romainia today, many in the .go.ro domain. Later
version of the tools were C programs linked against libssh,
statically, and had larger lists of passwords. Most of the passwords
were still dictionary words, and 8 characters, or about 8-10
characters. This tool was posted on various exploit boards, and adding
passwords to the list is a trivial matter. Later versions of the tools
added longer and longer lists of passwords, and more complex
passwords, plus they tried to login to accounts that may be left open
but shouldn't be- like httpd, mysql, nobody, etc.
Once the attackers got in, they almost always do the same thing:
install IRC crap, BNC's (I found a copy of PsyBNC), Bot's ("fastmech",
really "energymech"), and the like. There was even a channel on
Undernet for awhile that had these bots connect to, since the config
file in the tgz was already setup to connect there. This tgz was named
"mech.tgz". Others were spl.tgz, god.tgz. xpl.tgz, rkid.tgz. They were
frequently loaded with copies of Linux viruses RST (the Remote Shell
Trojan) and OSF (ELF infector, one of the more successful). In one
archive, I found over 5 copies of RST, with names like "ls" and
"sanders". I did an in-depth study on RST, and disassembled it. While
reseaching it, I found material from years back were a similar thing
happened: ssh's were attached, attackers broke in, they ran copies of
RST. Although RST checks for active reversing with checks for
ptrace/TRACEME, it was frequently found attached to kernel exploits
that involved ptrace; probably to try to boost the virus's power by
making sure it had root rights when run (if the exploit was
successful). There exist 3 files with all the tests and work I did on
it: RST.linux.02.zoo, SSH-bruteforce.zoo, and ssh-crack.rar; zoo and
rar archives. The report on RST is 'RST.Report.txt'.

There IS an actual file called "sshworm", but it's not very
impressive- just a shell script that tries to look for ssh keys and
login to systems it finds. It depends on alot of special circumstances
and users having their accounts setup just so, so it's very unlikely
to ever get farther than POC code (and hasn't, to date.). You kinda
have to help it along to get it going. The two scenerios
aren't/weren't related.

--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

On 2004-09-16, Dale Richards <dalerichards800@msn.com> wrote:
> Innocenti Maresin wrote:
>> Hello!
>>
>> There is many ssh worms in the Internet since this summer.
>> These worms often try to access
>> "test", "guest", "admin", "user" and "root" accounts.
>> See details in
>> http://seclists.org/lists/fulldisclo.../Jul/1243.html
>
> Interesting. I've seen these access attempts in my logs but never thought
> too much of it.
>
> Out of curiosity, I downloaded the file mentioned in that article
> (http://frauder.us/linux/ssh.tgz). As soon as I did, my antivirus software
> started complaining about "Linux.RST.B", "Hacktool.Slice" and
> "Hacktool.Rootkit".
>
> Does anyone know whether this worm is just trying default passwords or if it
> is using an SSH server vulnerability? It can't be brute forcing because I
> only see one or two access attempts per attack in my logs...

RST doesn't have any such ability, it is an ELF infector. Also, it
opens a backdoor for which no known client exists nowdays, and
attempts to contact a site long ago removed. The ssh logins were
likely attempts by one of the earlier generation tools, since you
didn't see many. I've seen those, and times when many attempts were
made as well.
To date, no ssh vulnerability relating to this has been found. I don't
call making ssh accounts with logins like "test:test" and
"guest:guest" a vulnerability, that's just senseless ;)

Limit access to ssh, make your passwords long, strong, and complex,
make sure all unneeded accounts are locked down/removed, maybe use the
allow user/deny user in sshd_config, and keep patched and you should
be OK.

Many of the archives you download from those sites like this one
contain RST and OSF as well. I'm not sure if that's on purpose, or
someone is unknowningly infested.


PS: [OT] One of the archives contained a cool IRC bot for linux; you
can get a clean copy of it here: http://www.energymech.net/ ;)


--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

jayjwa wrote:

> These aren't "worms". "worm" as it's used today is a mis-nomer
> for virus (I'm not going to argue this point again, see the alt.virus
> groups for many of my posts about that and my references).
> These are are straight-up attacks from other people.

I'm not willing to get to discussion on English terms.
Please, propose a well-understood word to name such phenomenon instead of "worm",
like "scan" or "crack", but no "indiscriminate straight-up attacks"
nor "semi-automated probing".
Maybe, "ssh account harvesting"?


> I'm sure there's an
> automatted script or two, but by and large they are people sitting
> down at another machine running attack tools. I've been following this
> and have studied it in depth, and have recoverd quite alot of the
> evidence off machines compromised in this way (logs, history files,
> shell histories, downloaded tools & archives, tgz's, two different
> viruses download and placed on the machines, several version of the
> linux ptrace exploit, etc).

Thank yoy for this reply. Are your results published somewhere?
If no, could you write some notes, especially practically useful?


> Then they'd use local
> exploits like mremap, do_brk, kmem/ptrace- all recent and semi-recent
> kernel bugs to try for root. If they could get root

Were there cases that they didn't try to get root?
In how many cases they attepmted to get root, but failed?
It's interesting to know is UNIX so secure as it seems ;(


> I don't call making ssh accounts with logins like "test:test"
> and "guest:guest" a vulnerability, that's just senseless ;)

Do you consider as a severe vulnerability
only such hidden-deeply-in-the-code things as do_brk flaw
or different flavours of buffer overflows?
I saw such thing as "rpc.statd gethostbyname buffer overflow exploit" only once,
but many times € ssh attempts, more or less intensive.
What does it mean?
That stupid passwords really _is_ a common vulnerability
regardless of what do you think about such type of host admins :)
This is a human vulnerability of course, not technical.
You can claim that these admins are "lame" or "brain-dead"
(as I can say about programmers who permit buffer overflows),
but now, some migration away from Windows to Linux exists.
This means, we'll have more and more "lame" admins in UN*X world :)
In another words, an average UN*X admin become more and more lame.
It's not a crash of UN*X culture or a crash of Linux.
We just can realize that some phenomena
what, as we thought, exist in Windows or Macintosh worlds only,
now exist also in UN*X world.
First of all, I mean "admins" who can't control their machines
and a lot of boxes controlled by remote bad guys.
Therefore, "ssh worms" will exist.
IMHO the FAQ on so-called-by-me "worms"
might help to discriminate possible really non-trivial menaces
among usual scripty noice.
Such FAQ should claim: NO menace for GOOD admin from there.
Also, because _most_ lame people still stay under M$,
an average BAD admin has a chance to read some FAQs,
to realize that he is a bad admin, to want to become a good admin
and to remove his bad admin's vulnerabilities.
Without such FAQ good UNIX admins spend time
trying to understand what means these ssh attacks,
while bad one (and their ISPs' network admins)
do not know what happens and what to do.





--
qq~~~~\ [ úá IP âåú ãåîúõòù ]
/ /\ \ [ FAQ you ] at news:local.chainik € rules at http://www.comtv.ru/~av95/chainik.html
\ /_/ /
\____/

In message <414C899B.5EC85A8@comtv.ru>, Innocenti Maresin
<av95@comtv.ru> writes
>jayjwa wrote:
>
>> These aren't "worms". "worm" as it's used today is a mis-nomer
>
>I'm not willing to get to discussion on English terms.
>Please, propose a well-understood word to name such phenomenon instead
>of "worm",
>like "scan" or "crack", but no "indiscriminate straight-up attacks"
>nor "semi-automated probing".
>Maybe, "ssh account harvesting"?

I think the distinction here is that a 'worm' is automatic, a program
which spreads by itself, and can attack others from an infected machine.
These recent attacks are from humans, someone is actually sitting at a
computer running the attack program. As far as we are concerned there
may be no difference, but a successful worm can create many more
attackers than there are human crackers in the world.
>
>
>> I don't call making ssh accounts with logins like "test:test"
>> and "guest:guest" a vulnerability, that's just senseless ;)
>
>Do you consider as a severe vulnerability
>only such hidden-deeply-in-the-code things as do_brk flaw
>or different flavours of buffer overflows?
>I saw such thing as "rpc.statd gethostbyname buffer overflow exploit"
>only once,
>but many times € ssh attempts, more or less intensive.
>What does it mean?
>That stupid passwords really _is_ a common vulnerability
>regardless of what do you think about such type of host admins :)
>This is a human vulnerability of course, not technical.

If your machine is successfully attacked, does it matter which kind of
problem it is? It is possible to force users to create good passwords,
to change them often, and not to use a password twice in a certain
period of time. Users hate this. Is it a vulnerability of a certain
Linux distribution if these policies are not already built-in at the
time of installation? Should the user be able to turn them off?

Certainly the serious versions of Windows, logging on to a server, have
this built in as standard. It is easy to dismiss all Windows versions as
having very poor security, but the server versions are capable of good
security. Not great, but good.

Windows has the 'advantage' of allowing people who do not understand
computers to use them. Is this a strength or a weakness? If Linux is to
become a popular desktop OS it must do the same, and some distributions
are moving in that direction. The result must be that more people who do
not understand anything about security are running computers connected
to the Internet. Should the operating system try to protect them from
their own ignorance? How well can it do this?

>You can claim that these admins are "lame" or "brain-dead"
>(as I can say about programmers who permit buffer overflows),
>but now, some migration away from Windows to Linux exists.
>This means, we'll have more and more "lame" admins in UN*X world :)

I think we know this, and we are seeing some of the results. Not only is
Linux attracting the kind of people who might use Windows, but in some
cases they are the same people, who bring bad habits with them.

>In another words, an average UN*X admin become more and more lame.
>It's not a crash of UN*X culture or a crash of Linux.
>We just can realize that some phenomena
>what, as we thought, exist in Windows or Macintosh worlds only,
>now exist also in UN*X world.
>First of all, I mean "admins" who can't control their machines
>and a lot of boxes controlled by remote bad guys.
>Therefore, "ssh worms" will exist.
>IMHO the FAQ on so-called-by-me "worms"
>might help to discriminate possible really non-trivial menaces
>among usual scripty noice.
>Such FAQ should claim: NO menace for GOOD admin from there.
>Also, because _most_ lame people still stay under M$,
>an average BAD admin has a chance to read some FAQs,
>to realize that he is a bad admin, to want to become a good admin
>and to remove his bad admin's vulnerabilities.
>Without such FAQ good UNIX admins spend time
>trying to understand what means these ssh attacks,
>while bad one (and their ISPs' network admins)
>do not know what happens and what to do.
>
There are services which inform about problems as soon as they are
found. CERT (www.cert.org) gives good quality information about security
problems, but they are only interested in big problems. Security Focus
runs a mailing list for this kind of information. Most Linux
distributions have a website or mailing list for security problems. I
think that if someone takes the time to convert all these security
alerts into a FAQ for beginners, the problem will already be over, or
less serious.

There is no easy way. To maintain good security, you must understand the
problems, and look at the information which arrives first. You cannot
wait for someone to convert the information to a simple set of
instructions.

Do you know about http://grc.com, Steve Gibson's Shields Up! site? This
is a fairly simple automatic port scanning program, but the way that the
results are presented is quite dramatic. It uses simple language, and it
scares people who are running open services, and perhaps this is a good
thing. Maybe Microsoft and the Linux distributions should put a link to
this site on the desktop. Even intelligent people who are not involved
in IT work are often totally unaware of the dangers of the Internet.
--
Joe

Stephan Goeldi <expires.1.10.04@usable.ch> writes:

> > Not really.
>
> Ah yes, I see. But anyway: Is there any script available, which totally
> blocks any machine trying to log in as user test (e.g.)?

Considering that ssh traffic (including the username) is encrypted, it
should be rather hard to filter ssh traffic by username anywhere other
than in sshd itself. (The other possible filtering point would be the
ssh client, but obviously you don't always have control over that.)

You'd need a script hook in the authentication process, which would
get triggered when someone attempts to log in using a certain (set of)
username(s). You'd probably want the login to be always refused at
that point. Offhand, I see three ways to do this:

- Patch sshd to add the possibility to call an external script at the
appropriate point.
- If you're using PAM, see if there's a PAM module which would be suitable.
If not, build your own.
- Create a script that parses the syslog messages generated by sshd
and checks the usernames and source IP addresses. (This will give
slower reaction times than the other methods.)

Regardless of the method you choose, this kind of auto-blocking
may actually open new DoS opportunities: consider what happens if
the login attempt _seems_ to be coming from, say, your DNS server? Or
your main database server? Or your default gateway?

--
Matti.Kurkela@welho.com

> You'd need a script hook in the authentication process, which would
> get triggered when someone attempts to log in using a certain (set of)
> username(s). You'd probably want the login to be always refused at
> that point. Offhand, I see three ways to do this:
>
> - Patch sshd to add the possibility to call an external script at the
> appropriate point.
> - If you're using PAM, see if there's a PAM module which would be suitable.
> If not, build your own.
> - Create a script that parses the syslog messages generated by sshd
> and checks the usernames and source IP addresses. (This will give
> slower reaction times than the other methods.)

As has already been pointed out in this thread, OpenSSH supports
AllowUsers & AllowGroups. Why on earth would you do any of the above
instead?

--
Richard Silverman
res@qoxp.net

On Fri, 17 Sep 2004 11:43:42 +0000, Stephan Goeldi wrote:

>> Not really.
>
> Ah yes, I see. But anyway: Is there any script available, which totally
> blocks any machine trying to log in as user test (e.g.)?
>
> The discussion about this
> (http://seclists.org/lists/fulldisclo.../Jul/1243.html and
> http://dev.gentoo.org/~krispykringle/sshnotes.txt) suggests, that there is
> more on this than only password guessing ...
What would be nice is a script that checks the logs and through IPTABLES
blocks multiple login attempts by the same IP.
Anyone know of such a script?

mc

On Fri, 08 Oct 2004 21:48:24 -0400, microcheap wrote:

> On Fri, 17 Sep 2004 11:43:42 +0000, Stephan Goeldi wrote:
>
>>> Not really.
>>
>> Ah yes, I see. But anyway: Is there any script available, which totally
>> blocks any machine trying to log in as user test (e.g.)?
>>
>> The discussion about this
>> (http://seclists.org/lists/fulldisclo.../Jul/1243.html and
>> http://dev.gentoo.org/~krispykringle/sshnotes.txt) suggests, that there is
>> more on this than only password guessing ...
> What would be nice is a script that checks the logs and through IPTABLES
> blocks multiple login attempts by the same IP.
> Anyone know of such a script?
>
> mc
Try psad. Not a script but checks your logs and optionally (but not
recommended by psad) blocks the offender.

http://www.cipherdyne.com/psad/

Jos

On Sat, 09 Oct 2004 10:53:29 +0200, Jos wrote:

> On Fri, 08 Oct 2004 21:48:24 -0400, microcheap wrote:
>
>> On Fri, 17 Sep 2004 11:43:42 +0000, Stephan Goeldi wrote:
>>
>>>> Not really.
>>>
>>> Ah yes, I see. But anyway: Is there any script available, which totally
>>> blocks any machine trying to log in as user test (e.g.)?
>>>
>>> The discussion about this
>>> (http://seclists.org/lists/fulldisclo.../Jul/1243.html and
>>> http://dev.gentoo.org/~krispykringle/sshnotes.txt) suggests, that there is
>>> more on this than only password guessing ...
>> What would be nice is a script that checks the logs and through IPTABLES
>> blocks multiple login attempts by the same IP.
>> Anyone know of such a script?
>>
>> mc
> Try psad. Not a script but checks your logs and optionally (but not
> recommended by psad) blocks the offender.
>
> http://www.cipherdyne.com/psad/
>
> Jos
Thanks. I will give it a try.
mc

> Try psad. Not a script but checks your logs and optionally (but not
> recommended by psad) blocks the offender.

Thank you. Why isn't it recommended?