************************************************************************** Security Bulletin 9222 DISA Defense Communications System August 25, 1992 Published by: DDN Security Coordination Center (SCC@NIC.DDN.MIL) 1-(800) 365-3642 DEFENSE DATA NETWORK SECURITY BULLETIN The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security Coordination Center) under DISA contract as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DDN facilities. Back issues may be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5] using login="anonymous" and password="guest". The bulletin pathname is scc/ddn-security-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/ddn-security-9222). ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! The following message is being relayed unedited via the ! ! Defense Information Systems Agency's Security Coordination ! ! Center distribution system as a means of providing DDN ! ! subscribers with useful security information. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + "ALIENS 4": Epilogue Dave Bouwer 23 Aug 92 On August 15, 1992, an alert for what was believed to be a new "polymorphic" or "adaptive" virus strain was posted. This virus was detected on a Macintosh IIci running System 7 at the Space Environment Laboratory in Boulder, Colorado. I was the researcher at NOAA/SEL that originated the alert, and I assume full responsibility for it. To make a long story short, "Aliens 4" is a ghost--that is, it was either a legitimate description or a peculiar combination of multiple viruses and system software problems. In any case, two weeks of work have failed to reproduce the original virus, and the alert needs to be canceled. For interested readers, I'm describing the circumstances that led to the alert and giving some of my personal reflections. I hope to be as honest as possible in this description so that others in a similar situation can learn from my experience. None of the views here represent those of NOAA or anyone else. The Space Environment Lab (SEL) is an amalgam of talented physicists, computer specialists, students, and administrative personnel. We do no classified work, but provide important near-real-time forecasts of the solar-terrestrial environment in addition to performing general research in solar-terrestrial physics. A potential "hacker" has no need to raid our systems: We are delighted to provide data nearly free of charge! The computer environment at SEL is a complex combination of real-time systems, super-computer links, high-end workstations, personal computers, and a strained ethernet network tying everything together. SEL's extremely capable staff are always trying, like most shops, to catch up on a demanding backlog of new systems, upgrades, bugs, programming, etc. We deal with an enormous amount of data: About 5 GB a day come through our Services division alone. I have been active in the computer sciences for nearly 20 years as a developer, systems manager, and high-end user. While I am a long way from "guru" status, I have a long string of experiences and considerable education in government, university, and private industry. About 50% of my time is devoted to my research in the time series analysis of solar variability; the rest is spent in putting together the latest in systems for scientific research. In other words, it was not without careful consideration or some expertise that I escalated the virus alert to a national level: the consequences of not alerting others seemed VERY serious, and I was nearly certain of what I had observed. Generally, at SEL, we have tended to worry little about computer security and have implemented only the basic measures, usually as an afterthought. Our priority is to get the job done, and most users in the lab manage their own systems both by choice and necessity. However, in the last year the MS-DOS systems have seen two infections: the infamous "Stoned" and "Michelangelo" viruses. Our concern about data security is beginning to increase. After all, we do work just down the street from a major university with a large computer science department! The nine Macintosh systems are all less than a year old, and there have seldom been any problems (least of all viruses). The "Lab Mac," which was available in a general computer lab area for visiting staff, students, etc., has been one of my responsibilities. Since I much prefer doing my papers and memos on the Mac instead of on my desk-top DECstation, I frequently used it and kept it working well (I have been using a Mac for about 5 years altogether, with a long history of VAX/VMS systems and some Unix). About once a month, or whenever a peculiar problem would emerge, I would run various combinations of our older anti-viral programs over all the files, and I had never found a problem. I was over-confident that our systems were unlikely to be seriously infected. I discovered the virus on Saturday, August 8, 1992, when I noticed a MandelZot Fractal application on the Lab Mac. Obviously, the neophyte students were doing what every new computer science student seems to do on a nice graphics system: making pictures for their dorm rooms! Such creative endeavors are not to be discouraged: they often generate enthusiasm and lead to new ideas. When I clicked on the application to see how they were doing, the application alerted me to an infection (ALL applications should do that!). Not too worried and a little amused, I began to check it out. The fractal application was last modified August 17, 1992, at 11:50 PM. (somebody was in very late!) Interferon informed me that a "Type 2" error was found in the System, Finder, MandleZot, Photoshop, Canopener, Mac Profiler, Norton, System Sleuth, and Interferon (now that doesn't exactly instill a secure feeling!). I was the one running all the applications, so I figured I had a VERY infected system. Since it was a Saturday, and I had a date, I put a notice on all the users' Macs (I did not know whether the virus had propagated via the network), posted a Lab-wide bulletin, and physically disconnected the Ethernet connections from all the Macs. I shut down the Pathworks process running on our Micro VAX/VMS server. Sunday I came in to work on the problem (so much for my day of fly-fishing my favorite river!). I ran Virus Rx 1.6, and it immediately became infected (I can't recall all that it found). Next, I tried Disinfectant 2.4. It reported what the Interferon run the day before had reported, identifying the virus as an nVIR A strain. I decided to wait until Monday to talk to our local NIST experts (we work in a large facility with an excellent networking staff). I began putting together a new Mac we had just received, planning to use it as a "test" machine. I also started planning how to campaign for new Lab computer security measures: the long-term implications were beginning to sink in! I issued a stronger Lab-wide memo telling users they MUST back up their files NOW. I disabled all Macs and told users to see me before starting their systems. As you can imagine, this directive was not received well the next day. In my overwhelming fear of lost data, I decided to err on the side of caution. This was my first mistake: over-reacting and creating an atmosphere of panic. Monday, amidst countless user problems, I managed to sit down at the infected machine with the local security guru. He came armed with the latest versions of SAM and Norton. By then, there were dozens of reports of printers not working, system crashes, odd screens, and disk drives not working. At this point, I was becoming convinced that at least 3 Macs were infected. Only the System 6 Mac's seemed problem-free. I suspected that our local Ethernet network was carrying the virus somehow. This was mistake number two: When users panic, every glitch that would normally be ignored becomes a symptom of the virus. I mis-diagnosed the extent of the problem on the basis of heresy, and not on my own direct experience. Since one of my bosses -- the one who approves all my recommended purchases -- was out of town, I broke the rules and had the division secretary rush-order $1800 of SAM and Norton software. Mistake number three: potential loss of data in the organization may not be grounds for overstepping one's authority. First we ran SAM (version 2.8 or 2.9). It reported the nVIR A strain as the other diagnostic software had on the previous day. My NIST colleague asked if I had another infected system or disk, and I said I was sure I did. Mistake number four: I should have made absolutely certain I had copies of the suspected virus. Other people will want to see any reported virus. We then told SAM to go ahead and eradicate the virus. It said it had done so, without a problem. We ran SAM again, and here was where all my alarms went off: On the second run, all the prior infected files and a few new ones (the infected Versaterm Client application was the most ominous) were infected with the MBDF A virus! We ran SAM again, telling it to fix the files. Again, it said it did so without any problems. Since we were running from write-locked floppies, the system had to re-boot. When it came back up, my external LaCie drive would not mount. The internal hard drive seemed to have no more problems. My NIST colleague could only tell me what I already knew: I had a problem! I consulted with another Mac expert, and he informed me about the new adaptive or polymorphic viruses. Then an alert user gave me the new IEEE Spectrum issue on data security (an excellent treatment in my opinion). I became convinced I had at least a 50% chance of having a polymorphic virus, and that's when I notified CERT of the ALIENS 4 virus (I came up at the last minute with the name: I felt I had to call it something!). Mistake number five was in jumping to a conclusion too soon. Now it's two weeks later. Despite seriously overdue projects, I have worked entirely on: (1) Rebuilding the infected system after erasing the drives (implementing the new 7.01, Pathworks 1.1, and removing all but the DECnet and FTP network extensions). (2) Trying to find the infected disk that started it all, or at least SOME copy of it. (3) Defending against management, user, and network criticisms. (4) Campaigning for new resources for new Lab-wide computer security measures. So far I've only successfully completed (1), and I'm giving up on the other three tasks. It's very hard to maintain political and technical clout after getting labeled as a "Chicken-Little." I do know that a department in the University has Macs riddled with the nVIR A strain and a copy of an X-rated script that MIGHT be used as a Trojan horse (I will be forwarding copies of that virus and the script to Symantec, Apple, and CERT, but I believe they will see nothing other than a simple nVIR A strain and a script of poor taste.) Other than the normal "glitches," there has been no additional evidence of an infection. To this day I believe the Lab had a new viral strain that posed a serious risk. However, I still ask myself whether I either: (a) saved the lab and others from catastrophic data loss, or (b) thoroughly embarrassed the Lab and myself. I'm sure (b) is true, but I guess I'll never know about (a). I still maintain that the highest priority, when data loss looms and confusion and fear begin to overwhelm the beleaguered system manager, is to protect the data. Yet I should have been more careful in deciding to escalate the alarm. In conclusion, because I am unable to reproduce the virus, ALIENS 4 is just a "ghost." What we all have to ask ourselves is: Is ALIENS 4 a ghost of "Christmas Future?" If I did observe a polymorphic or adaptive virus coming in on some innocuous Trojan horse, how could anyone else know it? And if the consequences of a false alarm are too severe, who would risk their career by reporting a "potential threat"? Finally, how are we going to defend ourselves against this kind of mutating computer threat (if it indeed becomes realized) in departments already straining their resources to the limits? I leave these questions to the readers of this confessional. I've got a very serious backlog of work to do. Sincerely, Dave Bouwer. **************************************************************************** * * * The point of contact for MILNET security-related incidents is the * * Security Coordination Center (SCC). * * * * E-mail address: SCC@NIC.DDN.MIL * * * * Telephone: 1-(800)-365-3642 * * * * NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST, * * Monday through Friday except on federal holidays. * * * ****************************************************************************