Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Flaw in Microsoft Windows SAM Processing Allows Continued Administrative Access Using Hidden Regular User Masquerading After Compromise (2010-M$-001)
From: Pavel Machek <pavel () ucw cz>
Date: Mon, 13 Dec 2010 08:15:41 +0100

Hi!

The reason I wrote this article was not to explain how to create a hidden 
user account.  I wrote the article to show you that you can modify the SAM 
in real time in a way that is undetectable by ANYONE.  This modification 
allows you to masquerade any user account as the built-in Administrator.

Christian,

"Continued Access" to a system means that someone has compromised a system 
and they have continued access.  This implies that the administrators don't 
know that they had been compromised.  And you think that auditing tools 
would see a hex value changed in the SAM, when even local administrators 
don't have read access to the SAM?

I don't see why 'continued access' is surprising. There's probably
1000 different ways to keep root access after you gained it
once. Yours is quite elegant, but... how is it different from common
rootkit?
                                                                Pavel


Thank you,
-----------------------------------------------------
StenoPlasma at ExploitDevelopment.com
www.ExploitDevelopment.com
-----------------------------------------------------

-------- Original Message --------
From: "Christian Sciberras" <uuf6429 () gmail com>
Sent: Thursday, December 02, 2010 2:51 PM
To: "Steno Plasma" <exploitdevelopmentdotcom () gmail com>
Subject: Re: Flaw in Microsoft Windows SAM Processing Allows Continued 
Administrative Access Using Hidden Regular User Masquerading After 
Compromise (2010-M$-001)

I don't understand how this is even relevant to security?

If a system was compromised, I'd have assumed it would be only logical 
to
investigate as to why and ultimately, what was changed.
Auditing tools would detect this in seconds, as well as a normal human
(unless we're talking about more than 10 user accounts on the same PC).

Either case, a compromised PC should be (at least) rolled back to before 
the
attack. Anyone keeping the system running without doing this
deserves getting hacked over and over.

I'd agree with MS (+any other similar scenarios). People should focus on 
not
getting hacked, not locking hackers out *after being hacked.*

My 2 cents,
Chris.





On Thu, Dec 2, 2010 at 6:59 PM, Steno Plasma <
exploitdevelopmentdotcom () gmail com> wrote:

----------------------------------------------------------
www.ExploitDevelopment.com 2010-M$-001
----------------------------------------------------------

TITLE:
Flaw in Microsoft Windows SAM Processing Allows Continued
Administrative Access Using Hidden Regular User Masquerading After
Compromise

SUMMARY AND IMPACT:
All versions of Microsoft Windows allow real-time modifications to the
Security Accounts Manager (SAM) that enable an attacker to create a
hidden administrative backdoor account for continued access once a
system has been compromised. Once an attacker has compromised a
Microsoft Windows computer system using any method, they can either
leave behind a regular user or hijack a known user account (Such as
ASPNET). This user account will now have all of the rights of the
built-in local administrator account from local or remote connections.
The user will also share the Administrator's desktop and profile. When
inspected by system administrators, the regular user always looks like
it is just part of the built-in user's group. The attacker can also
make the regular user account hard to detect by creating a user with
the username of "ALT-0160", for blank space. Events in the audit log
pertaining to the hidden account will be created if the system
administrator has enabled auditing, but the user name fields are all
blank. Once a system has been compromised, the attacker would need to
ensure the Task Scheduler service is enabled only when starting the
method. This method can be used to masquerade as any user account on
the computer system.

DETAILS:
Use the following steps to exploit this vulnerability.

Step 1: Attacker compromises the Windows computer using any available
method.
Step 2: Attacker creates a user account with a blank username using
'net user " " P () $$w0rd /add'. In between the double quotes, you can
use ALT+0160 to create the blankspace.
Step 3: Attacker creates an interactive scheduled task to run a minute
after creating it. This scheduled task brings up a command prompt as
the NT Authority\SYSTEM account on Windows 2000, XP, and 2003. 'at
11:24 /interactive cmd.exe'. If using Windows Vista, 7, or 2008
Server, the attacker must do all registry editing from the command
line using 'schtasks'.
Step 4: Once the SYSTEM command prompt comes up, open regedit from the
command line.
Step 5: Browse to 
'HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names'
Step 6: Click on the newly created user account's user name.
Step 7: Take note of the "Type" field for that user.
Step 8: In this example, the backdooruser's "Type" is 0x3f7 and the
built-in Administrator's is 0x01F4.
Step 9: Under 'HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users' click
on 000003F7.
Step 10: In the right pane, double click on the "F" key.
Step 11: Go to the 7th row of HEX values.
Step 12: Change the value from "F7 03" to "F4 01".
Step 13: Log off then log on using your new backdoor account.
Step 14: You will notice that you are now using the Administrator's
desktop and rights.
Step 15: When you run 'net localgroup Administrators' you will see
your backdoor account listed only when you log in as the backdooruser
to check for it. If any other user runs the same command they will
only see the regular user accounts.
Step 16: Delete any other temporary accounts you may have made during
the method.

VULNERABLE PRODUCTS:
All patch levels of Microsoft Windows 2000 Workstation, Windows 2000
Server, Windows 2003 Server, Windows XP, Windows Vista, Windows 7, and
Windows 2008 Server. (Windows Vista, Windows 7 and Windows 2008 Server
are harder to exploit because you cannot bring up an interactive
SYSTEM shell, but you can still dump the registry, edit the field,
then merge the registry back as SYSTEM to complete the method).

REFERENCES AND ADDITIONAL INFORMATION:
N/A

CREDITS:
StenoPlasma (at) ExploitDevelopment.com

TIMELINE:
Discovery: July 1, 2010
Vendor Notified: August 8, 2010
Vendor Dismissed: August 10, 2010 (MSRC says that there is nothing to
investigate because the action can only happen after a compromise.
This vulnerabilities deals with continued access without using DLL
injection or Rootkits)
Vendor Fixed: N/A
Vendor Notified of Disclosure: October 26, 2010
Disclosure to Bugtraq: December 2, 2010

VENDOR URL:
http://www.microsoft.com

ADVISORY URL:
http://www.ExploitDevelopment.com/Vulnerabilities/2010-M$-001.html

VENDOR ADVISORY URL:
N/A


Thank you,
-----------------------------------------------------
StenoPlasma at ExploitDevelopment.com
www.ExploitDevelopment.com
-----------------------------------------------------




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault