L0pht Security Advisory Released January 10, 1997 Application: Novell Netware 3.x Vulnerability Scope: Sites running Netware 3.x Severity: Users may create trojan horses by creating personal login scripts for users who do not already have one. Users may create or modify their own login scripts. Author: 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\\.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. Patch/Work Around: 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.