COMMAND
remote.nlm
SYSTEMS AFFECTED
Netware 4.x
PROBLEM
Simple Nomad (NMRC) found following. Due to the fact that the
Remote Console password encryption scheme uses a weak "salting",
once the encrypted password is recovered from an NCF file an
intruder could decrypt the password. The testing was done with
the following configuration:
Netware 4.11
Service Pack 5
This was also confirmed on Netware 4.1. The password for remotely
accessing the Netware console is assigned as a parameter passed to
the REMOTE.NLM. Typically this would be stored in the AUTOEXEC.NCF
file as follows:
LOAD REMOTE NMRC
In the above example, the password is NMRC. Although the
AUTOEXEC.NCF file is stored in a protected directory by default,
there is concern that any administrator editing the AUTOEXEC.NCF
file via Remote Console might display the portion of the
AUTOEXEC.NCF file with the password (Remote Console sessions
travel over the wire in plaintext). To address this concern,
Novell allows for the creation of an encrypted password.
It is created by typing REMOTE ENCRYPT at the console (assuming
you've already loaded REMOTE.NLM). After being prompted for the
password to encrypt, it is encrypted and displayed on the screen,
and you are given the option to create a file called LDREMOTE.NCF
in the SYS:SYSTEM directory. LDREMOTE.NCF can be called from
AUTOEXEC.NCF or the LOAD REMOTE line in the AUTOEXEC.NCF file can
be altered as follows:
LOAD REMOTE NMRC
becomes:
LOAD REMOTE -E 0A1360A501608836FB
So far so good. You now no longer have a plaintext password, and
it is stored in a secure location. Let's assume the worst - a
potential intruder obtains the encrypted password by sniffing a
Remote Console session in which the file containing the encrypted
password is viewed by the administrator, or by using an exploit
(http://geek-girl.com/bugtraq/1997_2/0199.html is an older example
that could be adapted for this purpose, or perhaps using the
INTRUDER tool from Pandora, available from the NMRC web site).
Once the intruder has the encrypted password it can be decrypted,
due to the fact that there is no server-specific salt. The salt
is stored in the last two characters - in the above example the
salt is stored in FB (the actual salt is FF XORed with FB). The
salt is the seconds that have passed since some early date in the
past, and yields a possible 256 salts. Since these are tied to
time and not the server itself, the salt is non-system specific.
Decrypting the password does not require another check of the
time - the salt is simply read in and used during decryption.
A 4 character password called NMRC gets 5 bytes added and this
would become: 0A1360A501608836FB while a password of NMRC.ORG with
the 5 bytes added becomes: F9AEBF1C381855A5FFAA7FAD2D. This
implies a symmetric algorithm with those 5 bytes containing key
and salting data. A plaintext attack will be done at our leisure
(mainly for fun), but there is a much easier way to decrypt it.
To decrypt, the intruder must have console access to any Netware
4.x server, such as one of the 2 user CD versions you can get in
one of those CNE classes or for $15.00 U.S. (1-800-395-7135, ask
for the intraNetWare 2-user eval copy). Once at his/her own home
server, the intruder performs the following steps:
- The REMOTE.NLM is loaded with the -E option followed by the
captured encrypted password.
- Enter Netware's internal debugger by typing the following 4
keys together: left shift - right shift - alt - esc
- Type in .M and enter, which will list the NLMs loaded along
with their addresses.
- Hit enter until you find the REMOTE.NLM, and write down the
data address.
- Type in D dataaddress and enter.
- 40 bytes (give or take, depending on NLM version) from the
address you typed in will be the unencrypted password, which
is viewable as plain text in the ascii dump area on the
righthand side of the screen. Note that any lower case
letters will have been transferred to upper case, since
Netware converted all lower case to upper case during the
original password encryption.
SOLUTION
Do not use Remote Console. It doesn't encrypt its session anyway,
so all work you do remotely flies across your LAN in plaintext.
Novell recommends not using Remote Console on critical servers,
but we recommend not using it at all. If any server's console is
compromised, this can be leveraged to obtain a copy of NDS and
subsequent password hash retrieval for cracking.
Here are some things administrators can do to make things safer:
1. Restrict physical access to the server (the debugger can't
be started through RConsole), and the backups.
2. Use an RConsole password that is not the same as any
account password on the system. If a hacker figures out
the RConsole password, and the console is locked
(Monitor.NLM), here's what they can do: i. Press the F1
key for the help screen (allocates 4k of RAM to display the
screen, then frees it when the screen is gone). ii. Guess
the Admin password (if intruder lockout is enabled, then
this won't be very useful to the hacker, but Administrators
should have a separate account set up in NDS that can
unlock the Admin account, and for other security-related
reasons).
3. Add the "-L" parameter to the "Load Monitor.NLM" line in
SYS:System/AutoExec.NCF.
4. Always lock the console (Monitor.NLM) without specifying a
password before ending an RConsole session.