OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Network Scan - sunrpc
From: James W. Abendschan (jwaJAMMED.COM)
Date: Tue Oct 31 2000 - 14:47:56 CST

On Mon, 30 Oct 2000, Abe Getchell wrote:
> Hello all,
> A _huge_ scan was performed on our network this weekend from
> 129.62.1.75 (graduate-etd.baylor.edu) looking for anything with sunrpc open.
> Has anyone noticed anything similar from this IP address before?
>
> 462816 28Oct2000 11:11:11 AM drop tcp 129.62.1.75 10101 xxx.xxx.xxx.xxx
> sunrpc

Yup. Here's a slightly modified writeup I sent to CERT:

On September 26th, 2000, two of the RH 6.2 Linux machines where I work
were broken into. The intruder apparently exploited a known bug in rpc.statd
(unpatched on these two boxes, naturally.)

One of these boxes was being used to probe machines. These probes
were sent to port 111/tcp and had a local port # of
10101/tcp. Interestingly, these probes were used to determine the
remote host OS, not enumerate RPC services.

The initial overflow attack came around 13:02 PDT from from 216.253.64.100.
As near as I can reconstruct, the sequence of events was as follows:

 * a overflow bug in the rpc.statd service was exploited to get remote root
 * a backdoor (/usr/bin/in.sys) was installed & started out of /etc/inittab.
   It's a modified telnetd that listens on port 36333 and executes a modified
   /bin/login (/usr/bin/loet). Presumably the modified login lets someone log
   in as any user with a magic password.
 * a loadable kernel module was copied over (/lib/modules/.spx274.o),
   along with a /etc/rc.d/rc.modules file. The rc.modules file
   loads (insmod) the .spx274.o module, and then executes
   /var/db/.spx274/spx274check. This program reads /var/db/.spx274/spx274back
   (likely the and the lkm's config file) and communicates with the module
   via a system call. The kernel module itself appears to be "stealth"
   lkm that attempts to hide files and processes. strings on the
   module shows things like:

    jinke
    Disabling CPUID Serial number...
    done.
    -> %s %s/%i
    spx274
    newKill()
    -> oldKill()...
    -> Got invisible signal...
    -> Returning -ESRCH...
    -> Returning -EPERM...
    -> Cloaking...
    -> Decloaking...
    -> Got execdeny signal...

 * a sshd executable (/var/db/.spx274/spx274bd) and a config file
   (/var/db/.spx274/samba.conf). This sshd binds to port 33663
   and presumably has a magic password granting root access over the
   encrypted session.
 * a ssh_random_seed file and a ssh_host_key file. The host key was
   apparently generated by rootrapier.aerohead.com.

All this looks like the result of an automated script; if the timestamps
on the files are to be believed, it was installed after the statd exploit
in under 30 seconds.

On October 12th at around 10:49 PDT, a connection was made from 12.72.34.126
(126.phoenix-06-07rs.az.dial-access.att.net) to the compromised box
on port 36333 (the "in.sys" backdoor). The intruder created a
"/var/tmp/.s" directory. This directory contained a "ss" executable and a
"results" file; the ss program was scanning the 208/8 network and recording
the host OS in the "results" file (16390 hosts scanned; up to 208.44).
The attacker probably would use this to grep for other linux machines
to attack.

Shortly afterwards, I noticed the scanning activity from the box.
At the same time, complaints started coming in and I took the box
offline. Two things struck me as interesting about this:

  1) They were scanning for host OS's only, not specific services.
  2) the ssh_host_key might suggest that the intruder owns (literally
     or figuratively) rapier.aerohead.com.

James 

--
a cookie is just a cookie, but a newton is fruit and cake.   <jwajammed.com>