site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Uniqs:
390
Share Topic
Posting?
Post a:
Post a:
Links: ·Forum FAQ ·Attitude Adjustment ·Linux docs ·DistroWatch ·OPLM
AuthorAll Replies


Rocktagon
Slightly Bent
Premium
join:2000-11-04
Chattaroy, WA

Remote Shell Trojan: Threat, Origin and Solution

kill_rst.zip 5,771 bytes
(kill_rst.tgz)
I put this in the 'Security' forum also for maximum exposure.
quote:
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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (»www.grisoft.com).
Version: 6.0.277 / Virus Database: 146 - Release Date: 9/5/01


--
The ALIENS are coming! Help DSLR SETI@Home Club make contact before Team Anandtech so we can win the challenge.


Smitedogg
Uzbekikitty
Premium
join:2000-11-11
Pueblo, CO

quote:
Regards,
- anonymous
Hmm, that's never a good sign, I'd like to look into it more before I put that in (No slight to you intended, that's very good information). Can you give me their URL?

Dogg
--
Failure is not an option. It comes standard with every Windows installation


Rocktagon
Slightly Bent
Premium
join:2000-11-04
Chattaroy, WA

The information I posted was submitted to BugTraq.
The Qualys site has more details.

quote:
"While no system is perfectly secure, we believe that open source technologies provide the necessary transparency to better protect against security vulnerabilities, especially those related to downloading software from the Internet" said Michael Tiemann, Chief Technology Officer of Red Hat Linux. "We applaud Qualys for delivering these tools as open source software to provide users with a trustable fix to this new security threat.

--
The ALIENS are coming! Help DSLR SETI@Home Club make contact before Team Anandtech so we can win the challenge.


Smitedogg
Uzbekikitty
Premium
join:2000-11-11
Pueblo, CO

Great, I feel a lot better now! Thanks for reporting this Rocktagon!

Dogg



Triskelios

join:2001-09-09

reply to Rocktagon
Virii like this will no doubt become more common as people find more ways to infect binaries, even after RST has died down.
The rule of preventing infection is just going to be the Windows tradition of not running binaries unless you can absolutely trust their source (or in my case, unless I built it myself). A possibly safe (but not very practical) way to work around this is to distribute what would have been an ELF binary as object files and have the end user link them...



anonie

@home.com

reply to Rocktagon
Not much to worry about, just making more out of this than necessary:

1. Found out that it will only affect machines with no 0 in its IP.

2. The user has to actually launch the e-mail attachment.

3. Attachment has to be run as root to have any real affect.

The company that found it made a bigger deal out of something that really isn't too much of a problem.



Wildcatboy
Invisible
Premium,Mod
join:2000-10-30
Toronto, ON
kudos:2
Host:
Security Product V..
Security

reply to Rocktagon

Actually, it is a real threat because of the modifications that can be made to it to make it more effective. However, This was posted on the Bugtraq on Sunday, I'd give it some time before I actually ran the so called fix provided by the anonymous author unless of course you are experienced enough to check it out and know what it exactly does to your system. Chances are In a day or two the file will be dissected by a few people on Bugtraq.



Triskelios

join:2001-09-09

said by Wildcatboy:

However, This was posted on the Bugtraq on Sunday, I'd give it some time before I actually ran the so called fix provided by the anonymous author unless of course you are experienced enough to check it out and know what it exactly does to your system.
I just checked the kill.c included with kill_rst/die_rst and its functions seem to do exactly what their comments say, and just remove or prevent infections in ELF binaries.
Aside from possible problems if a write error occurs for some reason (when attempting to modify a damaged binary?), this appears to be a trustworthy and reliable fix.


Triskelios

join:2001-09-09

reply to Wildcatboy

said by Wildcatboy:

However, This was posted on the Bugtraq on Sunday, I'd give it some time before I actually ran the so called fix provided by the anonymous author unless of course you are experienced enough to check it out and know what it exactly does to your system.
I just checked the kill.c included with kill_rst/die_rst and its functions seem to do exactly what their comments say, and just remove or prevent infections in ELF binaries.
Aside from possible problems if a write error occurs for some reason (when attempting to modify a damaged binary?), this appears to be a trustworthy and reliable fix.


Triskelios

join:2001-09-09

reply to Rocktagon

Oops

Oops, excuse me for the double post. My ISP's routers were being sluggish and I didn't realise that the first one had got through (server wasn't responding and it wasn't listed after I checked the site again), so I posted it again...


Kesh

@telia.com

reply to Triskelios

Re: Remote Shell Trojan: Threat, Origin and Solution

Yes, it moves the code segment up. But it's just as easily moved back again by a new virus And the use of profanity in the source code would prevent most, except the truly clueless, to compile and run it.

Smells like social engineering, in my nostrils. Only viable long term solution would be for the compiler to minimize the binary holes.

But what we really should get, is a sample of the actual virus to examine if it indeed uses the code - data gap.

Yawn. Low risk. Now and in the future...

Wednesday, 19-Jun 14:45:07 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 13.5 years online © 1999-2013 dslreports.com.
Most commented news this week
Hot Topics