In the first of this 3-part blog series, we covered the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled.
In this 2nd post we try to abuse applications that do not work well with CS changes, abusing years of “normalization” assumptions.
It is worth noting that the impact of this change will vary depending on the target folder.
Out of the box, Windows provides a tool to change CS information by invoking the underlying API NtSetFileInformation with FILE_CASE_SENSITIVE_INFORMATION flags.
This tool contains several checks at user-mode level to restrict the target folder but, as usual, it can be easily bypassed using different path combinations. It is possible to create a tool or invoke the API from PowerShell to remove these checks.
Let us go over the following scenarios:
Changing ROOT drive CS:
fsutil restrictions will be bypassed and most of the console will not work unless you specify full paths (mostly due to environment variables broken on case-sensitiveness).
Combinations to bypass this check include:
\?C: (by drive letter with long path)
\.BootPartition\ (by partition)
\?Volume{3fb4edf7-edf1-4083-84f8-7fbca215bfee} (volume id)
Change “protected folders” CS.
For some folders is not enough to be Administrator, but to have other type of ACL’s instead.
TrustedInstaller has the required permissions to do so and… you just need Admin permissions to change the service path:
If you change Windows folder case sensitiveness by using the same technique, Windows will not boot anymore.
These scenarios introduce new une ..
Support the originator by clicking the read the rest link below.
