RE: Remote Shell Trojan: Threat, Origin and the Solution

From: John Stauffacher (stauffac@chapman.edu)
Date: 09/10/01 

Date: Mon, 10 Sep 2001 08:25:43 -0700 (PDT)
From: John Stauffacher <stauffac@chapman.edu>
To: Oliver Petruzel <opetruzel@cox.rr.com>
Subject: RE: Remote Shell Trojan: Threat, Origin and the Solution
Message-ID: <Pine.GSO.4.05.10109100823530.14983-100000@nexus.chapman.edu>

It sounds to me like this is a feeble attempt to spread this "trojan" even
more. I dont like the sound of it. Anyone out there willing to "cleanroom"
this "immunizor"?

-John Stauffacher

On Sun, 9 Sep 2001, Oliver Petruzel wrote:

> Who is "us" and why post anonymously? Well, I can guess why, but it's
> strange to do so when sending from an apparently legitimate meail
> address at coders.com
>
>
>
>
> > -----Original Message-----
> > From: kai takashi [mailto:rst@coders.com]
> > Sent: Sunday, September 09, 2001 7:40 AM
> > To: bugtraq@securityfocus.com
> > Cc: incidents@securityfocus.com;
> > focus-virus@securityfocus.com; vulnwatch@vulnwatch.org;
> > contribute@linuxsecurity.org
> > Subject: Remote Shell Trojan: Threat, Origin and the Solution
> >
> >
> > Overview:
> >
> > At the 5th of September Qualys released a Security Warning
> > regarding a Linux based virus. This virus was called the
> > "Remote Shell Trojan" (RST) and it attacks Linux ELF
> > binaries. It has replicating abilities: when run it will
> > infect all binaries in /bin and the current working
> > directory. Besides that it also spawns a process listening on
> > UDP port 5503. When a properly crafted packet is received by
> > this process it will connect back with a system shell.
> >
> > Danger:
> >
> > Very often viri are not seen as a real security threat for
> > UNIX. A virus can not infect binaries where the userID it is
> > running under has no write access to. Even under this
> > situation viri can be a threat for UNIX based operating-
> > systems: Everytime a infected binary is run it will infect
> > all binaries in the current working directory. It is not
> > unthinkeble that a user with increased privileges will later
> > run a binary infected by the RST. In this way the virus can
> > transparently spread itself over the system. This is
> > especially the case in production environments of in an
> > environment where many users share files. This process will
> > get into a rapid once the /bin binaries are infected. Every
> > execution of normal system commands like 'ls' will infect all
> > binaries in the current working directory. In spite of the
> > theoretical immunity UNIX has is the situation described here
> > not unlikely to happen in many human situations. The backdoor
> > process can give unpriviledged people access to your system
> > under the UserID the backdoor process is running. Attackers
> > can attempt to get higher privileges on the system from there.
> >
> > Origin:
> >
> > RST was developed by us as a research project and intended
> > only for internal
> > use on our systems. Our goal was to analyse how a
> > non-priviledged virus could affect a system running Linux in
> > a normal work-environment. Things however didnt go as they
> > were intended to go. An infected binary accidentely leaked
> > out our research lab and came into the hands of so called
> > "scriptkiddies". They infected their own systems and other
> > systems where they had access to. From this point the virus
> > seemed to spread in the wild. This should never have happened
> > and we truely apologize that it did.
> >
> > Our main concern now is that the spread of this virus gets
> > stopped and that al the infected hosts get cleaned as soon as
> > possible. As of now the format of the specially crafted
> > packet send to the listening backdoor process is unknown to
> > the public. But this might eventually get reverse engineered
> > in the future and RST can then be actively abused by other people.
> >
> > Solution:
> >
> > We have created a set of utilities which can recursively
> > detect and remove the virus from the system. It also has the
> > option to make binaries IMMUNE for future infection by the
> > RST. We put our best effort in making these utilities as easy
> > to use as possible. And we STRONGLY RECOMMEND that you run
> > these to see if you are infected and to remove the RST from
> > all the infected binaries. We especially recommend that
> > multiuser systems make their system immune for the RST as the
> > risks for these systems are much higher. Immunisation works
> > by increasing the size of
> > the text segment by 4096 bytes so that the "hole" between the
> > text and data segments is gone. After this there's no space
> > for the RST to add it self to the binary anymore.
> >
> > The interface to these programs is simple and
> > self-explanating. The user can
> > decide wether he wants to automatically detect and remove the
> > RST on the system recursively or if he wants to apply the
> > remover on a per binary base. In this mode he can also get a
> > individual status report on wheter this binary is infected,
> > immune or innocent. Sample usage would be:
> >
> > % perl Recurse.pl remove
> >
> > For more information regarding this read the included documentation.
> >
> > Conclusion:
> >
> > Again we strongly recommand that anybody running Linux runs
> > the detector to see if their system is infected. Even if they
> > do not expect anything, they can always optionally immunise
> > their system. This is the only way we can fight the further
> > spread of this virus. Again we apologise for all the
> > inconvenience this may have caused. But maybe we can see it
> > as a lesson that Linux and UNIX are not immune for viri.
> >
> > Regards,
> > - anonymous
> >
>
>
 John Stauffacher
 Network Administrator
 Chapman University
 stauffacher@chapman.edu

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com

Relevant Pages

  • Remote Shell Trojan: Threat, Origin and the Solution
    ... At the 5th of September Qualys released a Security Warning regarding a Linux ... This virus was called the "Remote Shell Trojan" (RST) and it ... infect all binaries in /bin and the current working directory. ...
    (Incidents)
  • Remote Shell Trojan: Threat, Origin and the Solution
    ... At the 5th of September Qualys released a Security Warning regarding a Linux ... This virus was called the "Remote Shell Trojan" (RST) and it ... infect all binaries in /bin and the current working directory. ...
    (Bugtraq)
  • Re: virus/worm hacker attack
    ... This virus was called the "Remote Shell Trojan" ... infect all binaries in /bin and the current working directory. ... privileges will later run a binary infected by the RST. ...
    (comp.os.linux.security)
  • Re: Transfer of virus
    ... A virus must be executed to function. ... This execution can ... for example) to infect a system. ... A virus can be contained in ANY type of file, but it can't infect or spread ...
    (microsoft.public.security.virus)
  • Re: brute force ssh attack
    ... it's like a virus which can only be spread by ... For a virus to be viable it has to be able to infect files in such a way ...
    (Fedora)