Audit Windows permissions with freeware Windows Permission Identifier

Windows Permission Identifier is a freeware program that allows you to audit Windows permissions for files, folders, registry keys, services, and some other object types. Permissions for a listed item can be changed by right-clicking and choosing Change Permission. Results can be sorted by any column by clicking on a column header. Policies to audit can be saved to a file for later use.

Example #1 - Check if any existing files in your Windows folder (and subfolders) can be modified by a given user:
1. Click on Settings tab.
2. Set user and password to desired user account to audit.
3. Click Insert button. Set Check Type to File. Under Paths choose WINDIR. Under Alert If choose Write.
4. Click Start button to start audit.
5. Click on Results tab.
6. When audit is done, select the given policy.
7. Click Status column header to sort results by status. Any files in your Windows folder (and subfolders) that can be modified by the given user will have a red X for status.

Example #2 - Check if a given user can create files or folders in your Windows folder (and subfolders):
1. Click on Settings tab.
2. Set user and password to desired user account to audit.
3. Click Insert button. Set Check Type to Folder. Under Paths choose WINDIR. Under Alert If choose Add File and also Add Folder.
4. Click Start button to start audit.
5. Click on Results tab.
6. When audit is done, select the given policy.
7. Click Status column header to sort results by status. Any folders in your Windows folder (and subfolders) that the given user can add a folder or file to will have a red X for status.

A similar program is the command-line program AccessChk. There is an important difference between the two programs: Windows Permission Identifier lists the effective permissions of a given account, while AccessChk does not. Namely, Windows Permission Identifier takes into consideration the groups, such as the Users group and the Authenticated Users group, that a given account is a part of, while AccessChk does not. In my opinion, this feature makes Windows Permission Identifier the better program for most usage scenarios.

Note to Vista/Win 7 users: does not work properly when run elevated (at least on my computer).

Credit: discovered program at http://kareldjag.over-blog.com/.

 

I've found further problems with AccessChk v4.24: AccessChk sometimes gives results that are inconsistent with prior AccessChk results.

 

Note to those of you using Windows Permission Identifier on Vista x64 or Windows 7 x64: you may want to add separate policies for the virtual folder %WINDIR%\sysnative in order to process the real System32 folder. See http://www.nynaeve.net/?p=133 for more details about %WINDIR%\sysnative.

 

Nice and informative little program MrBrian. Thanks

 

You're welcome .

A note for users of SRP, AppLocker or similar: I found a number of locations within the Windows folder where a standard (i.e. limited) user (and therefore also malware) can write new files, and in some cases execute them. When I rebuild the computer, I will publish the folder locations here in a future post.

EDIT: changed 'can write files' to 'can write new files.'

 

I don't see write privileges under my limited account in the Windows folder. Unless I'm checking wrong, although I also checked HKEY_Local_Machine registry path and no problems there either. When time permits, maybe tomorrow, I'll check further.

 

Are these places coded into the default security template that is applied during installation? Or are they made by the owner after installation? Owner, as in owner of the created objects/containers.

Sul.

 

It's a computer with Windows and other software pre-installed from the computer vendor, to which I've installed some software also. I believe most if not all of these locations are likely present in a clean installation. When I'm done with my Windows 7 testing phase within the next few weeks, I'll wipe the hard disk and then install just Windows, immediately check the permissions, test each candidate location manually for correctness, and then post the results here.

 

What operating system are you using? I'm using Win 7 x64.

By the way, I should have used the phrase 'new files' instead of just 'files'. I corrected my previous post to reflect this.

 

W7 x64, Ultimate with Applocker rules engaged, so not sure if it makes a difference?

 

Yes, that's what I've always said: audit your permissions to discover stuff like this. Off the top of my head, an old example from Windows XP used to be that limited users, in a default install of XP with Microsoft's default ACLs from the factory, could create new files and execute them in the Windows\Temp folder, which would make a nice way to bypass SRP without any tricks if the Temp folder was not blacklisted with an additional, non-default rule.

That sounds pretty... strange. Last time I used AccessChk, I distinctly recall it reporting effective permissions for a folder properly, taking into consideration the groups the account belonged to. Like this: the permissions for a certain folder allowed only Read access to limited users, no writing, and a certain limited user account called "Joe" was not configured for any permissions in the security descriptor of that folder. When I ran "accesschk computername\Joe folderpath" it correctly reported that Joe has Read access - by virtue of belonging to the Users group, even though the account called Joe itself had not been given any permissions to that folder. Similar, when I ran "accesschk folderpath" it correctly reported that the Users group has Read permission to everything in that folder - obviously it doesn't bother to mention the account Joe, since Joe is part of the Users group and accesschk already said Users have Read access, so mentioning Joe would be redundant.

That, and then there's also that the very AccessChk web site says this:

I wonder if the guys who wrote "Windows Permission Identifier lists the effective permissions of a given account, while AccessChk does not" have actually tested this with AccessChk properly... I have this nagging doubt that maybe they just used "accesschk foldername" and then thought "Oh hey, our specific test account is not listed in this output, it's all just groups, so I figure AccessChk can't list the effective permissions of a given account at all." But I could be wrong. Wouldn't be the first time, and certainly not the last!

As far as inconsistent results with AccessChk, are these results the output of the exact same command line, in the exact same account that was used previously? And the actual permissions had not changed between the two tests? Just curious, as even small changes in the parameters will give dramatically different looking results.

 

Assuming this is correct, as I'm sure it is, to what extent beyond the ability to write to this temp folder could the malware write further? Wouldn't it still be denied write access to the critical areas such as the registry and other off-limits areas (to LUA accounts)? I distinctly remember a power user account at work a few years ago getting a rogue av installed on it by an ignoramous who should'a known better, but at least it was very easy to remove because although there were some privileges beyond that of a true limited account, it was not to the extent of a full admin account, so the rogue couldn't get its tentacles fully hooked into the O/S. Removal was very easy.

 

IIRC, my tested usage of AccessChk was this:
Accesschk -w -s schmo "c:\windows"

or this:
Accesschk -w -s -u schmo "c:\windows"

where schmo is the user account tested. Does that look correct?

As to your other points, I'll test (yet) again in a few hours and post results here. I actually hope it's user error instead of issues with AccessChk.

 

I've completed more tests. My task: find folders within \Windows folder in which a standard user account can create files.

Here's what I did:

1. Restored backup that I made the day that I got the computer.

2. Installed Windows Permission Identifier and AccessChk.

3. Created standard user account named schmo.

4. As a test case, created folder c:\windows\test1 and gave schmo permission to create files within it.

5. In the admin account, ran Windows Permission Identifier non-elevated. Created policy with settings User=schmo, Check Type=Folder, Path=%WINDIR%\, Alert If=Add File. Ran the audit.

Folders with status color of red X were:
c:\windows\debug\wia
c:\windows\registration\crmlog
c:\windows\system32\catroot2\{f750e6c3-38ee-11d1-85e5-00c04fc295ee}
c:\windows\system32\tasks
c:\windows\syswow64\tasks
c:\windows\tasks
c:\windows\test1
c:\windows\tracing

There were 29 folders with status color blue (=view permission denied), including c:\windows\temp.

6. In the same admin account, opened non-elevated command prompt and ran following command:
accesschk -duws schmo c:\windows

Result: 1 folder:
RW c:\windows\test1

7. Switched to schmo account and manually verified that files could be created without elevation in every of the 8 folders listed in step #5.

8. Compare the results of steps #5 and #6. AccessChk missed a number of folders within Windows where schmo could create files. Why?

9. Switched to admin account. Opened non-elevated command prompt and ran following commands:
accesschk -duws users c:\windows
accesschk -duws "authenticated users" c:\windows

I won't list the resulting folders here, but the result set contained all of the folders listed in step #5. Seeing results like this was what caused me to state that AccessChk doesn't take group membership into consideration - or at least it seemed so. Maybe somebody has an alternate hypothesis.

10. I tried step #6 but in an elevated command prompt. Same results.

11. I tried step #9 but in an elevated command prompt. Some additional folders were listed, including c:\windows\temp and some of its subfolders.

12. For completeness on x64 systems, a Windows Permission Identifier policy with Path=%WINDIR%\sysnative also needs to be created, for reasons covered in a prior post in this thread. In doing so, I found that the user schmo can create files in folder c:\windows\system32\spool\drivers\color.

Note: in some of the folders that I listed above, the created file (assuming it's executable) cannot be executed by the limited user due to permissions.

 

I believe so.

I did change permissions between the tests. I loosened permissions in c:\windows\help if I recall correctly, but did not change any other permissions. After loosening permissions in c:\windows\help, Accesschk did report at least some of the loosenings in c:\windows\help, but unfortunately did not list some of the folders it had listed before the loosenings. By the way, I did run Windows Permission Identifier again after the loosenings, to double-check that other permissions had not been messed with.

I'll try to reproduce this again. Maybe it was user error on my part, or maybe not....

 

These are the folders for which the limited user can execute the file created within: (tested on Windows 7 x64)

c:\windows\debug\wia
c:\windows\system32\catroot2\{f750e6c3-38ee-11d1-85e5-00c04fc295ee}
c:\windows\system32\tasks
c:\windows\syswow64\tasks
c:\windows\tasks
c:\windows\temp
c:\windows\system32\spool\drivers\color

 

Only to the extent that the ACLs allow: if the Users group has write permission to Windows\Temp but no write permission to for example Windows\System32, then the malware can obviously write in the Temp folder but not in System32. In other words, this is only a simple way to "bypass" SRP by taking advantage of lax SRP rules that don't consider where various users can really write and execute - it's not a method of privilege escalation. You can bypass a poorly made SRP policy like that, but you can't get your code to run as admin or system. So yes, the malware would still be only running with limited user privileges, unable to infect the entire system or other user profiles. So, not a way to get kernel rootkits installed from a LUA, but you could use it to run some program that the system admin doesn't want you to run even in a limited account, or get some fake av running and scare the user with it.

Regarding the Power Users group, depending on which Windows version one is running, they're either not very "limited" or not very "power(ful)" user accounts. A nice old read on that subject: http://blogs.technet.com/markrussinovich/archive/2006/05/01/the-power-in-power-users.aspx

I think the key issue here could be the words "non-elevated command prompt". AccessChk should be run elevated, as admin, to get "the whole story". For one thing, limited users don't have the "Read Permissions" special permision on some system folders like c:\windows\temp. AccessChk can give very different results depending on whether you run it as admin or not. If you get inconsistent results or group membership being overlooked with AccessChk running as admin, that's interesting and might be a bug - but if you get strange results running AccessChk without admin privileges, that's just business as usual. Tools like that really do need admin privileges to do their job to the fullest extent. Like AccessEnum, it'll give quirky results in LUA, not having all the privileges it would like. Also, it may not be immediately obvious that one should get different results depending on such things as whether one is asking AccessChk to check for the permissions of the "Users" group or "Authenticated Users" group, for example. Try only running AccessChk elevated as admin and see if you still get incorrect results.

 

I did in step #10. It gave the same results as step #6, namely only c:\windows\test1. So the issue still remains: why does AccessChk miss so many folders when running the following command in an elevated command prompt:
accesschk -duws schmo c:\windows
?

By the way, the reason that I didn't run both programs elevated in the head-to-head test is that Windows Permission Identifier doesn't work properly in some cases when elevated. Does anybody know a workaround?

 

Thanks Windchild. Kind of what I figured. I ran as a power user at home (XP Pro) for several years with no issues. I used to modify folder permissions constantly, looking for the best balance between convenience and protection, and I also did it for the learning benefits. After a while, of course, I decided to simply run as LUA because it's ultimatley the safest platform and at least for me does little to hamper convenience or usability.

 

I've completed some more tests. Permissions of existing files were the focus of the tests in this post. All tests of AccessChk in this post were from an elevated command prompt.

Test #1 - permission to write to 3 existing files:
File1 is readable and writable by account schmo. File2 is readable and writable by Users group. File3 is readable and writable by Authenticated Users group. AccessChk for schmo to writable files found only File1. AccessChk for Users to writable files found File2. AccessChk for Authenticated Users to writable files found File3. Windows Permission Identifier correctly found all three files for schmo.

Test #2 - permission to read 3 existing files:
Similar to Test #1 except testing permission to read the three files. Same results as in Test #1.

Conclusion: AccessChk again did not seem to consider group membership, while Windows Permission Identifier did.

Note: I also tried an older version of AccessChk, v4.21 from 2008, and got the same results as with v4.24.

 

I've tried now, but I cannot reproduce this. When I try to reproduce your test, AccessChk correctly tells me that the test account has RW access on all of the test files - correctly reporting that even though the test account itself has no permission on the two latter test files, it has RW permission by virtue of its membership in Users and Authenticated Users groups. This must be something strange going on in your system - or mine and all the other systems I've ever run AccessChk on. Do you have the Terminal Services service disabled by any chance? If you do, try enabling it and see what happens.

 

Thank you Windchild for your tests .

I am quite surprised that we are getting such different results. I am using Windows 7 Home Premium x64, and have not had any other issues with it in 2 months of usage so far. It hasn't been "tweaked" except for a few things such as making hidden files visible in Windows Explorer. Terminal Services service isn't present in the list of services.

I just ran the tests from an elevated command prompt. Test is the folder in which I placed the three test files. Please see the attached screenshot for the results.

I then switched to the schmo account and tried to open each of the three test files. All three test files opened in Adobe Reader.

 

Interesting stuff! I don't have any Home versions around here right now, so I unfortunately can't test that. It could be, I guess, that there's something about Home Premium that makes AccessChk not work correctly - but I doubt that would've slipped past the devs for this long. Regarding Terminal Services, I forgot its 'long' name has changed and is Remote Desktop Services these days. Do you have Remote Desktop Services running? If all else fails, you could just do "sc query TermService" and see if it's running. At least Process Explorer needs it to work right, and I figure AccessChk would as well.

 

Remote Desktop Services is running.

 

Well, darn. I'm officially out of ideas. I'll have to give it some more thought. Meanwhile, if you've got other systems around there and have the time, try that test on them and see if this isn't something limited to just one system. Strange problem in any case, though.