---------------------------------------------------------------------------

Section 07

Miscellaneous Info on Netware

---------------------------------------------------------------------------

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 <fname> option for LOGIN. Using "LOGIN /S NUL <login>" 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 <alt 174> <alt 174> (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?

It 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. The
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 and LOAD RSPX PASSWORD (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.

---------------------------------------------------------------------------

