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.

	- While performing the cleanups on these systems, I found evidence
of connections that were recently active.  The attacker(s) had made 
connections from 62.208.46.X and 62.206.57.X, both of which are
netblocks used by 'a-city.de'.
	The attackers are likely subscribers to a-city.de's dialup service,
which also suggests they may be from Germany.  The theory that these
machines are also hacked systems that are being used as relay points by
an attacker from another location is not likely as dialup accounts
connect and disconnect too frequently to be useful as relay points.


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 double quotes):
"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.
	- The permanent location for this alert is
http://www.necert.org/wstearns/initd-warning.txt .  Any changes will be
posted to this URL.  I would like to express thanks to the necert
organization (http://www.necert.org) for providing this space.  
	- You may wish to enlist help if you do not feel qualified to
handle this breach.

	Cheers,
	- William Stearns <wstearns@pobox.com>


V1.0	12/21/99
	- Emailed to a number of security resources.
V1.0.1	12/22/99
	- Only change: addition of the permanent URL for the document.
	- Mailed to the 'incidents' list.
V1.0.2	12/23/99
	- Fix typo: /etc/password is wrong, should be /etc/passwd