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.
Randy Richardson - randy@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com/
"We are NDS. Resistance is Futile. You will be Authenticated."
> 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 [thegnomeat_private]
> 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.
>
> _______________________________________________________________________________
>
>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:18:51 PDT