COMMAND
kernel
SYSTEMS AFFECTED
WinNT
PROBLEM
'No Strezzz Cazzz' found following. Neil Kirr found this bug 2
years ago! Reason that we make this posting is because we have
more/additional information. Neil only mentioned one password,
'NSC' found two. He used Outlook98, he uses Outlook Express 4.72
on NT4. Also in a reply from the MS Outlook Program Manager to
the NTBugtraq mailinglist it is said that "User.dmp is the file
written out when NT blue-screens". This is not true, at least not
in this case, it is obviously created because of an error
somewhere.
'NSC' found out about it while using the [find "POP3PASS" *]
command while on the \WINNT\system32 directory:
---------- USER.DMP
POP3PASS
We thought this was really weird, first of all because NT4
stored POP3-password in plain ASCII. And second because we
never noticed the USER.DMP file in the \WINNT\system32 before. So
open the file and retrieve your POP3-password by
Search/Find/POP3PASS (d0h). It showed up in the following lines:
y-\ POP3PASS \
":." O?u-~A"" O? D e M o N 7 1 1 6 C D C
This is important to know, because it was close to "D e M o N"
(we named provider DeMoN but in USER.DMP it was printed with a
space between each letter) so we could use that as an indicator
in case we don't know the password. By the way, if you open
USER.DMP it might take a little while before you actually see its
content when you open it. Task Manager will tell you that its
"not responding" but it is, just be a little patient.
'NSC' noticed that not only the complete contents of his OE
(E-mail, usenet and settings) where stored throughout the file,
it also contained the contents of his IE "Favourites" folder, his
complete "History" folder and a shitload of other data, most of
it useless. But it has a phonky effect when you scroll it down
quickly, so that makes up for being useless.
In USER.DMP You can find both your POP3 and dial-up password where
located within the first upper 10% of the file. So now we know
that if we don't know any of those passwords we can probably find
them close to the account where our POP3 is located, and close to
our account name. Be sure you read the file from up to down, not
from left to right, use "Word Wrap" if needed. We can confirm
that in all four USER.DMP's we have had so far the passwords are
close to the account or the account name.
USER.DMP is created by the infamous Dr. Watson program. It's a
dump of the process space of whatever the last program that
crashed was. Basically the same concept as core files on *nix.
If you have windbg installed you can load a user.dmp file and go
to the assembly view to figure out where if crashed (somewhat
more useful if you actually wrote the program and have the source
files/symbol tables handy).
Unfortunately NT4 doesn't control access to this file very well.
Then again NT4 doesn't control access to a lot of sensitive files
by default (Everyone/Full Control on C:\ for example). Windows
2000, while a bit more sane with security in genereal, flunks the
test here. The default location of user.dmp on Win2k is
C:\Documents and Settings\All Users\Documents\DrWatson\user.dmp.
This means that if you are not an administrator of the machine,
user.dmp never gets created (only admins have write access to All
Users). However, if you are, it gets put there with Everyone/Full
Control... sigh...
The reason that the account name and/or password have "spaces"
between the letters is because they are likely stored in memory
as Unicode strings. So those aren't actually spaces, they're
ASCII null characters; and there's no way to search for that in
notepad. Sysinternals (www.sysinternals.com) has a "strings"
utility that can dump both ASCII and Unicode strings out of
binary files.
The problem arises in that NT's default location for user.dmp is
world-readable. On NT4 systems, the default location is
%SystemRoot%\user.dmp, which will usually end up being
C:\WINNT\user.dmp. Default permissions on NT4 systems give
Everyone Full Control on the WINNT directory. Crash dump files
can often contain passwords and other sensitive information that
was stored in memory and never intended to be written to disk in
plain text. One example of this is the mail and news reader
Outlook Express, which stores the user's mail account passwords
in plain text (Unicode strings) in memory. OE also happens to be
crash-prone when it encounters ill-formatted messages.
Description of exploit:
1. Users Jim and Bob share the same NT workstation; both use OE to
check mail
2. OE stores its saved mail and account information in the user's
profile directory, which by default is set with permissions so
that only the user it belongs to can access it. Hence, Jim
cannot access Bob's mail directly because the OS won't let him
into Bob's profile directory.
3. Bob is using OE and it crashes, either accidentally or caused
by a message sent by someone designed to cause the crash; such
as a buffer overflow / invalud HTML / scripting / ActiveX
attack.
4. Jim can then open the user.dmp (world-readable) and sift
through it to get Bob's password. A good utility for this is
the Sysinternals (www.sysinternals.com) utility strings, which
can extract a list of Unicode strings out of a binary file.
Windows 2000 is also vulnerable, but in fewer circumstances.
It's default location for user.dmp is C:\Documents and
Settings\All Users\Documents\DrWatson\user.dmp. This location is
world-readable by default, but not world-writable. Normal users
will not have the user.dmp file created as they do not have write
access, however users that are an administrator (possibly power
users as well) of the local machine will be exposed to this
vulnerability.
SOLUTION
Run drwtsn32.exe to set crash dump options. There are two ways
to get around this problem (per-user):
1) Uncheck the "create crash dump file" checkbox.
2) Change the crash dump location to a directory that only you
have access to.
For a system-wide fix, delete the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
This will cause Dr. Watson to be replaced with a simple
"Application Error" box.
If you have installed MSVC it will automatically make itself the
system debugger, and it does not create crash dump files so you
are not vulnerable.
MS needs to fix Dr. Watson so that it sets permissions correctly
on the files it creates. A quick fix for the problem would be to
make Dr. Watson's default crash dump location be somewhere inside
the current user's profile. This of course will only work on
NTFS file systems, but if you are using FAT or FAT32 for your
filesystem there are much worse things that unprivileged users
can do...