Copy Link
Add to Bookmark
Report
29A Issue 03 02 11
% 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)
<MZ/ZM checks etc - out of scope in this document>
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
