phil@delta.eecs.nwu.edu (William LeFebvre) (08/17/89)
Now that the CERT has made the problem known, I can put forth an idea that might help prevent similar "breaches" in the future.... I have an idea for protecting Internet sites from breakins such as the one that was at the root of the problem just described by CERT. I have had this idea for quite some time, and I really can't see anything seriously wrong with it. When /bin/login knows it is processing a remote login, why can't it check the hostname against a list of "allowed" hosts? If the host is not in the list, make the login fail in the usual way (encrypt the password and fail the login) no matter *what* the password is. Each user can have his/her own list of "allowed" hosts, just like we do with ".rhosts". This file could contain not only host names, but also a limited form of wildcarding, such as "*.nwu.edu" (which would allow any host in the "nwu.edu" domain). What this prevents: random user from random Internet site repeatedly trying different passwords to try to log into an account over the net. As I understand it, the person in this most recent rash of invasions would first find a username (very easy to do) and try obvious passwords for that name. Login's 60 second limit is pretty much unimportant on the Internet: just type "!!" and keep trying (my apologies to "sh" users). Since this is done by /bin/login, ALL forms of network access are limited, be they rlogin, telnet, or whathaveyou. How this interferes: as a legitimate user, you can't log in from just anywhere. But how often does that happen? How often do you sit down at a random Internet site and log in to your primary computer? If you know you are about to make a trip to some other location, then plan ahead and put that location's domain in the list of allowed hosts before you leave. But just in case there are some people who really need the current openness, there should probably be a way for an individual user to disable the checking for his/her account, such as adding the line "*" to the list of allowed hosts. Let's face it: for 99% of the Internet hosts, you don't want a remote login from that host into your account to succeed. So why not have a mechanism in place for disallowing them? As a concerned sysadmin and user, I certainly want this kind of protection for my own account, and especially for my "root" account! And it's not like this is all that hard to do...... What think you all? William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
roy@phri.UUCP (Roy Smith) (08/18/89)
In <1064@accuvax.nwu.edu> phil@delta.eecs.nwu.edu (William LeFebvre) writes: > When /bin/login knows it is processing a remote login, why can't it > check the hostname against a list of "allowed" hosts? I can't find any problems with William's suggestion, but would add one more idea. Before allowing a shot at a username/password, require a network access password. The same thing could be done for dial-up access, but this is less of a problem. This password would be picked by the system administrator, (theoretically) ensuring that it wasn't an obvious one, like lusers tend to pick. This is not a new idea, but seems to be implemented only in very security concious sites; perhaps it should be the default way vendors ship their systems. Multiple failures to get the network access password right should be logged in the system security log. Actually, I can find one problem with William's suggestion. Just like people tend to pick poor passwords, I suspect many people would put "*" in their .netaccess files, effectively defeating the whole idea. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (08/18/89)
In article <3942@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In <1064@accuvax.nwu.edu> phil@delta.eecs.nwu.edu (William LeFebvre) writes: >> When /bin/login knows it is processing a remote login, why can't it >> check the hostname against a list of "allowed" hosts? > > Actually, I can find one problem with William's suggestion. Just >like people tend to pick poor passwords, I suspect many people would put >"*" in their .netaccess files, effectively defeating the whole idea. How about inverting the meaning of ".netaccess"? By this i mean making it a list of hosts/addresses to be rejected. There have been times when it would be desireable to let connections from all systems except a list of bad/undesireables. Steven M. Schultz sms@wlv.imsd.contel.com
mike@thor.acc.stolaf.edu (Mike Haertel) (08/18/89)
In article <3942@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In <1064@accuvax.nwu.edu> phil@delta.eecs.nwu.edu (William LeFebvre) writes: >> When /bin/login knows it is processing a remote login, why can't it >> check the hostname against a list of "allowed" hosts? > > [ . . . ] > > Actually, I can find one problem with William's suggestion. Just >like people tend to pick poor passwords, I suspect many people would put >"*" in their .netaccess files, effectively defeating the whole idea. If many people would put "*" in their hypothetical .netaccess files (and I am certainly among those who would) then attempting to restrict network logins in such a way is not a good idea to begin with. Clearly, systems should be designed to facilitate peoples' preferred ways of working. It is better to have to occasionally find and deal with a bad guy than to cripple everyone just on the offhand chance that a bad guy might cause trouble. -- Mike Haertel <mike@stolaf.edu> ``There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.'' -- J. S. Bach
evans@testmax.ZK3.DEC.COM (Marc Evans Ultrix Q/A) (08/18/89)
> check the hostname against a list of "allowed" hosts?
Chances are that if I were smart enough to modify something like telnet to
trace lognames/passwords, it wouldn't be too hard for me to also know what
the hostnames are, that were communicating. I could also probably know the
internet address and maybe even the hardware address. Assuming that I can
get this information, then it probably isn't too hard for me to set up my
host to mimic the environment used by the authorized user(s).
I am not trying to say that the idea isn't a bad one. It would probably
make it more difficult for people to gain unauthorized access. What I am
saying is that you will probably never remove all possible access means
as long as machines are networked together, and people have access to
either the console or the super users account at some point in time.
==========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)893-8481
Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076
==========================================================================randall@uvaarpa.virginia.edu (Randall Atkinson) (08/18/89)
In article <4614@thor.acc.stolaf.edu>, mike@thor.stolaf.edu (Mike Haertel) writes: >If many people would put "*" in their hypothetical .netaccess files >(and I am certainly among those who would) then attempting to restrict >network logins in such a way is not a good idea to begin with. Clearly, >systems should be designed to facilitate peoples' preferred ways of >working. It is better to have to occasionally find and deal with a bad >guy than to cripple everyone just on the offhand chance that a bad guy >might cause trouble. In short, you are saying that since you won't use a method of improving security yourself that no one should use that method. I disagree strongly. If there were such a mechanism to restrict the origin of telnet sessions to my accounts, I would use it. Your non-use of the mechanism is not sufficient grounds to say that such a mechanism shouldn't exist. On the other hand, if you have an idea for a better mechanism, many of us would like to hear about it.
scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (08/18/89)
In article <3942@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >Before allowing a shot at a username/password, require a network access >password. The same thing could be done for dial-up access, but this is >less of a problem. I know that this would pull "features" from both BSD and SysV, but I think that it would be trivial to do. If I understand things right, an incoming remote login (rlogin, telnet) is associated with one of a set of ttyp/pty devices. System V provides a "dialup password" facility that could provide the protection mechanism that Roy suggests, simply by specifying all of the pseudo-terminals in /etc/dialups and putting the appropriate shell entries in /etc/d_passwd. To see if your version of /bin/login has these features, simply use strings and grep to look for the filenames. -- Scott Hazen Mueller| scott@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott 685 Balfour Drive | (408) 298-6213 |Mail to fusion-request@zorch.SF-Bay.ORG San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email
phil@delta.eecs.nwu.edu (William LeFebvre) (08/19/89)
In article <35131@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) writes: > How about inverting the meaning of ".netaccess"? By this i > mean making it a list of hosts/addresses to be rejected. I was thinking of having two files, along the lines of the new "cron": ".login.allow" and ".login.deny". There should probably also be a provision for a system-wide default, so that for example the sysadmin could set up all accounts to allow remote logins for "*.eecs.nwu.edu". You realy don't want just a list of "bad guys". In my thinking, anyone I can't explicitly name is suspect. Not because of the sysadmin or the users at that particular site (after all, they are just as susceptible to breakins as I am), but more because it is easier and quicker for me to name those sites I want to log in from than those I never want to log in from. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
phil@delta.eecs.nwu.edu (William LeFebvre) (08/19/89)
In article <4614@thor.acc.stolaf.edu> mike@thor.stolaf.edu (Mike Haertel) writes: >Clearly, >systems should be designed to facilitate peoples' preferred ways of >working. They should also be designed to insure a certain amount of security to help guarantee their integrity for the legitimate users. >It is better to have to occasionally find and deal with a bad >guy than to cripple everyone just on the offhand chance that a bad guy >might cause trouble. The problem with that thinking is that by the time you find out the bad guy is being bad, it's too late. We were REAL lucky that Morris's worm wasn't designed to do any harm, removing files at random for example. If it had, then the results would have been absolutely catastrophic. What you're saying is: I don't want this lock on my door, because it's better to catch the burglar after he has broken in and stolen/destroyed everything than to force myself to lock and unlock the house every day just on the offhand chance that a bad guy might cause trouble. William LeFebvre Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
mike@thor.acc.stolaf.edu (Mike Haertel) (08/19/89)
In article <328@uvaarpa.virginia.edu> randall@uvaarpa.Virginia.EDU (Randall Atkinson) writes: >In article <4614@thor.acc.stolaf.edu>, > mike@thor.stolaf.edu (Mike Haertel) writes: > >>If many people would put "*" in their hypothetical .netaccess files >>(and I am certainly among those who would) then attempting to restrict >>network logins in such a way is not a good idea to begin with. > >In short, you are saying that since you won't use a method of >improving security yourself that no one should use that method. That is not at all what I said; learn to read English. I did not say "Since I would ... it is not a good idea", I said "If many people ... it is not a good idea." If a sufficient number of people disabled host name access checking for their accounts, it would be as if there were no access checking at all. If you had access checking turned on, but some other user on your machine didn't for their account, then your account would be nearly as exposed as theirs, as a bad guy logged into their account would be about 95% of the way to yours. Occasionally for my own amusement I will attempt to invent a new way to become the superuser; over the past few years I have found a surprising number of methods. I am convinced that if an interloper has access to any one `normal' account on your machine, that is as good as having access to all, if the interloper is reasonably talented. Fortunately most malicious people are more interested in being nasty than in learning the subtle aspects of the system. >I disagree strongly. If there were such a mechanism to restrict the >origin of telnet sessions to my accounts, I would use it. You can easily restrict telnet sessions to your own account; just write a short login shell that checks the remote host before execing your real shell. But if you have a reasonably `secure' password there is really no reason to waste the effort. -- Mike Haertel <mike@stolaf.edu> ``There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself.'' -- J. S. Bach
rackow@skeeve.mcs.anl.gov (08/19/89)
I do not think that any of the suggestions at ".netaccess" would have helped in the most recent version of security breaches. Since what my understanding of the problem was/is had to do with legitimate usage being "taped/bugged" by a bogus telnet program it would do you little good to have a ".netaccess" file. I guess it would help from random crackers at random hosts trying to break passwords. But in this case- since the real user wanted access from what proved to be a "untrustworthy" machine to get to another machine he had (or would have) put the "untrustworthy" host into the list. If the cracker was carefully monitoring the log from his bugus telnet, he could have quickly logged into the remote host as the user and examined the dot files to see where else he could come from. If you were alerted to the problem, you could remove the original bad host, but would that be enough??? I believe in having minimal amounts of hassle in getting from placce to place and the greater need and benifits of an "open" network so take the following and pipe to all flames to /dev/null. ;-) ----Start of paranoid security state------ A possibility for the security paranoid and those with large human memories would be to make the netaccess file include passwords (or shadow passwords with the location of the shadow file hidden from the user as well). Now you can have a "*" to allow all hosts with a password. When you login from a new host, it forces you to pick a new "generic" password and adds the new host to the access list and requires a new password for that host as well. The passwords can not be duplicated for any host in the list with all the crazy rules of non-word mixed case etc., etc.... (Like I said--large human memory.) You probably would want to put the access into "syslogd" as well so the admin can keep track of where the users are and be alerted of possible breaches. This would make it easier to knock the bad host out of the list, but the cracker could still have been playing havoc with your login for some time. Of course I never want to see this implemented, because my memory is not that large. ----End of paranoid security state------ Maybe the real solution would be the little personal crypt boxes that when you attempt to login give you a string you enter into your box. Your reply to that string is the output from your little box. I do not know how secure these things are, or if you can use one box for more than one host, but sometime in the next millenium this problem will probably be solved and we'll be dealing with a whole new set of problems. ;-) Gene Rackow email: rackow@mcs.anl.gov Math & Computer Science voice: 312-972-7126 Argonne National Labs FAX: 312-972-5986 9700 S. Cass Ave. Argonne, IL 60439
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (08/20/89)
In article <35131@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) writes: > How about inverting the meaning of ".netaccess"? By this i > mean making it a list of hosts/addresses to be rejected. There > have been times when it would be desireable to let connections > from all systems except a list of bad/undesireables. This could work both ways like netnews sys files are with newsgroups. The '*' operator could function like an 'all' wildcard, with BANG being used for negation. Paranoid, Inc. sites would go *.paranoid.com !* and everyone else could go !*.paranoid.com * ;-) The rule would be to run the .netaccess file until there is a match, and permit or deny access based on the presence or lack of a '!'. This implies that Paranoid, Inc. doesn't need the !* at the end except to feel warm and cozy ;-) -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | "Chocolate Teddy Grahams are just InterNet: jfh@rpp386.cactus.org | reincarnated Space Food Sticks." UUCPNet: {texbell|bigtex}!rpp386!jfh +------------ -- Richard Sexton ---
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (08/20/89)
In article <823@zorch.SF-Bay.ORG> scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) writes: >I know that this would pull "features" from both BSD and SysV, but I think >that it would be trivial to do. If I understand things right, an incoming >remote login (rlogin, telnet) is associated with one of a set of ttyp/pty >devices. System V provides a "dialup password" facility that could provide >the protection mechanism that Roy suggests, simply by specifying all of >the pseudo-terminals in /etc/dialups and putting the appropriate shell >entries in /etc/d_passwd. To see if your version of /bin/login has these >features, simply use strings and grep to look for the filenames. The dialup feature is old enough that it should be present in the bowels of BSD login. At any rate, the login I wrote last year should be adaptable [ hear that Dave? ] to BSD with little effort and it has dialups and every other known feature, useful or not ;-). Look under 'shadow2' or something like that in the comp.sources.misc archives near you. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | "Chocolate Teddy Grahams are just InterNet: jfh@rpp386.cactus.org | reincarnated Space Food Sticks." UUCPNet: {texbell|bigtex}!rpp386!jfh +------------ -- Richard Sexton ---
bzs@bu-cs.BU.EDU (Barry Shein) (08/21/89)
Rather than a list of hosts you can log in from (that makes me uncomfortable, except for root and other priv'd accounts) why not extend the rlogin .rhosts idea to three levels: No Password, Normal login, Paranoid login. By Paranoid login I mean implementing one of these various ideas using challenges or secondary passwords etc. At least it can be used to throw some more obstacles in the way. The problem, ultimately, is that the crackers generally get in via trap-doors, either out and out bugs or subtleties no one had thought of before. Including non-computer attacks (like looking through printouts.) In addition, whatever you do just challenges the cracker to try a different solution. Only allowing me to log into your system from certain sites challenges me to fool your computer into thinking that I'm coming from one of those sites (which is usually not very hard to guess if I know anything about the topology of your network or even just scan mailing lists and/or newsgroups for lists of machines you seem use, or just finger around, or send mail to yourname@various and see if I get an error return.) The security biz is subtle, you have to pick your trade-offs carefully. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (08/21/89)
In article <36813@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >The security biz is subtle, you have to pick your trade-offs >carefully. The security biz is just downright HARD. You have to pick your everything correctly. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | Speaking of Netnews Administration: InterNet: jfh@rpp386.cactus.org | "If Bill Vajk can do it, anyone can" UUCPNet: {texbell|bigtex}!rpp386!jfh +--------- -- Patricia O Tuama-----
guy@auspex.auspex.com (Guy Harris) (08/22/89)
>The dialup feature is old enough that it should be present in the bowels >of BSD login. No, it's not. It doesn't date back to V7, and the BSD "login" is based on the V7 one. The BSD "login" does not have a dialup password feature.
grandi@noao.edu (Steve Grandi) (08/23/89)
In article <3942@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >one more idea. Before allowing a shot at a username/password, require a >network access password. The same thing could be done for dial-up access, >but this is less of a problem. This password would be picked by the system >administrator, (theoretically) ensuring that it wasn't an obvious one, like >lusers tend to pick. This is not a new idea, but seems to be implemented >only in very security concious sites; perhaps it should be the default way >vendors ship their systems. Multiple failures to get the network access >password right should be logged in the system security log. > Here are patches to the 4.3BSD login.c program implementing a site password for dialup and network logins. The feature is activated by putting in a user named "site" in /etc/passwd. Hosts listed in /etc/hosts.equiv are not asked for the site password, nor are UUCP logins. I have also added better logging of network and dialup logins and login attempts. *** login.c.ORIG Sat Apr 12 16:51:15 1986 --- login.c Mon Jan 9 09:27:08 1989 *************** *** 39,42 **** --- 39,43 ---- #include <grp.h> + #define UUCICO "/usr/lib/uucp/uucico" /* UUCP login shell */ #define TTYGRPNAME "tty" /* name of group to own ttys */ #define TTYGID(gid) tty_gid(gid) /* gid that owns all ttys */ *************** *** 51,54 **** --- 52,56 ---- #define TRUE -1 + char site[] = "site"; char nolog[] = "/etc/nologin"; char qlog[] = ".hushlogin"; *************** *** 218,222 **** --- 220,310 ---- invalid = TRUE; } + /* + * If login is from a dialup or network line then require a + * site password. Make sure it is not an uucp login! + * We will explicitly look for trusted hosts here as well. + */ + { + char *ptr, *pp, *type, spass[100]; + char *index(); + struct passwd *spwd; + FILE *hostf; + int trusted = -1; + char ahost[MAXHOSTNAMELEN+1], rhost[MAXHOSTNAMELEN+1]; + + type = stypeof(tty); + + if (strcmp(type, "network") == 0) + { + hostf = fopen("/etc/hosts.equiv", "r"); + /* get remote host name */ + strcpy(rhost, utmp.ut_host); + if (ptr = index(rhost, '.')) /* truncate name at dot */ + *ptr = '\0'; + if (usererr != -1) + trusted = 1; + else if ((hostf != NULL) && (hflag == 1 || rflag == 1)) + { + /* cycle through hosts in /etc/hosts.equiv */ + while (fgets(ahost, sizeof(ahost), hostf)) + { + if (ptr = index(ahost, '\n')) /* nuke newline */ + *ptr = '\0'; + if (ptr = index(ahost, ' ')) /* only look at first entry */ + *ptr = '\0'; + if (ptr = index(ahost, '.')) /* truncate at dot */ + *ptr = '\0'; + if (strcmp (ahost, rhost) == 0) + { + trusted = 1; + break; + } + } + } + if (hostf != NULL) fclose(hostf); + if (trusted == -1) + syslog(LOG_INFO, "NETWORK %.*s@%.*s", + NMAX,utmp.ut_name, HMAX,utmp.ut_host); + } + + /* + * Lets see if this is a dialup or network line. + */ + if ((strcmp(type, "dialup") == 0 && + strcmp(pwd->pw_shell, UUCICO) != 0) || + (strcmp(type, "network") == 0 && trusted == -1)) + { + /* + * Check to see if an account by the name + * of "site" exists and then if it has + * a password. Then we use the password + * for that account. + */ + setpwent(); + spwd = getpwnam(site); + endpwent(); + if (spwd != NULL && *spwd->pw_passwd != '\0') { + SCPYN(spass, spwd->pw_passwd); + + setpriority(PRIO_PROCESS, 0, -4); + pp = getpass("Site Password:"); + namep = crypt(pp, spass); + setpriority(PRIO_PROCESS, 0, 0); + if (strcmp(namep, spass)) + invalid = TRUE; + } + + /*see bugs in getpwent(3)*/ + strncpy(lusername, utmp.ut_name, NMAX); + lusername[NMAX] = 0; + setpwent(); + if ((pwd = getpwnam(lusername)) == NULL) + pwd = &nouser; + endpwent(); + } + } + + /* * If user not super-user, check for logins disabled. */ *************** *** 366,370 **** namep++; strcat(minusnam, namep); ! if (tty[sizeof("tty")-1] == 'd') syslog(LOG_INFO, "DIALUP %s, %s", tty, pwd->pw_name); if (pwd->pw_uid == 0) --- 454,458 ---- namep++; strcat(minusnam, namep); ! if (tty[sizeof("tty")-1] == 'd' && strcmp(pwd->pw_shell, UUCICO) != 0) syslog(LOG_INFO, "DIALUP %s, %s", tty, pwd->pw_name); if (pwd->pw_uid == 0) -- Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228 UUCP: {arizona,decvax,ncar}!noao!grandi or uunet!noao.edu!grandi Internet: grandi@noao.edu SPAN/HEPNET: NOAO::GRANDI (NOAO=5355)