RST.b

[Ryan Russell <ryan () securityfocus com>]

Recently, lockdown mailed me with an analysis he had done of a Linux virus,
which I'm calling "RST.b".  Subscribers to the list may recall someone
claiming to be the author of the original RST posting here:
http://securityfocus.com/archive/75/213221

As part of my job for SecurityFocus working on the commercial portion
of the ARIS project, I have also performed an analysis and disassembly,
in order to verify lockdown's information.  SecurityFocus wishes to
make sure the general security community is aware of this issue, so
we are providing some information here.

Below is lockdown's analysis, minus the disassembly (removed strictly
due to size.)  He has given me permission to post it here.  His analysis
is fairly complete, and I can confirm his findings.  A couple of notes to
add: Contrary to what his first paragraph implies, there IS a backdoor,
as he later explains.  The /dev/hdx1 and /dev/hdx2 files act as semaphores,
allowing only one listening process per interface at a time.  The virus
tries to listen both on ppp0 and eth0, in promiscuous mode.

I contacted the people who host the Web server in question, and
didn't get much of a response.  I indicated that they might have
an intruder on their server reading their web logs, and asked if
they would be willing to provide copies of relevent log entries,
or at least a count of how many apparant victims there were.
The response I got indicated that "his account was terminated a
few weeks ago."  I received no response to a later request for
clarification.

                                        Ryan

---------------------------------------------------------------------

BASIC INFO
First I would like to thank lamagra, Cyphernaut and zen-parse for all their
help.  While messing around on a wargame box I found what I thought to be a
backdoor but after talking to silvio I found out it was a virus.  No wonder
I could not find the backdoor code, I was looking in the wrong places.  We
have been unable to determine exactly what spread it to this box but likely
the culprit is some exploit being passed around, possible a ssh one.  This
virus appears to be very similar to the RST
virus(http://www.securiteam.com/unixfocus/5MP022K5GE.html
http://www.qualys.com/alert/remoteshell.html).  Those alerts are not very
detailed but this virus seems to differ because the IP address the GET
request is sent to is not the same and it uses EGP(exterior gateway
protocol) for the backdoor instead of UDP.  The virus infects binary files
in the ELF format and the code only works on Linux.  To detect this virus
look for the existence of /dev/hdx, /dev/hdx1, or /dev/hdx2, that would be a
sign the virus has achieved root.  If you pull strings on /bin/ls and see
one of the following strings: GET /~telcom69/gov.php, snortdos, tory,
/dev/hdx, or xxxxyyyyzzzz then the virus would appear to have achieved root
as well.

ATTACHED
Attached to this email should be a plain text file and it contains the
disassemble of the virus.  I used gdb to get the assemble code and as I read
through it I added comments.  If I ever do something like this again I
promise I will format it differently because that is not pretty.  My
knowledge of assembly is pretty weak so do not be surprised to see errors.

ANALYSIS
This virus replaces the start address in the ELF headers with an address
that points to it's code.  So when an infected program is run it is
redericted to the virus code.  First thing that happens is it forks and the
parent goes off to the real start address and runs the normal code while the
child takes care of the evil stuff.  First thing the child does is call
ptrace to see if it is being traced, if it is being traced it exits.  This
is easy to get around though, open up the file in a hex editor and change
the int 80 to NOP NOP which prevents ptrace from being called.  That did not
do me much good because gdb did not want to follow the fork so I was left
wading through all the assemble code.  After it makes sure it is not being
traced it opens up the current directory and tries to infect the files
there.  After that is done it changes directories to /bin and attempts to
infect the files there as well.  Then it opens up /dev/hdx1 and /dev/hdx2
and calls mknod followed by fcntl().  Cyphernaut suggests the reasoning
behind this is to see if the virus has obtained root on the box, if so then
it exits.  Continuing on it makes a call to socket with the protocol set to
EGP, we'll come back to this later.  Next a socket call is made for TCP with
the IP set to 207.66.155.21 and port to 80.  The following GET request is
sent to the server: GET /~telcom69/gov.php HTTP/1.0\r\n\r\n.  gov.php does
not seem to exist on the server but that does not matter, the reason for
doing this is probably to get the IP's of infected machines.   The file
descriptor returned by the socket call is closed and it returns.  Read is
then called on a file descriptor which I believe to be the one returned by
the socket call with the protocol set to EGP.  It would appear 23 bytes into
what has been read it checks the data for the value 17.  If this does not
match then it returns and continues to read.  If it matches then it appears
to check to see if a string 42 bytes into the data read matches a hard coded
string which acts as a password.  If this does not match it returns and
continues to read.  If it does match it then checks the input for a 1 or 2.
 If a 1 is given it forks and executes /bin/sh -c <command read in> and then
exits.  If a 2 is given then a UDP packet is sent back containing the
password.  First thought was that this was put here for debugging purposes
but then it dawned on me that this might be here so they can scan the net
for infected hosts.  Not only do we have a virus spreading it is opening up
the infected boxes to attackers.  It should be noted that on the infected
box this was found on their was no sign of this remote backdoor.  A possible
explanation for this is if the box was rebooted after it obtained root then
/dev/hdx1 and 2 would exist preventing the code from launching the backdoor.

lockdown
(www.lockeddown.net) down at the moment


----------------------------------------------------------------------------
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