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
This archive was generated by hypermail 2b30 : Fri Dec 28 2001 - 08:30:32 PST