Security Incidents mailing list archives
Re: Network Scan - sunrpc
From: Guillaume Filion <gfk () LOGIDAC COM>
Date: Sat, 4 Nov 2000 16:33:02 -0500
Hi, I received the same probe, looks like this is a very popular scanning tool: Nov 3 22:26:52 cesam kernel: Packet log: input REJECT eth1 PROTO=6 24.200.yy.yy:10101 24.201.xx.xx:111 L=40 S=0x00 I=61434 F=0x0000 T=251 SYN (#51) I've send a message to abuse () videotron ca and usually, they're very prompt to respond. Best, GFK's At 12:47 -0800 31/10/00, James W. Abendschan wrote:
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 sunrpcYup. 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 root () rapier 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. <jwa () jammed com>
Current thread:
- Network Scan - sunrpc Abe Getchell (Nov 01)
- Re: Network Scan - sunrpc James W. Abendschan (Nov 02)
- Re: Network Scan - sunrpc Guillaume Filion (Nov 06)
- Re: Network Scan - sunrpc James W. Abendschan (Nov 02)