The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 9 Issue 35

Wednesday 25 October 1989

Contents

o Offensive message on electronic information board
Bob Morris
John Crider
o 14-year-old cracks TRW credit for major fraud
Rodney Hoffman
o Foreplay Doesn't Effect Response Time
Don Hopkins
o "Computer Virus Countermeasures" Article
Will Martin
o Hardware failure mimics hackers
Rob Wright
o Info on RISKS (comp.risks)

Offensive message on electronic information board

<RMorris.CCS@DOCKMASTER.NCSC.MIL>
Wed, 25 Oct 89 12:52 EDT
          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]


14-year-old cracks TRW credit for major fraud

Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>
25 Oct 89 09:02:23 PDT (Wednesday)
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."


Foreplay Doesn't Effect Response Time

Don Hopkins <don@cs.UMD.EDU>
Wed, 25 Oct 89 02:56:41 -0400
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]


"Computer Virus Countermeasures" Article

Will Martin <wmartin@STL-06SIMA.ARMY.MIL>
Wed, 25 Oct 89 10:02:48 CDT
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]


Hardware failure mimics hackers

"Rob Wright, VMS Systems Group, Curtin University" <CROBW@mail.cut.oz.au>
Fri, 6 Oct 89 11:02 +8:00
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.

Please report problems with the web pages to the maintainer

Top