Trojan Warning

 
Good day, all. This is a report about a backdoor tool that was recently found on some of our RedHat 4.x Linux boxes. I have incomplete information about it, but it seemed dangerous enough that a warning seemed in order. This report will provide information on detecting whether your system has this tool installed, removing it once it's installed, and protecting against it.

Quick summary:
A trojan binary, /sbin/initd, was found on some of our systems. It allows a remote user to connect and run arbitrary commmands with root privileges without authentication. It allows an attacker to connect to a large number of machines simultaneously and execute destructive commands with ease.

Symptoms:

     
  • A new libc5 binary, /sbin/initd (note; _not_ the standard /sbin/init which is needed for standard system operation), was installed on the systems and set to a mode that makes it impossible to delete by a normal user; the chattr command was needed to remove the immutable and append-only attributes.
  • Two copies of this command were running in the background, one listening on port 65534/tcp, the other on port 1049/tcp. Neither port is listed in our database of commonly used exploit ports.
  • It listens on those ports for remote requests and performs them on the local machine. It requires the remote client to enter a password (embedded in the binary) then will execute any additional commands.
  • The contents of the binary were not terribly explicit in their function, but did reveal that one of their jobs is to kill off the syslog binary. This technique, common in hack attempts, makes it impossible to track the attackers actions.
  • /etc/rc.d/rc.local was modified to start up /sbin/initd and /sbin/quotad at boot time; the latter was not found on the systems at all and did not appear to have been recently deleted from them.
  • The machines did _not_ appear to be running any password sniffers of their own.
  • We did not find any other obvious damage to the systems.
How do I know if I'm attacked?:
Unfortunately, the following steps may not detect this, or any other, backdoor as the details I'll present are relatively easy to change. However, it's a starting point:
     
  • See if you have a program listening on ports 65534/tcp or 1049/tcp. Try (all commands to be typed are in bold ): netstat -an | less

    • If you see 'tcp 0 0 0.0.0.0:1049' or 'tcp 0 0 0.0.0.0:65534', this tool may be running on your system. Look down through this list of ports running servers and mentally compare them to the list of servers that should be running on this system. Are there any ports that you don't recognize? Those are worth investigating. If you have a recent version of netstat, try: netstat -anp The '-p' will display the names of the programs and their PIDs that have those ports open at the far right of the display. This can help you in identifying and/or killing any unknown programs. If you have reason to believe that your 'ps' or 'netstat' programs may have been replaced with versions that hide running programs, you may wish to get a clean copy of these tools from the   distribution media or directly inspect the directories under the /proc filesystem. An additional option is to use a tool like nmap (http://www.insecure.org/nmap/index.html) to scan the ports on the system in question. nmap can scan the entire tcp port range in 5 minutes.
  • See if your system is still logging information to the system logs:

    • cd /var/log
    ls -alrt
    The most resently modified system log will be at the bottom of the listing; if the modification time is more than a half hour or so behind the current date (use the "date" command to see what the system thinks is the current date), this is a good sign that your system logger (syslog) has been stopped.
  • Run ps ax. 

    • This command will list the running programs on your system. If any commands have a name that looks something like 'syslog.itd' or 'syslog initd', this is a very good sign that you have this tool running. This/these pid's are very good candidates for killing off. Does this listing show any other programs you don't recognize?
  • If you have identified some server ports that you think might be running this tool, telnet to them. You'll need to enter a password. To identify the password for your system, type: 

    • strings /sbin/initd | grep -A 1 '^killall' | tail -1
    I won't include the password here; if you don't have the binary on your system, you don't need it. Now, type: 
    telnet localhost 65534 or telnet localhost 1049 or substitute the port you think it might be listening on. Type the password you saw above. At this point you should be able to type commands into this telnet session and have them execute on this system. Ignore the fact that you may not see the actual commands or password echoed back to you. Try typing: 
    /bin/echo hello
    and you should see at least "hello". For reasons that are unclear, not all commands complete successfully.
  • ls -al /sbin/initd should show a 6116 byte file. 

    • Running md5sum /sbin/initd should return: b4216d1fd97ac50bbcf807174eb8950d /sbin/initd
    Keep in mind that this could easily be named something else or compiled in a different way to change its size or md5sum.
How do I get rid of it?:
The previous disclaimer applies; your system might require different commands or steps to remove the tool.
     
  • First of all, remove the binary. Type carefully; make sure you type 'initd' and not 'init' or 'inetd'.

    • cd /sbin
    chattr -ia initd
    rm -f /sbin/initd
    Now kill any running copies: killall -9 initd
    At this point, run ps axf | less again and make sure that there are no remaining 'syslogd.itd' or 'initd' tasks. Check netstat -anp | less as well to make sure that those ports are now closed. If they remain open, a reboot may be necessary to clear the connections completely.
  • Check /etc/rc.d/rc.local . Our system had the following lines: '/sbin/initd' and '/sbin/quotad'. These should be removed from that file.
  • As a side task, check /etc/passwd for additional accounts that may have been added by this attacker. If you see any accounts with no password assigned (the first and second ':' characters will have nothing between them), a remote user can telnet in without any password. Also look for lines where the number between the second and third ':' is any number equal to 0 or a multiple of 65536 (for example, '0', '00', '000', '65536'. '131072', etc.). The root account is the only one that should have a 0 or equivalent User ID (also called the UID).

    • To disable these accounts, either place an asterisk ('*') immediately after the first colon, like so:
    "someaccount:*: ..." 
    or delete the line entirely. The asterisk method is preferred. For any lines that have a '0' equivalent UID, change the number to some high unused number, such as 9999
How do I protect against it?:
     
  • Follow the standard techniques of securing your system. A good starting point for this process is the Linux Administrators Security Guide (or LASG) at http://www.securityportal.com/lasg/ .
  • Change the root and user passwords on the system once the tool has been removed and you've checked the system for damage. As the attacker has had access to all the files on your system, including /etc/passwd and /etc/shadow, the attacker may be able to use a password cracking tool to figure out some of the passwords on your system. He/she may also have _changed_ some of the passwords.
  • If you have an ipfwadm or ipchains capable system (which includes most current Linux distributions), place the following commands in /etc/rc.d/rc.local :

    •  

     
     
     

    if [ -f /proc/net/ip_fwchains ]; then
    echo Installing ipchains block against initd. >/dev/console
    ipchains -I input -p tcp -d 0/0 1049 -y -j DENY -l
    ipchains -I input -p tcp -d 0/0 65534 -y -j DENY -l
    elif [ -f /proc/net/ip_input ]; then
    echo Installing ipfwadm block against initd. >/dev/console
    /sbin/ipfwadm -I -i deny -P tcp -D 0/0 1049 -y -o
    /sbin/ipfwadm -I -i deny -P tcp -D 0/0 65534 -y -o
    else
    echo System is not ipfwadm/ipchains capable. >/dev/console
    echo Not installing initd protection. >/dev/console
    fi

    This will stop any incoming attempts to connect to either of these ports. It will protect not only the firewall machine itself, but also the machines behind it. This block may temporarily interfere with one  out of ~32000 ftp connections.

  • Consider using a tool such as snort (http://www.clark.net/~roesch/security.html) or portsentry

    • (http://www.psionic.com/abacus/portsentry/) to monitor these ports and look for other signs of attack.
Closing notes:
     
  • The information provided in this document is provided as a public service only and is not warranted to be accurate. The reader assumes all responsiblity for the use of any of its content.
  • This document may be redistributed.
  • If you would like to be notified of any updates to this document, please send an email with "initd" in the subject line to me, William Stearns wstearns@pobox.com. Please do _not_ respond to all the

    • addressees if you received this in email.
    You may wish to enlist help if you do not feel qualified to handle this breach.