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…
Hi Gang!
On the risks of dealing with the press
How do you get the news out? What happens when you talk to reporters? How
accurate are news reports? As a part of my work on computer security, I had
a chance to research these questions. Here's my report. It has nothing to
do with computer risks, so died-in-the-wool RISKies ought to skip it.
In August 1986, we discovered someone breaking into LBL's computers, becoming
superuser, and then attacking other MILNET sites. Instead of closing our
doors to this bastard, we monitored and traced him for about a year. Since he
was privileged, we were at risk: at any time he might wreck our system. We
needed to keep our research a secret.
We contacted a few Bay area systems people and compared notes. Within a month,
someone leaked a bit of this to the San Francisco Examiner, and reporter John
Markoff mentioned LBL in an article on computer breakins. The article talked
about someone with the pseudonym "Pink Floyd". Three weeks after the article
appeared, the LBL intruder scanned our accounting files for user Pink Floyd --
aah, our intruder wasn't the same person, but surely read the news.
After getting burned by these leaks, we tried to keep our work silent. It
wasn't easy. Everyone wanted copies of our logbooks, althoug rarely did anyone
volunteer to help.
The FBI always wanted info, but would never tell me of any progress or
cooperation. In January 1987, I gave a copy of my logbook to the FBI, who
passed it to German authorities.
In June 1987, the SOB was arrested, and I thought we could go public. But the
FBI said that would screw up their indictments, so I kept my mouth shut. Every
2 weeks, I'd call them, and they'd say, "We're making progress. Don't
publicize anything or you'll sink the case."
In December, 1987, John Markoff of the San Francisco Examiner again picked up
LBL on his radar. Two people in Silicon Valley pointed him towards me, saying
that I knew about some hackers coming from Germany. I told him about the old
Chaos VMS breakins, which wasn't news. Didn't lie to him, I just didn't tell
him what I knew.
By Jan 1988, I doubted that the FBI would do anything, although they kept
saying otherwise. I wrote an article and submitted it to the Communications of
the ACM. The referees did a super job, and the paper was scheduled for the May
issue. We wanted a joint announcement in May to publicize both CACM and LBL.
In late February, Quick magazine of Germany called. They wanted to take my
picture for an article on some hackers. They didn't want to interview me, nor
did they ask any questions. We were puzzled, but LBL's Public Info Dept said
to let 'em take my picture. They did, but I told them nothing about what we
had done.
By early April, our plans were pretty well fixed. CACM would be in the mail by
May 9th, so CACM and LBL would jointly announce the news on that day. Karen
Frenkel of CACM along with LBL's public info guy, Chuck Hurly, made these
plans, and things were going well.
Going well until April 14th. The German magazine, Quick is a bit like a color
National Enquirer: sensationalism and scantily clad hussies. They ran a story
titled, "The Hunt for the Data Pirate". The story's based on my lab notebook.
Someone in Germany gave them a copy of my January 1987 notebook, and they wove
a story around it. The German guy hides behind a pseudonym, and they never
interviewed me. Indeed, the bulk of the story is from my notes. It's slightly
distorted since they've misinterpreted sections of my notes. Aaargh — what
should we do?
Friday, April 15th: Wire services pick up the Quick article, and reporters
start calling. We answer them, but say little. We schedule a press confrence
for Tuesday, April 19th, where we'll spill the beans. But LBL's Public Info
guy says that we owe an early release to John Markoff, since he twice stumbled
on the story, but each time I kicked dust in his eyes.
According to LBL's public information dept, you gotta be honest with the press,
or you'll get stung. In our case, we owed something to John Markoff. By now,
he's at the New York Times. We worked an agreement where I gave him a detailed
interview on Saturday, and the NY Times would publish the story on Tuesday,
April 19th. This way, we could alert the ACM folks, and have the press
conference on Tuesday morning.
Things foul up. Saturday evening, the NY Times editors decide not to embargo
the story. They'll run it Monday morning because, "Quick magazine's already
printed the story, so it's already been public". A Monday morning release
would destroy a Tuesday press conference: why come to hear yesterday's news?
Ignoring cogent arguments and pleadings, the Times will run it Monday morning,
no matter what. There'll be hell to pay...
Monday morning, April 18th. Front and center, above the fold, "Breach Reported
in US Computers"... LBL tells me to be invisible, so I hide out at the Oakland
IEEE Symposium on Security and Privacy. The CACM folks are justifibly upset -
we hadn't told them, yet the Communications of the ACM was prominently in the
article. A jillion reporters call my phone.
Press conference on Tuesday morning. Lots of fun. 3 dozen reporters, all
asking good, sharp questions. Ya can't dodge 'em, so you answer the best you
can. Afterwards, they crowd around and you the TV folks ask easy questions,
and the others ask barbed, jagged questions that snag at a half dozen issues.
Everything from Admiral Poindexter's "Sensitive but unclassified" policy to
set-user-ID questions.
Sensationalism? Distortion?
Hardly. Markoff's New York Times article distilled interviews with about 6
people, and was a much better summary than I could have written. The tone of
the article conveyed information, not speculation. I was astounded by its
comprehensive accuracy.
Follow-on articles in Bay area newspapers were impressively accurate and
non-sensational. The newspaper reports in the Oakland Tribune, SF Chronicle,
and Examiner went into depth of how we tracked the guy, and the relationships
between LBL and other agencies. SF Chronicle and Pittsburgh Post reporters
phoned the mysterious Laszlo Balogh in Pittsburgh, finding him to be a
self-described arms dealer for the Saudis. Lee Gomes of the Oakland Tribune
interviewed the guy in Hannover and found he's very touchy about saying who he
worked for. Even the Contra-Costa Times, hardly a great metropolitan
newspaper, meticulously separated speculation from facts.
Two weeks later, I'm finding reporters still digging out facts, and digging
into primary sources for information. My opinions of journalists has changed
180 degrees: behind our newspapers are damned hard working, incisive
reporters. There might be dodo reporters out there, but I haven't met 'em yet.
Lessions I've learned:
1) The press tries hard. More and more, I trust what I read.
2) Secrets can't be kept forever. Information diffuses.
3) Timing a press release is important, but tough.
4) Reporters won't sit on a story.
5) Avoid sensationalism and distortion by speaking plainly and directly.
6) Keep a notebook of everything that happens.
7) When you know facts, speak on the record. When you're speculating,
say so.
8) Publicity is like the wind. You can tell it's coming, but not what'll
be uncovered.
9) The press is good for us. Keeps us honest, makes us reflect on
what we're doing, and spreads the word.
And now for a word from our sponsor: For the real good stuff, run down to your
corner magazine rack and get a copy of the May issue of Communications of the
ACM. Compare what's in my article to what's in May 2nd Time magazine or the
April 18th NY Times, then judge for yourself.
Finally, my deep thanks to the RISKS people who knew about what we
were doing and kept the faith. Each of you helped through your
comments, support and advice, as well as through your public silence.
Some German automobile manufacturers are demonstrating new computerized communication technologies at their exhibition sites on Hannover Fair being held April 20-27, 1988. Mercedes demonstrates a new device which cannot only count a car (as is usually done with electromagnetic detectors fixed under the street) but also identify any cars specific `magnetic characteristic field'. According to extensive measurements, any individual car has an `individual magnetic print' different from any other. The detector box is simple to install (above ground, not buried into it), and by connecting it to other devices, installation and maintenance is said to be rather easy. When connected to a `traffic control system', any individual car may be identified on its ways by the stations it passes. Under these auspices, some German media have asked the question whether such a device should be installed, and for which purposes. While a spokesman of the Federal Minister for Traffic said, that he foresees only a usage as a traffic counting device (though an inexpensive one)and that he hopes that todays costs may be reduced significantly, a spokesman of the Federal Minister for Interior said, that his ministry would `very carefully analyse the potential of such a device'. So far, the discussion is only in the initial stage. Is there a discussion on a similar device anywhere else? Volkswagen, on its site, exhibited a project study to automatize highway-driving. According to the study, cars will be equipped, within 10 years, with (at least) a rather simple set of distance measuring devices which work much simpler than the `automatic pilots' discussed in the field. On a special lane, cars follow, with only 0.5 meters distance, a `pilot car'; a front device controls that the distance doesnot vary when the pilot car changes velocity. To the left of the lane, a low wall is needed in order to control the car to stay in the lane. Instead of running into the well known problems of analysing the changing environment to simulate a human driver (as is done in most studies), Volkswagen reduces the problem to find a proper `pilot car' or a queue of cars behind one pilot, then to properly and safely feed-behind, and then to switch on the automatic guidance system. Such a simple approach may significantly reduce the risks of highway driving (assumed you may rely on the pilot) in an unexpensive manner. Moreover, development and implementation of such a less complex system may use less time. My personal view is that the risks of such an approach are significantly less than with the `intelligent all-situation automatic pilot' which I see developing in most aumobile laboratories. Klaus Brunnstein, University of Hamburg, Fed.Rep.Germany
Here are descriptions of a virus and a nasty program header which run on the
Apple II family.
===============
The Elk Cloner V2.0
I found the Elk Cloner V2.0 #005 on a disk of mine in 1981 or 82. I'm
fairly certain it could not have been written before the publication of
Beneath Apple DOS, so I would date it around mid-1981... It works exclusively
with DOS 3.3.
THE VIRUS
1. It is installed by booting an infected disk. I'm not sure how it initially
gains control; apparently it is loaded in with some trash from T0 SA which DOS
loads for no apparent reason. (BTW, since HackerDOS rearranges DOS on the
disk, the Cloner would trash it. It might trash master disks, I don't know.)
If you use a modified DOS which marks T2 S3-8 as free for use (as HackerDOS
does), it would overwrite any file stored there.
A JMP $9B00 which was installed when the disk was infected jumps to this
code (I think) and loads the virus from T2 S3-S8 into $9000-95FF.
2. Next, it inserts its claws into DOS:
A. Hooks into the Do Command code at $A180 and makes every command
reset the DOS parse state to 0. I have no idea why it does this. It has
no obvious effects.
B. Hooks into the RUN, LOAD, BLOAD, and CATALOG commands to make them check
the disk accessed & infect it if necessary.
C. Create a USR vector for the Cloner diagnostics:
B=USR(10) Prints a cute poem:
ELK CLONER:
THE PROGRAM WITH A PERSONALITY
IT WILL GET ON ALL YOUR DISKS
IT WILL INFILTRATE YOUR CHIPS
YES IT'S CLONER!
IT WILL STICK TO YOU LIKE GLUE
IT WILL MODIFY RAM TOO
SEND IN THE CLONER!
B=USR(11) Prints ELK CLONER V2.0 #005 (version check)
B=USR(12) Read the disk & prints BOOT COUNT: (#)
B=USR(13) Infects a disk
3. Increments the boot count
4. Checks for any special event for this boot:
Boot # (hex) Effect
A Point reset vector to $FF69 (monitor)
F INVERSE
14 Click the speaker
19 FLASH
1E Switch letters at $B3A7-B3AA so filetypes T I A B will appear as I T B A
23 Change DOS signal character from ctrl-D to ctrl-E
28 Lockout the computer on reset (dangerous one!)
2D Run the current program on any keypress (locks out the machine, also
dangerous. BTW, this is done by setting the hibit of $00D6.)
32 Print above poem on reset
37, 3C, 46 Screw with the INIT code. I think it will give you an I/O
ERROR, but I haven't tried. 3C and 46 might be dangerous in that
it might not init a whole disk. I don't know.
41 'Crash' to monitor on every DOS command
4B Reboot
4C Reboot
4D Reboot
4E Reboot
4F Write 0 to the boot count & start all over again!
5. Sits back & infects disks.
This is how the program is structured:
9000 Version number
9001-9073 Setup
9074-908F [Check a disk for infection] code
9090-90D9 Replacement code for LOAD, BLOAD, & CATALOG
90DA-9178 [Infect] code
9179 Read VTOC
9181 Write VTOC
91A8 Print routine
91E4 Serial #
91E5 Marked with a 0/1 if a disk is infected/uninfected
91EC-9243 Diagnostics
9244-9328 Poem
9343-9435 Special events by boot count
9500-9532 Code which loads Cloner on boot
95E1-95FF ASCII: MATT BE<ctrl-D>JOHN HINKLYJOHN HINKLE<ctrl-D>
(The author's hero?)
These are within the VTOC:
B3BE Zeroed, I don't know why
B3BF Boot count
B3C0 Zeroed, don't know why
B3C2 Infection mark: Version number (=(9000))
There may be several versions out. The version number would be used so
later versions would write over older versions, for a new improved
infection.
THE TEST
Any of these methods will work:
1. Check T$11 S0 Byte 7. If it is non-zero, the disk might be infected.
2. Check T1 S0 B$80-82. If they are 4C 00 9B, you have the Cloner.
3. Check T2 S3 - T2 S8 for the Cloner.
4. From Applesoft, immediately after boot, enter B=USR(11).
THE VACCINE
If you write a 2 to T$11 S0 Byte 7, Cloner version 2 will not infect that
disk. I have verified this.
THE CURE
Write something (like 00:1 AD 88 C0 4C 59 FF) to sector 0 so you can't boot
that disk.
PRECAUTIONS
The Cloner will not work unless you boot an infected disk. It cannot infect
a write-protected disk. I have infected disks I use all the time. Just mark
them as infected & don't boot them.
===============
Disease DOS
This isn't a DOS at all, nor a virus, but a nasty program which is added
to the front of a program. The author posted it to a bulletin board with an
explanatory file. I don't know if they threw him off the BBS or promoted him.
(Promotion: higher disk quota, file access, more downloads permitted, etc.)
When the program is run, it decrements a boot count & erases the current
track after a number of runs. It might be used by a pirate who doesn't like
the fellow he is giving a program to, or who doesn't like people in general.
You can detect it by scanning your disks for the sequence BD 8C C0 B0 F6,
an unusual sequence which shouldn't be on any normal disk. (I haven't checked;
it could be on DOS 3.3, but I doubt it.) It won't be
divided between sectors because it is in the first few bytes of the file.
Or you can read T$11 S0 Byte 4, which is the number of boots remaining before
wipeout. Any commercial (read: non-standard) disk might be non-zero there.
===============
Note that a write-protect tab will deter either program: The Cloner can't
spread, & neither can increment/decrement the boot count.
And, no, I won't send you either program. So don't ask.
Phil Goetz
Please report problems with the web pages to the maintainer