Audit Windows permissions with freeware Windows Permission Identifier

I'll try it on Win XP Pro after I am done eating .

By the way, what OS did you do your tests on?

 

My test machine was XP Pro SP3. Maybe I should've used a Win7 Ultimate x64 instead.

 

Since some users of AccessChk may have skipped this thread, I've started a new thread about AccessChk. Please continue the discussion about AccessChk there.

 

For those who cannot run Windows Permission Identifier as true admin, you may notice folders or files in results with a blue colored Status and Access of 'View Permission Denied'. In order to get complete results, there can be no files or folders with 'View Permission Denied'. A workaround is to manually create for these files or folders an access control entry for group Users giving the permission 'Read Permissions'. In some cases you may need to change ownership in order to do so. I was able to eliminate all instances 'View Permission Denied' when doing an audit of \Windows.

 

MrBrian or Windchild,

Using AccessEnum I found Users had write access to the following:

C:\Windows\Registration\CRMLog

C:\Windows\System32\com\dmp

C:\Windows\System32\Fxs Tmp

C:\Windows\System32\Spool\drivers\color

C:\Windows\System32\Spool\Printers

C:\Windows\System32\Tasks\Microsoft\Windows\memorydiagnostic\Corruption Detector

C:\Windows\System32\Tasks\Microsoft\Windows\memorydiagnostic\DecompressionFailure Detector

C:\Windows\System32\Tasks\Microsoft\Windows\SyncCentre

C:\Windows\System32\Tasks\Microsoft\Windows\WindowsColourSystem\CalibrationLoader

C:\Windows\Temp

C:\Windows\tracing

Based on what MrBrian has posted I know that it is possible to execute from some of these directories. What can I do to protect myself? Thanks.

 

I haven't closely looked into each of these folders yet to form an opinion on mitigation strategies. I will though within a week, when I do a clean install of Win 7.

Here are some ideas:
a) Block or prompt on execution by standard users to each of these folders individually using SRP, AppLocker, HIPS, or changing access control entries in Security tab in Windows Explorer
b) change access control entries in Security tab in Windows Explorer to no longer allow write permissions to standard users for these folders

I believe a) is safer, but I haven't done any testing yet. I'll post further when I get around to the clean install. Backup before making changes!

 

Thanks for responding MrBrian. I will wait for your further testing before proceeding.

 

I'll post my mitigation techniques within a few days.

I've posted a list of vulnerable Windows 7 files/folders here.

 

Windows Permission Identifier gives no warning when a folder's contents cannot be listed due to NTFS permissions. This is an issue that can cause some relevant items to not be listed when Windows Permission Identifier isn't run as admin.

 

You're welcome .

What I did is outlined here.

 

I'd like to note that auditing of Windows permissions IMHO ought to be done every time a program is installed, or at the end of an installation batch if you're installing more than one program.

What can happen if you don't do regular permission audits? Recently, I installed printer software from a well-known printer manufacturer. An audit of permissions after the installation revealed that some of the installed executable files were writable by a standard user. If malware were to modify some of these files, and these modified files were later executed in an admin account, the malware could achieve system takeover.

 

I did some time tests on Windows Permission Identifier vs AccessChk (with -ws switches) on the \windows folder. Windows Permission Identifier was nearly 4 times faster.

 

Hi MrBrian if you see this can you please comment on it? I did a bit of malware testing on a different drive, no Internet connection, recent image of Win7x64 under the limited account with AppLocker disabled (because it of course disallows the malware from launching). One of the malware, a rogue av scanner, wrote not only to some expected directorys residing under C:\Users\myname\AppData..., but also to C:\ProgramData as seen in my attached ss. This seems odd because users don't have write permission to this directory, as the security tab even verified. how do you think this could have happened? Thanks!

 

Users do have permission to do this. Look at the Advanced permissions in the Security tab for ProgramData - double-click the 'Special' entry for Users.

 

Okay I missed that, thank you!