Subject: RISKS DIGEST 14.36 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 24 February 1993 Volume 14 : Issue 36 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: 3rd Conf. on Computers, Freedom, & Privacy, CFP 1993 (Bruce R. Koball) 2nd Conf. on Computers, Freedom, & Privacy -- PROCEEDINGS (Lance J. Hoffman) Educational Loan Services -- ELSI (Steve Hoffman) Phone problems: Re: "...Phone Jam", and a new problem (Bill Warner) MIT's on-line Student Information Services (Steve Bellovin) Kerberos and password-guessing attacks (Jonathan Kamens) Re: Tapping Phones (Fred Cohen) Re: On-line services (lack of) security (Bill Seurer) Re: request for opinions on Artificial Life (Bill Humphries) The RISKS Forum is a moderated digest discussing risks; comp.risks is its Usenet counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Wed, 24 Feb 1993 11:05:46 -0800 From: Bruce R Koball Subject: Third Conference on Computers, Freedom, and Privacy, CFP 1993 There's still time to register for CFP'93! A number of spaces in this limited-attendance event are still available, so act now! The Third Conference on Computers, Freedom and Privacy, 9-12 March 1993 San Francisco Airport Marriott Hotel, Burlingame, CA The sessions in the main program include: * ELECTRONIC DEMOCRACY * ELECTRONIC VOTING * CENSORSHIP AND FREE SPEECH ON THE NET * PORTRAIT OF THE ARTIST ON THE NET * DIGITAL TELEPHONY AND CRYPTOGRAPHY * HEALTH RECORDS AND CONFIDENTIALITY * THE MANY FACES OF PRIVACY * THE DIGITAL INDIVIDUAL * GENDER ISSUES IN COMPUTING AND TELECOMMUNICATIONS * THE HAND THAT WIELDS THE GAVEL * THE POWER, POLITICS AND PROMISE OF INTERNETWORKING * INTERNATIONAL DATA FLOW The conference will also offer a number of in-depth tutorials on subjects including: * Information use in the private sector * Constitutional law and civil liberties * Investigating telecom fraud * Practical data inferencing * Privacy in the public and private workplace * Legal issues for sysops * Access to government information * Navigating the Internet INFORMATION For more information on the CFP'93 program and advance registration call, write or email to: CFP'93 INFORMATION 2210 SIXTH STREET BERKELEY, CA 94710 (510) 845-1350 cfp93@well.sf.ca.us A complete electronic version of the conference brochure with more detailed descriptions of the sessions, tutorials, and registration information is also available via anonymous ftp from sail.stanford.edu in the file: pub/les/cfp-93 [SEE ALSO RISKS-14.21 (with an address correction in 14.26). PGN] ------------------------------ Date: Thu, 4 Feb 93 16:58:10 EST From: "Lance J. Hoffman" Subject: 2nd Conf. on Computers, Freedom, & Privacy-written & elec. proceedings The written proceedings and the electronic written proceedings of the Second Conference on Computers, Freedom, and Privacy, sponsored by the Association for Computing Machinery and held March 18-20, 1992 in Washington, D. C. are now available. To obtain the written proceedings, contact the ACM Order Department, P.O. Box 64145, Baltimore MD 21264, 1-800-342-6626 or 1-410-528-4261 (MD, AK, and outside US). The ACM order number is 533921. The price is $15.00 for ACM members and $26.00 for others. To obtain the electronic proceedings, make an ftp connnection to ftp.gwu.edu and login as "anonymous". Get file CFP2S00, which has a table of contents describing the other files CFP2S01, CFP2S02, ..., CFP2S11. Get these files if you desire them. Professor Lance J. Hoffman, Dept of Electrical Engineering and Computer Science The George Washington University, Washington, D. C. 20052 (202) 994-4955 fax: (202) 994-0227 hoffman@seas.gwu.edu ------------------------------ Date: Wed, 24 Feb 93 07:27:00 PST From: Steve Hoffman 24-Feb-1993 0959 Subject: Educational Loan Services -- ELSI My mother recently received several telephone calls from an organization called Education Loan Services Inc (ELSI), of Braintree, Massachusetts. Neither she nor any other family member had ever heard of ELSI -- an organization that reputedly acts as a student loan clearing house, and as I have inferred from my conversations with them, as a collections agency. The callers asked for her (Marie) or for my wife (Kelly) concerning a student loan. (Both my wife and I have had student loans. Mom predates the modern concept of a student loan :-) Mom, being computer-literate and quite familiar with the more typical computer snarls, naturally assumed it was a computer error and that it concerned either Kelly or me -- she naturally assumed the ELSI database had not been updated to indicate that both of our student loans had been paid. After an extended conversation with a representative of ELSI, I found they were "cold calling" anyone with a name that matched those on their loan paperwork, and further, that the match with Kelly's name was (apparently) a fluke. Further, the only way they claimed they could confirm that they had a mistake was for me to provide them with Mom's social security number. ELSI refused to accept any other information from me -- length of time at address, differences in surnames, attendance at other schools, etc -- concerning the parties (not) involved, nor could they provide any information on the cosigners of the student loan they claimed they were calling on. When my mother called ELSI back, a (different) ELSI representative indicated that it appeared to be a simple mix-up on the area code, and that her portion of ELSI did not have direct access to the ELSI folks placing the outbound calls. (Which we found rather surprising.) Interestingly, a different ELSI representative had told me that ELSI was calling people based on directory services information -- and not based on a mixed-up telephone number on the loan paperwork. This situation strikes me as having multiple risks. I could have provided ELSI with a bogus social security number for Mom. (I declined to provide any number.) If ELSI could validate the social security number -- and I am quite certain they could, via any one of several credit bureaus -- they would have already known that mom wasn't a match. (And then why did they call?) Such an organization could also easily be illicit -- "scavenging" either for social security numbers or worse, scavenging payments from the parents of former students -- parents who might unknowingly send an ELSI-like organization a payment or two to keep their child from `defaulting'. Steve Hoffman hoffman@xdelta.enet.dec.com ------------------------------ Date: 23 Feb 1993 20:15:07 -0400 (EDT) From: warner@ohio.gov Subject: Phone problems: "...Phone Jam" (RISKS-14.31) and a new problem One of the major causes of the long time to get the data from the failed computer is that phone switches have a lot more 'state' that they did in the past. For example, the State of Ohio Centrex (where I work in the telecom office) is served by the switch which failed. We have somewhere over 20,000 lines (I don't keep up with the details.) In the past we had to configure options like Call Forward No Answer and Call Forward Busy with written service orders. But now each line has an option called Call Forward No Answer Universal (At least the name is close!) which allows someone at the phone to specify the number to Call Forward Busy to. This can be changed at any time. Therefore in the case of a switch failure you can not just return to the "standard" configuration, but must load a lot of 'state' information from the failed computer. This type of state is becoming more common in "fancier" features. It makes it much easier to manage a large number of phones! Features like call forwarding, which also require the switch to remember a number, are becoming more and more common. The State of Ohio phones were dead from about 14 minutes or so. This likely affected the Franklin County Ohio Highway Patrol Post's (and General Head Quarters) public numbers also. Also, in yesterday's Columbus Dispatch it looks like Ohio Bell lost another one: The Columbus Dispatch, Wed Feb 17, 1993 Page 3 C (Metro Section) (Small article at the bottom in Columns 1 & 2) "Blown Fuse disrupts phone service" A blown fuse in the Ohio Bell switch serving 54,768 telephone lines in Worthington disrupted service throughout the day yesterday. Repairs were expected to be completed last night. Ohio Bell Spokesman Keith Jameson said 911 and other emergency numbers remained in operation, although getting a dial tome within the affected area was slow. Calling into the area was difficult most of the day, since Ohio Bell purposely blocked 75 percent of incoming calls while repairs were under way. Jameson said that strategy enabled people within the area to make calls. By 5 PM, the company had reduced blocked incoming calls to 50 percent. The switch shut down at about 10:30 AM, when at least one fuse blew, but Jameson said there may be other problems with the switch. The problem was not weather related, he said. William "Bill" Warner, III (N8HJP), State of Ohio - Telecommunications 2151 Carmack Rd, Columbus, OH 43221 (614)466-6683 warner@ohio.gov (Internet) ------------------------------ Date: Wed, 24 Feb 93 12:21:43 EST From: smb@research.att.com Subject: MIT's on-line Student Information Services (Kamens, RISKS-14.35) >In order to use SIS to access personal data, a user must first register an >"extra" password with the Kerberos database. The program that registers this >password does so by transmitting it to the Kerberos server in encrypted form >(using a key derived from the user's main Kerberos principal, for which he >already has a password) so that it isn't exposed to the network. But has the Kerberos protocol been beefed up yet to guard against password-guessing attacks? As Michael Merritt and I noted in our critique of Kerberos (Winter Usenix, 1991, Dallas), Kerberos is vulnerable to password-guessing. An intruder, from anywhere on the Internet and without any authentication, can request ticket-granting tickets for any user. These are encrypted with a key derived from the user's password. But guessing at passwords is an old game -- and one that succeeds, with ~25% probability, against typical UNIX system passwords. Kerberos is somewhat more secure, since it permits passwords to be longer than 8 characters, but I'm unaware of any study that's been done to find out if people actually take advantage of this. Granted, such attacks may not succeed against any particular student. But against a collection of students, the odds are pretty good that some will be vulnerable. I've seen proposals to strengthen Kerberos against such attacks, but I don't know if these have been deployed yet. And there are protocols that prevent any password-guessing attacks, even by eavesdroppers (i.e., Lomas et. al, 1989 SOSP; Bellovin and Merritt, 1992 Oakland Symposium). My point here is not to criticize the designers of SIS. All things considered, they seem to have done a very good job; the only other safeguard I can think of would be to notify the student of any new uses of the SIS account. Rather, I'm trying to point out that secure systems can't be built on weak foundations. Intruders don't go through security; they go around it. --Steve Bellovin ------------------------------ Date: Wed, 24 Feb 93 18:14:16 -0500 From: "Jonathan I. Kamens" Subject: Kerberos and password-guessing attacks (was MIT's on-line Student Information Services (SIS)) From: smb@research.att.com Date: Wed, 24 Feb 93 12:21:43 EST But has the Kerberos protocol been beefed up yet to guard against password-guessing attacks? Yes. The most recent release of MIT Kerberos Version 4 includes kadmin protocol enhancements to allow for the rejection of weak passwords, and code on the server to check and reject weak passwords. I don't know if any V4 vendors have incorporated changes like this into their products; I suspect it will happen eventually if there is enough demand for it. Furthermore, MIT Kerberos Version 5 supports optional preauthentication. MD5 on the user's password, Smart Card technology, or some other technique (the code is pretty abstract, so new preauthentication types can be added relatively easily) is used to create a "magic cookie" which is passed to the server along with the TGT request. If the cookie is wrong, the server won't give the user a TGT to decrypt. Preauthentication can be required or optional on a principal-by-principal basis. MIT V5 doesn't yet have weak-password rejection in it, but the hooks for it are there, and it will be added before the first official (i.e., not beta test) V5 release. I don't think DCE Kerberos has preauthentication in it right now, and I don't think they plan to add it before the first official DCE release (If you want them to, and you're a member of the OSF, then let them know!). I don't know whether or not DCE Kerberos has weak-password rejection in it. It is true that both V4 and V5 are still vulnerable to network eavesdropping weak-password attacks, since an eavesdropper can watch for a TGT on the network and try to decrypt it once it arrives, even if he doesn't know the preauthentication magic cookie which convinced the server to send the TGT. However, weak-password rejection makes the risk of an attack of this sort minimal, and it is not vulnerable on an entire-Internet scale like the attack which Steve mentioned. (Thanks to Ted T'so, tytso@mit.edu, for confirmation of much of the information above about V5.) Jonathan Kamens jik@Aktis.COM ------------------------------ Date: Wed, 24 Feb 93 07:51:07 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: Re: Tapping Phones (Schumann, RISKS-14.35) I must disagree [with the statement] that I am creating an unrealistic security scare. In fact, even if you are running Kermit from a PC, there are ways for remote sites to inject commands/code into your machine. The same is true for many PC-based telnet, FTP, and Xmodem protocols. Here is a real example: An FTP program was commonly used at one university to transfer information between user PCs and a file server. One day, someone noticed files appearing on their computer that shouldn't have been there. On subsequent investigation it was found that the FTP protocol allowed remote users to send files into the PC whenever the PC was setup to do outgoing transfers. It turns out that this is one of the most popular - public domain - FTP packages around. At this one site, a password was added to the process to prevent exchange when the other party did not know the password - but - they did a poor job of it, and someone discovered a trivial way to get past it within a few days. Another?: The well known attack where you transmit characters to a remote terminal that tell the terminal to store a sequence of characters and play it back can be exploited to attack remote computers running terminal emulators that are accurate. If you run Kermit, you may find that the VT emulations are good enough to do the job. That's right - even if you are simply logged in typing commands, you can be had if the attacker is good enough at it and your package is a true emulation. In fact, when you login, you usually even tell the remote site what kind of terminal you are emulating, thus easing it's attack burden. Another? X-windows without the magic cookie allows remote users to watch what is being displayed on your screen over the network. Most X setups are insecure in this way - at least most of the ones I have seen. Another? Well - I'll hold off for now awaiting your response. My point still seems to hold - encrypting links is not adequate to prevent access to your data - encryption without good computer security is generally not adequate - the government or anyone else willing and able to go to the trouble can get you by exploiting the places you login to - it is not patently safe to login to on-line information services, even if you don't run their software. - FC ------------------------------ Date: Wed, 24 Feb 1993 13:45:09 -0600 (CST) From: Bill Seurer Subject: Re: On-line services (lack of) security (Schumann, RISKS-14.35) "Mark W. Schumann" writes in RISKS 14.35 >Prodigy, the latter service you mention, requires the use of its own front-end >program on your PC. You cannot use Prodigy without it. Since this front-end >program executes on your PC, it does have the potential for the abuse you >mention. I personally do not use Prodigy in part because of this security >loophole. Oh boy, let's kick Prodigy around some more. Long ago when I was a Prodigy subscriber and the rumors of Prodigy's uploading of stuff it shouldn't started I did some experiments the results of which were posted here. I proved (as best I could) that the rumors were probably unfounded and based on Prodigy's method of allocating disk space without clearing it of previous data first. Some other people who contacted me had done similar experiments with similar results. >On the other hand, other communication services, such as Compuserve, do not >have this questionable "feature" at all. America On-Line, TSN, and probably others also have special communication programs that you must use. Other services which do not REQUIRE a specific comm program nonetheless OFFER one that usually improves use of the service. Genie (for sure, Aladdin) and Compuserve (vague memory from years ago) both do. >You dial Compuserve from your PC with a communications program of your choice. >At all times the contents of your memory and hard drive are under the complete >control of your CPU and communications program. Yeah, but how do you know that the authors of PC-TALK, Qmodem, or whatever don't have a special hook in them that when you call up Compuserve it doesn't (semi-seriousness on) upload all your pitiful Tetris scores so the FBI can blackmail you? Or heck, maybe Microsoft has modified Windows or DOS to append juicy data to the end of files opened for uploading somehow. Maybe the FBI knows that the authors of Qmodem use Turbo C++ (or whatever) and have had Borland modify the compiler to insert this surreptitious uploading code into the comm program automatically when it is compiled. Maybe AMI has modified this BIOS to do something like this. Who can you trust? (paragraph about QUICKB deleted) >Bottom line: No online service can cause your PC to execute code that is not >in the PC's memory space, Prodigy notwithstanding. Not true as I have already shown. In any case, any service that tried something like this would be committing corporate suicide. People would notice that their modems were uploading all this data if by no other means than the Send Data light on their modem and the hard disk access light and doubtlessly one of them would figure out what was happening. Even at high speeds with top notch data compression it still takes a long time to transfer any significant amount of data. Maybe "they" could somehow work it into the background so whenever your modem sent data you wanted it to a little bit extra would get mixed in but that seems pretty pointless. - Bill Seurer Language and Compiler Development IBM Rochester, MN Internet: BillSeurer@vnet.ibm.com America On-Line: BillSeurer@aol.com ------------------------------ Date: Wed, 24 Feb 93 13:41:18 -0600 From: "Bill Humphries, Data Husbandry Flunky" Subject: Re: request for opinions on Artificial Life (Cohen, RISKS-14.34) I understand that most AL research is done by writing AL programs which run on a virtual computer. The practice is analogous to hacking E Coli which can only live on a particular medium which is not availiable outside the lab's petri dish. I have no problem with people publishing code, even code which could be put to 'sinister' ends (such as PGP). The author is not responsible for the actions of the reader or end-user. If you want to provide some sort of security, perhaps you can make a proprietary virtual machine which you distribute with the code in your book. The code would then only run on the virtual machine. This could provide some way of at least tracking the spread of malevolent AL programs. Obviously this is not a perfect solution, but hey, what that guy from NASA says, this isn't a risk free world. Bill Humphries : U. Wisconsin Economics : 608-262-4543 ------------------------------ End of RISKS-FORUM Digest 14.36 ************************