Version .04 - January 6, 2000
There are a large number of variations of probes and attacks primarily directed against (presumably) SUN Solaris systems. In this chapter, we will discuss how to identify attacks that rely on access of the portmap program and that go directly to the service. Both are very common and quite dangerous as well. We will also discuss a bit about analysis of patterns in a large scale, information warfare style attack. We will ask you to look at data at a very sensitive time and try to imagine your job was to help make the call on what the world wide alert level should be. Finally we will revisit our friend nmap again, turns out a discussion of RPCs without a mention of nmap is a waste of time.
In a large number of attacks and probes, the signature is an access attempt against portmap. The first trace shown was detected using portsentry, a host based intrusion detection product with active defense. Portsentry uses an access list, the attacking computer in this case 172.20.20.1 will access TCP port 111, the expected location of portmap. Note that portsentry alerts to an attack and then in the second and third entry it reports on the action that it has taken, in this case it blocks the attacker's IP address (172.20.20.1) both with TCP Wrappers and also with the local ipchains firewall.
Active System Attack Alerts
rpcinfo -p | grep 32772
03:47:34.116255 192.168.42.6.1763 > 10.1.86.0.111: S
rpcinfo -p $1 >> $TMPFILE
From the script (running on attacker's (184.108.40.206) system
Dec 27 15:14:25 marlin rpcbind: refused connect from 172.20.20.1 to dump()
Dec 28 15:47:03 milo rpcbind: refused connect from 172.20.20.1 to dump()
Now the body of the connection, at this point a TCP connection is established and data can be passed. Defensively speaking, this is way too close for comfort for my taste. Now we will see data pushed from the prober (172.20.20.1) to the system (zappa). Note that zappa also sends data to the prober, if you don't want to keep track of the sequence numbers, the quick and dirty thing to do is look for the numbers in the parentheses (44) and so forth. This isn't just the lazy way to read traces, it can be crucial in a triage situation. Seasoned analysts in large facilities that come under attack may need to practice triage. As the attack traces come the analyst has a few seconds to evaluate them for their severity. The ones that get knocked down by the firewall are of interest in such a situation simply to know the kinds of attacks directed against your site and are just glanced at. A trace like the one we are working on may require additional consideration, the connection did get established, what happened, do we need to pull the system logs? Let's continue reading the trace together.
15:20:35.567136 172.20.20.1.856 > zappa.111: P
15:20:35.930580 172.20.20.1.856 > zappa.111: F
Before we move on to direct access of programs, did you notice the IP ID values in the body and close of the connection? Can we make any observations about our attacker? It seems reasonable that that our attacker's machine is pretty busy, because the numbers skip, zappa on the other hand seems fairly dedicated to serving the prober, perhaps this is an automated process probing a number of systems.
So far in this chapter we have been concerned with RPC attacks that use portmapper to locate the procedures they wish to attack. Attackers also go after RPC programs directly. Now we will take a look at this, starting with the classic attack signature, 32772 and moving on to some patterns that are still not understood at this time, but that certainly indicate an attack.
In the trace below, a secured portmapper detects an attempt against port 32772.
Jan 1 19:04:51 scylla tcplogd: port 32772
rpcinfo -p | grep 32772
Dec 26 09:29:43 nms1 rpcbind: refused connect
Dec 26 09:27:34 marlin rpcbind: refused connect
Twistah McLain was kind enough to email me an attack script that probes RPCs, a section of which is shown below:
In the following trace, we see there are even more variations of this directed against systems all over the world.
Dec 30 17:28:04 babble rpcbind: refused connect
"This is not a new technique. I most recently read a reference to it on page 232 of "Hacking Exposed," by Stuart McClure, Joel Scambray, and George Kurtz. (I heartily recommend this book -- http://www.hackingexposed.com) It discusses vulnerabilities in NFS. My comments are in brackets
'...never include the server's local IP address or localhost in the list of systems allowed to mount the file system. Older versions of the portmapper would allow attackers to proxy connections on behalf of the attackers. If the [attacker's] system were allowed to mount the exported file system [on a victim machine], attackers could send NFS packets to the target system's portmapper, which in return would forward the request to the localhost. This would make the request appear as if it were coming from a trusted host, and bypass any related access controls."This technique may be at work in your traces involving connections from "loopback.' "
So the bottom line, the loopback command may look odd, but once we know what it is used for, we are able to classify this a recon probe. Of course if a recon probe is successful, nine times out of ten a skilled attacker could use that information to launch a more devastating attack.
The trace below has the unset() attack we were just introduced to. In the unset() breakthrough sidebar we see that this activity can probably be attributed to reconnaissance, a showmount -e command or equivalent.
Dec 28 16:46:18 jeru rpcbind: connect
Dec 30 16:00:09 thumper portmap: connect
Dec 31 07:42:43 locust rpcbind: [ID 884469 daemon.warning]
If it help any, we stayed at green when we did this for real, heck there are a lot of attempts but most of these are being defeated by host and network perimeter devices. Here is another trace.
Dec 26 15:17:28 6E:kestrel /usr/etc/portmap:
> uname -a
Oh nmap! The intrusion analyst must know the nmap signatures when it probes RPC ports. It is so widely used that we should ask ourselves whenever we see an RPC attempt, could this be nmap?
Let's start this part of our discussion with a view from the attacker's side of the table, here is a trace run by Mary Chaddock against a Solaris 5.5.1 system. Please tune your analysis eyes to port 111, 2049, and 32776, these TCP active ports are of particular interest to us.
Starting nmap V. 2.3BETA9 by Fyodor (email@example.com, www.insecure.org/nmap/)
Interesting ports on sam.edu (192.168.8.96):
TCP Sequence Prediction: Class=random positive increments
Difficulty=39182 (Worthy challenge)
Remote operating system guess: Solaris 2.5, 2.5.1
Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds
We also see that nmap is able to fingerprint the operating system without much trouble. Now the sometimes-rpc15 does deserve some explanation, but that is coming. First though, let's do one more trace of the same machine with a UDP focus.
Starting nmap V. 2.3BETA9 by Fyodor
Remote OS guesses: HP-UX B.11.00, HP-UX 11.00,
MacOS 7.5.5 - 8.6, MacOS 8 running on an LC 475,
MacOS 8.5, Solaris 2.3 - 2.4, Solaris 2.5, 2.5.1,
Solaris 2.6 - 2.7, Solaris 2.6 - 2.7 X86,
Solaris 2.6 - 2.7 with tcp_strong_iss=0,
Solaris 2.6 - 2.7 with tcp_strong_iss=2
Nmap run completed -- 1 IP address (1 host up) scanned in 1400 seconds
This time we see 111, 2049 and 32771 as ports of interest in terms of RPCs. As nmap warned, the TCP fingerprinting is not as good when you can't to TCP! Is the nmap signature obvious on the network? Very, for one thing a port scan is big, big, big, so we will just look at a couple excerpts. In the first trace we will just take look at a small chunk of closed ports.
18:50:52.831580 waldo.edu.47862 > sam.edu.936: udp 0
Now let's move on the TCP. We aren't going to dwell on the options which as we write this do help serve as a signature for namp, but again, you can run it yourself and see what the footprint looks like on your network. We will look at two cases, one where the port is not open, the second where it is.
In this case we have a TCPdump trace of a probe by nmap to a closed port, 32771. We see two packets the active open, the SYN is set, the ISN is 2981802919. The response from sam is a reset and the ISN is incremented by one.
18:50:08.064279 waldo.edu.61345 > sam.edu.32771: S
18:50:08.238249 waldo.acu.edu.61721 > sam.acu.edu.32776: S