rconsole.passwd.netware.txt

`Date: Tue, 6 Oct 1998 02:36:11 -0500  
From: Simple Nomad <[email protected]>  
To: [email protected]  
Subject: NMRC Advisory - "Decryption" of the RCONSOLE Password  
  
Jeez I swear we'd be this productive all the time of fully funded. Anyway  
this makes up for the last one's lameness. -SN  
  
_______________________________________________________________________________  
  
Nomad Mobile Research Centre  
A D V I S O R Y  
www.nmrc.org  
Simple Nomad [[email protected]]  
06Oct1998  
_______________________________________________________________________________  
  
Platform : Netware 4.x  
Application : REMOTE.NLM  
Severity : Medium  
  
  
Synopsis  
--------  
  
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.  
  
Tested configuration  
--------------------  
  
The testing was done with the following configuration :  
  
Netware 4.11  
Service Pack 5  
  
Also confirmed on Netware 4.1  
  
Bug(s) report  
-------------  
  
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/Workaround  
-------------------  
  
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.  
  
Comments  
--------  
  
Novell has been notified, unsure how they plan to handle this. Personally  
we recommend not decrypting in RAM, but then the intruder simply uses an  
older unpatched version of REMOTE.NLM. Obviously using NDS to store the  
password would be prime location, and since Novell makes such a big deal  
out of the security of NDS one would think they'd use it to safeguard the  
password. Using a protocol scheme similiar to normal login authentication  
would also be desired.  
  
This was discovered after hearing a rumor that it could be done. We'd  
reveal the rumor source but he's a respectable Fortune 500 type who has  
requested anonymity. Besides, a lot of people have asked NMRC for this, so  
here it is. For fun, decode this one:  
  
7AB18DEFEFACF8EF58308102100210001698  
  
It should be noted you can also recover the "Lock file server console"  
password from the MONITOR.NLM roughly the same way -- it is stored  
decrypted in RAM, but in an allocated block of RAM somewhere before the  
last lowest NLM data segment. Hint: use the debugger's searching features  
on a "test" server to learn approximately where.  
  
_______________________________________________________________________________  
`