X-RDate: Thu, 12 Feb 1998 18:23:33 +0500 (ESK)
Date: Mon, 9 Feb 1998 01:32:25 -0500
From: [email protected]
To: [email protected]Subject: How one small flaw could lead to major problems
Greetings,
First off I would like to appologize to aleph1. It would appear that an
original draft of this got sent direct, before I had completed my
thoughts on it. I will try and be more carefull when wielding a loaded
mouse. (hope no one got hurt)
And now for the stuff ...
While perusing the rootshell.com site, I came accross the file
"sharepw.c" under January's archive group. The program demonstrates the
ability to decode the Windows95 "share-level" password. Curious, I
downloaded the file and began to examine it. The file itself weighs in
at 883 lines in length, though largely commented. The code contains
what are termed "pairs", "quads", "blocks", and "tables" that are used
to decipher the password 'inline'.
Upon further examination, (by mere chance actually), I noticed an
alarming similarity developing between the coded and decoded passwords.
Someone please correct me if I am wrong, but it would seem that the
"share-level" password is nothing more than an Simple-XOR cipher. With
this being the case, the 883 line program gets reduced the the few line
you see below.
u_char key[] = { 0x35, 0x9a, 0x4d, 0xa6, 0x53, 0xa9, 0xd4, 0x6a, };
void CrackSharePW(u_char *PW, u_long Size) {
PW[Size] = '\0';
while(Size--)
PW[Size] ^= key[Size];
}
The passwords can be found in the registry at:
SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan\<filename>
Parm1enc - for "Full Access Password"
Parm2enc - for "Read Only Access Password"
Feed the encrypted bytes and the number of bytes (the password length)
into the function, and it will decode it inline. I have tested this
with several password combinations with success for each of them, but
would appreciate knowing if I have made an error in the coding.
I should also point out a couple of notes.
(1) The "key" bytes used, aren't eight individual bytes, but rather the
"byte-order?" of the first four is reversed to get the second four.
(ie: 0xA9 becomes 0x9A)
(2) Though "share-level" access is largely not recomended, I have to
imagine that somebody is using it, furthur more it would then be
possible to assume that some of these users may be using the same
passwords as "Internet accounts", "Shell accounts", "ATM accounts", and
who knows what else.
(3) It is possible to write a program to obtain all "share-level"
passwords from a machine rather easily by running through the registry.
I'm not posting that portion of the program so that the "script-kiddies"
would have to do some work for a change.
(I'm not insulting anyone, the code is just too easy ...)
<RANT>
While I am not trying to refute the abilities of the original author,
this should serve to point out how one small defect in thinking can
cause major problems elswhere. Imagine the fortune 500 company with a
vast cross-platform network. Tucked away in a remote section of
offices, we find a group of machines set with "share-level" access used
between them. We run our program, extracting a list of passwords from
these machines. One, or more, of these passwords are the same as a
"Shell account" on the corporate mainframe. Badda-Bing Badda-Boom,
we're in ... run a few exploits ... yadda yadda yadda ... and root has
been compromised. All of this due to the fact that someone in a remote
office said "We never do anything special, why should I care?" and
someone in administration didn't catch it in time.
I know from personal experience that one administrator can know all the
exploits, bugs, fixes, hacks, cracks, patches, and quirks but unless
they receive cooperation from other administrative personell and the
general user population the system might as well not have any security
at all.
Security, IMHO, begins with the education of the administrator, procedes
through the implementation onto a system, and ends with the education of
the user. Thus, education is the key.
How many times do we run off to find the latest bug or exploit, only to
never take the time and explain to a user why they shouldn't hang a
"dial-in capable" modem off their machine, or why they should choose
"good" passwords, or better yet, why they must use passwords in the
first place. Garfinkle & Spafford "Unix & Internet Security" call it
security through obscurity, and go on to state that it doesn't work for
very long.
How many times do we try to explain to our superiors and our users about
the importance of security and administration, only to be returned with
remarks like "So what if they get in?", "Nobody here but you knows any
of this, why should we care?", or "We don't do anything special here,
what could possibly happen?" To deem something not a risk is one thing,
but to not care is quite another.
Now for the real trick ... how does one educate a group of
administrators and/or users that don't show an interest in what we would
term security, without appearing overly anal about the whole thing?
This is bugtraq you say? Where's the bug?
I percieve the bug as being:
* In the thinking of those who create systems with inherent flaws in
them (doing my best not to "MS bash").
* In the thinking of those who implement these systems in situations
where larger systems are at risk because of them.
* In the thinking of those who whould say, "But I don't do anything that
important, why should I secure my computer?"
* Also in the thinking of those who would say, "(joe worker), you're the
only one here who knows this kind of stuff ... what are we worried for?"
But on a positive note, if it weren't for these kinds of bugs, we
wouldn't have BUGTRAQ.
</RANT>
I appoligize if anyone feels that I have wasted their time with this,
but sometimes the oldest bugs never get fixed.
a 'frustrated' [a42n8k9]
