Date: Mon, 5 Nov 90 17:44 EST From: Jon David Subject: C&S text Volume 9, Number 7 (the November, 1990 issue) of Computers & Security contains an article, The Novell Virus, on pages 593-599. The following is the text of that article as submitted to them for publication. It is copyright (c) 1990, Elsevier Scientific Publishers, Ltd., and was sent by permission to CERT for inclusion in their virus archives. Computers & Security is the international journal for the professional involved with computer security, audit and control, and data integrity. Information on this, as well as other related Elsevier publications, is available from Elsevier Advanced Technology Mayfield House 256 Banbury Road Oxford OX2 7DH UK and Elsevier Advanced Technology Journal Information Center 655 Avenue of the Americas New York, NY 10010 USA ------------------------------------------------------------------------------ The Novell Virus by Jon David ---------------- Background ---------- Toward the end of February, 1990 word came in via e-mail about a LAN virus. This contact was initiated by a member of a US firm in response to a situation presented by one of their offices in England. A Novell-specific virus was said to have been found, this virus, from a user viewpoint, much like the Jerusalem B. It was specifically stated that the virus would infect servers from nodes and would bypass server write protect. Analyses in the UK reportedly indicated that "the 13th trigger is present, but Friday is only interesting." It was said to infect both EXE and COM files. In addition, the reports from the UK also mentioned a DAMASCUS B text string, and a trigger action halting the current processor. Although requested, no copies of infected files were forthcoming. Nothing more could be done without the virus. Present Situation ----------------- On Wednesday, June 13, 1990 a Canadian authorized Novell reseller phoned for help with what he considered a virus on Novell NetWare. He reported that one of his customers had encountered this problem. Based on the phone information, this virus sounded very similar to the British one earlier reported, including node alteration of server files without write privileges. This time the information was coming in direct, and the source seemed to know what he was doing. All items reported agreed with the February report. Reasonable advice was given regarding local treatment of the problem, and copies of infected files were again requested. Exactly one week later (June 20), disks arrived. Quick (same day - June 20) analyses indicated that the infections seemed like the Jerusalem B viruse. (An in-house LAN was not available. These analyses included tests on a non-LAN DOS computer, and checks by proven virus scan programs. The classic Jerusalem B "sUMsDos" string was certainly present, actually 56 times in one infected file. There was not, however, a "DAMASCUS B" string, a functionally trivial difference from the one described in the UK e- mail report, but indicative of there quite possibly being more than just a single virus attacking Novell NetWare.) Novell has long been the subject of security anecdotes. With a history of passwords traveling in cleartext format, with products providing both user and supervisor passwords to nodes not even connected to a server being advertised in reputable major publications, and the like, the breaching of Novell security was not viewed an impossibility. However, even though the original reports had been convincing, it was certainly possible that, for example, the Canadian server had independently been infected and the resulting virus spread misinterpreted. Since this, or something similar, well might have been the true situation in Canada, and since public warnings of a "Novell virus" would most likely have caused much user panic, it was felt best to properly test the virus on a Novell LAN before deciding what to do. Dr. Harold Highland, Editor-in-Chief emeritus of Computers & Security, and "father" of the recently released Computer Virus Handbook, was immediately consulted. Although a slight recent disability would keep him from personal participation in the actual testing, Dr. Highland agreed to assume leadership of the investigations. A three-person test team was formed. In addition to myself (representing virus and test expertise), it included Jay Nickson, President of On-Disk Software, in New York City (On Disk provides Quarantine, a LAN integrity product, and Jay is regularly involved in virus work, a second virologically aware eye), and Greg Drusdow, President of NUI (NetWare Users International - Greg was to be the contact with Novell, and represented the interests of NetWare users). It was felt that Novell would be responsive to a request for test facilities to allow appropriate tests to be confidentially conducted. For whatever reason[s], it was not until Wednesday, July 11 (three full weeks after the virus first arrived, and less than two days before the likely trigger date) that facilities were made available to us. On Monday, July 9, and after many repeated requests, we received indication that a test system would be made available to us. Testing was conducted at Novell's Paramus, NJ (USA) facility on Wednesday, July 11, and was done by Jay and I. Greg was there in an advisory/observational capacity. We met at 8:30AM, but further Novell work on the server kept us from starting the actual testing until almost 11:00AM. Test Environment ---------------- Testing was conducted privately (Greg, Jay and I, and authorized Novell representatives in and out, as time permitted, during the morning and afternoon testing, full time after the virus was shown to actually perform as specified) in a closed room on a NetWare 2.15C configuration (this was the version in use at the site initially reporting the virus) consisting of a server (286, 40 megabyte hard disk) and two nodes (both 386s with 1.2 megabyte diskette drives, one with a hard disk, the other without; the hard disk node was used to test node infection of the server). Viruses on diskette were always in my physical possession (including trips to the bathroom, lunch, etc.), and infected files were wiped (not just deleted) and the test room door locked when the room was not in use. (The Norton WIPEFILE was used for file wiping.) The system to be used as an infected node was created "clean" via an AT diagnostic low-level format, fdisk, format/s sequence (from write-protected floppies previously tested as clean). DOS/system programs were all kept in a single C: subdirectory (\DOS), and a set of testing utilities were read into a second subdirectory (\UTILS). An AUTOEXEC.BAT file was created; this included PATHing to both DOS and UTILS subdirectories, loading wd2 (WindowDOS, described below) and setting the prompt to $p$g (so there would be visible indication of the current directory at all times). WindowDOS, a commercial (i.e. not virus oriented) program in UTILS, was loaded as a TSR via AUTOEXEC.BAT to provide hot-key views of RAM usage and interrupt vector assignment. (The Jerusalem strain goes TSR when an infected program is run when RAM isn't infected.) CHKDSK was used to test available disk space. (The Jerusalem B increases the length of executed programs.) A C: subdirectory, BACKUPS, was created to contain copies of programs we would try to infect (for comparison, and for ready recreation of infected files that would be WIPEFILEd). At the server, user areas were established. Minimum trustee rights (ROS - read, open search) were given. No group privileges, supervisor equivalence or passwords were used. Booting at the node was always done from a write-protected boot diskette, and was followed, as appropriate for network connection, with ne1000 and then net3 commands (with the A: drive still the default). All diskettes were write-protected before system use. In addition, all were scanned for viruses by proven scanners (IBM's VIRSCAN and DDI's VIRHUNT) before use. The hard disk[s] were scanned after the systems were created (and before being used), and, as appropriate, throughout testing. Before any testing started, and after all initial software was in place, all systems were processed by Quarantine, the On Disk program, to establish reference integrity statistics for these systems for later comparisons. All hard disks were properly disinfected when testing was done for the day. AT diagnostic low level formats were again done to the two hard disks. All systems were shut off. Testing ------- 1. Virus Performance in Stand-Alone Mode. The virus was first tested in a non-networked environment. Although there was no interest in the results of these tests in terms of effects on a server, it was felt necessary to see the virus perform in this environment in order to compare stand-alone and networked effects. After diskette booting of the test node, WindowDOS (WD2) was hot-keyed to examine RAM and interrupt usage, and CHKDSK provided available memory and disk figures. (The same WindowDOS screen that gave RAM/interrupt information also provided available memory; CHKDSK was used out of habit.) An infected file was run from a write-protected infected diskette (one of the originals from Canada) . The program appeared to execute properly. (It was the Norton FF, with a date/time of May 23, 1990/11:57AM.) The were no disk changes, but a NO NAME TSR of size 1792 bytes had been loaded. (Subsequent RAM infecting always yielded the same TSR size.) This new (i.e. virus) TSR hooked interrupt vector 21. Execution of any program thereafter - whether the program was in the current directory, in the PATH or with a path given as part of the command - caused the executed program to grow in size by a bit more than 1800 bytes, i.e. to become infected. (Subsequent tests, while we were calm enough to mind such matters, produced file size increases in the 1806-1816 range; after the server started to get infected, described below, we got a bit less precise.) There were no additional RAM changes. When the node was booted "clean," and then shut down and rebooted immediately after the initial RAM infection, the system was completely "clean." Once, however, the hard disk contained any infected program[s], running an infected program infected RAM, if RAM was not already infected and with the virus in control of INT 21; the virus TSR then infected any executed program. The virus infected both COM and EXE files, and was a repeating infector, i.e. if a clean program was run N times, it was infected N times and its size grew N times 1800+ bytes; if a program was already infected N times, and was run an additional M times, its infection count was then N+M and its size grew by M times 1800+ bytes. COMMAND.COM did not get infected (although no specific attempts were made to infect it). Initial (RAM) infection was exclusively by execution of an already infected program, regardless of the location of the infected program (diskette, hard disk, whatever). Spreading (to disk based executables) of this virus was done exclusively via the TSR. The virus clearly "worked" in a stand-alone system, and worked as one would expect a Jerusalem B to work. 2. Virus Performance Connected to the LAN. It is important to note that the only executable program that was part of the load process was WD2.EXE (WindowDOS). The system was set up and run such that this file would not become infected. This was important to assure that reboots would always yield a clean start. (Be assured, though, that memory was checked after each and every reboot.) The server, as indicated earlier, had been set up to allow only ROS - read/open/search - privileges (no modify flags, write or delete, the first two of these being introduced later in the test process) to the node being infected and used to test the virus's effects on the server. 2. A) After a clean boot, the infected FF.EXE on diskette was run to infect RAM. Standard post-boot testing showed the virus hooked INT 21. The network connection was then established. WD2 revealed that net3, loaded after the virus (and from the write-protected boot diskette), had taken control of INT 21. The virus at the node, no longer in control in INT 21, had no effect when server programs were executed. (A later test revealed that a second execution of an infected program, after control of INT 21 had been relinquished to net3, would cause the virus to go TSR a second time, regaining control of INT 21 and also hooking INT 08. This pattern, just INT 21 when first going TSR, both 21 and 08 when reinfecting RAM after relinquishing control of INT 21, persisted throughout the testing.) 2. B) After a clean boot, the network connection was established (i.e. the system was not infected at the time of attaching to the network). The RAM infection was introduced after the node was connected. WD2 revealed that the virus had taken control of INT21, and also of INT 08. Server programs (SI, DI, FF, etc.) were executed, seemed to run properly and seemed to be unchanged. This was not what was expected. After this scenario repeated itself several times, we tested the server with Quarantine and discovered that, although neither the file sizes nor file contents of executed programs had changed, the date/time stamps of each and every executed program had changed, and ALL changes were to 05/23/90, 11:57AM. (This was the date/time - coincidental? - of the infected FF program initially used to infect the node). This date/time alteration should not have occurred, and seemed to be in violation of the NetWare modify flags protection. We tried adding several other rights (including write and create), but not modify flags. Each such alteration was followed by a reboot (with the infecting node starting clean), LAN connect and node infection. The virus performed the same way. Once we gave the modify flags privilege, the node would infect (i.e. increase the size of) executed server programs ALTOUGH THE NODE DID NOT HAVE WRITE PRIVILEGES! (Record was not kept regarding the date/time stamps.) The DDI scan program indicated all executed programs (both COM and EXE) were infected with a recognizable virus. (DDI called it Friday the 13th - Version 1; IBM, which would not scan the server, called it the 1813 at the node; there are many other aliases - PLO, Israeli, etc. - for it, and Jerusalem B is probably the most common.) In addition, all executed server programs grew by 1800+ bytes per execution. The "sUMsDos" string was introduced once per execution/infection. Infected server files were wiped and replaced with clean versions. The modify flags privilege was removed from the test node, and no infections, i.e. file size increases, occurred at the server when executing server programs from the node. The date/time, however, of executed server programs still changed, this time always to 11/15/88 - the time wasn't recorded - but we have no idea where this date/time came from. (In the furor that followed the node virus infecting the server, and fighting a time deadline for testing and reaction to test results - late in the afternoon of July 11, with a projected virus trigger date of July 13 - we decided to do as many test combinations as possible and bypass the recording of all we normally would have noted.) We did not have a date search routine with us, and can only assume the initial infection came from an infected program with that date/time. Modify flags privilege was again given the node, and the server was again infected. The server was kept infected, and the node was booted clean. The execution of an infected server program at the node infected the node. 2. C) We advanced the node and server dates to Friday, 7/13/90 by changing the date/time to 7/12 and 11:59PM, and letting the date change itself. The server and node were then rebooted. This added nothing new to the effects of the virus UNTIL the infected node was given the additional write (BUT NOT DELETE) privilege. From then on, both local and server programs requested for execution would not execute, but would yield a "Bad Command or file name" message. (This is a NetWare message. The equivalent DOS message has a lower case "c" in "command.") Investigation showed that the files were gone. Changing the system date to a date other than 7/13/90 had no effect after the virus was TSR with a 7/13/90 date. Shutting the system down, rebooting and changing the system date to either 7/12 and 7/14 (both were tested) showed the virus reverting to its spreading phase, and not deleting. This clearly indicated that advancing both node and server system dates on 7/12 to 7/14 should be done. Moreover, because of the cryptic trigger message regarding the UK Novell virus, the 12th-to-14th change should be done until it is proven that any 13th will not trigger the virus. 2. D) The NetWare SALVAGE seemed to recover virus-deleted files, but extensive testing was not done. They may or may not have been infected prior to deletion (probably not), and may or may not have had their date/time stamps changed (again, probably not.) Conclusions ----------- The virus does, with 100% certainty, infect NetWare 2.15C servers from infected nodes, do server writing without write privileges, do server deleting without delete privileges. Infected nodes exhibited the ability to override server-granted privileges, such overriding being at a "one-over" logical level. Unexplained date/time changes, particularly if to the same date (and that being other than the present date), may indicate a virus problem. Integrity programs well might automatically and accurately detect and report such changes. Prompt and proper investigation of such instances could easily prevent more serious damages. Novell may view this as just a virus problem, but this is not so, and the virus aspects of it are the least of its implications. With triggered infections failing to execute, and actually deleting requested programs, the odds are very high that the virus trigger, even if the 13th of every month, will not cause too much damage to be done. (It is presumed that users, after getting the "Bad Command or file name" message a few times, will contact their LAN administrators, and not serially execute all available programs. Furthermore, recreating server programs from backups or original media should be a rapid and automatic function for any LAN.) The major danger pointed out by these tests is that NetWare systems may have seriously deficient security, that a relatively small program entered at a node can spawn a correspondingly small TSR to readily bypass server protection mechanisms. Certain potentially important information has come in since the conclusion of testing on July 11. None of it has been verified by any of us on the original test team, but we tend to believe it. This information, from more than one source, indicates that that server deletion can be done from nodes with just ROS privileges (i.e. neither modify flags or write), and that the virus will do significantly more than just delete individual files. (Information is not now available regarding whether this accelerated trigger action is due to additional privileges, repeated deletion-trigger action - which we did not take time to do - or some other thing[s].) If this information proves true, there may be gaping holes in Novell security making it vulnerable to many common viruses and all sorts of other security breaches. (And, to throw in one additional item discovered after completion of testing, the Canadian NetWare version is reported as 2.15C, obtained from 2.15B via an upgrade kit. It is not known whether this is important or not, and we don't even know if our testing was done on a "straight" or upgraded 2.15C - Novell personnel haven't been in when phoned, and calls have not been returned.) To Be Done ---------- Now that the immediate crisis (i.e. Friday, July 13) has passed, 8/13 should immediately be tested as a trigger date. The basic testing should be repeated in a more orderly fashion. Although, from a Novell perspective, it is probably not necessary to run infected node programs repeatedly at the node to see if the virus performs as a "typical" Jerusalem B (black box, etc.), the tests should certainly be extended as necessary. The source of the date/time for changed server modification date/time stamps should be determined. Starting from the R/O/S node privileges, the node should be infected by files with different date/time stamps, and server programs then run to see if the infection date always comes from the date of the file causing the TSR. The effects of the addition of each privilege should be tested. Additional privileges should be added one at a time, then removed, to see if just one (MODIFY FLAGS, in particular) is adequate to bypass server write protect. Date/time of infected server files should be noted. For the July 13 trigger date, tests should be run to see if just write privileges, or just write and modify flags, will allow server file deletion from nodes. Files brought back by SALVAGE after deletion by the virus should be tested, with Quarantine or some other proven methodology, for integrity. Friday, April 13, 1990 should be tested as a trigger, as should the next Friday, the 13th (in September, 1991). In addition (and, particularly, because of the comment in the February report from Britain), other 13ths (8/13/90 is the next one) should be tested. Other Jerusalem B variants should be tested. Other "popular" virus should be tested. Other viruses hooking INT 21 should be tested. Everything should be tested on other NetWare versions. Everything should be tested with different processor hardware (at least 8088, 80286 and 80386). The virus should be tested on other popular LANs (Vines, 3+, etc.). The virus should be disassembled to see just what it does and how it does it. [One] Tester's Comments ----------------------- No further word about the supposed Novell Jerualem B virus had come in since the e-mail discussions of February (in spite of the fact there had been a subsequent Friday the 13th in April). Reports come in on a depressingly regular basis about viruses that prove to be baseless. It was not certain the report received in June from Canada was accurate, or that the infected files received would act as reported. All the same, this time personal discussions had be conducted with the reporting source, and it was felt he knew what he was doing. Without testing, one certainly wouldn't want to cry wolf (or LAN virus, or whatever) and cause a panic that might have had no basis in fact. It was most unfortunate that it took Novell three full weeks to provide test facilities, and that the trigger date was so close. I am supposed to be, and like to think of myself as, a test expert. I both know how to test, and earn goodly amounts of money performing tests for both vendors and users. The testing performed, although conclusive and serving the purposes for which it was intended, was rather sloppy in many ways. We were working under extreme time pressure and, even if you condemn me for sitting on the virus as long as I did, please excuse the admittedly rough testing. I'm not clear that Novell realized/realizes the full implications of the test results, i.e. the potential security exposure[s]. They of course realized the implications of a demonstrated field virus that looked as if it could impact NetWare systems in barely more than 24 hours time. (Somehow, though, I recall their first concern being whether or not it infected other network operating systems. When I recover from the effects of infecting a node, and seeing another totally innocent node being infected, I may see some humor in the user concern evinced by Novell.) I sent an e-mail advisory on this matter to Ken van Wyk at CERT, the Computer Emergency Response Team at Carnegie Melon, at about 3:00AM EDT (i.e. New York time) on the morning of July 12; Ken got around to posting it around 12 or so hours later. A Novell notice went out over NUI's NetWire on July 12; based on the facts, it was very misleading. The notice was significantly different from the one prepared locally late on the 11th, reviewed by Jay and I, and coauthored by Greg; I understand the changes were made exclusively by Novell, without the consent or approval of NUI. I have spoken to people that received the NetWire notice, and they have had the wrong impression of what happened. For some time many of us (in private, certainly not in print) have been discussing the way[s] LAN (and other types of as yet unreported, or at least unverified) viruses would work, and what could be done to combat them. Since this has proven to be a real LAN virus, I'm sure some warped, creative darlings will take steps to make ones bigger and better. Virus defense had better become a hot item for LANs (particularly NetWare users). Although there may well be hundreds of capable and well meaning people throughout the world who would intelligently use virus-related information, spreading such information among them, i.e. to separate and unique places, would significantly diminish the ability to react to this and similar problems by a coordinated and effective force. Calls have already started coming in regarding possibly related incidents. Those of us that have worked on this project so far have significant resources and knowledge at out disposal. I urge anyone with anything to contribute to contact Dr. Highland as indicated below. Dr. Harold Joseph Highland Computers & Security 562 Croydon Road Elmont, NY 11003 (516)488-6868 (voice) E-mail: Highland@DOCKMASTER.NCSC.MIL ----------------------------------------------------------------------------- Dr. David is a security consultant in Tappan, New York (USA). He has expertise in testing, and has been particularly active in virus areas. A frequent author and speaker on viruses and other contemporary security issues, he is on the International Board of Referees of Computers & Security, on the Editorial Advisory Board of the Virus Bulletin and was one of the two laboratory test sites involved in Elsevier's Computer Virus Handbook.