From: prl@iis.ethz.ch (Peter Lamb) Newsgroups: alt.security,comp.unix.admin Subject: Re: NIS and password security Message-ID: Date: 4 Dec 91 19:10:39 GMT References: <#hpq#bc@rpi.edu> <1991Dec4.170052.14839@mp.cs.niu.edu> Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH There have been a number of queries and some not completely accurate information posted on this question. I'll try to summarise the problem and suggested workarounds. None of the workarounds is particularly satisfactory, and I'll try to give a reasonable summary of the pros and cons. The problem is this: ypserv is totally indiscriminate about which machines it will respond to queries from. Normal NIS maps can be read by anyone on the Internet who can route packets to your NIS server and back. "secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier is using a privileged port (< 1024). This means that anyone can read your "secure" maps if they can crack root on some machine on the Internet and can route packets to your machine. The bug means that many machines on the Internet which use NIS are vulnerable to having their password files stolen and run through "Crack" or similar. Arguments about whether distributing Crack and fast U*ix encryption algorithms was a good idea aside, every wannabe cracker now has a copy of a reasonably state-of-the-art password guesser. As I said in my earlier post on this subject, the combination "I'm NIS and I serve everyone" and easily available password guessers has already led to breakins at some sites. This bug was reported to Sun in April 1990, and CERT has also been aware of it for about the same length of time. I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's called this week, which I understand will be available in Solaris 2.0. What to do about it: 1) The Sun Party Line. "Don't run ypserv on your gateway and disable IP forwarding on the gateway". This is commonly known as a "firewall" (provided the machine is also in other respects reasonably secure) and is probably already done by many commercial users of the Internet. It is not the greatest in convenience, and most University sysadmins would encounter, lets say, a little user resistance. Managing the gateway is also a pain. Switching off `routed' alone, as has been suggested here, is usually insufficient. However, provided the security of the firewall is not breached, you are safe from this attack, and many others. Instructions on how to disable IP forwarding in the kernel are in Sun's Network Admin manual. 2) The Lamb Party Line. If you communicate to the outside world through a smart router, filter out packets coming from external connections addressed to destination ports sunrpc/udp&tcp (port 111) and ports 600-1023, tcp&udp. This will prevent access to *all* sunrpc services from outside the router. It will also block access to the Kerberos protocols (probably also not a bad idea given the info. in Steve Bellovin's paper about Kerberos security problems), and will probably block the BSD `r' (rcp,rlogin, etc) commands, but don't count on it doing so. If you and your router are smart enough, you may be able to make the `r' commands work. Eg, for rlogin, allow the packets through iff their source is 513/tcp (this opens up a hole for a sufficiently clever cracker, though). Blocking port 111 alone is insufficient but will block the most obvious attacks (including those I've been told have already actually occurred). The above two solutions are the only real answers to the problem. There are some workarounds which make life harder for the potential cracker. 1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess your NIS domain name in order to talk to ypserv. This is purest security- through-obscurity. The domain name is normally only handled by automatic systems, and can be up to 64 characters long. Making the first part a reasonable handle may help system administration. Something like my-old-domainname-Ldp.T2d9wCY is probably reasonable. This precaution is vulnerable to "social engineering" attacks, ie. the cracker trying to fool a user at your site to reveal the domain name, since the NIS domain name can be discovered by any user on your machines. 2) Use passwd+ or npasswd to vet passwords. If you do this, you need to make all your users put their current password through the new password program. Using a premptive check on passwords for idiotic usage is a good idea anyway, independent of whether you use NIS or not. If you have Suns and you'd rather spend money than install free software, Sun Shield (TM) also provides this capability, along with other more or less useful things. Convex provides some similar capabilities in their passwd(1) program. Some other manufacturers may also have similar capabilities. The more sites that do this, the more frustrating it will become for crackers trying to guess passwords. Note that this problem is common to all versions of NIS or Yellow Pages, that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0, but it seems that this will be a little while coming, and for non-Sun machines even further off. Using NIS in combination with Sun's so-called `C2' security will *not* help. For those not aware of current technology in password guessing programs, Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against a U*ix encrypted password on any modern RISC workstation. This means that an encrypted password can be checked against the entire /usr/dict/words in less than a minute. "Crack" has been posted to the network, and you can assume that most crackers and wannabe's have a copy. Peter Lamb (prl@iis.ethz.ch) (depressed) PS: Sorry, I will not respond to requests for more details about how to exploit this hole. Sun and CERT have full details. If you have a Sun s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId was 1036869. Please contact Sun if you feel you need more details.