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