[BUG] Windows 10 default user profile is potentially writable by everyone

This is the story how I found out (by proxy) that the default user profile in Windows 10 is potentially writable by any user and the odyssey of trying to get this security bug fixed ... and failing to do so in the end.

For those who do not want to read the full story I posted a TL;DR version at the bottom. ;)


2017-05-19 19:55 - I got contacted by a friend who asked me for my input on an issue he (or rather his company) was having for weeks and months already and had not been able to figure out yet. Even Microsoft Germany, who they contacted themselves about this issue on 2017-03-28, did not have a solution for them.

Some background: His company is selling servers and support for them. So far, there are over 1.800 of their servers with over 100.000 connected clients and over 1.000.000 users out there and they had a problem with newly deployed Windows 10 systems they were not able to figure out.



Their product is offering a mode where a selected set of computers can be hardened in a way that prevents all network traffic except traffic between the server and the client. So no internet access or communication with other computers. Accessing files on the server is also restricted to very specific folders/shares. Users logging into these computers will also receive a fresh user profile so they do not have access to any private files. The point of this mode is to allow teachers to hold exams on these computers while reducing the chances of cheating by exchanging mails or files with others.

And this is where it all began ... people figured out how to cheat - using the default user profile folders, which for some reason was suddenly writable by everyone. And by doing this they found a security bug in Windows 10 that at this point no one on the internet seemed to have heard of yet.

So I told him I would look into the issue they were having since we were working on deploy a couple hundred Windows 10 machines ourselves.


2017-05-22 08:00 - I started setting up a Windows 10 1607 (Build 14393) machine and was honestly surprised about what I found:

icacls C:\Users

       NT AUTHORITY\SYSTEM:(OI)(CI)(F)

       BUILTIN\Administrators:(OI)(CI)(F)

       BUILTIN\Users:(RX)

       BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

       Everyone:(RX)

       Everyone:(OI)(CI)(IO)(GR,GE)

 

icacls C:\Users\Default

       BUILTIN\Administrators:(F)

       BUILTIN\Administrators:(I)(OI)(CI)(F)

       NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

       CREATOR OWNER:(I)(OI)(CI)(IO)(F)

       BUILTIN\Users:(I)(OI)(CI)(RX)

       BUILTIN\Users:(I)(CI)(AD)

       BUILTIN\Users:(I)(CI)(WD)

 

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"

       BUILTIN\Administrators:(OI)(CI)(F)

       NT AUTHORITY\SYSTEM:(OI)(CI)(F)

       NT AUTHORITY\SYSTEM:(F)

       CREATOR OWNER:(I)(OI)(CI)(IO)(F)

       BUILTIN\Users:(OI)(CI)(RX)

       BUILTIN\Users:(CI)(AD)

       BUILTIN\Users:(CI)(WD)

 

Just a small footnote:
AD - append data/add subdirectory
WD - wirte data/add file
CI - container inherit
I - permission inherited from parent container


Just to verify that I was not going crazy I installed a couple other Windows versions and checked the permissions there too.

So I installed Windows 7, Windows 8.1, Windows 10 1507 (Build 10240) and Windows 10 1511 (Build 10586) from DVD. All their folder permissions on the default user profile folder looked like this:

icacls C:\Users

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)

      BUILTIN\Administrators:(OI)(CI)(F)

      BUILTIN\Users:(RX)

      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

      Everyone:(RX)

      Everyone:(OI)(CI)(IO)(GR,GE)

icacls C:\Users\Default

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

      BUILTIN\Administrators:(I)(OI)(CI)(F)

      BUILTIN\Users:(I)(RX)

      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

      Everyone:(I)(RX)

      Everyone:(I)(OI)(CI)(IO)(GR,GE)

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

      BUILTIN\Administrators:(I)(OI)(CI)(F)

      BUILTIN\Users:(I)(RX)

      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

      Everyone:(I)(RX)

      Everyone:(I)(OI)(CI)(IO)(GR,GE)

The permissions of Windows 10 1703 (Build 15063) looked slightly differently:

icacls C:\Users
      NT AUTHORITY\SYSTEM:(OI)(CI)(F)
      BUILTIN\Administrators:(OI)(CI)(F)
      BUILTIN\Users:(RX)
      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
      Everyone:(RX)
      Everyone:(OI)(CI)(IO)(GR,GE)

icacls C:\Users\Default

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)
      BUILTIN\Administrators:(OI)(CI)(F)
      BUILTIN\Users:(RX)
      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
      Everyone:(RX)
      Everyone:(OI)(CI)(IO)(GR,GE)

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
      BUILTIN\Administrators:(I)(OI)(CI)(F)
      BUILTIN\Users:(I)(RX)
      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
      Everyone:(I)(RX)
      Everyone:(I)(OI)(CI)(IO)(GR,GE)

You can see how the (I) inheritance attribute is missing on the "C:\Users\Default" folder but the rest of the permissions are at least correct.

So something must have happened with the release of Windows 10 1607, something must have broken. And with 1703 they (at least tried to) fixed it again.

At this point I decided to check what happens with a Windows 10 1607 system that got installed from DVD and then got upgraded to 1703. Because if the upgrade to 1703 would fix the issue I could just tell my friend to update the clients and be done with the problem. The result was quite a mess though:

icacls C:\Users

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)

      BUILTIN\Administrators:(OI)(CI)(F)

      BUILTIN\Users:(RX)

      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

      Everyone:(RX)

      Everyone:(OI)(CI)(IO)(GR,GE)

icacls C:\Users\Default

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)

      BUILTIN\Administrators:(OI)(CI)(F)

      BUILTIN\Users:(RX)

      BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

      Everyone:(RX)

      Everyone:(OI)(CI)(IO)(GR,GE)

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows"

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

      BUILTIN\Administrators:(I)(OI)(CI)(F)

      BUILTIN\Users:(I)(RX)

      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

      Everyone:(I)(RX)

      Everyone:(I)(OI)(CI)(IO)(GR,GE)

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu"

      BUILTIN\Administrators:(OI)(CI)(F)

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)

      NT AUTHORITY\SYSTEM:(F)

      BUILTIN\Users:(OI)(CI)(RX)

      BUILTIN\Users:(CI)(AD)

      BUILTIN\Users:(CI)(WD)

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

      BUILTIN\Administrators:(I)(OI)(CI)(F)

      BUILTIN\Users:(I)(RX)

      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

      Everyone:(I)(RX)

      Everyone:(I)(OI)(CI)(IO)(GR,GE)
 

icacls "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"

      BUILTIN\Administrators:(OI)(CI)(F)

      NT AUTHORITY\SYSTEM:(OI)(CI)(F)

      NT AUTHORITY\SYSTEM:(F)

      BUILTIN\Users:(OI)(CI)(RX)

      BUILTIN\Users:(CI)(AD)

      BUILTIN\Users:(CI)(WD)

      BUILTIN\Administrators:(I)(OI)(CI)(F)

      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

      BUILTIN\Users:(I)(OI)(CI)(RX)

      BUILTIN\Users:(I)(CI)(AD)

      BUILTIN\Users:(I)(CI)(WD)

      BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

      Everyone:(I)(RX)

      Everyone:(I)(OI)(CI)(IO)(GR,GE)

So even on a Windows 10 1607 system that was upgraded to 1703 you end up with the (I) inheritance attribute missing on the "C:\Users\Default" folder and still folders further down the line that are writable for all users. In addition to that they now also added explicit access rights on top of inherited ones, adding to the mess.

A system that got upgraded from Windows 10 1511 straight to 1703 without ever having 1607 installed showed the same permissions as a 1703 install traight from the DVD.

(What I did not test was what happens when you take a 1507 or 1511 system and upgrade those to 1607. I would assume the permissions would be equally messed up.)

At this point it was clear what this meant. Any logged in user could modify the default user profile by creating new files and folders, including the "Startup" folder. Which means that anything placed in there would be executed for any new user logging into a computer for the first time, including administrators.


2017-05-22 13:30 - On the same day I compiled all the information I had gathered and sent everything to our company's Technical Account Manager (TAM) at Microsoft. I also included a possible way how users could exploit this bug by placing executable files into the "Startup" folder and having a new user with admin rights log onto the machine. (Keep this in mind for later...)

2017-05-22 15:30 - I sent a mail to my friend with two commands that would fix the issue for him. Only downside is that the commands need to be executed on all affected clients. With a proper software distribution system that is not much of an issue though

       icacls C:\Users\Default /Q /C /T /inheritance:e

       icacls C:\Users\Default /Q /C /T /reset

All the commands do is enable the inheritence on all objects and subobjects of the folder specified and then delete all the explicitly set permissions.

2017-05-22 17:00 - I got an answer from the TAM that he had opened a ticket/call about the issue and that an engineer should get in touch with me soon.

2017-05-22 17:39 - An active directory Support Engineer (SE) from the Romanian office sent me an email asking me when he could call me to get a better grasp of the issue I had found.

2017-05-23 08:00 - Told the SE when he could reach me.

2017-05-24 11:00 - The SE from the Romanian office called me and we had a lengthy chat about the issue. He agreed that this is a security problem and that the issue should be fixed. He proposed to file a business impact (BI) report in order to hopefully speed things up a bit. After the call I sent him the two commands I had already sent my friend so he could include them in the ticket/call. Maybe they could make use of them and it would speed the release of a fix up a little more.

2017-05-24 12:20 - I got the summary of the last call with the SE.

2017-05-25 13:25 - The business impact (BI) template arrive in my inbox.

2017-05-26 09:00 - The filled out BI report was sent to the SE and to our TAM.

2017-06-09 15:25 - I got an email from a Senior Escalation Engineer (SEE) from the Munich office who told me that he had taken over the ticket/call and that he would talk to the product group about the issue.

2017-06-12 14:00 - After a lengthy call with the SEE I was informed that Microsoft would be releasing a patch with the next patchday (13./14.06.) that would adress the issue and fix it. And we agreed that he would call again on 16.06. to verify if everything had worked out.

2017-06-12 14:35 - All euphoric I contacted my friend and told him the good news. He was equally happy.

2017-06-13 14:00 - I got another email from the SEE informing me that he had already tested the RS1 hotfix and that the result was rather ... disappointing. All the patch did was fix the permissions of the folder "C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup". The final fix would be moved to RS4 (March/April 2018). He did promise me that he would bring it up with the people in charge again and that he would get back to me.

2017-06-13 15:11 - My friend informed me that Microsoft had by now released CVE-2017-0295, claiming that the issue was fully fixed and all you would need to do is install KB4022715 (Windows 10 1607 & Server 2016) or KB4022725 (Windows 10 1703). Which obviously is not true since all the patches do is fix the permissions of the "Startup" folder. Acknowledgements in the CVE went to two other people, so apparently I was not the first one to report the issue.

2017-06-14 17:00 - I confirmed the information from the SEE that only the "Startup" folder would get fixed and contacted the SEE about it via email.

2017-06-16 12:10 - The SEE contacted me again and told me that apparently the "icacls" solution would not be enough and that he was still in contact with the product group in order to maybe still get a full patch out.

2017-06-21 13:45 - After another lengthy call with the SEE where he assured me again that he too thinks this is a severe issue that needs to be fixed, he sent me another icacls command that he thinks would do a better job at fixing the permissions:

       icacls C:\Users\Default /Q /C /T /remove:g BUILTIN\Users

2017-06-27 11:40 - The SEE informed me that he had created another "work item" for the product group so the group would have to discuss the issue again.

2017-07-06 15:00 - The SEE informed me that his inquiry had been shot down again by the product group. He told me that he would bring it up with the TAM again in order to escalate the issue further.

2017-07-12 13:50 - The SEE informed me that he and the TAM had escalated the issue at a "rather prominent position".

2017-07-17 11:40 - The SEE informed me that the outlook for a proper patch before the RS4 release in March/April 2018 is rather bleak. The reasoning of the product group is that there is a rather simple workaround available with the icacls command.

2017-07-26 15:30 - In another lengthy call with the SEE he told me again that there most likely will not be a proper patch for the issue before RS4. I agreed to close the ticket/call since it was going nowhere at this point.

2017-07-26 17:30 - I got the final mail from the SEE with the summary about the issue, the workaround and the assumed date of March 2018 when they might release a proper patch.


TL;DR

• The default user profile under Windows 10 1607 (and any version upgraded from (and possibly through) that) is writeable by every user
• Microsoft released a half-assed patch that only fixed the permissions for the "Startup" folder because it was the only exploit I mentioned in my original ticket
• Microsoft released a CVE-2017-0295 article claiming that the issue has been fully fixed
• Microsoft refuses to fix the issue properly because there is a "simple command everyone can execute" but has not (to my knowledge) told anyone about this command because everyone assumes the issue has been fixed by KB4022715 and KB4022725
• Microsoft postponed the release of a proper fix until RS4 (March/April 2018) for an issue introduced in July 2016

While I obviously disagree with the decision made by Microsoft (or rather the product group) I have to give the SE and SEE a shoutout for their professionalism, how they handled the case and how they gave me the feeling that they really wanted to get this issue fixed. Whether the last part was actually genuine or just really good training I cannot be sure of but I will give them the benefit of the doubt.


[1] https://twitter.com/BeingSysAdmin/status/891905855788126208
[2] https://www.reddit.com/r/sysadmin/comments/6qmn49/windows_10_default_user_profile_potentially/