Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Stefan Kanthak]

Jeffrey Walton wrote:

> Hi Stefan,
> 
>> ... administrative rights for every user account

This WAS the default for user accounts back then, and still IS the
default for user accounts created during setup.

> Hmmm... XP/x64 appears to have a bug such that the second user also
> needs to be admin (perhaps XP/x86, too). XP does not recognize the
> first account as admin, so the second account cannot be limited (at
> least on my test box).

1. A "normal" (read: attended) setup of XP forces you to create at
   least one user account (besides the always created "Administrator")
   during setup which gets administrative privileges.

   You can demote this user account on the command line with
   "NET.EXE LOCALGROUP Administrators %USERNAME% /DELETE" as well as
   interactive with "MMC.EXE LUSRMGR.MSC" and
   "RUNDLL32.EXE NETPLWIZ.DLL,UsersRunDll" alias
   "CONTROL.EXE Userpasswords2".

   Only the dumbed down "User Accounts" control panel applet
   (run via "CONTROL.EXE NUSRMGR.CPL" alias
   "MSHTA.EXE res://NUSRMGR.CPL/nusrmgr.hta") insists on having a
   second user account (besides the builtin "Administrator") with
   administrative rights and does not allow to demote the second
   (superfluous) administrative account.

JFTR: neither the dumbed down "User Accounts" control panel applet
  nor "CONTROL.EXE Userpasswords2" show disabled accounts.

2. The "out-of-box experience" allows you to create up to 5 user
   accounts during setup, which all get administrative privileges.

3. An unattended setup of XP does NOT force you to create a (second)
   user account (besides the always created "Administrator") at all,
   and allows you to disable the "out-of-box experience" too.

4. After setup the dumbed down "User Accounts" control panel applet
   defaults to create administrative accounts (and forces you to
   create an administrative account if there is only one, for
   example after unattended setup), while "MMC.EXE LUSRMGR.MSC" creates
   "users", and "CONTROL.EXE Userpasswords2" creates user accounts as
   "power users" (it shows a dialog with "users", "power users" and
   "administrators" where "power users" is selected).

The result: Jane Doe has administrative rights, via the user account
created during attended setup or afterwards with "Users & Passwords"
and its default setting.

Q.E.D.

> Vista and above make the first user admin, but others users default to 
> standard.

It's basically like XP: the (attended) setup forces you to create at
least one user account which gets administrative privileges.

The result: as long as John Doe uses his Windows PC with just the
user account created during setup he is administrator.

regards
Stefan

[ fullquote removed ]

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

Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Jeffrey Walton]

Hi Stefan,

> ... administrative rights for every user account
Hmmm... XP/x64 appears to have a bug such that the second user also
needs to be admin (perhaps XP/x86, too). XP does not recognize the
first account as admin, so the second account cannot be limited (at
least on my test box).

Vista and above make the first user admin, but others users default to standard.

Jeff

On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak  wrote:
> Hi,
>
> since it's start about 20 years ago Windows NT supports (fine grained)
> ACLs, including the permission "execute file".
>
> In their very finite wisdom Microsoft but decided back then to have
> this permission set on EVERY file a user creates (and assumes it is
> set on local and remote file systems which dont support ACLs).
>
> The result: on Windows, malware can run everywhere (and since CWD
> alias "." is in the path, can be started everywhere)!
>
>
> These fundamental errors, combined with two other fundamental errors
> (NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access
> for non-administrative user accounts, and administrative rights for
> every user account) turned Windows NT into the same unsafe, insecure
> and vulnerable system its predecessors MS-DOS and Windows 3.x were
> and enabled miscreants to abuse internet-connected Windows systems
> to distribute SPAM, launch DDoS attacks, spread malware, etc.
>
>
> For a company that puts "compatibility" above all other criteria this
> decision might have looked reasonable ... BUT: it was NOT!
>
>
> Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to the
> existing DOS- and Win16-API. To run existing applications written for
> the old APIs Windows NT introduced NTVDM (the "Virtual DOS Machine")
> and WoW (the "Windows on Windows" subsystem); only these Windows NT
> components had to be made compatible (and "unsafe" enough to run old
> applications).
>
> There was ABSOLUTELY no need to sacrifice the safety and security of
> Windows NT and the Win32-API for the sake of "compatibility": the
> Win32-API was new, no existing applications had to be supported!
>
>
> Then sloppy developers started to build their applications for the
> Win32-API of this unsafe/insecure environment ... and expected their
> unsuspecting victims^Wusers to have write access to %SystemRoot% and/or
> %ProgramFiles% to write their *.INI files, for example, or to run their
> crapware with administrative or power-user rights.
>
>
> JFTR: since many years Microsoft makes many (almost futile) attempts
> to mitigate the effect of their wrong design decision(s), for example:
>
> *  alias
>   
>
> * 
>
> * 
>
> *  alias
>   
>
> *  alias
>   
>
> * 
>
> *  alias
>    PLUS the
>   28(!) security bulletins listed there
>
> but NEVER tackled the source of the problem!
>
>
> Instead they introduced things like the "security theatre" UAC: with
> Windows 8 the user account(s) created during setup still have
> administrative rights. And Windows 7 introduced the "silent" elevation
> for about 70 of Microsoft own programs...
>
>
> stay tuned
> Stefan Kanthak
>
>
> PS: if you want to mitigate the wrong design decision that every file
> is "executable": add and propagate an inheritable-only "deny" ACE
> with "execute file" permission for the user group "WORLD\Everyone"
> alias "S-1-1-0", "(D;OIIO;WP;;;WD)" in SDDL notation, at least for
> "%USERPROFILE%" and "%ALLUSERSPROFILE%" alias "%ProgramData%".
>
> On Windows NT 6.x, consider to add another "deny" ACE which prevents
> the directories/objects owner from changing/removing that permission:
> "(D;;WDAC;;;OW)" in SDDL notation.
>
> Since this mitigation will stop "Administrators" and "LocalSystem"
> to run files in their user profiles (to be precise: in "%TEMP%"
> alias "%USERPROFILE%\Local Settings\Application Data\TEMP" resp.
> "%USERPROFILE%\AppData\TEMP" where self-extracting installers will
> typically unpack and execute their payload) you'll have to remove
> the user environment variables TEMP and TMP of these user accounts
> (setting the system environment variables TEMP and TMP which point
> to %SystemRoot%\TEMP into effect).
>
>
> See the script 
> for a POC (targetting Windows NT 5.x). It sets the "deny" ACE also
> on subordinate directories which are exempt from ACL inheritance,
> as well as some of the user-writable subdirectories of %SystemRoot%
> 

[Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Stefan Kanthak]

Hi,

since it's start about 20 years ago Windows NT supports (fine grained)
ACLs, including the permission "execute file".

In their very finite wisdom Microsoft but decided back then to have
this permission set on EVERY file a user creates (and assumes it is
set on local and remote file systems which dont support ACLs).

The result: on Windows, malware can run everywhere (and since CWD
alias "." is in the path, can be started everywhere)!


These fundamental errors, combined with two other fundamental errors
(NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access
for non-administrative user accounts, and administrative rights for
every user account) turned Windows NT into the same unsafe, insecure
and vulnerable system its predecessors MS-DOS and Windows 3.x were
and enabled miscreants to abuse internet-connected Windows systems
to distribute SPAM, launch DDoS attacks, spread malware, etc.


For a company that puts "compatibility" above all other criteria this
decision might have looked reasonable ... BUT: it was NOT!


Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to the
existing DOS- and Win16-API. To run existing applications written for
the old APIs Windows NT introduced NTVDM (the "Virtual DOS Machine")
and WoW (the "Windows on Windows" subsystem); only these Windows NT
components had to be made compatible (and "unsafe" enough to run old
applications).

There was ABSOLUTELY no need to sacrifice the safety and security of
Windows NT and the Win32-API for the sake of "compatibility": the
Win32-API was new, no existing applications had to be supported!


Then sloppy developers started to build their applications for the
Win32-API of this unsafe/insecure environment ... and expected their
unsuspecting victims^Wusers to have write access to %SystemRoot% and/or
%ProgramFiles% to write their *.INI files, for example, or to run their
crapware with administrative or power-user rights.


JFTR: since many years Microsoft makes many (almost futile) attempts
to mitigate the effect of their wrong design decision(s), for example:

*  alias
  

* 

* 

*  alias
  

*  alias
  

* 

*  alias
   PLUS the
  28(!) security bulletins listed there

but NEVER tackled the source of the problem!


Instead they introduced things like the "security theatre" UAC: with
Windows 8 the user account(s) created during setup still have
administrative rights. And Windows 7 introduced the "silent" elevation
for about 70 of Microsoft own programs...


stay tuned
Stefan Kanthak


PS: if you want to mitigate the wrong design decision that every file
is "executable": add and propagate an inheritable-only "deny" ACE
with "execute file" permission for the user group "WORLD\Everyone"
alias "S-1-1-0", "(D;OIIO;WP;;;WD)" in SDDL notation, at least for
"%USERPROFILE%" and "%ALLUSERSPROFILE%" alias "%ProgramData%".

On Windows NT 6.x, consider to add another "deny" ACE which prevents
the directories/objects owner from changing/removing that permission:
"(D;;WDAC;;;OW)" in SDDL notation.

Since this mitigation will stop "Administrators" and "LocalSystem"
to run files in their user profiles (to be precise: in "%TEMP%"
alias "%USERPROFILE%\Local Settings\Application Data\TEMP" resp.
"%USERPROFILE%\AppData\TEMP" where self-extracting installers will
typically unpack and execute their payload) you'll have to remove
the user environment variables TEMP and TMP of these user accounts
(setting the system environment variables TEMP and TMP which point
to %SystemRoot%\TEMP into effect).


See the script 
for a POC (targetting Windows NT 5.x). It sets the "deny" ACE also
on subordinate directories which are exempt from ACL inheritance,
as well as some of the user-writable subdirectories of %SystemRoot%
which dont host executable files.

WARNING: unfortunately the (only) Microsoft utility which allows to
add the specific ACEs, ICACLS.EXE, used in this script has but a
serious bug; cf. 

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