rick@seismo.CSS.GOV (Rick Adams) (12/29/88)
This is a PERFECT example of why you should have a separate login for each uucp connection. Anything less invites site "spoofing" as is taking place. --rick
jbayer@ispi.UUCP (Jonathan Bayer) (12/29/88)
In article <10420@rpp386.Dallas.TX.US>, jfh@rpp386.dallas.tx.us (The Beach Bum) writes:
=
=
= I was thinking about various security problems I have with this system
= and a possible problem on other systems occurred to me.
=
= This site has a public access UUCP connection. The login and phone
= number are both well known. I have long been aware that having this
= information be public is inviting crackers to come visiting, and in
= the last three months or so, I have been the subject of a few failed
= attempts. So, I have been on my guard since this site was first put
= on the net a year ago, and each new attempt gives me more points to
= ponder.
=
= Today I thought about another possible problem - the well connected
= site. Say that there exists a very well connected site. One which
= talked with a large fraction of the net. For example, uunet. The
= system name is known, and because the system is well managed, the
= connection might even be trusted. So, the scenario is that a cracker
= tries to gain access to a site using `uunet' as its system name and
= sees what is available.
=
= Well, this is exactly what happened here today. Below are the log
= entries from an aborted attempt:
=
= uucp uunet (12/27-15:42) OK (startup)
= uucp uunet (12/27-15:42) REQUESTED (S D.rpp386c3ec27 X.rpp386C6c3e yls - yls)
= yls uunet (12/27-15:42) REQUESTED (R /usr/mail/uucp /usr/spool/uucppublic yls -dc dummy 777 yls)
= yls uunet (12/27-15:42) USERFILE: access denied (/usr/mail/uucp)
= yls uunet (12/27-15:42) REQUESTED (R /etc/passwd /usr/spool/uucppublic/passrpp yls -dc dummy 777 yls)
= yls uunet (12/27-15:42) USERFILE: access denied (/etc/passwd)
= yls uunet (12/27-15:42) OK (conversation complete)
= uucp br549 (12/27-15:42) yls XQT DENIED (uucp -C /usr/spool/uucppublic/* br549!/usr/spool/uucppublic )
=
The first question is:
Is there a password for uunet on your system?
if so, then:
How did this person get the password?
If he got it from uunet, then the obvious result is:
UUNET HAS HAD A MAJOR SECURITY BREAK. SOMEBODY HAS A COPY OF UUNET's
Systems FILE, AND HAS ACCESS TO EVERY SYSTEM THAT UUNET CALLS UP.
Obviously, if you don't have a password for uunet then you are taking a
major risk, since anybody who wishes to can dial up and log in as uunet.
--
Jonathan Bayer ------------------------------------
Intelligent Software Products, Inc. "The time has come," the Walrus said...
19 Virginia Ave. ------------------------------------
Rockville Centre, NY 11570 (516) 766-2867bill@ssbn.WLK.COM (Bill Kennedy) (12/30/88)
In article <44465@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: > >This is a PERFECT example of why you should have a separate login >for each uucp connection. > >Anything less invites site "spoofing" as is taking place. > >--rick I had a similar intrusion which prompted me to set up separate logins for each uucp neighbor and separate Permissions appropriate to each site. That managed to keep the cracker out but they still tormented the modems until something more interesting distracted them. I carried it still a step further (after new logins and passwords). The attack that prompted me to do it was quite recent, not the successful intrusion I refer to below. I set up a separate group that is exclusively for uucp neighbors and my own local user account. I then removed "other" execute permissions from uucico and Uutry and "other" write permissions from almost everything. This keeps a mischievious local user (I'm not aware of any) from running a uucico by hand and watching the phone number and login information from being displayed or doing it with Uutry and having it saved to a file! Putting my local account in that group lets me work with the Systems, etc. files without having to su. I'm almost glad this subject came up because it's a more benign reminder of the need for security for uucp connections as well. When this site was vandalized about two years ago it took a low level format on the disks and a re-install to be certain that all of the holes got shut (at least the ones I know about). I never expected an intruder to get into uucico, I'm unsure what they could accomplish (other than what has already been posted). The next measure for this site is to have a "gatekeeper" system whose duties and capabilities are restricted to news and mail and having the system with the sensitive data one level back from the phones. Yes, I'd like to spread my paranoia. The memory of the incident that caused the paranoia is as vivid as if it happened yesterday. I would have much preferred becoming paranoid by reading a news article. Your system is not secure since you have agreed to let it have uucp neighbors and telephone access (nor is mine). That's all the more reason to be beady eyed and hard nosed about what little security you have left. -- Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM
roy@phri.UUCP (Roy Smith) (12/30/88)
bill@ssbn.WLK.COM (Bill Kennedy) writes: > I had a similar intrusion which prompted me to set up separate logins for > each uucp neighbor and separate Permissions appropriate to each site. We had a uucp breakin a while ago (described in vivid detail on the old security mailing list several years back). The major faults in our security system were violations of the most basic rules. First, one of our uucp neighbors kept his L.sys file world-readable and second, we had a user account here with no password on it. The point of this message is to underscore that before you go off arguing about the fine points of your security system, you should make sure that your front door is not wide open. My experience is that the single biggest threat to system security is simple carelessness about passwords. People pick bad ones (or none at all), write them down in obvious places, tell other people what they are, never change them, and resist all efforts by system administrators to make them alter their ways. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
rick@seismo.CSS.GOV (Rick Adams) (12/31/88)
> I set up a separate group that is exclusively for uucp neighbors and my > own local user account. I then removed "other" execute permissions from > uucico and Uutry and "other" write permissions from almost everything. > This keeps a mischievious local user (I'm not aware of any) from running > a uucico by hand and watching the phone number and login information from > being displayed or doing it with Uutry and having it saved to a file! > Putting my local account in that group lets me work with the Systems, etc. > files without having to su. If uutry allows people without normal read access (i.e. use the access system call on the System file) to run uucico with debugging, then it is badly broken and should be fixed. The BSD uucico fixed this many years ago.
rick@seismo.CSS.GOV (Rick Adams) (12/31/88)
Note that UUNET DOES NOT HAVE A CONNECTION TO THIS SITE. There is no security problem on uunet (that I know of...)
rogerk@mips.COM (Roger B.A. Klorese) (12/31/88)
In article <44466@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >If uutry allows people without normal read access (i.e. use the access >system call on the System file) to run uucico with debugging, then it >is badly broken and should be fixed. The BSD uucico fixed this >many years ago. If I remember correctly, it allows debugging but prints ??????? for the chat script, which seems like a reasonable approach. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 928 E. Arques Ave. rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) Sunnyvale, CA 94086 I don't think we're in toto anymore, Kansas. +1 408 991-7802
jbayer@ispi.UUCP (Jonathan Bayer) (01/01/89)
In article <44467@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:
=Note that UUNET DOES NOT HAVE A CONNECTION TO THIS SITE.
=
=There is no security problem on uunet (that I know of...)
My apologies. I spoke without knowing the complete story. I hereby award
myself 3 lashes with a wet noodle.
--
Jonathan Bayer ------------------------------------
Intelligent Software Products, Inc. "The time has come," the Walrus said...
19 Virginia Ave. ------------------------------------
Rockville Centre, NY 11570 (516) 766-2867dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (01/04/89)
In article <10445@admin.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >In article <44466@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >>If uutry allows people without normal read access (i.e. use the access >>system call on the System file) to run uucico with debugging, then it >>is badly broken and should be fixed. The BSD uucico fixed this >>many years ago. > >If I remember correctly, it allows debugging but prints ??????? for the >chat script, which seems like a reasonable approach. This is true, but if you have echo turned on by default, or your Dialer file turns it on for Hayes-type modems (ex. Telebit) they will see the modem echo the commands back. Unfortunately, having echo on is useful for debugging, and I have my script set up to "send A, expect A, else send A, expect A" etc trying to make sure the serial port and the modem are at the same baud rate. Does anyone know if "ATS50=255E=0\rATDT0123456789E=1\r" will do the correct thing (ie. turn on echo back on before dialing the telephone number)? Dan -- Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102
mike@ists.ists.ca (Mike Clarkson) (01/05/89)
In article <44466@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > If uutry allows people without normal read access (i.e. use the access > system call on the System file) to run uucico with debugging, then it > is badly broken and should be fixed. The BSD uucico fixed this > many years ago. SCO Xenix hasn't fixed this. At least as of 2.2.1 (last year). (Note that rpp386 is listed as an SCO Xenix 2.2.1 site in the maps.) Mike. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.ists.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
mike@ists.ists.ca (Mike Clarkson) (01/05/89)
In article <10420@rpp386.Dallas.TX.US>, jfh@rpp386.dallas.tx.us (The Beach Bum) writes: > Well, this is exactly what happened here today. Below are the log > entries from an aborted attempt: > > ... > uucp br549 (12/27-15:42) yls XQT DENIED (uucp -C /usr/spool/uucppublic/* br549!/usr/spool/uucppublic ) ^ | Note that the intruder was not very bright: | No uucp that I know of will expand * | Mike. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.ists.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
andys@genesis.ATT.COM (a.b.sherman) (01/06/89)
In article <44466@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >> I set up a separate group that is exclusively for uucp neighbors and my >> own local user account. I then removed "other" execute permissions from >> uucico and Uutry and "other" write permissions from almost everything. >> This keeps a mischievious local user (I'm not aware of any) from running >> a uucico by hand and watching the phone number and login information from >> being displayed or doing it with Uutry and having it saved to a file! >> Putting my local account in that group lets me work with the Systems, etc. >> files without having to su. > >If uutry allows people without normal read access (i.e. use the access >system call on the System file) to run uucico with debugging, then it >is badly broken and should be fixed. The BSD uucico fixed this >many years ago. The Basic Networking Utilities (HoneyDanBer UUCP) on System V Release 3 (maybe earlier) does not give out passwords to non-super users. It will display copious debugging information to anybody, but all strings *SENT* are displayed as ?????????? to all but root. If you are so bold as to have no uucp password, anybody can use this to figure out how to get in to your system, since uucico is happy to display anything you echo back (like the login id). If you have a password, there is no security breach. -- andy sherman / at&t bell laboratories (medical diagnostic systems) room 2e-108 / 185 monmouth pkwy / west long branch, nj 07764-1394 (201) 870-7018 / andys@shlepper.ATT.COM ...The views and opinions are my own. Who else would want them?
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/07/89)
>No uucp that I know of will expand *
Honey DanBer will, if the target system has been given execute permission
for the uucp command.len@netsys.COM (Len Rose) (01/08/89)
# If you are so bold as to have no uucp password, anybody can use this
# to figure out how to get in to your system, since uucico is happy to
# display anything you echo back (like the login id). If you have a
# password, there is no security breach.
If you have your Permissions file set up correctly , you can run with
no password. HoneyDanBer or BNU as AT&T likes to describe it has several
options in /usr/lib/uucp/Permissions that can be set to lock down any
account. Running with "nuucp" and no password is safe if you have your
Permissions file set up correctly.
--
len@netsys.com
{ames,att,rutgers}!netsys!lenjc@minya.UUCP (John Chambers) (01/09/89)
In article <10420@rpp386.Dallas.TX.US>, jfh@rpp386.dallas.tx.us (The Beach Bum) writes: > > ... the scenario is that a cracker > tries to gain access to a site using `uunet' as its system name and > sees what is available. > > Well, this is exactly what happened here today. Below are the log > entries from an aborted attempt: > > uucp uunet (12/27-15:42) OK (startup) > uucp uunet (12/27-15:42) REQUESTED (S D.rpp386c3ec27 X.rpp386C6c3e yls - yls) > yls uunet (12/27-15:42) REQUESTED (R /usr/mail/uucp /usr/spool/uucppublic yls -dc dummy 777 yls) > yls uunet (12/27-15:42) USERFILE: access denied (/usr/mail/uucp) > yls uunet (12/27-15:42) REQUESTED (R /etc/passwd /usr/spool/uucppublic/passrpp yls -dc dummy 777 yls) > yls uunet (12/27-15:42) USERFILE: access denied (/etc/passwd) > yls uunet (12/27-15:42) OK (conversation complete) > uucp br549 (12/27-15:42) yls XQT DENIED (uucp -C /usr/spool/uucppublic/* br549!/usr/spool/uucppublic ) > This reminds me of one complaint I've always had about UUCP, and which the new, improved documentation for hdb hasn't helped much. There are all these nice log files that look like they should help a lot in the task of diagnosing such attacks. But the logs are rather cryptic, and it's not always clear just what's going on. It would help a whole lot if someone could provide a detailed manual on how to interpret UUCP logs. For instance, I've noticed that the first two fields, which obviously contain ids and sysnames, can refer to either end of the connection. In comparing log entries with what actually happened, I find it quite difficult to determine what the rules are. In the above example, is "yls" an id on the sending or receiving end? Or should the terms be "originating" and "accepting" or "master" and "slave"? Sure, you can determine in this case by looking at the password file, but sometimes the id is in both files. In the last line, is "uucp" referring to the id on rpp386 or br549 or the pseudo-uunet? To make effective use of the logs for tracking down security problems, it would help a lot if I could look at a log entry and say EXACTLY what it means. Right now, I work mostly on the basis of what it COULD mean, and quite a bit of the log turns out to be ambiguous. Note that I'm not criticising the existing UUCP security, which I find quite a bit better than any of its competitors. The complaint is about the still-incomplete documentation. I understand that it takes time to do all this, and the log files are rather version-dependent (in addition to be an internal file of a proprietary package), and all that. Still, it would be a big help if it were better documented. This is definitely a case where secrecy and obscurity helps those trying to violate security, and administrators would be helped a lot by full documentation. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (01/09/89)
While we're bitching about the contents of the uucp logs, let me add my complaint. I've had some trouble with modems and phones lines, and a h*** of a time figuring out what was going on, because uucp only logs the device used on a SUCCESSFULL connection. If the connection fails, I have no idea which line was used. I figured out I had a modem configured incorrectly by noticing I never had a successful outgoing session logged for that line. Frustrated Dan -- Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102
chip@vector.UUCP (Chip Rosenthal) (01/10/89)
In article <9@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >There are all these nice log files that look like they should help a lot >in the task of diagnosing such attacks. But the logs are rather cryptic This is a valid complaint. That's one of the reasons why the "Managing uucp and Usenet" Nutshell handbook is so helpful. Probably why uunet gives them away why you signup. -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.