Re: increase in ftp scanning

[<admin () dnsppp net>]

On Mon, 4 Mar 2002 quentyn () fotango com wrote:
> Date: Mon, 04 Mar 2002 12:15:34 +0000
> From: quentyn () fotango com
> To: "incidents () securityfocus com" <incidents () securityfocus com>
> Subject: increase in ftp scanning
>
> Has any one else notice a huge increase in ftp scanning over the last
> few weeks ( esp the last 2)

Yes.  And we have one box that has responded to the scanning in
a not-so-good way.  I'll lay out the facts as we have them, but
will draw no conclusions.  

1. The box is running the latest wu-ftpd 
   (vers.c: Version wu-2.6.2(1) Tue Dec 18 00:59:26 EST 2001)
   and is set up for anonymous-only access with a limit of
   three remote logins in /etc/ftpaccess.

2. The usual spate of multiple, simultaneous fast anonymous logins
   causes ftp to respawn too quickly, causing inetd to remove
   it from its list, closing the tcp 21 server socket.

   The multiple logins occur within on or two seconds and look like:

   wu.ftpd[21733]: connect from [n+V74VB+bdfLzvtBRVkeumF8YT83goZf]@159.218.61.181
   wu.ftpd[21732]: connect from [YDY7fD+aVNtrisWNUC3ZciPsvkiMfc4e]@159.218.61.181
   wu.ftpd[21727]: connect from [vzTixt7F2blOmPsmbF5nsbrtZrOFDFSN]@159.218.61.181
   ... 24 similar lines deleted for brevity ...

All would be well if the scenario stopped there, but it gets weird after this.
Ordinarily, with inetd removing ftp from the game, tcp port 21 would no longer 
exist as a server socket.  But in this case, three minutes after inetd gives
up on ftp, tcp port 21 server socket returns.  *And* two new tcp server sockets 
are present as well:

$ netstat -tan | fgrep 1397
tcp        0      0 0.0.0.0:13977           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:13978           0.0.0.0:*               LISTEN 

$ lsof | fgrep -e 1397 -e USER
COMMAND     PID   USER   FD   TYPE     DEVICE   SIZE/OFF     NODE NAME
inetd       133   root    6u  inet 0x0172b414        0t0      TCP *:13977 (LISTEN)
inetd       133   root   13u  inet 0x025a2414        0t0      TCP *:13978 (LISTEN)

After the attack, inetd is still running with its original PID and is now
servicing two new ports.  Connecting to port 13977 doesn't seem to do anything.  
However connecting to 13978 causes inetd to make a call to auth (tcp 113) and 
after a couple of carriage returns, spits back 'Unexpected proxy opcode'.

lsof of the compromised inetd looks like:

COMMAND     PID   USER   FD   TYPE     DEVICE   SIZE/OFF NODE NAME
inetd       133   root  cwd    DIR        8,4       1024        2 /
inetd       133   root  rtd    DIR        8,4       1024        2 /
inetd       133   root  mem    REG       8,18      17048   143450 /usr (/dev/sdb2)
inetd       133   root  mem    REG        8,4      79508    71767 / (/dev/sda4)
inetd       133   root  mem    REG        8,4     614840   139270 /lib/libc.so.5.4.46
inetd       133   root    0u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    1u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    2u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    3u  inet 0x006c4018 0xd15567e2  TCP OBFUSCATED_ADDRESS:21->159.218.61.181:46755 (CLOSE_WAIT)
inetd       133   root    4u  inet 0x00f08018        0t0  TCP *:37 (LISTEN)
inetd       133   root    6u  inet 0x0172b414        0t0  TCP *:13977 (LISTEN)
inetd       133   root    7u  inet 0x00f08c0c        0t0  TCP *:23 (LISTEN)
inetd       133   root    8u  inet 0x003fe018        0t0  TCP *:110 (LISTEN)
inetd       133   root   11u  inet 0x003fec0c        0t0  TCP *:143 (LISTEN)
inetd       133   root   13u  inet 0x025a2414        0t0  TCP *:13978 (LISTEN)
inetd       133   root   14u  inet 0x034a6414        0t0  TCP *:21 (LISTEN)  

lsof of the normal inetd looks like:

$ lsof | fgrep inetd
inetd       133   root  cwd    DIR        8,4       1024        2 /
inetd       133   root  rtd    DIR        8,4       1024        2 /
inetd       133   root  mem    REG       8,18      17048   143450 /usr (/dev/sdb2)
inetd       133   root  mem    REG        8,4      79508    71767 / (/dev/sda4)
inetd       133   root  mem    REG        8,4     614840   139270 /lib/libc.so.5.4.46
inetd       133   root    0u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    1u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    2u   CHR        1,3        0t0    69748 /dev/null
inetd       133   root    4u  inet 0x03b32018        0t0      TCP *:time (LISTEN)
inetd       133   root    5u  inet 0x03b32414        0t0      UDP *:time
inetd       133   root    6u  inet 0x02760018        0t0      TCP *:ftp (LISTEN)
inetd       133   root    7u  inet 0x03b32c0c        0t0      TCP *:telnet (LISTEN)
inetd       133   root    8u  inet 0x03b30018        0t0      TCP *:pop3 (LISTEN)
inetd       133   root    9u  inet 0x03b30414        0t0      UDP *:tftp
inetd       133   root   10u  inet 0x03b30810        0t0      UDP *:bootps
inetd       133   root   11u  inet 0x03b30c0c        0t0      TCP *:imap2 (LISTEN)
inetd       133   root   12u  unix 0x0170b414        0t0   932032 ->0x0170bc0c     

(And no, none of the 'bad' services listed above are not exposed to the 
outside world.)

tcpdump against the two new ports reveals no traffic outside of our own
probing.  Snort showed nothing unusual at the time of the attack (if in fact, 
it was an "attack").  Maybe it's just a bad combination of inetd and wu-ftpd, 
or perhaps a broken inetd, but the two extra sockets are troubling.  Even more 
troubling is the proxy opcode message.

This particular box has a complet, well-known signature (MD5's, processes, 
directories, files, links, attributes, /dev, ports, modules, logs, you-name-it) 
and other than inetd adding the two ports, the system has not been tampered with.

This has occurred twice in the last two weeks and an extensive look around
the usual places out on the net has not helped us identify what's going on.
We've tried running the various wu-ftpd exploits (bobek, ftp-pass, ftpbug,
ftpwarez, wh0a, wu-ftpd-exp, wu-ftpd-v2, wu-ftpd26, wuXploit, wuftpd-god,
wuftpd-sdump, wuftpd2600) against our own box but have been unable to create
the problem on our own.

For now, wu-ftpd is disabled.  We like scp better anyway.  :)

Comments?  Thanks in advance.

Niles Mills
admin () dnsppp net



----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com