RISKS-LIST: RISKS-FORUM Digest Wednesday 25 October 1989 Volume 9 : Issue 35 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Offensive message on electronic information board (Bob Morris, John Crider) 14-year-old cracks TRW credit for major fraud (Rodney Hoffman) Foreplay Doesn't Effect Response Time (Don Hopkins) "Computer Virus Countermeasures" Article (Will Martin) Hardware failure mimics hackers (Rob Wright) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: Wed, 25 Oct 89 12:52 EDT From: RMorris.CCS@DOCKMASTER.NCSC.MIL Subject: Offensive message on electronic information board Offensive Message Flashes at Busy City Corner By Linda Wheeler Washington Post, October 25, 1989 An offensive message that mystified the owners of an electronic information board was flashed Monday at Connecticut Avenue and L Street NW, one of the city's busiest intersections. A Georgetown University law student, Craig Dean, said he saw the message "HELP STAMP OUT A.I.D.S. NOW: KILL ALL QUEERS AND JUNKIES" flash five times in 25 minutes. Minutes after seeing the message, he called the city Human Rights Office and the Washington Blade, a gay community newspaper. Doug Hinckle, a staff photographer for the Blade, saw the message flash once and photographed it. ... Judith Miller, president of Miller Companies, which own the building at 1101 Connecticut Ave. NW and the message board, said she did not know how the statement got onto the board. She refused to believe it had appeared until told of the photographs. Her company has complete control of the board and does not accept any paid messages or advertisements, Miller said. "I would never do anything like that," she said. "There is no way I would allow such a statement to appear."... Yesterday, Keller, a five-year employee of the Miller Companies, said he did not write the statement and does now know how it became part of the normal flow of headline news. Miller said she believes her computer system may have a "virus" and will have experts search to find where the unauthorized statement originated. "How absolutely awful," she said of the message. ... [Also noted by John Crider, crider@itd.nrl.navy.mil, who added: Possibly another case of how media-induced heightened awareness, this time about viruses, can lead to the emergence of a new scapegoat; years ago the operator would have been fired on the spot, but now it's a viral infection. Both are knee-jerk reactions - conclusions should come AFTER the facts are examined. -John Crider] ------------------------------ Date: 25 Oct 89 09:02:23 PDT (Wednesday) From: Rodney Hoffman Subject: 14-year-old cracks TRW credit for major fraud Condensed from a story by Jennifer Warren in the 'Los Angeles Times' 18-Oct-89: A 14-year-old Fresno, CA boy obtained secret "access codes" to the files of TRW Credit from a bboard and used them to pose as a company or employer seeking a credit history on an individual whose name he picked randomly from the phone book. From the histories, he obtained credit card numbers which he then used to charge at least $11,000 in mail-order merchandise (shipped to a rented storeroom) and make false applications for additional cards. He also shared his findings on bboards. Police began investigating when TRW noticed an unusual number of credit check requests coming from a single source, later found to be the youth's home telephone number. The high school freshman, whose name was not released, was arrested at his home last week and later released to his parents. His computer was confiscated and he faces felony charges that amount to theft through the fraudulent use of a computer. "Here's a 14-year-old boy with a $200 computer in his bedroom ... and now he has shared his data with countless other hackers all over the nation," said Fresno Detective Frank Clark, who investigated the case. "The potential [for abuse of the information] is incredible." ------------------------------ Date: Wed, 25 Oct 89 02:56:41 -0400 From: don@cs.UMD.EDU (Don Hopkins) Subject: Foreplay Doesn't Effect Response Time Computer Sex Game In Ambulance System (Associated Press) The Washington Post, Tuesday, October 25, 1987 NEW YORK, Oct. 23 -- A sex-oriented game is in the computer that monitors city ambulances, but an official dismissed speculation that the game could distract dispatchers or lead to computer problems. John Petrofsky, a computer consultant for the Emergency Medical Services, said in the New York Post that "Foreplay" has been in the EMS system since September 1988. The program could slow the computer or stop it for 30 minutes, Petrofsky said. It also might carry a "virus" that could shut down the computer for two days, he said. EMS spokeswoman Lynn Schulman said the inspector general of the Health and Hospitals Corp. had confirmed that the game was in the system, but she said it had no effect on response time, which has been reduced in recent months. [Also indirected from Geoff Goodfellow] ------------------------------ Date: Wed, 25 Oct 89 10:02:48 CDT From: Will Martin Subject: "Computer Virus Countermeasures" Article Readers of RISKS might be interested in a rather strange article in the October '89 issue of DEFENSE ELECTRONICS, p. 75, entitled "Computer Virus Countermeasures -- A New Type Of EW" [EW = Electronic Warfare], by Dr. Myron L. Cramer and Stephen R. Pratt (both of Booz, Allen & Hamilton, Inc.). The reason I consider this "strange" is because the whole thrust of the article is how computer-based ECM [Electronic CounterMeasures] and EW systems could be infected by viruses which are transmitted over the air and enter those systems or their components via the normal sensing channels -- that is, they would pick up a digital stream the same way they would pick up an enemy radar signal, and that digital stream would contain code which would somehow find its way into the executable code for the system's processor(s). That whole concept seems very odd to me. Maybe I just don't know enough about the field to really understand this, but I cannot see how input data, which the system designers already know could be any electromagnetic signals or noise impinging on the system's sensors or antennae, could get intermixed with or interfere with the operating executable code of the sensor device or a central processor that is collecting and analyzing such data. It is certainly obvious that an enemy agent working in or having access to the source of the software controlling such a computer-based EW system could implant a trojan horse or backdoor access into that software before it is fielded. Perhaps then the enemy could transmit a special sort of signal that woud trigger the execution of such code in fielded systems, which would then self-destruct or provide erroneous results or otherwise misbehave. But I find it hard to envisage how some signals from outside, within the operational environment of such an EW system, could do anything to the executing code within embedded microprocessors or larger support computers. [Except of course something like EMP or an electromagnetic-signal barrage that would just scramble the memories or damage the components of inadequately-shielded devices. But that would just render them inoperative, and would be the EW equivalent of blowing some holes in them. :-) It wouldn't surreptitiously install new code...] The article does mention the idea of letting the enemy steal EW equipment or designs which have embedded in them trapdoor or other methods for allowing their functions to be subverted or controlled after they have been installed in enemy operational systems. I think this idea was used by Tom Clancy in _Cardinal of the Kremlin_ or another of his books. Other methods mentioned include contaminating maintenance or diagnostic software with a virus. Those all seem fairly straightforward paths into executable software, but I still have problems trying to understand how sensed data could interfere with or modify executable code. Getting some virus program in the input data to go inside the operating code seems to me to be practically impossible, unless there is some sort of doorway or hole in that code that had previously been illicitly hidden there. It's sort of like the "blood-brain barrier" that makes it hard to deliver drugs into certain parts of the nervous system. Is there something basic here I'm just not understanding, or is this article's basic premise flawed? Regards, Will Martin [Trapdoors abound. The sendmail debug option and the gets missing bounds check are recent reminders of the nature of the problem. Out-of-band signals also may trigger trapdoor effects. Furthermore, whether these effects result from an accidental flaw in the system or a preplanned Trojan horse program that would wait for the attack to be triggered, the results could be serious in either case. PGN] ------------------------------ Date: Fri, 6 Oct 89 11:02 +8:00 From: "Rob Wright, VMS Systems Group, Curtin University" Subject: Hardware failure mimics hackers Synopsis: Two systems - same day, same symptoms. Hackers? No, hardware! Dateline, Monday 20th September 1989, Bentley, Western Australia. Curtin University of Technology. The VAX-11/750 computer in the Geophysics Laboratory refused to allow any user to log in. All passwords, including SYSTEM were declared invalid. The system manager contacted me and I showed him how to break in. There appeared to be some disk damage, but after setting all passwords to known values, the system was apparently usable. Shortly thereafter all was not well. Indeed, after any two users were logged in the system refused further logins, complaining that the licensed number of system users had been exceeded. Given that this particular machine (running VMS 4.7) has never been a microVAX, the only class of system which imposed such a limit, I naturally suspected foul play. At this stage I was sure that the system had been hacked, and was recommending a total re-installation of all the software, starting from known, reliable distribution tapes. Then I read on the net that Columbia University Plasma Physics Laboratory has the very same set of symptoms and on the same date:- >From: IVERS%CMR.MFENET@CCC.NMFECC.GOV >Subject:Virus or coincidence? >Date: 20 Sep 89 03:41:04 GMT >Message-ID:<890919204104.47800129@CCC.NMFECC.GOV> > >On Monday morning, our users (including the system manager) were surprised to >find that they could no longer log in to our VAX 11/750 (VMS V4.5). >Coincidentally, one user reported the appearance of several files in >his directory with names like WARNING., VIRUS., and ATTACK.. He thought >it was a joke and said nothing at the time the files appeared. > >The system was booted with UAFALTERNATE =1. It appeared that SYSUAF.DAT >was intact, but the passwords were no longer valid. A SYSUAF.DAT file >was restored from a backup set and new passwords were issued. The problem >is that now when more than 2 users attempt to use the system, a message >of the type LICENSED NUMBER OF SYSTEM USERS EXCEEDED appears. > >As for the "virus" files - all that remains are subdirectories of names >similar to the files reportedly seen by the user (one of them is called >[.DEADLY-VIRUS]). > >Any ideas as to the cause or cure of the LICENCED NUMBER OF... problem, >or insight into the nature of the "virus" would be appreciated. > > Thanks in advance, > Tom Ivers (system manager) > Columbia U. Plasma Physics Lab > Internet: IVERS@CUPLVX.APNE.COLUMBIA.EDU > MFEnet: IVERS@CMR My confidence in the hacking hypothesis rose by leaps and bounds. Then the advice starts to roll in:- >From: coburn@clovax.enet.dec.com (John T. Coburn) >Subject:Re: Virus or coincidence? >Date: 20 Sep 89 23:25:20 GMT >Message-ID:<836@mountn.dec.com> >The LOGINOUT.EXE image in SYS$SYSTEM would seem to be damaged, probably by the >virus attack that occurred. This may not be the only image damaged or changed. >You should restore the disk from a good backup tape. This is the only way you >can be sure of removing all artifacts of a virus attack. >A short term fix for the LICENSED NUMBER OF... problem is to get a good copy of >LOGINOUT.EXE off a backup tape (or your distribution tape VMS V4.4 - be sure to >check the V4.5 upgrade to see if it changed LOGINOUT.EXE). >From: dragon@NSCVAX.PRINCETON.EDU (Richard B. Gilbert) >Subject:Re:Virus or coincidence? >Date: 21 Sep 89 00:57:49 GMT >Message-ID:<8909210036.AA10261@ucbvax.Berkeley.EDU> > I think you've been well and truly screwed. The safest thing to do >is to scrub your disk and restore from a backup that you are certain is >clean. > > I have this horrible feeling that SYS$SYSTEM:LOGINOUT.EXE has been >patched or replaced. Only extensive checking would reveal what else has >been tampered with. You had better assume that any sensitive information >on your system has been compromised and that _anything_ may have been >tampered with! > > Even after you restore your system, you will still be vulnerable to >a repetion of the same attack! You will need to read and heed the "Guide >to VMS Security". You should probably have security alarm ACLs on >SYS$SYSTEM:SYSUAF.DAT, SYS$MANAGER:SYSTARTUP.COM or SYSTARTUP_V5.COM, >SY$MANAGER:SYLOGIN.COM and perhaps a couple of other things. This will >not prevent a breakin but it will make it tougher to do it tracelessly. >Check your modem lines if any. Are they all set /MODEM /HANGUP /DIALUP? >If not, they provide a potential entry point for a cracker. > > Priveleged accounts such as FIELD, and SYSTEST should be kept turned >off with /FLAGS=DISUSER and enabled only when needed. > > The default DECnet account also provides a potential point of entry. > > I'm real glad I'm not in your shoes. >From: @YMIR.BITNET:KVC@FRIDAY.A-T.COM ("Kevin V. Carosso") >Subject:Re: Virus or coincidence? >Date: 21 Sep 89 00:57:00 GMT >Message-ID:<4EA69B97FB5FE04D85@YMIR.BITNET> >The fact that you are running VMS V4.5 and getting the "USERS EXCEEDED" >message is an important clue. User limits for MicroVMS were enforced by >code in LOGINOUT.EXE. When you upgraded your license on your MicroVAX, >say from 2 users to 8, DEC sent you a VMSINTAL kit which patched LOGINOUT." > >The fact that your 750 suddenly has a user limit of 2 (indeed any limit at all) >and is not running VMS V5 means that you may be running with a LOGINOUT.EXE >copied from a MicroVMS system. One distinct possibility is that someone >took the LOGINOUT.EXE from a MicroVMS system, possibly patched in their >own trapdoor, and copied it to your 750 replacing the standard >SYS$SYSTEM:LOGINOUT.EXE. > >A couple of years ago there were a rash of breakins to VMS machines >characterized, in part, by patched LOGINOUT.EXE's being left behind. > >You should consider restoring LOGINOUT.EXE from tape. You also might want >to save the suspicious one and check it out with ANALYZE/IMAGE (which will >report PATCH information unless the image was patched without using >the standard VMS PATCH utility). > Finally Tom Ivers contacts me:- >From: IN%"Thomas.Ivers%CUPLVX.APNE.COLUMBIA.EDU@munnari.OZ" 2-OCT-1989 10:53:09.83 >To: CROBW@acad.cut.oz >CC: >Subj: Coincidence (not virus) > >Rob, > Our problems have been traced to a bad floating point accelerator in >our /750. Evidently, the virus files were a benign coincidence. You can >check this on your system by pulling your FPU and rebooting. (You'll have >to do a CONVERSATIONAL BOOTSTRAP because you'll find the passwords are mangled >after pulling the board). Otherwise, things should work fine without the FPU - >a bit slow, perhaps. Hope this helps. Sure enough, when the FPA was replaced in our Geophysics machine the problems vanished. Apparently the FPA is used for password encryption. No one has satisfactorily explained the 'licensed users exceeded' phenomenon. As to the failure mode of this subsystem, one presumes that those computing at the time of the failure would have some wrong answers, but further users were spared this worry by not being able to access the system. ------------------------------ End of RISKS-FORUM Digest 9.35 ************************