Microsoft has updated its mitigation guidance for CVE-2024-30080 – a critical remote code execution (RCE) server side vulnerability that needs no authentication to exploit – as the security researcher who reported it shared more details on the attack path for the CVSS 9.8-rated bug.
CVE-2024-30080 is a Microsoft Message Queuing (MSMQ) vulnerability that Microsoft marked as “exploitation more likely” on June’s Patch Tuesday. (MSMQ is a distributed messaging system lets applications talk via message queues that are reachable both locally and remotely. It is not enabled by default, but it is used by applications including some operational technology even if it is, strictly speaking, now “dead”...)
Analysis by the Shadow Server Foundation suggests that 256,000 devices are publicly exposed and hence potentially vulnerable to CVE-2024-30080. The security researcher at China’s Kunlun Labs who reported the vulnerability has now shared a top-level analysis, revealing in brief that the bug (a race condition that leads to a use-after-free) exists in the mqise.dll executable, in a function named RPCToServer.
Whilst there was some concern that the vulnerability was wormable – i.e. malware exploiting it could potentially propagate automatically without a need to conduct authentication on a system – an earlier critical MSMQ vulnerability in 2023 dubbed “QueueJumper” and allocated CVE-2023-21224, despite its apparent severity, did not get exploited.
CheckPoint, revealing that bug in April 2023, said “an attacker could gain control of the process through just one packet to the 1801/tcp port with the exploit, triggering the vulnerability” but a full exploit POC failed to land and the bug never made CISA’s “known exploited” list (The Stack just checked anew.) Either MSMQ is too arcane for many black hats to get their heads around or exposed credentials are just so widely available now that reverse engineering a patch for a somewhat obscure messaging system does not seem worth the investment of time for most. (If any Red Teamers exploit MSMQ bugs in the wild, we’d love to hear from you!)
Given the criticality, some more attack path details and Microsoft’s warning that exploitation may be likely, patching/mitigating sounds judicious regardless. The “mitigation” details are now essentially to patch or disable: Microsoft says in that patch section that “the Windows message queuing service, which is a Windows component, needs to be enabled for a system to be exploitable by this vulnerability. This feature can be added via the Control Panel. To determine if your system is susceptible, check to see if the MSMQ HTTP-Support feature is enabled and if there is a service running named Message Queuing on the machine.”
