lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6CE64522B84947358F702BC8B8AEA33F@celsius>
Date: Thu, 19 Sep 2013 16:14:04 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <full-disclosure@...ts.grok.org.uk>
Cc: bugtraq@...urityfocus.com
Subject: Re: %windir%\temp\sso\ssoexec.dll (or:
	howtrustworthy is Microsoft's build process)

This is a followup to <http://seclists.org/fulldisclosure/2012/Mar/17>
and <http://seclists.org/fulldisclosure/2013/Aug/225>:

On Sunday, March 04, 2012 9:06 PM I wrote:

> Hi @ll,
> 
> the system image "\Setup\WIM\setup.wim" on the "POSReady 2009 eval CD",
> available from the Microsoft Download Center under
> <http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1e077ece-3f19-4c41-b219-6fcc821fb5fc>,
> contains the following registry entries:
> 
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\SSOExec]
> "Asynchronous"=dword:00000001
> "Impersonate"=dword:00000001
> "Logoff"="SSOReset"
> "Unlock"="SSOExec"
> "Lock"="SSOReset"
> "DLLName"="%windir%\\temp\\sso\\ssoexec.dll"

[...]

> To complete the picture: the ACLs on the directory "%windir%\temp" in
> systems installed from this image/CD allow unprivileged users to create
> a subdirectory "sso" in "%windir%\temp" and then the "ssoexec.dll",
> allowing them to have their code run under every (other) user account
> used to log on afterwards, resulting in a privilege escalation.

After I learned that the same vulnerability exists in EVERY installation
of Windows Embedded POSReady 2009 I contacted a vendor and Microsoft
again.

The vendor got the following reply from Microsoft:

| The Microsoft Windows Embedded Product team, along with the MSRC 
| (Microsoft Security Response Center) team researched this in early
| 2012 and determined that this is a not a vulnerability because 
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Microsoft Malware Protection Center does not consider this to be 
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| malware.
  ~~~~~~~~

OUCH! How absurd!

| It was determined that these keys came from XP Embedded and 
| the Standard Windows Logon Component. They found no evidence of 
| malware on our build systems and the presence of the keys is not
| an indication that malware was ever present on the systems

There is no file "ssoexec.dll" in Windows Embedded POSReady 2009!
As far as I know there is no file by this name in ANY version/variant
of Windows!

I requested clarification about these absurd statements and whether
a hotfix will be provided from the MSRC <secure@...rosoft.com> and
got the following answer:

| Could you explain how the EOP attack works using this DLL?
| Normal users don't have write permission to %windir%, and if an
| attacker controls an Administrator account then they've already
| defeated security.

to which I replied:

| The directory in question is but "%windir%\temp\"!
| In Windows Embedded POSReady 2009 UNPRIVILEGED users can create
| the subdirectory "sso\" and the DLL "ssoexec.dll".
| Game over!

which yield another absurd answer from the MSRC:

| After some research, it appears this EOP attack requires that the
| attacker has already violated one of the 10 Immutable Laws of Security
| (http://technet.microsoft.com/library/cc722487.aspx ), most notably
| laws #1 or #3. You should read the article to understand why those
| laws matter.

OUCH! I asked the MSRC again:

| which part of "In Windows Embedded POSReady 2009 UNPRIVILEGED users
| can create the subdirectory "sso\" and the DLL "ssoexec.dll" is not
| understood?

and got the final answer:

| We are aware of the issues and arguments you've mentioned. An attacker
| in a position to carry out these attacks could also carry out many
| other attacks we can't stop. The link provided below explains this in
| detail.

OUCH!

Stefan Kanthak

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ