COMMAND
Novell Netware 3.x
SYSTEMS AFFECTED
Systems running Novell Netware 3.x
PROBLEM
The following text is l0pht copyright and it is part of their
security advisory released January the 10th. Author is John Tan.
Scenario: Users without a personal login script are vunerable to
a trojan horse type attack. Any user logged into the server can
create a personal login script for any user that does not already
have one. A user may also create their own personal login
script, circumventing any access control implemented through
EXITing to menu systems or issuing commands from the personal
login script. Under these senarios, one user may use another to
launch an elevated privelidges attack. Alternately, a user may
EXIT from the login script, circumventing any menu systems
typically used to restrict access at the presentation level. The
vunerability has been tested under Netware 3.x, is believed to
exist in Netware 2.x (but is un-tested). Netware 4.x is planned
to undergo examination.
Details: Under Netware 3.x, the user's login script is stored in
that user's mail directory. In this directory, any user that is
logged into the server may create new files. If user A were to
create a file called LOGIN. in the SYS:\MAIL\ subdirectory that
corresponds with their own or another user's mail id, user A
could cause a number of things to happen which could be used
toward user A's ends.
Example 1: Elevated Privlidges #1
Bad D00D writes a "brute force" style DOS program and carries
it around on floppy disk. Bad D00D logs into your Netware
network as "GUEST" and types "map" to find that the F: drive
is mapped to the SYS volume. "GUEST" types "F:" and "cd \MAIL"
to change to the mail directory. "GUEST" then types
"a:slipit" to run his program. The program copies file
"A:LOGIN" to every directory it finds below the working
(F:\MAIL) directory. Since Bad D00D assumed that "GUEST"
would not have file "S"can rights in the MAIL directory, the
program will try every directory name possible, optionally
starting with "1" (as it assumes that you wish to treat the
supervisor different), then proceeding to "00000000" and
working sequentially to "ZZZZZZZZ". File "A:LOGIN" contains
the following ASCII text:
#F:\PUBLIC\EVILCMDS.BAT
Example 2: Elevated Privlidges #2
Bad D00D logs into your Netware Network as "GUEST" and finds
a menu system. The menu system allows for word processing
and faxing. It does not seem to allow for Bad D00D to run
his cool "slipit" program. So Bad D00D runs the word
processor and creates an ASCII file with the following text:
EXIT
Then Bad D00D ("GUEST"), tries to save the file under
F:\MAIL. "GUEST" only sees one sub-directory under F:\MAIL
and saves the file under that directory as "LOGIN". Then Bad
D00D exits the word processor and logs out of Netware. He
immediately logs back into Netware and WOW! There's no more
menu system, just the DOS prompt. Cool, Bad D00D can now run
his "slipit" program.
Example 3: Backdoor Installation
Bad D00D discovers that he forgot a disk and has to go home
and get some other programs. He figures that he will have
quite a bit more file system access as "GUEST" next time he
logs in now that he has run his "slipit" program. But he
won't have the SYSCON access rights he desires. He really
needs passwords for SUPERVISOR or equivalents. So with the
word processor from before, or perhaps EDIT, he creates the
file F:\MAIL\1\LOGIN with the following ASCII text:
#C:\COMMAND.COM /C @ECHO=OFF
#C:\COMMAND.COM /C COPY F:\MAIL\1\L0GIN.EXE F:\LOGIN\LOGIN.EXE
Bad D00D then types "copy A:L0GIN.EXE F:\MAIL\1\L0GIN.EXE".
Now, the next time SUPERVISOR logs in, the SUPERVISOR will
copy the trojan L0GIN.EXE to F:\LOGIN\LOGIN.EXE and as users
login, their passwords will be recorded to an ASCII file
F:\MAIL\<GUESTMAILID>\<USERNAME>.TXT. Of course this means
that Bad D00D has to specify a different mail directory for
each server to match the GUEST mail id on that server.
If Bad D00D can find out other usernames that are supervisor
equivalent and their mailids, he can do this for them too.
He could also just write another "slipit" program that could
optionally distribute additional support files with the
LOGIN. file.
SOLUTION
This is a documented vunerability (pg. 118 of the Netware Concepts
Manual). The vunerability exists due to the architecture of the
login procedure. The SYSCON utility creates a MAIL directory for
every user it creates. It does not however, create a personal
login script for each user as Novell has assumed you wish to have
the user call the default login script. Strangely enough, Novell
cautions strongly against this practice but continues to make it
the default. Novell suggests "For security purposes, each user
should have a login script, however minimal". This advise only
addresses vunerabilities introduced when one user alters
another's login script. It does not, however, address attacks
involving the modification of a user's own personal login script.
There is, to the best of my knowledge, no patch or work around
for defending against these types of attacks.