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_at_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
>> 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 root_at_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_at_jammed.com>
Received on Nov 07 2000
Intro
