As most of our regular readers are aware, this is Cyber Security Awareness Month and the ISC handlers are writing diary entries about securing various ports and services. For the die hard security professionals, this month is nothing more than a review of things you have learned over the past 10-20 years. For those new to information security, it is our hope that you learn more about the various ports and services which are commonly used on networks. As the old adage states, those who do not learn from the past are doomed to repeat it. It is my hope that you as our reader will learn from the mistakes of our collective past so that as an industry we don't have to repeat things (as often at least).
In many cases when a client makes an RPC call for a given program, it will first connect to the rpcbind or portmapper service (tcp/udp 111) on the destination system to determine the ultimate port where the request should be sent. The active port 111 will have a list of all active services, and tell the requesting client were to connect. However, infosec professionals should know that under some versions of Unix rpcbind not only listens on the TCP/UDP port 111, but it also listens on UDP ports greater than 32770. The exact port number is dependent on the OS release and architecture. Thus, packet filtering devices, router ACL blocks, and firewalls that are configured to block access to rpcbind/portmapper at only port 111, may be subverted by sending UDP requests to rpcbind listening above port 32770. This vulnerability may allow an unauthorized user to obtain remote RPC information from a remote system even if port 111 is being blocked.
To finish a part of the story, I eventually found that Wietse Venema (author of SATAN, TCP wrappers, and other security tools) had developed a replacement to the native rpcbind/portmapper program that would correct two of the main issues I had with it at the time: access controls and logging. With this tool, I was able to at least attempt to thwart the attacker (my supervisor) until told otherwise, and limit the amount of data my workstation was allowing out.
While Unix based RPC doesn't seem to be as prevalent today, I do expect that this construct can and will be used in the future in new and different ways. We all have seen or heard of stories where there is an intrusion which involves some legacy application which was not properly secured. Chances are some of you may have one of those applications running on the interior of your network.
Scott Fendley, ISC Handler on Duty
Oct 11th 2009
1 decade ago
The big misunderstanding with RPC is that programmers think it is *mandatory* for RPC.
It is *not*. As a matter of fact, to increase security, I always registered my RPC servers on a fixed port, where clients can find it without needing portmapper/rpcbind.
The problem with registering with the portmapper is that you don't really know who is querying for that information + one can be called "indirectly", via that same portmapper (which is obviously what happened in your student time).
By the way, the Wietse Venema's replacement for rpcbind had a bug when "authenticated RPC" was send : according to documentation it refused authenticated RCP - at that time at least, code showed it removed authentication (AUTH_NONE) and then *forwarded* the call ! He was amused when I reported it, but I never saw a correction (it's years ago and since then I'm not programming that much anymore).
Besides the general recommendation : don't use portmapper for RPC programs at all, there is really no reason to allow tcp/udp traffic to port 111 from the Internet (or to the Internet)...
Oct 14th 2009
9 years ago