On Mon, 4 Mar 2002 quentynat_private wrote: > Date: Mon, 04 Mar 2002 12:15:34 +0000 > From: quentynat_private > To: "incidentsat_private" <incidentsat_private> > 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 adminat_private ---------------------------------------------------------------------------- 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
This archive was generated by hypermail 2b30 : Tue Mar 05 2002 - 08:38:34 PST