Date: Tue, 10 Mar 2020 21:40:56 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Cc: bugtraq@...urityfocus.com
Subject: [FD] Defense in depth -- the Microsoft way (part 63): program
	defaults, settings, policies ... and (un)trustworthy computing

Hi @ll,

in 1993, Microsoft introduced Windows NT, and with it the following
hierarchy (or rules) of program defaults, settings and policies:

- policies override settings;

- user-specific policies and settings take precedence over system-
  wide policies and settings;

- hard-coded program defaults are in effect only when neither a
  policy nor a setting is present;

- policies are reserved for use by the (local) administrator, they
  MUST NOT be set by any other party, and can not be set by users!


To comply with the nearly 26 year old "Designed for Windows"
guidelines and meet the above rules, the following implementation
has to be (and typically is) provided:

- programs (including system components and system programs like
  control panel, registry editor, ...) store their user-specific
  settings in the user's registry below

  [HKEY_CURRENT_USER\Software\%VENDOR_NAME%\%PROGRAM_NAME%]
  "%setting%"=...

  or (for some older programs, like file explorer)

  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\%PROGRAM_NAME%]
  "%setting%"=...

- system components and system programs which have only system-wide
  settings store them in the registry below

  [HKEY_LOCAL_MACHINE\SOFTWARE\%VENDOR_NAME%\%PROGRAM_NAME%]
  "%setting%"=...

  or (for some older programs)

  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\%PROGRAM_NAME%]
  "%setting%"=...

- policies are optional, ie. not all settings have a corresponding
  policy;

- policies are stored in the registry below

  [HKEY_CURRENT_USER\Software\Policies\%VENDOR_NAME%\%PROGRAM_NAME%]
  "%policy%"=...

  or (for some older programs)

  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\%PROGRAM_NAME%]
  "%policy%"=...

  and

  [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\%VENDOR_NAME%\%PROGRAM_NAME%]
  "%policy%"=...

  or (for some older programs)

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\%PROGRAM_NAME%]
  "%policy%"=...

- the registry keys
  [HKEY_LOCAL_MACHINE\SOFTWARE],
  [HKEY_CURRENT_USER\Policies] and
  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies]
  and all their subkeys are protected by ACLs which allow only privileged
  users to write below them;

- programs read their policies/settings from the following registry keys
  in the given order, stopping at the first instance of the respective
  policy/setting registry entry:

  [HKEY_CURRENT_USER\Software\Policies\%VENDOR_NAME%\%PROGRAM_NAME%]
  [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\%VENDOR_NAME%\%PROGRAM_NAME%]
  [HKEY_CURRENT_USER\Software\%VENDOR_NAME%\%PROGRAM_NAME%]
  [HKEY_LOCAL_MACHINE\SOFTWARE\%VENDOR_NAME%\%PROGRAM_NAME%]

- some (older system) programs read their policies and settings from the
  following registry keys instead:

  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\%PROGRAM_NAME%]
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\%PROGRAM_NAME%]
  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\%PROGRAM_NAME%]
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\%PROGRAM_NAME%]

- only if the registry entry is not found below all 4 keys the hard-coded
  program default is used;

- when a policy is present for a setting, the (graphical) user interface
  shows the resulting effective setting, but does NOT allow to change it,
  and optionally a text that indicates the presence of a (overriding)
  policy as reason for the restriction.


Unfortunately some pigs^Wprograms are but created more equal than others.

In other words: Microsoft's developers don't always follow the scheme and
implementation depicted above and ABUSE registry keys reserved for policies
to store settings, ignoring their own "Designed for Windows" guidelines!


Example/demonstration #1:
~~~~~~~~~~~~~~~~~~~~~~~~~

1. On Windows 7 or any newer version, log on to the UAC-controlled
   administrator account created during Windows setup.

2. Delete the following registry entry:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
   "ConsentPromptBehaviorAdmin"=dword:...

3. Open "Control Panel"->"User Accounts", then click on
   "Change User Account Control settings" and verify that the UAC
   slider is set to the highest level titled "Always notify", where
   UAC auto-elevation is (supposed to be) turned OFF.

4. Start "WUSA.exe /?" (or another program which has UAC auto-elevation
   enabled) and notice NO UAC prompt there: the GUI used to view the
   effective setting in the previous step lied to you!

Cf. <https://msdn.microsoft.com/en-us/library/ee424306.aspx>
and <https://technet.microsoft.com/en-us/dd835564.aspx>


Example/demonstration #2:
~~~~~~~~~~~~~~~~~~~~~~~~~

1. On a fresh installation of Windows 10, start a command prompt and
   run the following command lines (for example from the batch script
   %SystemRoot%\Setup\Scripts\SetupComplete.cmd) to see the whole mess:

   REG.exe QUERY HKEY_CURRENT_USER\Software\Policies /S
   REG.exe QUERY HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies /S
   REG.exe QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies /S
   REG.exe QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Policies /S

2. For every policy registry entry found check that a corresponding
   setting registry entry is evaluated by the program or component
   which uses the policy registry entry, and whether this setting
   registry entry eventually exists.


stay tuned, and far away from Microsoft's UNTRUSTWORTHY mess!
Stefan Kanthak

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists