itm4n
commented
2 years ago Hello,
Thank you for your PR! :)
I took some time to look into it and do some research. In the end, I implemented it a bit differently. Since, the recommendation is to configure both SYSVOL and NETLOGON, I considered both values for the check although SYSVOL is the most obvious target for an MitM attack. I also added a test case to make sure that the machine is domain-joined, otherwise this check is irrelevant. Finally, I also considered the RequirePrivacy=0/1, which could also be used in place of RequireIntegrity=0/1.
Side notes:
- In case of a "vuln" check, "compliance" is redundant because the script works like this: in case of a "vuln" check, "items reported = vulnerable = non compliant", and in the case of an "info" check, items are reported whatever the result, hence the "compliance" attribute need.
[System.Environment]::OSVersion.Versionmight not report the actual OS version if PowerShell is loaded through a custom interpreter. Therefore, I implemented my ownGet-WindowsVersionwhich extract the version from the registry.
AdrianVollmer
The vulnerability patched by MS15-011 allows a man in the middle to inject group policies when the DC is polled for updates, because Windows used to not check the file shares identity by default. Starting with Windows 10, the file shares identity is indeed checked by default. They call this "hardened UNC path". However, the hardening had to be explicitely configured for SYSVOL before Windows 10. Also, Administrators can disable the UNC path hardening manually. If they do, privilege escalation to SYSTEM is possible for anyone in a man in the middle position.
This commit adds the Cmdlet Invoke-HardenedUNCPathCheck which reports whether the system is vulnerable.
I rate this medium because a legit DC has to be available and exploitation can be difficult. I have managed to so in the past, but I'm not aware of convenient public exploit.