Netware Hack FAQ v5

[ Return to TOC | Return to FAQ Page ]

### Section 12

    For Administrators Only

    12-1. How do I secure my server?
    12-2. I'm an idiot. Exactly how do hackers get in?
    12-3. I have xxx setup and xxx version running. Am I secure?

    12-1. How do I secure my server?

This question is asked by administrators, and I'm sure no hackers will read this info and learn what you admins might do to thwart hack attacks ;-)

One thing to keep in mind, most compromises of data occur from an employee of the company, not an outside element. They may wish to access sensitive personnel files, copy and sell company secrets, be disgruntled and wish to cause harm, or break in for kicks or bragging rights. So trust no one.

    Physically Secure The Server -
    ------------------------------

This is the simplest one. Keep the server under lock and key. If the server is at a site where there is a data center (mainframes, midranges, etc) put it in the same room and treat it like the big boxes. Access to the server's room should be controlled minimally by key access, preferably by some type of key card access which can be tracked. In large shops, a man trap (humanoid that guards the room) should be in place.

If the server has a door with a lock, lock it (some larger servers have this) and limit access to the key. This will secure the floppy drive. One paranoid site I know of keeps the monitor and CPU behind glass, so that the keyboard and floppy drive cannot be accessed by the same person at the same time.

If you only load NLMs from the SYS:SYSTEM directory, use the SECURE CONSOLE command to prevent NLMs being loaded from the floppy or other location.

A hacker could load a floppy into the drive and run one of several utility files to gain access to the server. Or they could steal a backup tape or just power off the server! By physically securing the server, you can control who has access to the server room, who has access to the floppy drive, backup tapes, and the System Console. This step alone will eliminate 75% of attack potential.

    Secure Important Files -
    ------------------------

These should be stored offline. You should make copies of the STARTUP.NCF and AUTOEXEC.NCF files. The bindery or NDS files should be backed up and stored offsite. All System Login Scripts, Container Scripts, and any robotic or non-human personal Login Scripts should be copied offline. A robotic or non-human account would be an account used by an email gateway, backup machine, etc.

Compile a list of NLMs and their version numbers, and a list of files from the SYS:LOGIN, SYS:PUBLIC, and SYS:SYSTEM directories.

You should periodically check these files against the originals to ensure none have been altered.

Replacing the files with different ones (like using itsme's LOGIN.EXE instead of Novell's) will give the hacker access to the entire server. It is also possible that the hacker will alter .NCF or Login Scripts to bypass security or to open holes for later attacks.

    Make a list of Users and their accesses -
    -----------------------------------------

Use a tool like Bindview or GRPLIST.EXE from the JRB Utilities to get a list of users and groups (including group membership). Once again, keep this updated and check it frequently against the actual list.

Also run Security (from the SYS:SYSTEM directory) or GETEQUIV.EXE from the JRB Utilities to determine who has Supervisor access. Look for odd accounts with Supervisor access like GUEST or PRINTER.

It is also a good idea to look at Trustee Assignments and make sure access is at a minimum. Check your run from Security to see if access is too great in any areas, or run TRSTLIST from the JRB Utilities.

Security will turn up some odd errors if SUPER.EXE has been run. If you are not using SUPER.EXE, delete and rebuild any odd accounts with odd errors related to the Bindery, particularly if BINDFIX doesn't fix them yet the account seems to work okay. If a hacker put in a backdoor using SUPER.EXE, they could get in and perhaps leave other ways in.

    Monitor the Console -
    ---------------------

Use the CONLOG.NLM to track the server console activity. This is an excellent diagnostic tool since error messages tend to roll off the screen. It will not track what was typed in at the console, but the system's responses will be put in SYS:ETC\CONSOLE.LOG. When checking the console, hit the up arrow to show what commands were last typed in.

While this won't work in large shops or shops with forgetful users, consider using the SECUREFX.NLM (or SECUREFX.VAP for 2.x). This sometimes annoying utility displays the following message on the console and to all the users after a security breach:

    "Security breach against station  DETECTED."

This will also be written to an error log. The following message is also written the the log and to the console:

    "Connection TERMINATED to prevent security compromise"

    Turn on Accounting -
    --------------------

Once Accounting is turned on, you can track every login and logout to the server, including failed attempts.

    Don't Use the Supervisor Account -
    ----------------------------------

Leaving the Supervisor logged in is an invitation to disaster. If packet signature is not being used, someone could use HACK.EXE and gain access to the server as Supervisor. HACK spoofs packets to make them look like they came from the Supervisor to add Supe equivalence to other users.

Also, it implies a machine is logged in somewhere as Supervisor, if it has been logged in for more than 8 hours chances are it may be unattended.

    Use Packet Signature -
    ----------------------

To prevent packet spoofing (i.e. HACK.EXE) enforce packet signature. Add the following line to your AUTOEXEC.NCF -

    SET NCP PACKET SIGNATURE OPTION=3

This forces packet signature to be used. Clients that do not support packet signature will not be able to access, so they will need to be upgraded if you have any of these clients.

    Use RCONSOLE Sparingly (or not at all) -
    ----------------------------------------

When using RCONSOLE you are subject to a packet sniffer getting the packets and getting the password. While this is normally above the average user's expertise, DOS-based programs that put the network interface card into promiscuous mode and capture every packet on the wire are readily available on the Internet. The encryption method is not foolproof.

Remember you cannot "detect" a sniffer in use on the wire.

Do NOT use a switch to limit the RCONSOLE password to just the Supervisor password. All you have done is set the password equal to the switch. If you use the line "LOAD REMOTE /P=", Supervisor's password will get in (it ALWAYS does) and the RCONSOLE password is now "/P=". Since the RCONSOLE password will be in plain text in the AUTOEXEC.NCF file, to help secure it try adding a non-printing character or a space to the end of the password.

And while you can use the encryption techniques outlined in 02-8, your server is still vulnerable to sniffing the password.

    Move all .NCF files to a more secure location (3.x and above) -
    ---------------------------------------------------------------

Put your AUTOEXEC.NCF file in the same location as the SERVER.EXE file. If a server is compromised in that access to the SYS:SYSTEM directory is available to an unauthorized user, you will at least have protected the AUTOEXEC.NCF file.

A simple trick you can do is "bait" a potential hacker by keeping a false AUTOEXEC.NCF file in the SYS:SYSTEM with a false RCONSOLE password (among other things).

All other .NCF files should be moved to the C: drive as well. Remember, the .NCF file runs as if the commands it contains are typed from the console, making their security most important.

    Use the Lock File Server Console option in Monitor (3.x and above) -
    --------------------------------------------------------------------

Even if the RCONSOLE password is discovered, the Supe password is discovered, or physical access is gained, a hard to guess password on the console will stop someone from accessing the console.

    Add EXIT to the end of the System Login Script -
    ------------------------------------------------

By adding the EXIT command as the last line in the System Login Script, you can control to a degree what the user is doing. This eliminates the potential for personal Login Script attacks, as described in section 03-6.

    Upgrade to Netware 4.1 -
    ------------------------

Besides making a ton of Novell sales and marketing people very happy, you will defeat most of the techniques described in this faq. Most well-known hacks are for 3.11. If you don't want to make the leap to NDS and 4.1, at least get current and go to 3.12.

    Check the location of RCONSOLE.EXE -
    ------------------------------------

In 3.11, RCONSOLE.EXE is located in SYS:SYSTEM by default. In 3.12 and 4.1 it is in SYS:SYSTEM and SYS:PUBLIC. You may wish to remove RCONSOLE.EXE from SYS:PUBLIC, as by default everyone will have access to it.

    Remove [Public] from [Root] in 4.1's NDS-
    -----------------------------------------

Get the [Public] Trustee out of the [Root] object's list of Trustees. Anyone, even those not logged in, can see virtually all objects in the tree, giving an intruder a complete list of valid account names to try.

    Load the LOGIN.EXE locally -
    ----------------------------

Copy the LOGIN.EXE to the local hard drive. Not only does this speed up the login process ever so slightly, it prevented trojaned LOGIN.EXEs from being introduced during the login process. While this does create a problem with exposing the LOGIN.EXE on the C: drive to local attack, you could download a fresh copy during the login process to try and at least keep a clean copy on the local drive.

    12-2. I'm an idiot. Exactly how do hackers get in?

We will use this section as an illustrated example of how these techniques can be used in concert to gain Supe access on the target server. These techniques show the other thing that really helps in Netware hacking - a little social engineering.

    Exploitation #1
    ---------------

Assume tech support people are dialing in for after hours support. Call up and pose as a vendor of security products and ask for tech support person. Called this person posing as a local company looking for references, ask about remote dial-in products. Call operator of company and ask for help desk number. Call help desk after hours and ask for dial-in number, posing as the tech support person. Explain home machine has crashed and you've lost number.

Dial in using the proper remote software and try simple logins and passwords for dial-in software if required. If you can't get in call help desk especially if others such as end users use dial-in.

Upload alternate LOGIN.EXE and PROP.EXE, and edit AUTOEXEC.BAT to run the alternate LOGIN.EXE locally. Rename PROP.EXE to IBMNBIO.COM and make it hidden. Before editing AUTOEXEC.BAT change the date and time of the PC so that the date/time stamp reflects the original before the edit.

Dial back in later, rename PROP.EXE and run it to get Accounts and passwords.

Summary - Any keystroke capture program could produce the same results as the alternate LOGIN.EXE and PROP.EXE, but you end up with a Supe equivalent account.

    Exploitation #2
    ---------------

Load a DOS-based packet sniffer, call the sys admin and report a FATAL DIRECTORY ERROR when trying to access the server. He predictively will use RCONSOLE to look at the server and his packet conversation can be captured. He will find nothing wrong (of course).

Study the capture and use the RCON.FAQ to obtain the RCONSOLE password. Log in as GUEST, create a SYSTEM subdirectory in the home directory (or any directory on SYS:). Root map a drive to the new SYSTEM, copy RCONSOLE.* to it, and run RCONSOLE. Once in try to unload CONLOG and upload BURGLAR.NLM to the real SYS:SYSTEM. Created a Supe user (i.e. NEWUSER) and then typed CLS to clear the server console screen.

Log in as NEWUSER. Erase BURGLAR.NLM, new SYSTEM directory and its contents. Run PURGE in those directories. Turn off Accounting if on. Give GUEST Supe rights. Set toggle with SUPER.EXE for NEWUSER. Run FILER and note SYS:ETC\CONSOLE.LOG (if CONLOG was loaded) owner and create date, as well as SYS:SYSTEM\SYS$ERR.LOG owner and create date. Edit SYS:ETC\CONSOLE.LOG and remove BURGLAR.NLM activity, including RCONSOLE activity. Edit and remove RCONSOLE activity from SYS:SYSTEM\SYS$ERR.LOG as well. After saving files, run FILER and restore owner and dates if needed. Run PURGE in their directories. Logout and login as GUEST and set SUPER.EXE toggle. Remove NEWUSER Supe rights and logout. Login as NEWUSER with SUPER.EXE and remove GUEST Supe rights. Finally logout and login as GUEST with SUPER.EXE and turn on Accounting if it was on.

Summary - You have created a backdoor into the system that will not show up as somthing unusual in the Accounting log. Login as GUEST using SUPER.EXE and turn off Accounting. Logout and back in as NEWUSER with SUPER.EXE, do what you need to do (covering file alterations with Filer), and logout. Log back in as GUEST and turn on Accounting. The NET$ACCT.DAT file shows only GUEST logging in followed by GUEST logging out.

    12-3. I have xxx setup and xxx version running. Am I secure?

This question has been coming up lately. A lot. Admins asking me if their sites are secure. Here is an example from a post to one of the Netware newsgroups with my comments, as it is generic enough to apply to a number of locations (in other words, no you are not 100% secure):

    >Here is the scenario:  A supervisor of a network suspects that he may
    >be facing termination of employment in the near future.  He is embittered
    >and aggravated.  As system administrator for the network, he oversees
    >the computers that track all business actions.  Basically, he can bring
    >the organization to it's knees in a heartbeat, and he knows it.  He has
    >made comments in passing that it is possible that either time bombs have
    >been set in the system, or that a possible "Dead-man's clutch" may exist
    >(if he's not there to disable some mechanism daily/weekly the system will
    >be compromised).

    Not nearly as easy to set up in the environment you've specified. However,
    I'd let that rumor continue so as to waste your time looking for a
    dead-man's clutch. In the meantime, I'd be stealing stuff from those
    databases and selling them to the competition.

    >Here is the tech specs: A Novell 3.12 server that serves databases, email
    >and user files to 30 PC's running Windows 3.1.  The network is attached
    >to the Internet.  No OS's other than DOS/Windows and Novell.  The
    >network is attached to a larger network that is very accessible to the
    >public (via physically attached machines, and the Internet).  There
    >are no firewalls.  The supervisor is the only person with supervisor
    >password/privileges on the server, as well as the only person who knows
    >the details of the network, the server disk layout, the server nlm's.
    >Basically the only person who has been inside the server which is such
    >a vitally mission critical system.
    >
    >Here's what I have so far:
    >        1. quarantine the 30 node network and server by physically
    >           disabling it's Ethernet access to the outside world.

    This is an interesting step. However your problem returns once you
    re-attach.

    >        2. make a full system backup of the server before touching
    >           investigating or touching anything.

    If a problem occurs and you restore your backups, any virii, trojans,
    and other back doors will get back into the system.

    >        3. "secure" the Novell server (see below)

    Read my hack FAQ. ftp://ftp.fastlane.net/pub/nomad/nw/faq.zip

    You see, if I were to leave a backdoor, I would leave several.

    1) I would run BINDFIX and then run a bindery cracker on ALL accounts
    on the server against the .OLD bindery files. I would use
    ftp://ftp.fastlane.net/pub/nomad/nw/bindery.zip to do this, along with
    a huge word list. This should not only get me most passwords on the
    system, but get automated passwords as well. For example, Arcserve
    5.01g installs an account called CHEY_ARCHSVR with station restrictions
    and a password of WONDERLAND. I'd remove the station restrictions and
    either use SUPER.EXE to set up CHEY_ARCHSVR as a toggled Supe account,
    or just make it plain old Supe equivalent. Most people do not check
    these kinds of accounts.

    2) I would install the alternate LOGIN.EXE and PROP.EXE to give myself
    a way to see new passwords that have been changed. These files can be
    found at ftp://ftp.fastlane.net/pub/nomad/nw/nwl.zip, details in the
    FAQ.

    3) I would delete all zero length personal login files (see the FAQ for
    why).

    4) Any logins (such as the one possibly used by an SMTP gateway) which
    would be normally restricted would be toggled with SUPER.EXE. GUEST
    would be toggled.

    5) Message files (such as the ones used in displaying error messages)
    would be hacked so that security violations would display harmless
    messages.

    >        4. "secure" all PC's (see below)

    I would install keystroke grabbers on a number of machines, like those
    found at ftp://onyx.infonexus.com/pub/ToolsOfTheTrade/DOS/KeyLoggers/

    >        5. erect a firewall disabling IPX passage into the network
    >           but allowing TCP/IP (email services required).

    I would use some of these "very public" machines and install a sniffer,
    and I would use NetCat to redirect port 25 traffic to a particular
    address to a different machine's telnetd, bypassing the firewall.
    ftp://onyx.infonexus.com/pub/ToolsOfTheTrade/Unix/nc100.tgz for NetCat.

    With the sniffer it could be possible to get the RCONSOLE password.
    See ftp://ftp.fastlane.net/pub/nomad/nw/rcon*.zip for details.

    I would make sure that IP is on my server, and make sure XCONSOLE is
    running. Once past the firewall, I'd telnet to the server's IP
    address and run either X11 or VT100 remote console sessions with the
    server.

    >        6. notify the supervisor that he is fired, and take whatever
    >           actions are necessary to keep him from coming in physical
    >           contact with the network.

    If planned ahead, the supe will have his/her backdoors in place, and this
    will not matter. In fact, s/he will probably MAKE SURE that they do not
    even look at a machine.

    >There's a gotcha,  getting the supervisor password.  It would be
    >ideal to inadvertently get it, but thats a long shot.  The system
    >administrator will probably have to be asked for it at step 6, whether
    >he gives it to us is IMHO unlikely.

    The FAQ tells how you can recover from this easily.

    Remember, you've eliminated social engineering from your checklist. I'd
    attach a modem to a PC for PCanyWhere and then call up stating, "I'm the
    vendor your ex-employee hired to dial in and check blah-blah. If I were
    you I'd change my dial-in password." Once in (in the middle of the night)
    I'd activate a backdoor and proceed to make your competitor rich.

[ Return to TOC | Return to FAQ Page ]