Windows Vulnerability in COM Objects Trigger RCE To Control The Systems Remotely
\n \t
\n
<\/BR>
\n
\n \t
\n
<\/BR><\/p>\n
James Forshaw of Google Project Zero has shed light on a significant security vulnerability in Windows related to accessing trapped COM objects through the IDispatch interface. <\/p>\n
This research highlights an intriguing bug class that exploits cross-process communication features in object-oriented remoting technologies like COM objects<\/a> and .NET Remoting<\/a>, potentially allowing attackers to execute code in higher-privileged server processes.<\/p>\n The vulnerability stems from the flexibility of remoting technologies that allow objects to be shared between client and server processes. <\/p>\n While designed to simplify the development of cross-boundary services, these features can inadvertently expose unsafe objects. <\/p>\n Forshaw notes<\/a> that if an object is returned and marshaled \u201cby reference,\u201d it remains in the server process, making it vulnerable to exploitation. One such example is XML libraries, which could allow remote code execution by leveraging scripting features.<\/p>\n Specific cases, such as CVE-2019-0555, illustrate how developers assumed safety in certain object implementations, only to inadvertently expose dangerous interfaces. <\/p>\n Another example, CVE-2017-0211, demonstrated how attackers could use the IPropertyBag interface to create arbitrary COM objects in a server\u2019s context, potentially elevating their privileges.<\/p>\n The IDispatch interface\u2014a key part of OLE Automation\u2014enables late binding of COM objects for scripting languages like VBA and JScript. <\/p>\n By leveraging the type library mechanism, attackers can exploit the CreateInstance method in remoted objects to instantiate COM objects within a server\u2019s process. This can be used to gain control over the server, bypassing security boundaries.<\/p>\n Forshaw demonstrated this issue using tools like his OleView.NET PowerShell module<\/a><\/em>, identifying several COM classes exposed through local services. <\/p>\n While investigating specific service classes, such as WaaSRemediation<\/em>, Forshaw explored how these hidden vulnerabilities could be exploited for privilege escalation or injection attacks.<\/p>\n The research took an interesting turn when Forshaw analyzed the WaaSRemediationAgent<\/em> class, a Windows service running as a Protected Process (PPL-Windows). <\/p>\n While Microsoft considers PPL not to be a strict security boundary, it restricts certain tools, like script engines, from being loaded into protected processes. Forshaw proposed and tested a novel injection method targeting the IDispatch-based interface.<\/p>\n By redirecting the COM registration of a vulnerable object (e.g., StdFont) to a malicious class, attackers could potentially inject .NET-based payloads or other harmful code into the protected process. <\/p>\n Forshaw showed how exploiting registry keys and .NET COM reflection could load arbitrary assemblies, enabling code execution.<\/p>\n While the proof-of-concept worked on Windows 10, Forshaw encountered challenges on Windows 11 (24H2). <\/p>\n Microsoft had introduced mitigations, such as cached signing level validations, which blocked libraries that lacked Windows-level signing. <\/p>\n However, Forshaw found a workaround by using a 32-bit version of the type library, proving that the exploit remains viable with enough effort.<\/p>\n Although Forshaw\u2019s research did not directly demonstrate privilege escalation, it highlighted IDispatch interfaces\u2019 risks in remoting technologies. <\/p>\n Attackers with administrative privileges could use the attack method to inject code into a protected process, such as LSASS, or even by standard users if suitable COM servers are exposed.<\/p>\n Forshaw noted that Microsoft has addressed some attack vectors by improving type library validation, but certain areas remain vulnerable.<\/p>\n Notably, while this vulnerability requires significant expertise to exploit, it reinforces the need for secure object handling across process boundaries<\/p>\n Forshaw\u2019s blog underscores how subtle design decisions in remoting technologies can lead to significant security risks. <\/p>\n The ability to trap and manipulate COM objects across privilege boundaries serves as a reminder of how complex systems can be exploited in unintended ways.<\/p>\n While the demonstrated attacks require administrative privileges or careful setup, they highlight an ongoing problem with how object-oriented remoting technologies handle cross-boundary interactions.<\/p>\n As always, users and organizations are encouraged to keep their systems updated and audit services for exposed interfaces to mitigate potential risks. Meanwhile, Microsoft may need to continue refining its mitigations to address these advanced attack vectors.<\/p>\n This research serves as a reminder of the complexities and challenges in securing modern operating systems, particularly when dealing with legacy technologies like COM.<\/p>\n Find this Story Interesting! Follow us on\u00a0Google News<\/a>,\u00a0LinkedIn<\/a>, and\u00a0X<\/a>\u00a0to Get More Instant Updates<\/strong><\/p>\n The post Windows Vulnerability in COM Objects Trigger RCE To Control The Systems Remotely<\/a> appeared first on Cyber Security News<\/a>.<\/p>\n<\/div>\nUnderstanding the Trapped Object Bug Class<\/strong><\/h2>\n
The Role of IDispatch and Type Libraries<\/strong><\/h2>\n
PS> $cls = Get-ComClass -Service\n\nPS> $cls | % { Get-ComInterface -Class $_ | Out-Null }\n\nPS> $cls | ? { $true -in $_.Interfaces.InterfaceEntry.IsDispatch } | \n\n Select Name, Clsid\n\nName Clsid\n\n---- -----\n\nWaaSRemediation 72566e27-1abb-4eb3-b4f0-eb431cb1cb32\n\nSearch Gathering Manager 9e175b68-f52a-11d8-b9a5-505054503030\n\nSearch Gatherer Notification 9e175b6d-f52a-11d8-b9a5-505054503030\n\nAutomaticUpdates bfe18e9c-6d87-4450-b37c-e02f0b373803\n\nMicrosoft.SyncShare.SyncShareFactory Class da1c0281-456b-4f14-a46d-8ed2e21a866f<\/code><\/pre>\nInjection into Protected Processes<\/strong><\/h2>\n
PS> $obj = New-ComObject -Clsid 72566e27-1abb-4eb3-b4f0-eb431cb1cb32\n\nPS> $lib = Import-ComTypeLib -Object $obj\n\nPS> Get-ComObjRef $lib.Instance | Select ProcessId, ProcessName\n\nProcessId ProcessName\n\n--------- -----------\n\n 27020 svchost.exe\n\n\nPS> $parsed = $lib.Parse()\n\nPS> $parsed\n\nName Version TypeLibId\n\n---- -------- ---------\n\nWaaSRemediationLib 1.0 3ff1aab8-f3d8-11d4-825d-00104b3646c0\n\n\nPS> $parsed.Classes | Select Name, Uuid\n\nName Uuid\n\n---- ----\n\nWaaSRemediationAgent 72566e27-1abb-4eb3-b4f0-eb431cb1cb32\n\nWaaSProtectedSettingsProvider 9ea82395-e31b-41ca-8df7-ec1cee7194df<\/code><\/pre>\nMitigations and Implications<\/strong><\/h2>\n