Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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]
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."
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]
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]
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