24-Sep-86 00:26:42-PDT,12559;000000000000 Mail-From: NEUMANN created at 24-Sep-86 00:24:29 Date: Wed 24 Sep 86 00:24:29-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.63 DIGEST Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Wednesday, 24 September 1986 Volume 3 : Issue 63 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: NOTROJ (a Trojan Horse) (James H. Coombs via Martin Minow) Massive UNIX breakins at Stanford (Scott Preece [two more messages!]) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.) ---------------------------------------------------------------------- Date: 23-Sep-1986 1644 From: minow%regent.DEC@decwrl.DEC.COM (Martin Minow, DECtalk Engineering ML3-1/U47 223-9922) To: risks@csl.sri.com Subject: NOTROJ (a Trojan Horse) Found on a local bboard: Date: Sat, 20 Sep 86 04:17:50 EDT From: "James H. Coombs" Subject: NOTROJ--it IS a trojan Distribute far and wide! (C)Nobodaddy, 1986 A Story of a Trojan Horse With Some Suggestions for Dismounting Gracefully by James H. Coombs NOTROJ.COM is a TROJAN HORSE (comes in NOTROJ.ARC--for now). I first became aware of NOTROJ when a member of The BOSS BBS community reported his belief that the program destroyed the directory of his hard disk. After two days of restoring his files, he concluded: This Trojan was written by a real Pro---he knows his ASM and uses it as a weapon---not a tool. From lokkin' at the job he did on me, I tendto doubt that I would have found the bomb has I been smart enough to look. ---PLEASE!!!!! Spread the word 'bout this one. It's a Killer! In the next couple of days, I saw a similar note on the Boston Computer Society bulletin board. This victim rather pathetically credits NOTROJ with a "valiant" attempt at saving his data. The program in question is a time-bomb (about 10 minutes) and works by the "SOFTGUARD UNFORMAT" method of attack. I'm not sure what it did, or how it did it, or even how I could have recovered the disk but the NOTROJ program I had in the background alerted me to the fact, and tried a valiant attempt to shut down the hard disk. To no avail, though. Since my hard disk was becoming fragmented anyway, I decided to test NOTROJ. Everything looked pretty reasonable from the start; in fact, the program looks like a very useful tool (although I'm not in love with the interface). One loads NOTROJ resident and then accesses the options menu through Alt-N. The menu contains about fifteen items, some of them annotated "DANGER", e.g., "Format track (DANGER!)". For each parameter, the user can select one of four responses: Proceed, Timeout, Reboot, or Bad Command. The menu also provides a fifth option--"Pause&Display"-- which provides the user with full information on the activity that the currently active program is trying to perform and prompts for one of the four primary actions, e.g, Proceed. I selected "Pause&Display" for all of the DANGERous parameters. Everything worked fine, although I found that iteratively selecting "Timeout" in response to the "Write sectors" interrupt hung up the machine. I fooled around with a number of commands and finally reproduced the disk crash. At the time, I was running the DOS ERASE command (I had been suspicious of that one for quite some time anyway). I don't have the full message that the program displayed, but I did write down this much "Softguard-style low-level disk format." (Keep those words in mind.) In spite of the fact that I had prepared for a disk crash, it took me at least an hour to get running again. When I booted the machine, I was thrown into BASIC and could not get back to the system. I put a DOS diskette in, and got an invalid drive error message when I tried to access the hard disk. Here is the recovery procedure for this and most disk crashes: 1) Insert DOS system disk in drive A. 2) Reboot the machine. 3) Run FDISK and install a DOS partition on the hard disk. 4) Format the hard disk with the '/S' option. 5) Restore files from the most recent full-disk Bernoulli or tape backup. 6) Restore files modified since the most recent full-disk Bernoulli or tape backup. Once I got a minimal system running, I decided to reproduce the crash to ensure that this was not some quirk of bad programming. What, ho! I got bored playing around with COPY and ERASE and a few other programs. I waited for a while, read a magazine--no signs of a simple timing technique. I began to think that NOTROJ might be more incompetent than vicious. Something about the documentation made it seem unlikely that the author was a criminal. It occurred to me, however, that the author might have had some time to waste on this program. Does he, perhaps, check to see how full the hard disk is? It would be reasonable to evade detection immediately after a bomb by making it impossible to reproduce the crash. In addition, it would be much more painful for people if they have restored all of their files or gradually rebuilt their hard disks before they discover that this is a trojan horse. So, I restored all of my files. This time, Norton's NU command turned out to be the great blackguard that was trying to format my disk (according to NOTROJ--although it was only reading the FAT). So, I restored my hard disk. All of the while, however, I had the nagging feeling that the documentation did not reflect the personality of someone vicious. When I got running again, I took a look into NOTROJ.COM. Nowhere could I find the words from the message "Softguard-style low-level disk format." That convinced me. I have concealed passwords on mainframes by assembling strings dynamically instead of storing them statically. Our trojanette must have used the same technique so that no one would spot the suspicious messages. I had counted on being able to get them directly from the program so that I would not have to take the time to write the whole message down while my system was being operated on. I do recall NOTROJ patting itself on the back, however, for preventing "further damage." As I think back on it, the documentation contains something of a rant against copy-protection schemes, including Softguard. In addition, I had always been troubled by the fact that the name NOTROJ is an acrostic for TROJAN and also an assertion that the program is not itself a trojan. The documentation is also very badly written. One has to experiment to make sense of it, although that is nothing new in software documentation. Also, the style is something of a pidgin English, which seems consistent with the fact that the author has an Oriental name (Ng, or is that for "no good"?). Well, since the author's name and address are listed in the documentation, I decided to give him a call. Mirabile dictu! It's a real name, and I got a real number--I just didn't get an answer, even at 2 a.m. It doesn't make much difference anyway, there's nothing that he can say to convince me that he had legitimate reasons for concealing error messages and that his program is not a trojan horse. There is also the possibility that the person listed as author has nothing to do with the program. Could the pidgin style of the documentation be the work of a clever linguist--an acrostic fan--a sick person who considers himself to be the bozo that Sherlock Holmes was always after? Who knows? I have to write a book. No time to play with these fools. So, be careful. Note that sysops don't have the time to test every program extensively. If a program like NOTROJ requires that a disk be more than 70% full, for example, a lot of people may never have any problems with it. What else can we do? Does someone want to try to prosecute the author of NOTROJ? And how do we keep ourselves from becoming paranoid about new noncommerical software? Eventually, I think it will all shake out just fine. Those of us who are prepared for problems provide others with the testing and filtering. Junk like NOTROJ just does not make it into my community. Actually, I find mediocre software much more of a problem. I have spent a lot of time and money sorting through megabytes of chaff to find but a few grains of wheat. I would like to see us find some way to constrict the growth of chaff and worms both. If we can't do this, many of us may have to switch to commercial software. --Jim Replies may be made to: BITNET: JAZBO@BROWNVM BBS: The BOSS, BCS, Hal's, et passim BIX: jcoombs ------------------------------ Date: Tue, 23 Sep 86 09:16:21 cdt From: "Scott E. Preece" To: RISKS@CSL.SRI.COM Subject: Massive UNIX breakins at Stanford [This was an addendum to Scott's contribution to RISKS-3.61. PGN] I went back and reviewed Brian Reid's initial posting and found myself more in agreement than disagreement. I agree that the Berkeley approach offers the unwary added opportunities to shoot themselves in the foot and that local administrators should be as careful of .rhosts files as they are of files that are setuid root; they should be purged or justified regularly. I also agree that it should be possible for the system administrator to turn off the .rhosts capability entirely, which currently can only be done in the source code and that it would be a good idea to support password checks (as a configuration option) on rcp and all the other remote services. scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece ------------------------------ Date: Tue, 23 Sep 86 08:41:29 cdt From: "Scott E. Preece" To: RISKS@CSL.SRI.COM Subject: Re: Massive UNIX breakins at Stanford > From: Rob Austein > I have to take issue with Scott Preece's statement that "the fault lies > in allowing an uncontrolled machine to have full access to the network"... I stand by what I said, with the important proviso that you notice the word "full" in the quote. I took the description in the initial note to mean that the network granted trusted access to all machines on the net. The Berkeley networking code allows the system administrator for each machine to specify what other hosts on the network are to be treated as trusted and which are not. The original posting spoke of people on another machine masquerading as different users on other machines; that is only possible if the (untrustworthy) machine is in your hosts.equiv file, so that UIDs are equivalenced for connections from that machine. If you allow trusted access to a machine you don't control, you get what you deserve. Also note that by "the network" I was speaking only of machines intimately connected by ethernet or other networking using the Berkeley networking code, not UUCP or telephone connections to which normal login and password checks apply. The description in the original note STILL sounds to me like failure of administration rather than failure of the networking code. scott preece [OK. Enough on that. The deeper issue is that most operating systems are so deeply flawed that you are ALWAYS at risk. Some tentative reports of Trojan horses discovered in RACF/ACF2 systems in Europe are awaiting details and submission to RISKS. But their existence should come as no surprise. Any use of such a system in a hostile environment could be considered a failure of administration. But it is also a shortcoming of the system itself... PGN] ------------------------------ End of RISKS-FORUM Digest ************************ -------