Attack pathology
*Hobbit* (hobbit@avian.org)
Tue, 28 Mar 1995 00:54:33 -0500
A while back I was having a discussion about Pingware with someone, and we
arranged for a run of it against my own firewall just to see how hard it would
try, and how well I'd resist. About two weeks passed, and then a few days ago
the test finally happened. Here is the meat of what showed up in my logs, with
some annotations. The person has asked not to be identified, so I have changed
the attacking address to a random RFC1597 one and her name to Jacko.
A very brief look at Pingware at a recent trade show revealed almost identical
architecture to many cracker scripts collected from sites under attack. This
isn't all that surprising, since it's based on attacks they've observed and
tracked, but I would have thought the eminently capable folks at Bellcore would
have turned it all into a more efficient program. The equivalent C code to
do "showmount -e $target & ; pid=$! ; sleep 3 ; kill $pid" isn't rocket
science, after all, and burns an order of magnitude less CPU.
I am surmising that we begin with the Pingware run, since this logging looks
different from the second wave which is clearly an ISS run. The first test
probably was going to be a writeable-directory check; the packet sucker trigger
bytes must have confused it. Note that the only reason this connection was
refused is because Jacko came from an unregistered host. Normally, FTP
connections to here are allowed.
Mar 23 17:13:29 avian pubftp: refused connect from 172.20.133.6:1033
Mar 23 17:13:33 avian pubftp: sucked 3: ^?|$
Mar 23 17:13:35 avian pubftp: sucked 9: ^?|'SYST^M^J
Mar 23 17:14:20 avian pubftp: sucked 16: user anonymous^M^J
Now it gets interesting -- attempts to grab files via TFTP. Still pretty
standard stuff.
Mar 23 17:13:58 avian tftp?: refused connect from 172.20.133.6:1040
Mar 23 17:13:58 avian tftp?: sUcked 23: ^@^A/etc/passwd^@netascii^@
Mar 23 17:14:04 avian tftp?: refused connect from 172.20.133.6:1040
Mar 23 17:14:04 avian tftp?: sUcked 28: ^@^A/etc/hosts.equiv^@netascii^@
Mar 23 17:14:10 avian tftp?: refused connect from 172.20.133.6:1040
Mar 23 17:14:10 avian tftp?: sUcked 25: ^@^A/etc/services^@netascii^@
Mar 23 17:14:16 avian tftp?: refused connect from 172.20.133.6:1040
Mar 23 17:14:16 avian tftp?: sUcked 20: ^@^A/.rhosts^@netascii^@
And as expected, various RPC probes. The logging in this case doesn't try
to be smart about the portmap request, but given that these are UDP probes
[distinguishable by the capital "U" in sUcked], I initially suspect that it's
"showmount -e avian.org". I later prove that it is *something* to do with
mountd by comparing this against a packet dump, and note that the string
"^@^A^F%" corresponds to where the RPC program number is in the packet, with
the high bits stripped off. Sure enough, mountd is program number 100005, or
hex 00 01 86 A5 in network order, which becomes 00 01 06 25 here and forms the
above string.
Mar 23 17:14:37 avian sUnrpc?: refused connect from 172.20.133.6:937
Mar 23 17:14:37 avian sUnrpc?: sUcked 56: /x<^P^@^@^@^B^@^A^F ^@^@^@^B^@^@^@^C^@^@^@^A^F%^@^@^@^A^@^@^@^F^@^@^@
Mar 23 17:14:43 avian sUnrpc?: refused connect from 172.20.133.6:937
Mar 23 17:14:43 avian sUnrpc?: sUcked 56: /x<^P^@^@^@^B^@^A^F ^@^@^@^B^@^@^@^C^@^@^@^A^F%^@^@^@^A^@^@^@^F^@^@^@
Good thing I'm not running X on the firewall, eh?
Mar 23 17:14:52 avian X?: refused connect from 172.20.133.6:1036
Mar 23 17:14:53 avian X?: sucked 12: B^@^@^K^@^@^@
Mar 23 17:14:57 avian X?: sucked 12: B^@^@^K^@^@^@
A less persistent rlogin check than Fred Cohen's scanning service, but still
worthwhile. The syntax here is "remote-user^@local-user^@..." -- note that
Pingware [or whatever] got this slightly *WRONG* for testing the -froot bug,
and is using "-l" for the local username on her end! Probably not that it
matters if -froot had any prayer of working anyway.
Mar 23 17:14:58 avian rlogind?: refused connect from 172.20.133.6:1023
Mar 23 17:14:59 avian rlogind?: sucked 20: ^@bin^@bin^@ansi/38400^@
Mar 23 17:15:00 avian rlogind?: sucked 22: ^@-l^@-froot^@ansi/38400^@
This seemed to be a dividing point in between the tests, given the lag time.
Unfortunately I'd forgotten the specifics of my conversation with Jacko, and
failed to pay attention to the proposed "attack date" of March 23. Thus, I had
expected all this to happen a week before it did, and she was doing it all
from an unknown host, so I thought it was a REAL ATTACK!! To find out more
about it, I winged a few port scans, ICMP fakeouts, and other nasties at her
but she was still there.
So by this point I had found and mounted up one of *her* NFS filesystems was
ripping through it with L5 when the next batch of probes came in. By now,
Jacko might have just trying to manually telnet here to try and find out why my
machine was all of a sudden probing the crap out of *her* machine. In any case,
her telnet doesn't handle environment variables, or else I probably would have
gotten her username here...
Mar 23 17:42:11 avian telnet?: refused connect from 172.20.133.6:1072
Mar 23 17:42:12 avian telnet?: sucked 1: ^@
Mar 23 17:42:13 avian telnet?: sucked 3: ^?|$
Mar 23 17:42:17 avian telnet?: sucked 3: ^?|'
Now what appears to be an ISS run starts, first with "rpcinfo -p" --
distinguishable by the capital "S", for "stream", i.e. a TCP connection to
portmap. Again, dumb logging, but staring at this and a packet dump is enough
to figure out what it was trying to do. The ^D near the end does indeed
correspond to 4, or PMAPPROC_DUMP.
Mar 23 17:42:21 avian Sunrpc?: refused connect from 172.20.133.6:632
Mar 23 17:42:22 avian Sunrpc?: sucked 44: ^@^@^@(/qX<^@^@^@^B^@^A^F ^@^@^@^B^@^@^@^D^@^@^@
Standard Sendmail checks. You wouldn't have gotten "Wasn't a telnet" unless
you were running the "telnet detection" code I hacked into Sendmail.
Mar 23 17:43:29 avian sendmail: Wasn't a telnet?
Mar 23 17:43:33 avian sendmail: [172.20.133.6]: VRFY decode
Mar 23 17:43:33 avian sendmail: [172.20.133.6]: VRFY bbs
Mar 23 17:43:33 avian sendmail: [172.20.133.6]: VRFY lp
Mar 23 17:43:33 avian sendmail: [172.20.133.6]: VRFY uudecode
Mar 23 17:43:33 avian sendmail: "wiz" command from [172.20.133.6] (172.20.133.6)
Mar 23 17:43:33 avian sendmail: "debug" command from [172.20.133.6] (172.20.133.6)
And here's my big hint that it's an ISS run...
Mar 23 17:43:34 avian pubftp: refused connect from 172.20.133.6:1075
Mar 23 17:43:38 avian pubftp: sucked 64: user anonymous^Jpass -iss@iss.iss.iss^Jpwd^Jmkd test^Jrmd test^JQUIT^J
At this point, her machine dropped off the net, possibly in response to the
overambitious back-testing I was doing. Oops!! Since I'd made the mistake of
mounting her mountable filesystem the default way, i.e. "hard", *my* machine
was now wedged whenever it tried to do anything like search through the
root filesystem, and *I* had to reboot! So it goes...
Notable tests that were NOT done: password guessing through ftpd or rexec,
rexd, YP, direct NFS probing, finger or rusers, portmap proxy calls, and
probably several other things I'm forgetting offhand [and that SATAN won't
cover either]. A grope through the raw packet log indicates that no tests
were done against any ports I didn't have alarmed.
FYI, the packet suckers used here are some simple mods to Wietse's latest
"tcpd", available here in /src/fixkits/tw72.fix. Being able to log this stuff
is damn handy, and I highly recommend using *something* that can do it.
Wietse's replacement portmap/rpcbind is much smarter about RPC logging, but
since a *firewall* doesn't need to run a real portmap at all, I just hung
tcpd off it as an alarm. And now I even know how to interpret the results.
_H*