Defense+ fails to protect *protected* registry key [fixed]

Learn about Computer Security Leak Testing/Attacks/Vulnerability Research
1

update:

Grab test program by wj32 here. If allowed to run it modifies registry permissions for HKLM bypassing Defense+ silently!

  • Do not run it unless you know what exactly you are doing and how to revert back changes *

Defense+ (v3.12) settings:
Paranoid mode.
Computer security policy is on screenshot #1 - all items have default predifined/custom policies/exceptions etc.
Image execution control is set to normal with default extensions to check: exe, bat, com.
Shellcode injections protection is on without exceptions, though it is irrelevant for the test.
All units to monitor under
Defense+/Advanced/Defense+ Settings/Monitor Settings are checked (enabled).
“My protected files”, “My protected COM interfaces” groups have default (for v3.12) items.
“My protected registry keys” group has default items, except one more item is added to the list: HKEY_LOCAL_MACHINE* .

P.S.:
SubInACL program described in original post can be prevented by Defense+ from modifiying registry permissions if we do following modification to Defense+ settings:

However, mentioned protected interface can guard registry’s permissions from SubInAcl only because of coincidence:

-------------- original post start here ----------------------

I used MS app called SubInAcl for the test. Though this app is safe and harmless (with proper application), technique which is used by it to modify registry hives’ permissions (ACLs) is NOT intercepted by Defense+.

I’m not sure, whether this technique can be used (or is already used) by malware writers. Would like to see any live malware which modifies registry hives’ ACLs.
Modifying ACLs probably could lead to operating system destruction or other not desirable consequences.

Test (OS and Comodo details are in my sig).

subinacl.msi is downloaded from this MS page. Then it is installed. At the end we end up with subinacl.exe (packed as zip archive and attached).

Defense+ options are following.
Paranoid mode.
Computer security policy is on screenshot #1 - all items have default predifined/custom policies/exceptions etc. Only explorer.exe has exception to allow to launch cmd.exe.
Image execution control is set to normal with default extensions to check: exe, bat, com.
Shellcode injections protection is on without exceptions, though it is irrelevant for the test.
All units to monitor under
Defense+/Advanced/Defense+ Settings/Monitor Settings are checked (enabled).
“My protected files”, “My protected COM interfaces” groups have default items.
“My protected registry keys” group has default items, except one more item is added to the list: HKEY_LOCAL_MACHINE* .

Now we launch cmd.exe and execute following command:
somepath\subinacl.exe /keyreg “HKEY_LOCAL_MACHINE” /deny=system .
please do not execute this or similar command on your system unless you know what exactly U r doing

Defense+ alert “cmd.exe tries to execute subinacl.exe” appears and we allow this activity.
Then second alert (screenshot #2) appears and we block this activity.
No more alerts from Defense+ (what about “subinacl.exe tries to modify protected registry key” ?).
SubInAcl successfully modified ACL for HKEY_LOCAL_MACHINE hive. We can see it on command output (screenshot #3) and confirm it by launching regedit and verifying permissions for HKEY_LOCAL_MACHINE.

[attachment deleted by admin]

2

Hi SS26,

Just guessing, Microsoft is a Trusted Vendor and this is an MS application…

3

So what?
Defense+ is in Paranoid mode which disables any autolearning for any apps.
As for SubInAcl’s technique to modify registry ACLs, i wrote already:

4

Adding \Device\NamedPipe\lsarpc to the protected devices will have SubInAcl trigger an alert in Paranoid mode.

5

Yes, you are right :-TU thanks :-TU
How did you know?

6

I tested SubInAcl using a custom config with wildcarded entities to scavenge for a related alert, though it appears that lsarpc is not strictly specific to SubInAcl main purpose alone.

7

What a catch :-TU …especially taking into account that it has been cleared up by experimental way :o

P.S.: Information about protected lsarpc prevents modifying registry ACLs (at least by one technique) is worth adding into docs or wiki :THNK

8

Guess lsarpc can be used to thwart SubInAcl but not regedit.

Blocking that device will prevent regedit to display the SID alias or to browse for a new user/group but the permission, at least for existing groups, could still be changed.

Guess some other testcase would be needed to verify pros/cons of this entity :-\

9

True. I didn’t take into account that fact (was totally concentrated on subinacl). It’s interesting whether technique used by regedit to modify ACLs can be implemented in another program.

P.S.:
Added lsarpc to my protected files. First thing to notice every app (even those that never tried to access any protected files) is trying to access this “protected interface” (Defense+ wording). That probably could be one of reasons why lsarpc is not in the list by default.

10

Uh, the LSA API is used by programs to lookup user names, SIDs, and privilege names. It’s almost completely unrelated to the registry (or ACL modification). One could write a program which doesn’t lookup any SIDs, opens a key and calls NtSetSecurityObject… Are you sure this bypass is invalid?

11

Just made a test program (attached). This one shouldn’t use the LSA API at all. After you run it check the ACL of HKEY_LOCAL_MACHINE.

[attachment deleted by admin]

12

Was sure. Because adding protected “file” which mentioned Endymion solved issue with subinacl.

Thanks for this :-TU
I will definitely try it and write back >:-D

13

But it is a coincidence that subinacl happens to use the LSA API for looking up usernames. If you prevent it from doing so, it will fail, but that doesn’t mean setting the security descriptor of the key will be blocked. My test program avoids using the LSA API, so blocking it won’t do anything.

14

wj32

Thank you for attention to this thread!

Your program successfully adds one more entity to HKLM permissions while HKLM* is being in “protected registry keys” of Defense+.

Apparently Defense+ (by the way v3.12) fails to catch it with settings described earlier.
Do you know possible solution to catch it with D+ ? Particular API/COM interface (if added to protected entities D+ would catch it) ?

So protecting LSA API with D+ is useless to prevent unauthorized registry’s permissions modifications? It seems so… :THNK

15

Thanks for providing the missing testcase.

Indeed Regedit was able to alter permissions even with a denied \Device\NamedPipe\lsarpc whereas it was not able to display SID names/alias.

There is no apparent workaround to this other than using a LUA account or equivalent (Drop my rights, HShellExtPack, Run As with a LUA account)

16

Updated (re-wrote) first post.

17

Yes, it’s useless. D+ needs to either deny WRITE_DAC permission to protected keys or hook NtSetSecurityObject.

18

CIS’ developers comments, please.

19

Hi guys,

it will be fixed in the next release.

thanks for your information !!!

eXPerience

20

Thank you for informing us :-TU