Netware Hack FAQ v5

[ Return to TOC | Return to FAQ Page ]

### Section 06

    Fun with Netware 4.1

    06-1. What is interesting about Netware 4.x's licensing?
    06-2. How can I tell if something is being Audited?
    06-3. Where are the Login Scripts stored and can I edit them?
    06-4. What is the rumored "backdoor" in NDS?
    06-5. How can I remove NDS?
    06-6. How can I remove Auditing if I lost the Audit password?
    06-7. Does 4.x store the LOGIN password to a temporary file?
    06-8. Everyone can make themselves equivalent to anyone including Admin. How?
    06-9. Can I reset an NDS password with just limited rights?
    06-10. What is OS2NT.NLM?
    06-11. Do you have to be Admin equivalent to reset a password?
    06-12. What if I can't see SYS:_NETWARE?
    06-13. What are security considerations regarding partitions of the tree?
    06-14. Can a department "Supe" become a regular Admin to the entire tree?

    06-1. What is interesting about Netware 4.x's licensing?

It is possible to load multiple licenses and combine their total number of users. For example, if you are in one of those Novell CNE classes where they give you a 2 user 4.1 license, you can get everyone's CD in class and combine them on one server. If you get 10 CDs you have a 20 user license. I know of no limit to the maximum number of licenses and user limit, except for hardware limitations supporting it. This means you could load more than one copy of 1000 user Netware 4.1 on a server (assuming you have unique copies, not the same copy twice).

itsme has done some poking around with his tools, and has the following to say regarding the SERVER.EXE that comes with Netware 4:

     what's inside server.exe:
     0001d7c7  server.nlm          type=07
     000d319d  "Link" 000d504a
     000d31a5  unicode.nlm         type=00  (ordinary NLM)
     000d504a  "Link" 000d6e9c
     000d5052  dsloader.nlm        type=00  (ordinary NLM)
     000d6e9c  "Link" 000db808
     000d6ea4  timesync.nlm        type=00  (ordinary NLM)
     000db808  polimgr.nlm         type=0c  ('hidden' NLM)
       by editing the binary of server, and changing the type of polimgr.nlm
       from 0c to 00  (offset 007a or 000db882 in server.exe)
       it becomes unhidden.
       hidden NLM's are protected from debugging with the netware debugger.

       polimgr.nlm  manages the license files, after it reads the file,
       it checks with somekind of signature function whether it is a valid file
       the function doing the checking can be made to always return OK, then
       you can create an any number of users license.

    06-2. How can I tell if something is being Audited?

Use RCONSOLE and do a directory scan of SYS:_NETWARE. There will be some binary files named NET$AUDT.* if Auditing has been used. Old Audit files will be named NET$AUDT.AO0, .AO1, etc. A current Auditing file will be named NET$AUDT.CAF. If these files do not exist, no Auditing is being or has been done. To check to see if Auditing is currently active, try to open the current Auditing file like this:

          LOAD EDIT SYS:_NETWARE\NET$AUDT.CAF

If it pulls up something (with a little garbage) then Auditing is currently turned off. If you get an error stating that NET$AUDT.CAF doesn't exist and do you wish to create it, that means the file is being hend open and Auditing is currently active on SOMETHING (remember, the EDIT.NLM normally handles open files pretty well, but trying to open a file already open in SYS:_NETWARE always gets this error).

Also, if the site is running Novell's Web Server software, use a web browser and try http://www.target.com/scripts/convert.bas?../../_netware/net$audt.caf and if you DO NOT receive an error, Auditing is or was active. See section 05-10 for details on this bug.

    06-3. Where are the Login Scripts stored and can I edit them?

The Login Scripts are stored in, you guessed it, SYS:_NETWARE. Unlike the binary files used in NDS, these files are completely editable by using EDIT.NLM. Doing an RCONSOLE directory scan in SYS:_NETWARE will turn up files with extensions like .000, these are probably Login Scripts. Pull up a few, they are plain text files. For example, you found 00021440.000:

          LOAD EDIT SYS:_NETWARE\00021440.000

If it is a Login Script, you will see it in plain english and you can certainly edit and save it. This completely bypasses NDS security, and is the main weakness. You can use this to grant a user extra rights that can lead to a number of compromises, including full access to the file system of any server in the tree.

    06-4. What is the rumored "backdoor" in NDS?

The rumored backdoor in NDS exists - to an extent. The rumor is that there is a way to set up a backdoor into a system in NDS that is completely hidden from everyone and everything. There IS a way to get real close to this, although how "hidden" it is remains to be seen. One catch - you need full access to NDS i.e. Admin access to set it up. But if you can get Admin's password or access to a user with Admin or equivalent access then you can put in a backdoor that may go unnoticed for months, or perhaps never be discovered. Here's how to set it up:

          - Get logged in as Admin or equivalent.
          - In NWADMIN highlight an existing container.
          - Create a new container inside this container.
          - Create a user inside this new container. No home directory.
          - Give this user full Trustee Rights to their own user object.
          - Give this user full Trustee Rights to the new container.
          - Make this user security equivalent to Admin.
          - Modify the ACL for the new user so they can't be seen.
          - Adjust the Inherit Rights Filter on the new container so no one can
            see it.

Now this technique can be used by the paranoid admin that wants to give another user full access to a container, and this user wants to restrict access to this container. To prevent this user from forgetting their password (and making a section of the tree unmanageable or worse, disappear) an admin will use similiar techniques.

I have not been able to fully test this but it looks completely invisible to the average LAN admin. This does require an above average knowledge of NDS to set up, so most administrators will not even know how to look for this user.

Let's say you installed your backdoor at the XYZ Company, put your container inside the MIS container and called it BADBOY. Your backdoor is named BACKDOOR. Login like this:

          LOGIN .BACKDOOR.BADBOY.MIS.XYZ

Now you will show up in the normal tools that show active connections on a server, so naming your backdoor "BACKDOOR" is probably not a great idea. Think of a name that might look like an automated attachment, and only use it when you think you won't be noticed.

If the site has Kane Security Analyst, they can find the backdoor.

    06-5. How can I remove NDS?

This one is dangerous. This one will get you your Admin account back if you lost the password, and is not for the light-hearted if you plan on actually using NDS afterwards. Do this at a 4.1 console:

    LOAD INSTALL -DSREMOVE

Now in the INSTALL module, go ahead and try to remove NDS. As a part of the process, it will ask you for the Admin password, get this, JUST MAKE ONE UP. If you get errors, no problem. Keep going and you can remove NDS from the server. Even though you gave it the wrong password, it will still let you remove NDS. I told you this one is real wicked...

    06-6. How can I remove Auditing if I lost the Audit password?

If the Auditor forgets the password, try a simple wipe and reload. Hello, hello, you seemed to have fainted...

You can try this although there is no guarantee it will work, it is just a theory. You see, the Auditing files are located in SYS:_NETWARE. As long as they are there and Auditing active, even deleting NDS and recreating it will not turn off Auditing. If you wish you can delete and rebuild SYS: which will get it. Try these listed items if you are desperate. I have tried them in the Nomad Mobile Reseach Centre lab and got this to work a couple of times -- but once I trashed the server and NDS. One time it didn't work at all. But here it is:

          - Use RCONSOLE's directory scan and get the exact names of the Audit
            files, you know NET$AUDT.CAF but also files with an extension of .$AF
            are Auditing files, too.
          - Use the techniques in 06-2 and determine exactly which files are
            being held open by this particular server for Auditing.
          - Try booting up the server and running a sector editor.
          - Search the drive for the file names you found.
          - Change all occurrences of these names, save changes, and boot up.
          - If that didn't do the trick, try booting up the server using a 3.x
            SERVER.EXE and try and get to SYS:_NETWARE that way. Then delete the
            Auditing files.
          - If THAT doesn't work, use repeated calls to the SYS:_NETWARE's
            directory table (using the APIs) and either delete or change the
            afore mentioned files.

Gee, maybe a "simple wipe and reload" is easier...

    06-7. Does 4.x store the LOGIN password to a temporary file?

Yes and no. No to 4.02 or higher. Here's the scoop on 4.0.

The version of LOGIN.EXE that shipped with 4.0 had a flaw that under the right conditions the account and password could be written to a swap file created by LOGIN.EXE. Once this occured, the file could be unerased and the account and password retrieved in plain text.

    06-8. Everyone can make themselves equivalent to anyone including Admin. How?

A couple of things might cause this. One, I'd check the rights for [PUBLIC], and secondly I'd check the USER_TEMPLATE id for excessive rights. The Write right to the ACL will allow you to do some interesting things, including making yourself Admin equivalent. For gaining equivalence to most anything else you need only Read and Compare.

The implication should be obvious, but I'll spell it out anyway. A backdoor can be made if an account is set up this way. Let's say you've created an account called TEST that has enough rights to do this kind of thing. Simply go in as the TEST account, make yourself Admin equivalent, do your thing, remove the Admin equivalent, and get the hell out. Neat and sweet.

    06-9. Can I reset an NDS password with just limited rights?

There is a freeware utility called N4PASS, that is meant for Netware 4.10 (uses NDS calls and is not bindery based). The intention of this package is to enable a Help Desk to reset passwords for users without granting them tons of rights. It uses full logging and does not require massive ACL manipulation to do it.

Obviously being set up to use this utility opens a few doors. The filename is N4PA12.EXE, and can be retrieved from the author's web site at http://fastlane.net/homepages/dcollins and the author can be reached at dcollins@fastlane.net.

A couple of interesting things about this utility -- if configured incorrectly the server may be compromised in a number of ways. For instance, the password generated is a calculation that uses a 'temp filename', the date, the user's loginname, helpdesk login name, seed value, and a few other items. (its in the n4pass.txt file)

N4PASS is not set to purge immediately, the file is salvagable. Also, if the rights to the N4PASS directory are too open, you can discover the default password, among other things. The text file included with the utility covers this, so read it carefully if you are installing it. If you are hacking, read it carefully too ;-)

It is critical that access to the sys:\n4pass\password is secure since any 'temp file' (.1st extension) can cause the 'password reset' for the person listed in the 'temp file'.

    06-10. What is OS2NT.NLM?

OS2NT.NLM is a Novell-supplied NLM for recovering/fixing Admin, like after it becomes an Unknown object, as opposed to User -- especially after a DSREPAIR. This module is considered a "last resort" NLM and you must contact Novell to use it. While I haven't seen it, it is supposed to be on one of Novell's FTP sites. It supposedly is customized by Novell to work with your serial number and is a one-time use NLM. You have to prove to Novell who you are and that your copy of Netware is registered.

I would suspected it is possible that this NLM could be hacked to get around the one-time use and serial number/password thing, but a restore of NDS from a good backup would accomplish things better. This way is a little destructive.

    06-11. Do you have to be Admin equivalent to reset a password?

No. There is a freeware utility called N4PASS, that is meant for Netware 4.10 (uses NDS calls and is not bindery based).

The intent is for helpdesk staff to reset passwords for users without setting up elaborate ACL settings for a group to control the password property. It supposedly does this with full logging. I'm looking for info on it, so let me know if you have tips on its use.

    06-12. What if I can't see SYS:_NETWARE?

A number of people have sent me information regarding this, it seems if Novell's 410pt3 patch is applied you can no longer see the _NETWARE directory. This is hardly surprising as the ability to look into this directory has become increasingly difficult.

If you are an administrator you'd probably want to load this patch. If you're a hacker -- don't dispare. Most administrators are real slow in updating their systems ;-)

    06-13. What are security considerations regarding partitions of the tree?

Most of this is covered as individual items, but here is a bit regarding partitioning of the tree.

As mentioned in section 02-6, you can set the bindery context of a server to help you recover a lost ADMIN password. It should be noted that you can only access containers in the current servers partition.

With larger networks things get more complex. For example, a "supervisor" account (one with full access to the file system) may have limited access on another server. The number of possible leaks for intruders grows with the size of the network.

A hacker could exploit this and gain control of other partitions, if any object in the first partition they have compromised has access rights to other directory partitions. Intruders could easily give themselves security equivalence to that object, or change that objects password with SYSCON, then login as that object and access the other partitions.

In other words, if a read/write or master partition is stored on one server, its supervisor can potentially manage all objects in this partition, and since its supervisor's password can be reset from the console, other partitions are at risk.

Read/only replicas of partitions by nature will not allow you to set your bindery context to a container in that area -- they are, duh, read only. Of course the brave can disconnect the server from the network, and run DSREPAIR on that server to change the partition to master, but that's rather extreme.

Novell recommends trying to restrict object rights to their own partition and to create replica partitions only on trusted server. Let's use an example to illustrate:

- Server ACCOUNTING has lots of spreadsheets, documents, and a database used by the accounting department with all kinds of information. The container ACCT-USERS has the IRF set so that they manage themselves.

- There is an account called MAINTENANCE in the ACCT-USERS container that the manager of accounting can reset the password. This is done when the LAN administrators need to perform any kind of maintenance, such as building IDs with tricky access rights, etc. that the accounting manager doesn't know how to do.

- A read/write replica of the partition containing the ACCT-USERS container exists on a server across town in a small sales office. A temporary office clerk hired from a local temp agency has access to the storage closet where this server is kept.

- One afternoon the temporary uses SETPWD.NLM and resets the MAINTENANCE account password.

- The next day (after replication) the temporary rifles through all accounting documents which include payroll and personal information, sales forecasts, future plans for capital expenditure, etc.

    06-14. Can a department "Supe" become a regular Admin to the entire tree?

Yes, under certain conditions.

- The tree has an OU called LAWDEPT.
- The Admin account is at the root of the tree.
- A departmental supervisor account called FRED is located in LAWDEPT with Admin rights to the LAWDEPT OU (a Trustee of LAWDEPT and supe rights to objects and properties).
- Server LawServer is in the LAWDEPT OU with two bindery contexts, one in the LAWDEPT OU and one at the root (so Admin can login via the bindery if needed)
- Although FRED only has browse at the root, he can run SYSCON and modify the Admin account to gain more access, like say the password.
- If FRED is a psychopath, he can delete the Admin account and render tree management useless.

[ Return to TOC | Return to FAQ Page ]