This post is off-topic, but given the scope of attention that has
surrounded this issue its probably worth Firewalls people being at least
aware of it.
Anyone interested in this story can find a lot of information at my
NTBugTraq web site (http://ntbugtraq.rc.on.ca/index.html). There you
will find responses I have published wrt the EE Times articles, as well
as links to those articles and Microsoft's responses as well
(Microsoft's responses link back to my responses if you'd rather go that
route).
>Anyone familiar with NT SIDS? Apparently it has been cracked and the
>implication of doing so spells another "service-pack" from Microsoft.
Yes, I am familiar with NT SIDS, unfortunately they don't really have
anything to do with the cracking that's being going on. A SID is simply
a Security Identifier. As to them (or something) being cracked, the
brief version is this;
NT passwords are stored in the NT Registry as representations of the
plain-text password. They're first OWF hashed using RSA MD4 hashing
function, then obscured (obfuscated) using DES. The first step can't be
reversed (generally accepted), but the second step can. The algorithm to
do this has been published as part of a really useful SAMBA utility to
allow SAMBA systems to create a user database from an NT user accounts
database (Security Access Manager dB or SAM). The value retrieved after
running this utility is what is referred to as "Plain-Text Equivalent"
in that it can be used to construct a challenge/response if other
information is also known.
It would therefore be conceivable, SHOULD ADMIN ACCESS BE ACHIEVED TO
THE REGISTRY, to extract a password hash and turn it into something that
could be used to access a network resource as some user. If cracked
using a password dictionary (or brute force tool like l0phtcrack for
NT), a plain-text password could be yielded and used to log on at a
console.
The point is that you must first gain access to either the registry
itself (in which case you need to be either the Administrator, a member
of the Administrators Group, or the Backup Operator), or to a backed up
copy of the SAM hive of the registry (either through the
%systemroot%\repair directory or by physical access to an Emergency
Repair Diskette). Mis-configuring the system could make this access
available.
>I was given a demonstration on how to change the system registery.
It's
>actually fairly easy and bypasses all the protection Microsoft setup.
I'll
The access you refer to needs to be done as Administrator, which doesn't
really bypass all the protection Microsoft set up. Starting the Schedule
service requires Administrator access, which could then be used to start
up the Registry Editor (REGEDT32) as user SYSTEM. User SYSTEM has
complete privilege to the entire registry, hence the protections are not
bypassed, you are seeing what that user is permitted to see. The user
SYSTEM cannot log into a machine, and this methodology cannot be used
via a network connection, so it means that physical console presence is
a pre-requisite. Its also only useful if this is all done on a Domain
Controller.
So if you can get Administrator privilege at the console of a Domain
Controller, it would be possible to exploit it. It shouldn't take a
rocket scientist to figure this out, as well as the ways to prevent such
a set of circumstances from occurring unintentionally.
The passwords are also stored in DES encrypted format for LanMan
compatibility. This version is generally weak and would likely be the
target of any cracking attempts (but this isn't what was discussed in
the article).
CIAC Bulletin H45 discusses this issue, together with some suggestions.
See my archives at http://ntbugtraq.rc.on.ca/index.html under the CIAC
bulletin message title for some additional comments on their bulletin.
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security
owner of the NTBugTraq mailing list:
http://ntbugtraq.rc.on.ca/index.html
|
|
