Netware Hack FAQ v5

[ Return to TOC | Return to FAQ Page ]

### Section 07

    Miscellaneous Info on Netware

    07-1. Why can't I get through the 3.x server to another network via TCP/IP?
    07-2. How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF?
    07-3. How can I login without running the System Login Script?
    07-4. How do I remotely reboot a Netware 3.x file server?
    07-5. How can I abend a Netware server? And why?
    07-6. What is Netware NFS and is it secure?
    07-7. Can sniffing packets help me break in?
    07-8. What else can sniffing get me?
    07-9. How does password encryption work?
    07-10. Are there products to help improve Netware's security?
    07-11. What is Packet Signature and how do I get around it?
    07-12. Do any Netware utilities have holes like Unix utilities?

    07-1. Why can't I get through the 3.x server to another network via TCP/IP?

Loading the TCPIP.NLM in a server with two cards does not mean that packets will be forwarded from one card to another. For packet forwarding to work, the AUTOEXEC.NCF file should have the line:

    load tcpip forward=yes

For packets to go through the server, you must set up a "gateway=aa.bb.cc.dd" option on the workstation. This leaves routing up to the server. If you are writing hack tools, keep this in mind if they use IP. Some older routers may not recognize the Netware server as a router, so you may not have many options if your target is on the other side of one of these routers. Newer routers are Netware aware and will "find" your server as a router through RIP.

Netware 3.11 IP will only forward between two different subnets. Proxy Arp is currently not supported in Netware IP. Example:

    123.45.6 & 123.45.7 with a mask of ff.ff.ff.00 will forward packets

    123.45.6 & 231.45.7 with a mask of ff.ff.ff.00 will not

This way you do not waste precious time trying to cross an uncrossable river. Some admins use this to limit the flow of IP traffic.

    07-2. How can I boot my server without running STARTUP.NCF/AUTOEXEC.NCF?

For Netware 3.xx, use these command-line options:

    SERVER -NS to skip STARTUP.NCF, and

    SERVER -NA to skip AUTOEXEC.NCF

NetWare 2.x does not HAVE the files STARTUP.NCF and AUTOEXEC.NCF. Instead they hard-code all the information into NET$OS.EXE, so you will have to rebuild it to change anything.

    07-3. How can I login without running the System Login Script?

Often an admin will try and prevent a user from getting to DOS or breaking out of the System Login Script to "control" the user. Here's to way to prevent that -

- Use ATTACH instead of LOGIN to connect to a server. ATTACH will not run the login script, whereas LOGIN will. ATTACH.EXE will either have to be copied to a local HD or put in SYS:LOGIN.
- Use the /s option for LOGIN. Using "LOGIN /S NUL " will cause LOGIN to load the DOS device NUL which will always seem like an empty file.

    07-4. How do I remotely reboot a Netware 3.x file server?

If you have access to a server via RCONSOLE it may come in handy after loading or unloading an NLM to reboot a server. Build an NCF file by doing the following steps -

- Create a file called DOWNBOY.NCF on your local drive. It should be a text file and contain the following lines:

            REMOVE DOS
            DOWN
            EXIT

- Copy up the file to the SYS:SYSTEM directory using RCONSOLE.

- At the System Console prompt, type DOWNBOY and enter.

What happens is this - the REMOVE DOS statement frees up the DOS section in server RAM, the server is downed (if there are open files, you will be given one of those "are you sure" messages, answer Y for yes), and the EXIT command tries to return the server console to DOS. But since you removed DOS from RAM, the server is warm booted.

    07-5. How can I abend a Netware server? And why?

I'll answer the second question first. You may be testing your server as an administrator and wish to see how you are recovering from crashes. Or you may be a hacker and wish to cover your tracks VERY DRAMATICALLY. After all, if you are editing log files and they are going to look funny when you are done, a good crash might explain why things look so odd in the logs.

These are per itsme:

    - Netware 4.1 : type 512 chars on the console + NENTER -> abend
    - Netware 3.11 : NCP request 0x17-subfn 0xeb with a connection number higher
      than the maximum allowed will crash the server (yes you will need the APIs)

If you have console access, try this:

    - At the server console type UNLOAD RENDIRFIX
    - Use your local copy of SYS:PUBLIC/RENDIR.EXE
    - In SYS:LOGIN type RENDIR   (login not required, just
    attaching to the server)

    07-6. What is Netware NFS and is it secure?

NFS (Networked File System) is used primarily in Unix to remotely mount a different file system. Its primary purpose in Netware is to allow the server to mount a Unix file system as a Netware volume, allowing Netware users access to Unix data without running IP or logging into the server, and Unix users to mount a Netware volume as a remote file system. If the rights are set up incorrectly you can gain access to a server.

While the product works as described, it is a little hard to administer, as user accounts on both sides must be in sync (name and password) and it can be a fairly manual process to ensure that they are, unless the versions are Netware NFS 2.1 or greater with Netware 4.x AND the Unix side is NOT running NIS. Simply adding the proper UID to the NDS object to create a relationship for rights to be passed back and forth. There are three modes -- Unix is God, Netware is God, or both are right.

A reported problem with Netware NFS is that after unloading and reloading using the .NCF files, a system mount from the Unix side includes SYS:ETC read only access. If this directory can be looked at from the Unix side after a mount, .NCF and .CFG files could be viewed and their information exploited. For example, SYS:ETC is a possible location of LDREMOTE.NCF, which could include the RCONSOLE password.

On Netware 3.11 if you ask the portmapper for an NFS handle it will give you one. When you give NFS the file handle it will check its LOCAL portmapper and then grant the request. You can then read any file on the mount you just made.

Netware NFS' existence on a server says you have some Unix boxes around somewhere, which may be of interest as another potential system to gain access to.

    07-7. Can sniffing packets help me break in?

Yes. If a user is logging in and the password is being transmitted to the server unencrypted, it will show up as plain text in the trace. If the site uses telnet and ftp, capturing those password will come in handy. Outside of gaining access to another system, many users will make their passwords the same across all systems.

For a list of DOS-based sniffers, see the alt.2600/#hack FAQ. I personally prefer the Network General Sniffer ;-)

RCONSOLE.EXE is the client-launched application that provides a remote server console to a Novell Netware file server. The connection between client and server allows administrators to manage servers as if they were at the physical server console from their desks, and allow virtually any action that would be performed at the server console to be performed remotely, including execution of console commands, uploading of files to the server, and the unloading and loading of Netware Loadable Modules (NLMs). It is not only an effective tool for administrators, it is a prime target for hackers.

A critical point of access to many servers is the actual physical console. This is one of the main reasons why physical security of the server is so important and stressed by security conscious administrators. On many systems you have a level of access with little to no security. Netware is no exception.

The main reason to hack RCONSOLE is to gain access to the Netware server console. No, you aren't physically there, but the OS doesn't know any different. And the main reason to gain access to the Netware server console is to utilize a tool to gain Supervisor access to the Netware server.

During the RCONSOLE process, the password does come across the wire encrypted. If you look at the conversation you will see packets containing the RCONSOLE.EXE being opened, the possible servers to be accessed, etc. This conversation is nothing but NCP packets.

Once RCONSOLE is up on the workstation, the user chooses the server, hits enter, and is prompted for a password. After entering the password, the conversation contains two 60 byte IPX/SPX packets going back and forth followed by 4 NCP packets, 64 bytes, 60 bytes, 64 bytes, and 310 bytes in length respectively. The next IPX/SPX packet, 186 bytes in length, contains the password. It is located at offset 3Ah, which is easy to find. Offset 38h is always FE and offset 39h is always FF.

Now comes the use of a tool called RCON.EXE from itsme that can take some of the information you have collected and turn it into the password. What you need are the first 8 hex bytes starting at offset 3Ah, the network address, and the node address. Now the network and node address are in the header of the packet that contains the encrypted password, but can also get these by typing USERLIST /A which returns this info (and more) for each person logged in.

Now why just the first 8 hex bytes? That's all Novell uses. Great encryption scheme, huh?

    07-8. What else can sniffing get me?

Jeff Carr has pointed out that RCONSOLE sends screens in plaintext across the network for all to see (well, all with sniffers). This means you can see what is being typed in and what is happening on the screen. While it is not the prettiest stuff to look at, occassional gems are available. Jeff's best gem? The RCONSOLE password. The server had been brought up without REMOTE and RSPX being loaded, they were loaded by hand at the console after the server was brought up. The first RCONSOLE session brought up the screen with the lines LOAD REMOTE PASSWORD and LOAD RSPX (with PASSWORD being the RCONSOLE password), and this was being sent to the RCONSOLE user's workstation in plaintext.

Teiwaz discovered that SYSCON sends password changes in plaintext. While SETPASS, LOGIN, MAP, and ATTACH all encrypt the password in 3.x, SYSCON does not.

    07-9. How does password encryption work?

From itsme -

    the password encryption works as follows:
     1- the workstation requests a session key from the server
         (NCP-17-17)
     2- the server sends a unique 8 byte key to the workstation

     3- the workstation encrypts the password with the userid,
         - this 16 byte value is what is stored in the bindery on the server

     4- the WS then encrypts this 16 byte value with the 8 byte session key
        resulting in 8 bytes, which it sends to the server
         (NCP-17-18 = login), (NCP-17-4a = verify pw) (NCP-17-4b = change pw)

     5- the server performs the same encryption, and compares its own result
        with that sent by the WS

    -> the information contained in the net$*.old files which can be found
       in the system directory after bindfix was run, is enough to login
       to the server as any object. just skip step 3

    07-10. Are there products to help improve Netware's security?

While there are a number of products, commercial and shareware/public domain that have some security-related features, the following products are either really good or have some unique features.

There is a commercial product called SmartPass, which runs as an NLM. Once installed, you can load this and analyze existing passwords for weaknesses. A limited-time free demo can be obtained from the following address:

http://www.egsoftware.com/

SmartPass will check passwords on the fly, so a user can be forced to use a non-dictionary word for a password.

Another commercial product product that will check from a dictionary word list and simply report if the password is on the list is Bindview NCS. There is a brand new NDS version of this product but I haven't look at it yet. The bindery version is god-awful slow, but completely accurate. It requires Supe access to run. Bindview can also produce a number of reports. including customized reports to give you all kinds of info on the server and its contents. For more info on Bindview:

http://www.bindview.com/

For doing Auditing on a 3.x version of Netware, try AuditTrack. It will track all access to a directory or individual file by user, which can come in handy for seeing who is doing what. Out of the box Netware 3.11 has virtually no way to track what an individual user is doing, but the AuditTrack NLM helps greatly. E.G. Software, the developer, can be reached at:

http://www.egsoftware.com/

Intrusion Detection Systems puts out a commercial product called Kane Security Analyst. It is considered by many to the "SATAN" of Netware. One of its abilities is locating hidden objects in the NDS tree. For a good demo, a 30 day trial version, and more info:

http://www.intrusion.com/

"SafeWord for Netware Connect" is an NLM that does password checks in a Netware Connect environment:

http://www.safeword.com/nwcspec.html

There is a product called Password Helper that "enhances" the security around the changing of passwords for 3.x. It is a local EXE/server NLM product that allows non-Supe users to reset passwords.

    07-11. What is Packet Signature and how do I get around it?

Packet signatures works by using an intermediate step during the encrypted password login call, to calculate a 64-bit signature. This block is never transmitted over the wire, but it is used as the basis for a cryptographically strong signature ("secure hash") on the most important part of each NCP packet exchange.

A signed packet can indeed be taken as proof sufficient that the packet came from the claimed PC.

NCP Packet Signature is Novell's answer to the work of the folks in the Netherlands in hacking Netware. The idea behind it is to prevent forged packets and unauthorized Supervisor access. It is an add-on option in 3.11, but a part of the system with 3.12 and 4.x. Here are the signature levels at the client and server:

Packet Signature Option and meaning:
0 = Don't do packet signatures
1 = Do packet signatures if required
2 = Do packet signatures if you can but don't if the other end doesn't support them
3 = Require packet signatures

You can set the same settings at the workstation server. The default for packet signatures is 2 at the server and client. If you wish to use a tool like HACK.EXE, try setting the signature level at 0 on the client by adding Signature Level=0 in the client's NET.CFG. If packet signatures are required at the server you won't even get logged in, but if you get logged in, hack away.

If you wish to change the signature level at the server, use a set command at the server console:

    SET NCP PACKET SIGNATURE OPTION=2

    07-12. Do any Netware utilities have holes like Unix utilities?

This is a fairly common question, inspired by stack overrun errors, sendmail bugs, and the like that exist in the Unix world. The reason you do not have these kind of exploits in common Netware utilities is because:

- You use a proprietary shell that can be loaded without accessing the server, therefore no shell exploits exist.
- Virtually all Netware utilities do NOT use stdin and stdout, so no stack overruns that exploit anything.
- Since the shell is run locally, not on the server, you have no way to use a utility to gain greater access than you have been granted, like a SUID script in Unix.
- Yes there are utilities like HACK.EXE that grant extra access under certain conditions in 3.11, but no Novell-produced utility comes close to granting extra access.

[ Return to TOC | Return to FAQ Page ]