|
|
Passwords 02-1. How do I access the password file in Novell Netware? 02-2. How do I crack Novell Netware passwords? 02-3. What is a "brute force" password cracker? 02-4. What is a "dictionary" password cracker? 02-5. How do I use SETPWD.NLM? 02-6. What's the "debug" way to disable passwords? 02-7. Exactly how do passwords get encrypted? 02-8. What are the dangers of "storing" captured passwords?
02-1. How do I access the password file in Novell Netware?
Contrary to not-so-popular belief, access to the password file in Netware is not like Unix - the password file isn't in the open. All objects and their properties are kept in the bindery files on 2.x and 3.x, and kept in the NDS database in 4.x. An example of an object might be a printer, a group, an individual's account etc. An example of an object's properties might include an account's password or full user name, or a group's member list or full name. The bindery files attributes (or flags) in 2.x and 3.x are Hidden and System, and these files are located on the SYS: volume in the SYSTEM subdirectory. Their names are as follows:
Netware version File Names
--------------- ----------
2.x NET$BIND.SYS, NET$BVAL.SYS
3.x NET$OBJ.SYS, NET$PROP.SYS, NET$VAL.SYS
The NET$BVAL.SYS and NET$VAL.SYS are where the passwords are actually located in 2.x and 3.x respectively.
In Netware 4.x, the files are physically located in a different location than on the SYS: volume. However, by using the RCONSOLE utility and using the Scan Directory option, you can see the files in SYS:_NETWARE:
File What it is
-------------- --------------------------
VALUE.NDS Part of NDS
BLOCK.NDS Part of NDS
ENTRY.NDS Part of NDS
PARTITIO.NDS Type of NDS partition (replica, master, etc.)
MLS.000 License
VALLINCEN.DAT License validation
Here is another way to view these files, and potentially edit them. After installing NW4 on a NW3 volume, reboot the server with a 3.x SERVER.EXE. On volume SYS will be the _NETWARE directory. SYS:_NETWARE is hidden better on 4.1 than 4.0x, but in 4.1 you can still see the files by scanning directory entry numbers using NCP calls (you need the APIs for this) using function 0x17 subfunction 0xF3.
02-2. How do I crack Novell Netware passwords?
There are a few ways to approach this. First, we'll assume Intruder Detection is turned off. We'll also assume unencrypted passwords are allowed. Hopefully you won't have to deal with packet signature (see 07-11) Then we'll assume you have access to the console. Finally we'll assume you can plant some kind of password catcher. Access to a sniffer might help. These are a lot of ifs.
If Intruder Detection is off, you can use a "brute force" password cracker. See section 02-4 for details.
Encrypted passwords is Novell's way of protecting passwords from sniffers. Since older versions of Netware (2.15c) sent passwords as plain text over the wire, a sniffer could see the password as it went by. To secure things, Novell gave the administrator a way to control this. Later versions of the LOGIN.EXE program would encrypt the password before transmitting it across the wire to the server. But before this could happen, the shell (NETX) had to be updated. Since some locations had to have older shells and older versions of LOGIN.EXE to support older equipment, the administrator has the option of allowing unencrypted passwords to access the server. This is done by typing SET ALLOW UNENCRYPTED PASSWORDS=ON at the console or by adding it to the AUTOEXEC.NCF. The default is OFF, which means NOVELBFH could be beeping the server console every attempt! Fortunately most sites turn this switch on to support some old device.
If you have access to the console, either by standing in front of it or by RCONSOLE, you can use SETSPASS.NLM, SETSPWD.NLM or SETPWD.NLM to reset passwords. Just load the NLM and pass it command line parameters:
NLM Account(s) reset Netware version(s) supported
------------ ----------------- ----------------------------
SETSPASS.NLM SUPERVISOR 3.x
SETSPWD.NLM SUPERVISOR 3.x, 4.x
SETPWD.NLM any valid account 3.x, 4.x
See 02-5 for more SETPWD.NLM info.
If you can plant a password catcher or keystroke reader, you can get them this way. The LOGIN.EXE file is located in the SYS:LOGIN directory, and normally you will not have access to put a file in that directory. The best place to put a keystroke capture program is in the workstation's path, with the ATTRIB set as hidden. The advantage is that you'll get the password and Netware won't know you swiped it. The disadvantage is getting access to the machine to do this. The very best place to put one of these capture programs is on a common machine, like a pcAnywhere box, which is used for remote access. Many locations will allow pcAnywhere access to a machine with virtually no software on it, and control security access to the LAN by using Netware's security features. Uploading a keystroke capture program to a machine like this defeats this.
If the system is being backed up via a workstation, this can be used as a good entry point. These workstations have to have supe equiv to back up the bindery and other system files. If you can access this workstation or use the backup systems user account name then you can get supe level login.
itsme, the notorious Netherlands Netware hacker, developed KNOCK.EXE by rewriting one byte of ATTACH.EXE to try without a password to get into a server. KNOCK.EXE utilitzes a bug that allows a non-password attach to get in. This works on versions of Netware earlier than 2.2, and 3.11. Later versions have the bug fixed. Given enough time you will get in.
Another alternative is the replacement LOGIN.EXE by itsme. This jewel, coupled with PROP.EXE, will create a separate property in the bindery on a 2.x or 3.x server that contains the passwords. Here is the steps to use these powerful tools:
- Gain access to a workstation logged in as Supervisor or equivalent (or use another technique described elsewhere for getting this type of access)
- Run the PROP.EXE file with a -C option. This creates the new property for each bindery object. Remember, you must be a Supe for this step.
- Replace the LOGIN.EXE in the SYS:LOGIN directory with itsme's. Be sure to flag it SRO once replaced.
- Now it is set. Keep PROP.EXE on a floppy, and check the server with any valid login, Supervisor or not, after a week or two.
- To check the passwords captured, type PROP -R after your logged in. You can redirect it to a file or printer. A list of accounts and passwords, valid and working, are yours.
- Don't forget to hide your presence! See section 05-3 for details.
02-3. What is a "brute force" password cracker?
If Intruder Detection is off, you can just guess the password until you get it. This can be automated by using a program that continually guesses passwords, known as a "brute force" password cracker. One program that does this is NOVELBFH.EXE (for version 3.x only). This program will try passwords like aa, ab, ac and so on until every legal character combination has been tried. You will eventually get the password. However this assumes you have 1) a lot of time since it takes a second or two for each try (more on a dial-up link), and 2) access to a machine that will run one of these programs for hours, even days. And if Intruder Detection is on you will be beeping the System Console every couple of seconds and time-stamping your node address to the File Server Error Log.
For brute-force attacking old bindery files, there is a program called CRACK. This program works on Netware 3.x and can be found at
http://www.mechnet.liv.ac.uk/~roy/freeware.html
I have not tried this program personally, but have heard of good results from others.
02-4. What is a "dictionary" password cracker?
For a password cracker that works against a single account and uses a dictionary wordlist, try NWPCRACK.EXE by Teiwaz. You must supply a dictionary wordlist (see the alt.2600/#hack FAQ for FTP sites with wordlists), and you are subject to the same limitations as NOVELBFH (no Intruder Detection, 3.x only) but it works great.
For a password cracker that works directly against either the .OLD bindery files left over after a BINDFIX or even a live bindery, look for BINDERY.ZIP. This ZIP by Al Grant contains BINDERY.EXE which will, among other things, extract user information out of bindery files into a Unix-style password text file. Then you can use BINCRACK.EXE from the same ZIP to "crack" the extracted text file. BINCRACK.EXE, like NWPCRACK.EXE, requires a word list. BINCRACK.EXE is extremely fast.
One interesting thing, the BINDERY.ZIP file also contains versions of BINCRACK for Solaris 1 and Solaris 2, so you can copy that extracted user info to a Sparc and do lightning-quick cracks.
For checking existing passwords for guessability, see section 07-9.
02-5. How do I use SETPWD.NLM?
You can load SETPWD at the console or via RCONSOLE. If you use RCONSOLE, use the Transfer Files To Server option and put the file in SYS:SYSTEM.
For 3.x: LOAD [path if not in SYS:SYSTEM]SETPWD [username] [newpassword]
For 4.x: set bindery context = [context, e.g. hack.corp.us] LOAD [path if not in SYS:SYSTEM]SETPWD [username] [newpassword]
In 4.x the change is replicated so you have access to all the other servers in the tree. And don't forget, you must follow the password requirements in SYSCON for this to work. That is, if the account you are changing normally requires a 6 character password, then you'll need to supply a 6 character password.
02-6. What's the "debug" way to disable passwords?
You must be at the console to do this:
/left-shift//right-shift//alt//esc/ Enters Debugger type "d VerifyPassword 6" Write down 6 byte response for later use type "c Verifypassword=B8 0 0 0 0 C3" Sets system to turn off pword checks type "g" To make the system change and drop you back into the console
to turn password checking back on...
/left-shift//right-shift//alt//esc/ Enters Debugger type "c VerifyPassword= xx xx xx xx xx xx" Where xx's are the previous recorded numbers that where written down. type "g" To make system changes and drop you back to into the consoleTeiwaz updated these steps to make things easier and workable. And one other note -- this will NOT disable password checking in 4.x. Sorry....
02-7. Exactly how do passwords get encrypted?The algorithm for 3.x and 4.x is, according to some sources, the same. It is a proprietary algorithm that is supposed to be one-way.
The following is a description of the source code located at the dutiws.twi.tudelft.nl site in the /pub/novell directory. The code was posted by Fauzan Mirza on sci.crypt for discussion, and produced the following bit-by-bit description in comp.os.netware.security by David Wagner (I've removed most of the flame comments):
encryptp(int id[4], char password[]) char buffer[32]; concatenate password[] to itself until its at least 32 bytes long put the result in buffer[] concatenate id[] to itself until its at least 32 bytes long xor the result into buffer[] return encrypt(buffer[]) encrypt(char buf[32]) nibble output[32]; /* a nibble = 4 bits = half a byte */ apply some complicated (but easily reversible!) function to buf[] for (i=0; i<32; i++) output[i] = S-box[buf[i]]; return output[] /* a 16 byte return value */ where the S-box[] crunches 8 bit values down to 4 bit values. So here's how to invert the password hash function, given the 16 byte hash output[] value: for (i=0; i<32; i++) pick any x such that S-box[x] == output[i] /* this is easy */ buf[i] = x apply the reverse of the complicated function to buf[] concatenate id[] to itself..., and xor the result into buf[] use the resulting 32 byte buf[] as the inverse password Of course, there are several nitpicking details which I've left out: if you're actually writing the inversion program, you have to make sure to take care of the details, but they only make the programming more complicated, they don't make the inversion process any slower once the program is written. Also, there is the fact that the inverse password will include full 8-bit values, not just ASCII alphanumerics. Once could try to be a bit more sophisticated to ensure you get an inverse which is alphanumeric. I haven't bothered to think about this case too much -- it doesn't seem to be worth the neurotransmitters. The reason you don't get the "true" "original" password is because when you pick 'x' above, you can't know which 'x' was the "true" "original" value, since the S-boxes throw away information.
02-8. What are the dangers of "storing" captured passwords?There are several, I'm sure you can think of more.
- If the admin finds them online, they will obviously know something is up especially if it's under your account.
- If another user on the system realizes what you're doing, they could possibly exploit other user's accounts (in an unsave manner) and tip off the admin that something is up.
- With something like itsme's LOGIN/PROP utility, there's the chance that YOUR password will get stored in the file, thus allowing anyone who realizes what's up to use your account with virutally no effort on their part. This is especially dangerous when the admin is playing around with LOGIN/PROP because they want to see "how it works".
- Another user might realize what's up, and may be able to provide enough evidence to prove that it's you doing it. Had some other user previously found the file, and exploited accounts (and caused damage), you would likely be blamed for it.Therefore it is recommended that passwords are encrypted, preferably using something halfway secure (XOR is not encryption).