System Profiling Through RPC

by Screamer Chaotix

The Sun RPC (Remote Procedure Call) port mapper running on port 111 can be your best friend - or your worst enemy.  As usual, it depends on what side of the fence you choose to play on.  For the purposes of this article, I will assume the reader is interested in exploring the possibilities of remote system profiling without the need for old fashion programs such as Finger.

Through the port mapper running on 111, we can see what RPC programs are running on the remote machine, and may even get a chance to exploit one or two.  The beauty of RPC is that, by it's very nature, it's designed to be open to the Internet.  And while most people have gotten around to getting rid of annoyances like Finger, EXPN/VRFY on port 25, and of course, default accounts, not too many give RPC a second look.

I could hypothesize as to why that is, perhaps the most obvious being that port 111, by itself, is not really a security hole.  Its best use, from an invader's perspective, is to show exactly what's running where.

For brevity, we will focus on two RPC programs.  One can be used to gain information about the target system, the other could potentially give us access to the machine.  These daemons are rusersd and mountd.

But first, how do we find them?  You could take your target machine and simply run the client version of these commands against it to see if anything gives, but I prefer knowing if the RPC ports are up and running or not before I go attacking anything.  To find open ports, a simple Nmap scan will suffice:

$ nmap -sS -p 111 192.168.2.* > port_111 &

I'll assume you have a machine and, for legality purposes, it's a computer you own (not 0wn).  To see what RPC daemons are running, simply run the following command:

$ rpcinfo -p target.host.com

What will return is a listing of listening daemons, for example:

program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100024 1 udp 32770 status 100021 1 udp 32770 nlockmgr 100021 3 udp 32770 nlockmgr 100021 4 udp 32770 nlockmgr 100024 1 tcp 32769 status 100021 1 tcp 32769 nlockmgr 100021 3 tcp 32769 nlockmgr 100021 4 tcp 32769 nlockmgr 100005 1 udp 644 mountd 100005 1 tcp 645 mountd 100005 2 udp 644 mountd 100005 2 tcp 645 mountd 100005 3 udp 644 mountd 100005 3 tcp 645 mountd 100025 1 udp 32790 rusersd

How convenient, we have both mountd and rusersd up and running.

Let's begin by doing a little snooping.  The first thing hackers would do a few years back was a quick and dirty finger @target.host.com to see who was logged into that machine.  Nowadays, people know it's not a good idea to leave their login information lying around, even if it's just a username.  What people don't realize however, is that they may still be giving out this very same information without realizing it.  Enter rusers, which can be found through www.rpmfind.net if not already included in your distribution.

$ rusers -l target.host.com

For those of you wondering if that's a lowercase L or a one, it's the former (as in little larry).  With this command, you will be brought back to the good old days of Finger, as login information will appear before you (if people are logged in at that time of course).  Here's an example for your viewing pleasure:

Login Shell Last Login screamer /bin/bash Wed Nov 2 from home.ctu.cia.gov dash /bin/bash Thurs Dec 5 from grazer.ctu.cia.gov

Darn, and I thought by getting rid of Finger I was safe!  Guess not.  So there we go, we have some login information.  Now the next step I won't even get into.  If you don't know what I'm talking about, it includes "password," "love," "sex," "secret," "god," last names, addresses, birthdays, spouse names, dog names, and maybe even a little social engineering.

Now, let's move on to more important matters, shall we?  Namely, mountd.  Now mountd isn't all that terrible, when properly configured (natch).  The mountd protocol can be used to mount a remote drive, onto a local one, and allow you to view the contents of that drive as though it were on your local machine.  In other words, you can see inside a computer without logging in.  O.K., let's use mountd to its full potential.  To do this, we'll use a little program called showmount.  The showmount client, in a nutshell, displays mountable drives on either your local or a remote machine.  These are drives that can be mapped to a local drive and traversed as though that's exactly what they were:

$ showmount -e target.host.com

Which returns (if you're lucky):

/usr/bin root /home/johns (everyone)

Great, so we have a couple of mountable drives there.  The first is owned by root, which we can't touch.  Fortunately, the next drive on the list looks like a users home directory.  Bingo!  As Lord Nikon would say, "You're in the butter zone now, baby."

You can see inside this drive without even logging in!  Begin by making a new directory to mount the remote one onto, in our case we'll call it new_mount.  Then we mount the remote drive onto it, like so:

$ mkdir new_mount $ mount target.host.com:/home/johns new_mount

If everything goes smoothly, you can now cd into your new_mount directory, type ls, and see everything inside that users directory.  Ooh, wow, you say.  Who cares?  I'm a hacker, I don't want to read someone's email, I want to explore the system they're using.  Fortunately, with a home directory mounted on your computer you can.

That, after all, is the magic of an .rhosts file.  Yes that's right, .rhosts, that file you should never have in your home directory is your ticket into this remote machine.  Simply create an .rhosts file that contains this line.

your.machine.com johns

From there, all you have to do is rlogin into the remote machine.

$ rlogin -l johns target.host.com

And there you have it.  You're now logged into the remote machine as user "johns".

From here, you can use any number of local exploits to achieve root.  Naturally, those all depend on the architecture of the machine, so look around or better yet, try and figure out somethings yourself (shocking concept, huh?).

For just a minute, let's say you didn't find a mountable drive that belonged to a user but was however, open to everyone.  Possibilities exist for getting access here as well, potentially even as root.  If you're lucky enough to find /usr/bin (or any other directory located in a users path), you can mount the drive to your local machine and modify any number of programs in there to do your bidding.  And if someone foolishly runs those programs as root (which is entirely possible), you can have some serious fun.

Make ls discreetly add a new user with root privileges, and voilà, you have your very own backdoor.  Try to be as inconspicuous as possible, name the new user "system_" or something to that effect, so it doesn't draw too much attention.

Last and certainly least, RPC is probably unnecessary on about 97% of the systems that use it.  Why you need to show who's logged in through rusersd is beyond me, and why you would ever want to have people on the Internet mounting your drives on their local machines doesn't seem to make a lick of sense.

These things do exist, believe me.  Scan a university, you're bound to find a machine you can root with just a little effort.  Naturally, I can't actually recommend it, don't want to see anyone go to jail, but it's good to know what's possible, if only so you can better protect yourself.  Until next time, never stop exploring.

Thanks to everyone who helped, and shouts to the one and only Dash Interrupt, Unreal, w1nt3rmut3, dual_parallel, and pengs every where.