% Preserving Novell Netware Compatibility % Preface ~~~~~~~ In IRG#8 I presented some things to keep in mind if you have the wish that your virus can successful attack a Novell Netware network environment. However, this article was done in great haste and some things has been left out or contained bugs. Also wrong explanations were given in some situations about Novell quirks. In this article I try to give a better understanding in what problems might occur if your virus resides in a network environment. Please note that my primary target are Novell 3.x netware systems, as I don't have access to newer versions. Windows NT is out of context in this article, since discussing such item also calls up the inner workings of Windows NT for successful infection of targets on that operating system. Wildcards ~~~~~~~~~ Some viruses make use of an undocumented feature of the wildcards in DOS to avoid heuristic warnings of scanners like Thunderbyte. As search argument for the FindFirst/FindNext functions they use strings like "*Rajaat.COM". Although this works fine with DOS, it doesn't work within the Novell environment, returning no file found. I didn't test if it would locate all files ending with the word "Rajaat", as this isn't of any use in viruses. This minor glitch is no problem at all, since it only concerns non-resident viruses, and since a non-resident virus lacks any sophistication anyway it is appropriate to leave out Novell compatibility as well. To see a virus that typically fails on a Novell environment is my own Great_Prepender virus, presented in the April Fools edition of the Virus Laboratories And Distribution (VLAD) magazine. Sharing Violations ~~~~~~~~~~~~~~~~~~ Another thing you have to keep in mind is that there is a higher probability of failure on files during opening them. This might happen when a file is in use by another user (or virus scanner). So be sure to check all file actions wether they successfully return or with some error. Bailout immediately from your infection routine if this happend. Interrupt unhooking by NETX ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NETX program from Novell Inc. performs a nasty way of squeezing itself into the dos interrupt chain, and if mostly results in your virus int 21h being disabled when the virus became memory resident before loading NETX. If you want to make sure that your virus does stay resident, you can use a little trick. Check for NETX being loaded (you can monitor its own residency check, which I used in Diametric/Matricide) and if so, modify the int 22h vector in the current PSP to point to the rehooking engine. After that you'll let it proceed to the old int 22h handler. Printer problems and NETQ ~~~~~~~~~~~~~~~~~~~~~~~~~ If you are writing a fast infector that infects on open, you should take in account that you must prevent to open a file called NETQ (without extension). Novell uses this name for writing to its print queues, and after closing or writing to it, Novell itself can't write to it anymore, effectively betraying the presence of the virus by disabling all prints in your network. Beware the Rights ~~~~~~~~~~~~~~~~~ Since Novell Netware uses many kinds of restrictions that can be placed on either files or directories, you need to check various things during infection of the files. When you understand the different restrictions that can be set, you just know what you need to check for. Directory Rights ~~~~~~~~~~~~~~~~ SRWCEMFA ³³³³³³³Àį Access : Whatever, not needed I think. ³³³³³³ÀÄį File Scan : This means you can do FindFirst/FindNext ³³³³³³ functions in this directory, so if you are ³³³³³³ writing a directect action virus and you ³³³³³³ can't find any files, this doesn't have to ³³³³³³ mean that there are no files indeed. ³³³³³ÀÄÄį Modify : When the user that runs the virus has ³³³³³ modify rights in this directory, he can ³³³³³ change the file attributes of a file. So if ³³³³³ your virus needs to infect a file, don't ³³³³³ just clear those attributes, do this only ³³³³³ if you see that the file is set to read ³³³³³ only, and afterwards, check for an error. ³³³³ÀÄÄÄį Erase : The virus can erase files in this ³³³³ directory. Idea for a payload? ³³³ÀÄÄÄÄį Create : This might come in handy when you want to ³³³ make a companion virus. You don't need ³³³ Write permission to write to a file, only ³³³ Create is sufficient. ³³ÀÄÄÄÄÄį Write : You definately need this for any kind of ³³ virus that needs to modify the host file. ³³ If a write fails, you should abandon the ³³ infection routine. ³ÀÄÄÄÄÄÄį Read : You can read files in this directory, so if ³ you want to make your next virus truly ³ Netware compatible, check when you read the ³ file header (everyone does MZ/ZM checks) if ³ the read succeeded. ÀÄÄÄÄÄÄÄį Supervisory : Whoooaaaaaa! :-D Strategy for Novell Netware ~~~~~~~~~~~~~~~~~~~~~~~~~~~ What you can do best when you want to make a virus that is successful in a Novell Netware environment, you better use the following infection method: Get Attributes If No Attributes Jump Infect Clear Attributes On Error Jump Companion (no 'M' flag) Infect: Open File On Error Jump Companion (sharing violations) Read Header On Error Jump Companion (no 'R' flag) Write Virus to EOF On Error Jump Create_Trick (no 'W' flag) Move FilePointer to Start Write Header to BOF (No check, it worked a moment ago) Close File Set Attributes (No check, it worked a moment ago) Jump Done Create_Trick: Rename File to something else On Error Jump Done (Rename Inhibit flag set) Create new file with with same filename On Error Jump Done (no 'C' flag) Write Infected Header to BOF On Error Jump Done (no 'W' flag) Copy Original Program On Error Jump Done (no 'R' flag) Write Virus Close File Delete Original On Error Jump HideDamage (no 'D' flag) Jump Done HideDamage: Set Attributes Hidden+System+ReadOnly (just hide it) Jump Done (can't do anything else, if 'M' flag is there) Companion: Create Companion file On Error Jump Done (no 'C' flag) Write Virus Close File Done: As you can see, you need to do a lot of checks, but this is the most effective way to propagate through the network. As additional features you can add the eXecute only flag to the companion files, that makes it virtually impossible for virus scanners to detect the virus. The drawback is that files that are set eXecute only won't be backed up by Netwares SBACKUP, so if your virus is only a companion virus, a system administrator can simply wipe out your virus by backing up all executables, deleting them on the harddisk and restore them from the backup again, which is ofcourse not desireable by us. Deleted files ~~~~~~~~~~~~~ Since Novell doesn't truly delete files unless a directory flag is set to Purgeable or when a PURGE command is issued, files still can be recovered using SALVAGE. If you want your virus to be a real fast infector don't forget to include infection on delete, so that when your virus is killed, it can accidentally be recovered by some user. eXecute only ~~~~~~~~~~~~ Files that have the execute only flag set can't be opened, not by a virus, nor a backup utility (like SBACKUP). That means that you can use the execute only flag as infection marker for your files in a network environment, since you can't reinfect a file since you cannot open it anymore. A nice side effect is that a virus scanner also can't open the files anymore, thus rendering your virus truly full-stealth even when not resident. Beware that you do not set the execute only flag on exe hosts with internal overlays or that contain some sort of internal pmode extender or self check, since execution of these files will miserably fail. Novell Bootimage Multipartite ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Novell provides the possibility to let a diskless workstation remotely reboot from a server. To make this possible, you can store boot images of a floppy drive in the SYS:LOGIN directory. The default boot file is NET$DOS.SYS. If your virus is running with supervisor rights, you can infect this file in a multipartite fashion. Instead you have to use the file functions for infection, but the boot code can be the same like normal multipartite code. If there are certain workstations that have to be booted using different drivers, there is a text file called BOOTCONF.SYS, where all MAC addresses are stored and the respective boot image it needs. Just find any SYS file in that text and infect those files like you would do NET$DOS.SYS. This will make sure that all workstations are infected once they are rebooted. Ofcourse you can make your life easier and just go for exe infection and take SYS:LOGIN/LOGIN.EXE, but some companies use logon replacements. And besides, what virus scanner will scan SYS files for boot viruses? Spoofing Console Messages with Novell 3.11 (and how it fucks up within 3.12) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An interesting possibility for Netware 3.x. is that you can send anonymous messages to the console. You can simulate error messages easily, prompting the supervisor to do something you want, like unmounting the SYS volume and start running VREPAIR.NLM, or any program you need to compromise the security of the network, making it possible for your virus to propagate faster. Get an error message manual or Netware 3.11 too see what kind of messages the server can show on the console screen. Unfortunately it can't be that easy, since Netware 3.12 spoils the party. Since Netware 3.12, the server will display where the message originates from, making it easy to extinguish genuine server messages and the ones your virus tries to send to the server. The best you can do is trying to detect with version of Novell Netware your virus is running on. Multipartite ~~~~~~~~~~~~ Multipartite viruses that haven't been well-written won't make it far in a good maintained Novell environment. Many Novell networks don't have any hard disks in their clients. All data and programs get run from diskette or straight from the network drive. If you write a multipartite virus, make sure that it also can go resident from executable files, in contrast to the Tequila virus, which doesn't have a chance to survive in a network environment (even neglecting the fact that it won't survive in a environment where Windows is used). I'm currently trying to exploit the possibility of Remote Program Loaders as a default way to go memory resident from the Master Boot Record, but I'm experiencing problems with QEMM. Anyone who knows a way to fix problems with DOSDATA please mail me. System File Tables ~~~~~~~~~~~~~~~~~~ You like manipulating the SFT in order to make your virus stealth, or make infecting it a little easier? Forget it, your virus won't even make it to a Novell network environment. SFT's are useless and I'm afraid you've got to do all file related functions in the old-fashioned way. To see how effective SFT's are, try getting my DSA virus to infect one single file on the network. Rajaat, November '98