Intrusion Detection FAQ: The trouble with RPCs

Stephen Northcutt
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dec 26 09:27:41 ext portsentry[12857]: attackalert: SYN/Normal scan from
host: 172.20.20.1to TCP port: 111
Dec 26 09:27:41 ext portsentry[12857]: attackalert: Host 172.20.20.1 has
been blocked via wrappers with string: "ALL: 172.20.20.1 : DENY"
Dec 26 09:27:41 ext portsentry[12857]: attackalert: Host 172.20.20.1 has
been blocked via dropped route using command: "/sbin/ipchains -I input -s
172.20.20.1 -j DENY -l"

So what is going on here? Portmap's job is to keep track of the location of various RPC services by port. If the attacker can access portmap they can get information needed to purse an attack against a specific service. This is not hard for them, the system is designed to give out information about these services. For instance, there is a user program rcpinfo -p that dumps all the services and creates a table of the port where the are located. An example of this is given below:

rpcinfo -p | grep 32772
100024 1 udp 32772 status
100002 2 tcp 32772 rusersd
100002 3 tcp 32772 rusersd
# man rusersd

rpc.rusersd(1M) Maintenance Commands rpc.rusersd(1M)

NAME
rpc.rusersd, rusersd - network username server

SYNOPSIS
/usr/lib/netsvc/rusers/rpc.rusersd

DESCRIPTION
rpc.rusersd is a server that returns a list of users on
the host. The rpc.rusersd daemon may be started by inetd(1M)
or listen(1M).

Since various tools may be used to access portmap, some of these leave a particular signature. This trace was dumped using the -vv option to tcpdump which provides the TTL and IP ID and also the -x which provides the hex dump.

03:47:34.116255 192.168.42.6.1763 > 10.1.86.0.111: S
467400212:467400212(0) win 32120 (DF) (ttl 47, id 4282)
4500 003c 10ba 4000 2f06 b889 c0a8 2a06
1001 5600 06e3 006f 1bdb f614 0000 0000
a002 7d78 73be 0000 0204 05b4 0402 080a
0deb ad2a 0000

03:47:34.116596 192.168.42.6.1764 > 10.1.86.1.111: S
463993015:463993015(0) win 32120 (DF) (ttl 47, id 4283)
4500 003c 10bb 4000 2f06 b887 c0a8 2a06
1001 5601 06e4 006f 1ba7 f8b7 0000 0000
a002 7d78 714d 0000 0204 05b4 0402 080a
0deb ad2a 0000

The dump() program is used by rpcinfo to collect and report all the active RPC services. Christopher Misra did some analysis to prove the rcpinfo -p and dump() connection. He ran a reconnaissance attack perl script named rpcscan.sh with the line:

rpcinfo -p $1 >> $TMPFILE

The tested system was running Wietse Venema's portmap replacement, and the attacker's system was listed in /etc/hosts.deny.

From the script (running on attacker's (172.0.0.1) system
---------------------------------------------
# ./rpcscan.sh zappa
Let's find some exploitable services eh?
#

From syslog
-----------
Jan 3 15:03:59 zappa portmap[6790]: connect from 172.0.0.1 to dump(): request from
unauthorized host

So to summarize, if you detect an attempt to access dump() this can be an indicator your are being probed with an rpcinfo -p or equivalent, an example of this is shown below. Note this was collected from a system log such as /var/log/somelog, not a network log. Below are a couple examples that were collected "in the wild" during the "Y2K" watch.

Dec 27 15:14:25 marlin rpcbind: refused connect from 172.20.20.1 to dump()
Dec 27 15:14:40 marlin rpcbind: refused connect from 172.20.20.1 to dump()
Dec 27 15:14:43 marlin rpcbind: refused connect from 172.20.20.1 to dump()

And a day later, we see similar activity:

Dec 28 15:47:03 milo rpcbind: refused connect from 172.20.20.1 to dump()
Dec 28 18:51:09 milo rpcbind: refused connect from 172.20.20.3 to dump()

So then, we surmise these traces targeted at dump() are reconnaissance as opposed to a direct exploit attack. In the trace below we have the good fortune of having two views of the same event from a system log (daemon.log) and also from a network log (tcpdump). Having multiple sensor views gives us a better picture of what is happening. We open with a trace grepped from a logfile called daemon.log. This should be pretty familiar to us by now.

daemon.log:Dec 27 15:20:35 zappa
portmap[31540]: connect from 172.20.20.1 to
dump(): request from unauthorized host

Next we see the same event, logged by tcpdump. We know that you are very familiar with TCP traces at this point, but we will still break up the conversation into opening, body and close, simply because it makes for easier reading.

First the opening, we have the three way handshake complete with, SYN, SYN/ACK, Lone ACK. Please note that the port pairs here are 856 and 111, this could indicate the attacker is root (or a program running as root) on a Unix system.

15:20:35.513401 172.20.20.1.856
> zappa.111: S
1835148885:1835148
885(0) win 512 <mss 1460> (ttl 55, id 30337)
15:20:35.514378 zappa.111 > 172.20.20.1.856: S
831851235:83185123
5(0) ack 1835148886 win 33580 <mss 1460> (DF)
(ttl 60, id 5371)
15:20:35.552481 172.20.20.1.856 > zappa.111: . ack 1
win 16060 (DF) (ttl 55, id 30358)

Fusing host and network logs

One of the things that we learned over the Christmas holidays of the millennium turnover, was that intrusion detection state of practice is not yet advanced enough to allow the analyst to rely on network traffic alone. The process of using both system and network logs to determine an accurate battle picture is called fusion by the U.S. Department of Defense, we think it is both a good term and a great concept. Please take some time as you work though through each example to ask yourself is it a system log, or a network log. As you continue to examine logs and become familiar with their content, a wonderful thing happens, you can read them without thinking about the source. You just know it is a system log, or a network log and what that means to the battle picture, you are fusing! At the end of the chapter we will remind you to review the material you have covered and make your own determination on whether fusing is something you need to pursue in your analysis journey.

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
1:45(44) ack 1
win 16060 (DF) (ttl 55, id 30363)
15:20:35.725410 zappa.111 > 172.20.20.1.856: . ack 45
win 33536 (DF) (ttl 60, id 5373)
15:20:35.889546 zappa.111 > 172.20.20.1.856: P 1:33(32) ack 45
win 33580 (DF) (ttl 60, id 5374)

Well, that isn't too serious most likely! We have a single exchange of data, the prober pushes one small chunk of data to zappa, who answers back with one chunk. 44 and 33 octets of data respectively is probably not enough for a buffer overflow or any significant loss to a recon probe. If this is all the data, we may be OK. And it is all the data we have a graceful close, as always in a successful close both sides of the connection initiate a close with a FIN and the other side acknowledges.

15:20:35.930580 172.20.20.1.856 > zappa.111: F
45:45(0) ack 33 win 16060 (ttl 55, id 30446)
15:20:35.931557 zappa.111 > 172.20.20.1.856: . ack 46
win 33580 (DF) (ttl 60, id 5375)
15:20:35.932534 zappa.111 > 172.20.20.1.856: F 33:33(0) ack 46
win 33580 (DF) (ttl 60, id 5376)
15:20:35.968683 172.20.20.1.856 > zappa.111: . ack 34
win 16060 (DF) (ttl 55, id 30461)

There is the one unhappy observation here that the attacker initiated the close so that he, or his process remained in control throughout the conversation. In conjunction with the system log, in a busy attack, I would be willing to triage this as low severity. If it was the only detect of the day, I might want to take a closer look at my system and network perimeter defenses and try bumping zappa with an rpcinfo or two.

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
connection attempt from M-^DM-^Z^D@^A@[10.96.22.193]

Underground legend has it that 32772 is the expected location of rstatd on a Solaris box and this might even be correct. It also might not be correct as shown on this rpcinfo trace from a Solaris system that we have already examined.

rpcinfo -p | grep 32772
100024 1 udp 32772 status
100002 2 tcp 32772 rusersd
100002 3 tcp 32772 rusersd

The idea here is simple though, avoid portmap all together and go directly to the probable location of the service. 32772 is the classic, one analyst refers to it as a "Sun locator", but it is not the only target as we will see very clearly.

Dec 26 09:29:43 nms1 rpcbind: refused connect
from 172.20.20.14 to getport(100099)
Dec 26 09:29:21 192.168.3.5 rpcbind: refused connect
from 172.20.20.14 to getport(1000)
Dec 26 09:29:26 192.168.3.5 rpcbind: refused connect
from 172.20.20.14 to getport(1000)
Dec 26 09:29:30 192.168.4.8 rpcbind: refused connect
from 172.20.20.14 to getport(100099)

In the trace please focus for a minute on getport(100099). The analyst that detected this attack has done some additional work to determine the program that is being targeted. And we see the result of this below.

crash:/etc/rc2.d# rpcinfo
program version netid address service owner
[ ... lots removed ... ]
100099 2 192.168.1.2.autofs - superuser

So then, when we see a getport(100099) we can be pretty durn certain the attackers are not shooting blindly. getport(1000) also turns out to be very common in practice, consider the system log below.

Dec 26 09:27:34 marlin rpcbind: refused connect
from 10.12.20.6 to getport(1000)
Dec 26 09:27:39 marlin rpcbind: refused connect
from 10.12.20.6 to getport(1000)

So far we have seen connections directly to TCP Port 111 a getport(1000) and the prog 100000.

Twistah McLain was kind enough to email me an attack script that probes RPCs, a section of which is shown below:

#!/bin/sh
#all of these shiz are exploitable and i have 0 day for
#so i decided to make a rough scanner to sort through the rpcinfo krap
#[eCh0@LucidX.com]
TMPFILE=/tmp/.rpcscanfile
TOOLTALK=100083
STATUS=100024
AUTOFSD=100099
NISD=100300
MOUNTD=100005
PCNFSD=150001
REPORT=" was found on tcp port "
function scan() {
echo "Let's find some exploitable services eh?"

There is a great danger in using exploit scripts to build your defenses or intrusion detection signatures, they may not work at all or they not achieve the results the author's intended. However, in this case this exploit script serves as more evidence that 100099 is targeted and they are almost certainly armed with an AUTOFSD exploit.

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
from 128.32.36.33 to getport(100099)
Dec 30 17:18:00 darkstar rpcbind: connect
from loopback(\000\000\346\365) to unset()
Dec 30 17:18:00 darkstar rpcbind: connect
from
Dec 30 17:27:47 darkstar rpcbind: refused connect
from 128.32.36.33 to getport(100099)
Dec 31 07:42:34 darkstar rpcbind: refused connect
from 128.8.176.40 to getport(100099)

Have you been noticing the dates on these detects? Most of these were collected in a small time space, about six days or so. In a large attack, or information warfare scenario, the wise analyst uses depth and breadth ( or magnitude and variation ) to help maintain situational awareness. So far the examples we have seen are pretty easy to understand until the darkstar report above. Now we have this "loopback(\000\000\346\366) to unset()" thing to deal with and we are going to follow it with a lot of really odd stuff. The loopback may be to allow access to the system, consider the following note from Richard Bejtlich:

"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.

Today is January 6, 2000, by the time you read this book, we probably will have figured out what all of these patterns mean and have the analysis posted on the GIAC web page, after all the only one that is still unresolved today is the binary characters to getport(). However, we need to take you on a journey through the material as it looked on December 31, 1999. Right now, today, as you are reading this you have the advantage of all the analysis that has occurred since this was written and that will help you with unset() and friends, but it will not help you as much if you find yourself as an analysis in a firefight. So we will still be learning patterns but we will also learn, depth and breadth which are far more important.

Twas the week after Christmas 1999 and all through the net, there were several reasons to be concerned. CERT had released their denial of service advisory about tools like trinoo, tfn2000 and a warning that December 31 a large attack might be directed against web servers. There were claims everywhere about Y2K viruses, special viruses that would go off on the millennial turnover and hackers that were going to it us hard hiding in the noise of Y2K software problems. Finally there was Y2K, a lot of my friends were very concerned. That was the backdrop that caused us to begin the information monitoring and sharing effort that became known as the Global Incident Analysis Center. So now, take a second and put yourself in the lead incident handler seat for your organization and pretend these traces were coming into systems and networks that are your responsibility. You have already seen the attack information shown above and have read all the gloom and doom alerts and then you see the traces from the next section. As we like to say, severity is best evaluated from the point of view of the system owner!

The role of the blitz in information warfare

Whether you wish incapacitate your enemy, or simply need a diversion, the blitz is your friend in information operations. In football you can blitz against the run, or the pass, you can call it a blitz if you use one additional player to rush the passer or if you throw the kitchen sink at the opposing team and that illustrates magnitude and variation. You can conduct offensive information operations by using a large scale attack where you throw a large number of exploits at your opponent from a large number of source locations, and or make use of proxy tunnels. Size does matter, but this is not the scenario that most defenders fear, you can also throw a large number of attacks that they have never seen before. There was a time when we would have never believed that a large body of exploits could exist we had never prepared for, December 1999 taught us that wasn't true, we did see a huge number of attacks never before discussed.

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
from loopback(\000\000\024\036) to unset()
Dec 28 16:46:18 jeru rpcbind: connect
from loopback(\000\000\024\037) to unset()
Dec 28 16:46:18 jeru rpcbind: connect
from loopback(\000\000\024) to unset()

The trace below brings up a new class of problems, the control question mark series to getport(). This attack has been attributed to the XXX, but at the time, we had never seen such a pattern. You can imagine our concern when you consider the number of attacks that had been detected worldwide on the week between Christmas and New Years (depth or magnitude) and the variety or breadth of these attacks.

Dec 29 05:35:46 dns1 rpcbind: refused connect from
172.20.20.1 to getport()
Dec 29 23:05:07 www rpcbind: refused connect from
172.20.20.1 to getport(^?>XH)

So where were we? On December 29 we had a working theory that the unreadable characters might be a script that still needs bugs worked out. However, a wise analyst has told us that when he runs these to ground, they are always compromised systems. That does not preclude the buggy script theory, but since these have been detected from multiple sources it might mean the attackers knew a lot that we didn't.

Even worse, the trace below shows this has been going on for some time and there is a getport(3000 | ) as well. The trace below shows several of the patterns.

Dec 12 17:58:08 robot rpcbind: refused connect
from 172.20.20.3 to getport(3000 |)
Dec 12 17:52:28 mail rpcbind: refused connect
from 172.20.20.3 to getport(o^?ZX)
Dec 12 20:51:21 mail-test rpcbind: refused connect
from 172.20.20.4 to dump()
Dec 12 20:49:54 printhost rpcbind: refused connect
from 172.20.20.4 to dump()

unset() breakthrough

One of the interesting things about the GIAC project is how we learn from one another. Here is a note I received January 2, 2000.

Hi,
I am not sure this is what you were looking for but it is Sunday morning, it is raining outside and I feel like reading a bit of C.

So, according to the source from 4.4BSD and Wietse's secure portmap what we are seeing in the loopback calls to unset() is actually an attempt to unset an NFSD binding. At which point, coming from a localhost, it could well be something to do with a showmount -e but this is not entirely obvious as a showmount asks for an enumeration - what I'd do is atttach gdb to a showmount and see if it does a mount/umount sequence to try and get the mount list.

Ciao,
Arrigo Triulzi

Now it is time to put you in the lead analysts seat, pretend that today is December 31, 1999, we asked CERT if they had more information about these traces than we did and there was no answer. A lot of the traces that have been detected are still unsolved (on December 31, 1999). You may be dealing with a large class of new attacks. In the next trace we see our first instance of callit(nsrstat), we continue to escalate in both depth and breadth.

Dec 30 16:00:09 thumper portmap[21053]: connect
from IP.32 to callit(nsrstat): request from unauthorized host
Dec 30 16:00:12 thumper portmap[27908]: connect
from IP.32 to callit(nsrstat): request from unauthorized host
Dec 30 16:25:34 thumper portmap[18086]: connect
from IP.32 to callit(nsrstat): request from unauthorized host
Dec 30 16:25:37 thumper portmap[16721]: connect
from IP.32 to callit(nsrstat): request from unauthorized host

But wait, there is more, here we see a variation on the 1000 port number, could this mean dump everything less than 1000?

Dec 31 07:42:43 locust rpcbind: [ID 884469 daemon.warning]
refused connect from 128.8.176.40 to getport(1000<)

Your assignment is to continue to provide input, to be ready to provide information that would let the in charge make the decision to move to condition yellow. Remember the conditions, the CERT advisory that a major attack could occur, the virus warnings, the hacker warnings and then you see traffic like this. Stop, stop, stop everything! What call would you make? Please do not read on till you answer; review the data and then decide. Do you recommend going from condition green to condition yellow? There really isn't a right answer per se, there is a need to experience the process, this is a tough spot to be in! Do it in practice before you have to bet your career on it is our advice!

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[150]:
rejected prog 100000 proc 3 call from 10.208.120.9

We don't know about you, but we have no clue what a 100000 proc 3 call is, however we all know what rejected means. Stephen got that figured out when he was learning about dating in high school! And if you go up a trace, you see refused, that is what happened when he was on travel and tried to use his US Airways (you earn miles) Visa card. Now while rejected and refused were traumatic events in one's personal life, they are music in the sound of a handler's eyes! If the defenses are holding we don't have a severe situation. No, I do not like it when I am down to my host defense layer, did you notice that? But, hey, it is still a defensive layer. Sometimes we see traces that give us more pause for thought. Dear paganini in the next trace comes under serious attack!

> uname -a
SunOS paganini 5.6 Generic_105181-03
sun4m sparc SUNW,SPARCstation-LX
> grep ttdbserverd /var/adm/messages

Dec 27 18:26:46 paganini /usr/dt/bin/rpc.ttdbserverd[3481]:
_Tt_file_system::findBestMountPoint --
max_match_entry is null, aborting...
Dec 27 18:26:46 paganini inetd[139]:/usr/dt/bin/rpc.ttdbserverd:
Segmentation Fault

Dec 27 18:26:56 paganini unix: rpc.ttdbserverd[3482]
attempt to execute pre on stack by uid 0

There is something you don't see everyday, this could indicate activity beyond simple probing! The segmentation fault would probably create a core file. I would take a close look at that! Also, this time there are no comforting words like refused or rejected. If you wanted to know which was the most serious trace in the chapter, I would think this one deserves a nomination.

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 (fyodor@dhp.com, www.insecure.org/nmap/)

Interesting ports on sam.edu (192.168.8.96):

Port	State	Protocol	Service
21	open	tcp	ftp
22	open	tcp	ssh
25	open	tcp	smtp
80	open	tcp	http
111	open	tcp	sunrpc
139	open	tcp	netbios-ssn
389	open	tcp	ldap
515	open	tcp	printer
554	open	tcp	rtsp
2049	open	tcp	nfs
2766	open	tcp	listen
3306	open	tcp	mysql
5050	open	tcp	mmcc
8080	open	tcp	http-proxy
32776	open	tcp	sometimes-rpc15

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

sometimes-rpc

nmap has a table that is tweaked from time to time and may be the best source for interesting RPC ports. As Daniel Ayers pointed out, NMAP is shipped with a file, nmap-rpc, that lists the RPC programs and program numbers it knows about. (This file is attached - these are the RPC programs it will look for by default). If it can't locate that file anywhere, NMAP will use /etc/rpc.

# This was created by Vik Bajaj with help
# from various members of the nmap-hackers list.
# To join nmap-hackers send mail to nmap-hackers-subscribe@insecure.org
# Nmap is available from http://www.insecure.org/nmap/
# All the rpc services we could find as of Feb22, 1999
# Tweaked a bit by Fyodor

3270_mapper 100013
NETlicense 100062
admind 100087
alis 100018
amd 300019 amq

.... ( Many ports removed, go get nmap source! )

autofsd 100099 autofsd
bootparamd 100026 bootparam
bssd 300433 bss
yppasswdd 100009 yppasswd
ypserv 100004 ypprog
ypupdated 100028 ypupdate
ypxfrd 100069 rpc.ypxfrd ypxfr

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
(fyodor@dhp.com, www.insecure.org/nmap/)
Warning: No tcp ports found open on this machine,
OS detection will be MUCH less reliable
Interesting ports on sam.edu (192.168.8.96):

Port	State	Protocol	Service
111	open	udp	sunrpc
137	open	udp	netbios-ns
138	open	udp	netbios-dgm
514	open	udp	syslog
2049	open	udp	nfs
32771	open	udp	sometimes-rpc6

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
18:50:52.831686 waldo.edu.47862 > sam.edu.937: udp 0
18:50:52.831768 waldo.edu.47862 > sam.edu.327: udp 0
18:50:52.831849 waldo.edu.47862 > sam.edu.635: udp 0
18:50:52.831928 waldo.edu.47862 > sam.edu.554: udp 0
18:50:52.832007 waldo.edu.47862 > sam.edu.321: udp 0
18:50:52.832084 waldo.edu.47862 > sam.edu.1600: udp 0

The UDP size zero is quite helpful in this case, as is the static source port. The problem is that nmap changes about every other week, so there will probably be a command line option to modify both of these behaviors by the time the book is printed. However, you can run nmap on your systems and see what signatures you see!

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
2981802919:2981802919(0) win 8192 <mss 1460,nop,wscale
0,nop,nop,timestamp 13486573 0> (DF)
18:50:08.066649 sam.edu.32771 > waldo.edu.61345: R
0:0(0) ack 2981802920 win 0 (DF)

In the next trace, we have a TCPdump trace of a probe by nmap to an open port, 32776. The response from sam is a SYN/ACK, the three way handshake is completed and nmap closes the connection with a RST.

18:50:08.238249 waldo.acu.edu.61721 > sam.acu.edu.32776: S
3006255052:3006255052(0) win 8192 <mss 1460,nop,wscale
0,nop,nop,timestamp 13486574 0> (DF)
18:50:08.254079 sam.acu.edu.32776 > waldo.acu.edu.61721: S
3403285064:3403285064(0) ack
3006255053 win 8760 <mss 1460> (DF)
18:50:08.254167 waldo.acu.edu.61721 > sam.acu.edu.32776:
. ack 1 win 8760 (DF)
18:50:08.272890 waldo.acu.edu.61721 > sam.acu.edu.32776:
R 1:1(0) ack 1 win 8760 (DF)

To summarize, we have chosen to deal with RPCs in some detail since they are a primary attack vector. We have seen that attackers may go through portmapper or directly to a high numbered service port. As always reconnaissance is critical, the attacker needs to gather information about the location of the service and version of the operating system to prepare the appropriate attack. In addition to a number of specific signatures, we have also used an example of a real situation, the Y2K cyber-assurance watch, to give you a taste of the task of a senior analyst in a large scale attack or information warfare scenario.

< Previous Question | Back to Intrusion Detection FAQ Home | Next Question >

Check Them Out!

Real world people giving real world training.
-John Szyszlo, The Gem Group, Inc.

Intrusion Detection FAQ: The trouble with RPCs

Check Them Out!

Latest Whitepapers

Latest Tweets

Contact Us