Dear Media Matt...
>It's quite capable of breaking individual passwords on a 386,
>when most people choose passwords 7 characters or less, which cuts the
>time in half. The fact that the passwords are unsalted in the hash
>is what makes the processor requirements so low.
It takes over 6 days on a PP200 to get to 7 characters, so you do the
math and tell me how long that would take on a 386. I've got specs that
have pegged it at ~77k crypts/second on a P133. Heck, I could probably
drive the space shuttle off of an atari, but...
>I never said there were no cracking programs for unix. But does NT
>shadowing passwords, for example? Unix has the support of a public
>awareness, and a community effort to keep it viable. NT has one large
>company, and a lot of detractors.
What is the community effort to keep Solaris viable. What's the name of
the freeware version of HP-UX? Did IBM start giving away AIX? Tribbles I
say, go get yourself a tribble.
Editor's note, here comes the stuff spoon fed from magazines directly
into Media Matt's brain, like something out of "a clockwork
>As for getting the password hashes, the "only the Administrator"
>statement was made by Mike Nash, Microsoft's Director of Marketing for
>the Windows NT server.
Well, yes, Mike did say that MM. But guess what, I said it too, and you
can see it on the same page you saw Mike's statement (assuming you took
it from the source at http://www.microsoft.com/security). But chances
are you've only read the articles from EE Times, or even worse, some
other poor slob of a journalist's interpretation of Larry Lange's
interpretation of Yobie Benjamin's interpretation of "some hackers"
Why not come on down to Russ' used boats and Anti-EE Times articles
emporium, at http://ntbugtraq.rc.on.ca/, I guarantee I'll beat the pants
off of any journalist who doesn't do their homework. Just because it was
a marketing guy that said it doesn't *always* make it untrue. So far,
and to the best of my knowledge and ability, it is impossible to get the
hashes from a default out-of-the-box installation of Windows NT 4.0
without having to be either the Administrator, a member of the
Administrator's group, or a Backup Operator. I defy anyone to prove that
statement untrue today (Mudge, if you're reading this could you please
hold your announcement off until at least tomorrow...;-])
>The passwords are held in the NT database
> -- and I don't think, with all the bugs around, that you want to bet
it can't be
Sure, I'll bet you can't tell me a way to access it MM.
>There is a world-readable by default copy in
>\WINNT\SYSTEM32\CONFIG\SAM, used by system components, but the
>potential exists to exploit conditions to access it to obtain the user
Too bad this isn't completely true, or you might have had a point. That
directory, while granting READ access to the group "Everyone", is only
available to a console operator (i.e. someone sitting in front of the
box) or an Admin via the network, by default. The files in it are only
put there if a process has been run to update the Emergency Repair
Diskette (note Update, not Create), which can also only be run by an
Admin. The files there are not used by any "system components" and can
safely be deleted after they have been backed up.
So the risk exists for systems where multiple people access the same
machine via the console (Citrix included), and that machine is a Domain
Controller, and an Admin has updated the Emergency Repair diskette and
not deleted the archive files made by that program.
>Back to network sniffing, for that matter, you can obtain the hash
>via sniffing because NT often uses authentication where a client sents
>-hashed- password to the server, rather than the plaintext. The Server
NT to NT authentication never sends plaintext, it sends a
>knows the hashed password, matches it, and authenticates, rather than
>receiving the plaintext and calculating it. So it's even unnecessary to
>perform a dictionary attack to abuse a hash, since you just modify a
>to send the hash.
As long as NT allowed downgrading of the authentication protocol, it has
been possible to modify a Samba client to request an NT box to downgrade
to plain text for SMB authentication. Nothing new here, but it hardly
has any bearing on an NT machine being used as a Firewall. This has been
fixed in SP3 already in beta to be released within days.
EVERY SYSTEM which relies entirely on a reusable password is at risk
this way. You can augment NT with other authentication mechanisms like
SecurID, etc... or encrypt the channel the communications go over.
Clearly Kerberos would be better, but its not fail-proof either.
>This depends, I think, on the modifications made to NT by the Vendor.
>Again, unix's vulnerabilities are often well known and can be patched.
>NT's are voodoo for many people. Look at the "experts" -- 90% of
>certified NT people will not know the first thing about NT security.
Aye Captain, I'll get you some more tribbles. Your babble is bubbling
and you seem to be frothing at the mouth. I thought only Todd did
>The bottom line is that NT, and its security, is in its infancy, and
>Unix is not.
What, pray tell, does this have to do with a COTS Firewall? Often you
will only have a list of the things that the vendor has done to the
underlying OS (and in some cases, not even that). How does anyone know
if that's all that needs to be done? If we all know so much about Unix
security issues, then why are there still several messages every day to
the BugTraq mailing list, and announcements every month from vendors
through CERT/CIAC/whatever telling us about something new they've
You take all the best aspects of 30 different operating systems, put
them together, and then compare them against one. The question wasn't
whether Unix is better, but whether NT is secure enough to be used as a
platform for a Firewall (and I presumed at COTS Firewall). We all live
in glass houses, so instead of throwing stones maybe its better to just
answer the questions with some insightful commentary and knowledge,
rather than repuking someone else's less than completely thought out
R.C. Consulting, Inc. - NT/Internet Security
owner of the NTBugTraq mailing list: