-1

I am using Microsoft's Attack Surface Analyzer, and I would like to get a better understanding of what would be the best way to mitigate the findings.

For example if in my report I get Directories Containing Objects With Weak ACLs, Description: The folder C:\Program Files (x86)\My_Folder contains files and/or folders with ACLs that allow tampering by multiple non-administrator accounts. the "Action:" part of the report is as follows: The ACL should be tightened. Do not allow users to write to start points, files or directories that influence control over other users.

In this case would an appropriate solution be to use a utility such icacls to change the ACL(s) of the Parent folder access to Administrator only access using a PowerShell script?

A different example I have is the Services Vulnerable To Tampering, Description: The service My_Service is vulnerable to tampering by multiple non-administrator accounts.

the "Action:" part of the report simply says The relevant ACL(s) must be tightened.

In this case we are talking about service(s), and I don't have a clue where to go with that one...

Thanks ahead for your time and any help!

0siris
  • 91
  • 8
  • I believe serverfault will be a good place for your question instead of security stackexchange. There may be people who have used such tools and have had such experiences over there. – Limit Jun 06 '18 at 18:27
  • Thanks for the tip, is there a way to port it over? – 0siris Jun 06 '18 at 19:17

1 Answers1

1

For the files, calling icacls or - since you're using Powershell - implementing the change yourself using [System.Security.AccessControl.*] classes are both valid options. You could also use Windows Explorer's Properties window, Security tab, which allows editing ACLs.

For the Windows service, it's trickier but possible. The sc.exe command (Service Control) can display and edit service ACLs; see here for more information. It's a messy process, though, and even more prone to errors than using something like icacls because you need to set the entire ACL at once, rather than manipulating individual entries. There's also no other easy way to manipulate service ACLs (beyond using the SCM APIs to call SetServiceObjectSecurity). The ACL itself is stored in a not-human-readable blob in the registry.

A more important question, though, is why are those ACLs so weak? A well-behaved program[1] would not modify the ACL on its install directory to let non-admins write there; by default that is disallowed. Similarly, a well-behaved program would not create a Windows service with a weak ACL (the vast majority of services probably have default ACLs, which do not allow non-admins to tamper with the service's configuration). Rather than trying to fix the problems manually, it might be better to figure out where they came from and prevent the mistake from being made in the first place.

[1] Steam is an excellent example of a very poorly-behaved program, security-wise; I think it does in fact weaken its install directory ACL and possibly also a service ACL.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • I was wondering if you could elaborate further as how the weakness could happen... For example in the case of the directory, is it the installer that is not settings the proper ACLs? As far as the services go, could it be a certain function call that might be unsafe, an external library or dll whose ACL is not appropriate for what the application is doing? – 0siris Jun 07 '18 at 19:10
  • A privileged (Admin) program, such as an installer, would need to directly modify the ACLs on the directory and service. It might not be an installer, but it does have to be a privileged program. The default ACL in either case does not allow non-admins to make changes, including preventing non-admin changes to the ACLs. Unless you enable auditing of ACL changes - disabled by default on most systems - you're unlikely to know for sure what process changed the ACLs, but you can use Attack Surface Analyzer to compare the ACLs before and after a change, such as installing or running a program. – CBHacking Jun 08 '18 at 05:54
  • If you're asking what might constitute an unsafe modification for a service, there are a number of possibilities. The service's executable process might be changed (to an untrusted one). The account the service runs as could be changed, for example from a limited account to SYSTEM. The service's parameters that are passed to the executable could be changed, potentially causing it to load untrusted DLLs or execute attacker-chosen actions. The ACLs on services (and on the service control manager in general) are usually very tight, for good reason. A compromised service is very bad. – CBHacking Jun 08 '18 at 05:58