Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
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 stefan.kant...@nexgo.de 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: * http://support.microsoft.com/kb/269049 alias http://technet.microsoft.com/security/bulletin/ms00-052 * http://support.microsoft.com/kb/306850 * http://support.microsoft.com/kb/905890 * http://support.microsoft.com/kb/953818 alias http://technet.microsoft.com/security/advisory/953818 * http://support.microsoft.com/kb/959426 alias http://technet.microsoft.com/security/bulletin/ms09-015 * http://support.microsoft.com/kb/2264107 * http://support.microsoft.com/kb/2269637 alias http://technet.microsoft.com/security/advisory/2269637 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 http://home.arcor.de/skanthak/download/~EXECUTE.INF 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
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
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 ]
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak stefan.kant...@nexgo.de 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)! Keep these coming...these are very interesting reads...thanks Stefan. James
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
On 2013-08-24 16:33, Jeffrey Walton wrote: 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 stefan.kant...@nexgo.de 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: * http://support.microsoft.com/kb/269049 alias http://technet.microsoft.com/security/bulletin/ms00-052 * http://support.microsoft.com/kb/306850 * http://support.microsoft.com/kb/905890 * http://support.microsoft.com/kb/953818 alias http://technet.microsoft.com/security/advisory/953818 * http://support.microsoft.com/kb/959426 alias http://technet.microsoft.com/security/bulletin/ms09-015 * http://support.microsoft.com/kb/2264107 * http://support.microsoft.com/kb/2269637 alias http://technet.microsoft.com/security/advisory/2269637 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 http://home.arcor.de/skanthak/download/~EXECUTE.INF 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,
Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!
I would prefer a more literarily neutral approach than that thought-filled, swear-prone discussion. The problem disclosed is interesting and the solution provided smooth. The pejoration in words really makes me think to which extents could the affirmations be true or just blow outs. sloppy developers, finite wisdom, the form sentences are made with adjectives that clearly shows personal insatisfaction to the subject takes out credits of the report. It would make a perfect reading if it followed the proposal of the subject security in depth without so much personal thought put in. -Original Message- From: James Lay Sent: Monday, August 26, 2013 12:16 pm To: bugtraq@securityfocus.com Subject: Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere! On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak stefan.kant...@nexgo.de 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)! Keep these coming...these are very interesting reads...thanks Stefan. James
