Linux Remote Shell Trojan: Threat, Origian and the Solution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 - -- Douglas J. Hunley ([EMAIL PROTECTED]) - Linux User #174778 Admin: http://hunley.homeip.net/Admin: http://linux.nf/ Brainbench Linux Administration Certified ~~ Now offering Linux admin services for the home user ~~ The Swedish Chef has been assimilated. Borg borg borg! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjucv0kACgkQOPP+k4ZeTm36uwCdFVUBGKergMCwTSXaMD4MWs6x Gu4AoKKqNhWe20oOV+lau6t1VfizeCT+ =sEvm -END PGP SIGNATURE- kill_rst.tgz
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
Doug I got the program it did not find any problems here. Thanks cheers -- Rick Sivernell Dallas, Texas 75287 972 306-2296 [EMAIL PROTECTED] Caldera Open Linux eWorkStation 3.1 Registered Linux User .~. / v \ /( _ )\ ^ ^ In Linux we trust! ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
Re: Linux Remote Shell Trojan: Threat, Origian and the 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 This sounds like a hoax. The utils might be the actual trojan... stayler Amen, Brother. IMMUNE binaries? Give me a break. Joel ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
On Monday 10 September 2001 22:27, Joel Hammer babbled: 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 This sounds like a hoax. The utils might be the actual trojan... except that it was on bugtraq. and it's a perl script that can be reviewed. and nobody has debunked it yet -- Douglas J. Hunley ([EMAIL PROTECTED]) - Linux User #174778 Admin: http://hunley.homeip.net/Admin: http://linux.nf/ Brainbench Linux Administration Certified ~~ Now offering Linux admin services for the home user ~~ ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
On September 10, 2001 10:54 pm, Douglas J. Hunley wrote: On Monday 10 September 2001 22:27, Joel Hammer babbled: This sounds like a hoax. The utils might be the actual trojan... except that it was on bugtraq. and it's a perl script that can be reviewed. and nobody has debunked it yet except that there isn't a single mention by CERT. -- burns ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
On Monday 10 September 2001 11:00, burns wrote:
| except that there isn't a single mention by CERT.
cert is primarily a reactive, report-after-the-fact outfit. we'd none
of us have working computers if we based our security solely on cert
advisories.
though from bugtraq:
Has any expert c programers examined the c code to see if it actually
does what the remarks say?
I am suspicious of anything that is posted anonymously no matter how
well it's documented. I
don't know C well enough to tell if the documentation is accurately
portraying what the code is
really doing.
If it's not then this a one very well crafted socially engineered
virus...
and
I'm not an expert in C or the ELF filestructure. Here is what I did:
1) Read the Recurse.pl file. It's essentially the command:
find ${directory} -type f -chmod +x -exec ${cleaner} ${options}
\{\} \;
$directory defaults to '/'
$cleaner defaults to './kill'
$options defaults to ''
Nothing to see here, move along.
2) Read the Makefile. It compiles the executable (using a potentially
compromized gcc, ld, etc.) and copies it (using a potentially
compromized cp) so that there are two versions of the executable
(./temp and ./kill). It runs ./temp on ./kill, ostensibly to
clean it, then deletes ./temp
3) Read kill.c.
When you ask it to analyze a file, kill appears to do only that-
it reads but does not write. It reads the ELF header. If the
ELF header doesn't exist or is not an executable header, it dies.
If the ELF header exists and is executable, it reads the text
segment and then the data segment. It accepts only the text
segment
with an offset from the beginning of the file of 0 (that is, the
first text segment).
It calculates the following:
padding = datasegment's virtual address - ( textsegment's address +
textsegment's size )
= amount of information between beginning of data segment
and end of text segment
psize = ( end of textsegment ) - execution entry point
= amount of information between end of textsegment
and beginning of execution
poffset = ( end of textsegment ) - psize
= ( end of textsegment ) - (end of textsegment) + execution
entry point
= execution entry point
If the padding is too large (there is too much space between the
data segment and text segment) then the file is judged to be
non-infected, and non-protected.
If the padding is not too large, and the psize is 4096 then the
trojan is declared active. If the psize is not 4096 then the
trojan is declared inactive and the file protected.
When you ask it to disinfect a file, it first analyzes the file
and makes the calculations, above. Then it alters the ELF header,
so that execution will begin with the actual program code, not
the trojan code (assuming the trojan stores the offset of the
program code at offset 1). It leaves the trojan in place, though
inactive, presumably so that the file will not become reinfected
with an active trojan. This step bothers me.
When you ask it to make an innocent file immune, it does all of
the above calculations, with one change:
poffset = end of the first textsegment in the file
Then it walks through the all of the program headers named in the
ELF header. For each one except the textsegment itself, it pushes
it forward in the file by 4096 bytes. Then it grows the
textsegment
by 4096 bytes. It updates the section header, and pushes the end
of the file out by 4096 bytes. I have some trouble with how it
does this.
4) Created an unpriveleged user account, put some executable files
in a directory owned by this user, moved the sources of this
stuff to that directory, and created a symlink from `./kill' to
'/bin/touch'. Modified the Perl script to start with '.' instead
of '/', and had it execute. This effectively executed /bin/touch
on all of the files in the directory. The Perl script appeared
to perform as advertised.
5) Copied fresh copies of an executable (GNU bash, in this case)
to the directory. Ran strace and saved the output to a file.
(the command was 'strace ./bash -c touch bleh 2 nonimmune').
Immunized the executable with `./kill 3 executable', then
ran strace again ('strace ./bash -C touch bleh 2 immune').
Checked the differences between the two strace outputs. Aside
from predictable differences (times and PIDs had changed,
of course,) the executable behaved the same as observed by
strace before and after immunization. The file before immunization
differed from the file after immunization, however (diff
reports 'Binary files original and immunized differ').
From what I can tell, this program does more or less what it claims
it does- that is, it ensures that the space between the text segment
and
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
That was the kicker for me.. On Mon, 10 Sep 2001 22:27:32 -0400, Joel Hammer wrote: 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 This sounds like a hoax. The utils might be the actual trojan... stayler Amen, Brother. IMMUNE binaries? Give me a break. Joel ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
Re: Linux Remote Shell Trojan: Threat, Origian and the Solution
That is a valid point. However, this whole Immune issue just gives me the heeby-jeebies On Mon, 10 Sep 2001 22:54:56 -0400, Douglas J. Hunley wrote: On Monday 10 September 2001 22:27, Joel Hammer babbled: 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 This sounds like a hoax. The utils might be the actual trojan... except that it was on bugtraq. and it's a perl script that can be reviewed. and nobody has debunked it yet ___ http://linux.nf -- [EMAIL PROTECTED] Archives, Subscribe, Unsubscribe, Digest, Etc -http://linux.nf/mailman/listinfo/linux-users
