Ok...this one is a little better than the last one...technically speaking
but not very much of a threat if you think about it. While technically
sound (and full of neat tricks to get information which might otherwise be
gotten easier through other methods), it still doesn't mean much of a
threat.
First of all (once again) you'd be hard pressed to find a router which will
allow SPX through. Even if the RCONSOLE session was over TCP/IP, you would
have to be running NetWare/IP in order to connect via Telnet (I
know...NetWare 5 is pure IP...save that for when everyone upgrades).
Second, even if you could capture the RCONSOLE password from a trace, you
would still have to go through the business of tracing through the "test"
server to find the unencrypted form of the password.
Third, if you finally got access to the server from RCONSOLE (assuming
you're using this to dig up the NDS tree), you would have to transfer all of
the *.NDS files from the SYS: volume of the server. This is not possible
with RCONSOLE and you can't get at those files any other way (the OS
prevents access to that directory).
Fourth, you wouldn't be able to create a new NDS tree with the files from
another server without calling NDS support at Novell and having them do a
DSDUMP. They would have to select the files you want to put back in as your
database and then do a bunch of db pruning/cleanup in order to make the
database workable. Probably more money than your average hacker is willing
to pay.
Of course, the more sophisticated person could write an NLM which would
delve into the database and dump stuff out for you. You could install this
from an RCONSOLE session (ie transfer the NLM somewhere on the server then
load it). But then again, NLMs aren't that easy to write and a snooper
would definitely draw attention to himself if he ABENDs a server remotely.
My solution? If you must do RCONSOLE, run PPTP (Novell not MS) This way,
outside prying eyes can't see the RCONSOLE session. Oh...going through a
firewall would help too. BTW -- Novell's PPTP actually works; the MS
implementation is typical - misinterpret the spec, implement it halfway (and
poorly) thus leaving it full of holes.
The ultimate solution, if you have a really sensitive server, is to not load
RCONSOLE and do SECURE CONSOLE.
I'm still waiting for BackOrifice for NetWare...
[VENT MODE ON]
Why are people constantly trying to fabricate holes in NetWare? Is it so
others think that NetWare has just as many security holes as other OS's?
Pound-for-pound, NetWare is more secure than other OS's I've seen bandied
about on BUGTRAQ. If you find a bug/hole, fine but let's not try to make
one up, ok?
[VENT MODE OFF]
-- dcc --
-----Original Message-----
From: Simple Nomad [SMTP:thegnomeat_private]
Sent: Tuesday, October 06, 1998 3:36 AM
To: BUGTRAQat_private
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 [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:54 PDT