CyBourn is launching the Cybersecurity Express, bringing you trending subjects in sizeable chunks! Hop aboard and let us take you on a journey of what’s happened during the past days in the trilling world of Cybersecurity. Mind the gap and keep your limbs and heads inside the vehicle at all times, because we are passing at high speed through attacks, zero-day vulnerabilities and exciting news.
We are now arriving at our first destination:
You may be familiar with Microsoft disclosed vulnerability CVE-2021-40444, in which Windows Server 2008 through 2019 and Windows 8.1 through 10 systems are susceptible to attack via a malicious ActiveX control used by a Microsoft Office document that hosts the MSHTML browser rendering engine.
A patch has been released on September 14th, this mitigation method being advised above all other workarounds proposed by specialists so far: having “protected mode” on, modifying registry keys etc. The widows updates are a must, after the mitigations proposed by Microsoft were bypassed successfully and the attack was carried out even with files that have no MoTW (Mark of the Web) flag, for which “protected mode” does not apply.
We can only hope this patch put an end to the ActiveX nightmare for good and eliminates all other bypass possibilities. See the vulnerability official page, “Security Updates” section for more information on the cumulative updates, which also address other 60 vulnerabilities (86 including Microsoft Edge), fixing one bonus unexploited zero day: CVE-2021-36968 – Windows DNS Elevation of Privilege Vulnerability
Impacting Azure Linux virtual machines that use the Open Management Infrastructure (OMI). This utility is intended to function similarly to Windows WMI service allowing for collection of logs and remote management commands. OMI is built to require authentication, binding commands to a user ID, but a bug allows for malformed requests that manage to skip the authentication phase and are interpreted as coming from root. Even worse, the tool can be configured for remote management, whilst running an HTTPS server on port 5986 which can be connected to with a standard HTTPS client like curl and receives XML-derived SOAP protocol commands. A compromised system will allow the attacker to run arbitrary commands as root using OMI syntax. More so, if OMI is configured to listen on a network port, the attacker can use that get control of other virtual machines on the same network.
CVEs issued being tied to this OMI utility exploit:
Not all hope is lost, to mitigate this threat you can use your platform’s package tool to upgrade OMI, with commands such as: “sudo apt-get install omi”, to the the latest version v1.6.8-1 of the software. You can first check to see if you are vulnerable by connecting to your Azure VMs and run the commands below to see the OMI version installed:
In the cases where OMI listens on TCP ports, limiting access to these ports via Linux firewall, is advised. A global firewall deny rule, with allow rules only for specific machines that need to access a given service is always a good measure.
This may be old news, as it was reported to Microsoft back in August, still poses a major threat, because any Cosmos DB account that had Jupyter Notebook enabled could be compromised. Microsoft security teams took immediate action to disable the notebook service, right after the critical vulnerability was reported to them. Remediated or not, users are still required to perform mitigation steps due to the risk that their Cosmos DB primary keys were obtained by malicious actors.
Using a chain of vulnerabilities in the Jupyter Notebook feature of Cosmos DB, an attacker can query information about the target, obtaining a set of credentials that can be used to view, modify, and delete data in the Cosmos DB account.
Follow this Microsoft guide to regenerate your Cosmos DB Primary Key, should this mitigation be applicable in your organization.
Approaching our final stop:
Microsoft keeps making the headlines, with yet another critical vulnerability discovered, “the first cross-account container takeover in the public cloud” researchers say.
A malicious Azure actor could compromise the multitenant Kubernetes clusters hosting ACI, establishing full control over other users’ containers, enabling him to steal customer secrets and images deployed to the platform, and possibly abuse ACI’s infrastructure for cryptomining. By deploying a WhoC to ACI, researches managed to read the container runtime and were shocked to find runc version v1.0.0-rc2, released way back in October 2016, known to be vulnerable to at least two container breakout CVEs. All that was left was to modify a PoC container image and deployed it to ACI to get a reverse shell running as root on the Kubernetes node. Once here, they monitored the traffic on Kubelet port 10250 for a request that includes a JWT token in the authorization header. Used the az container exec to run a command on the uploaded container, resulting in the bridge pod sending an exec request to the Kubelet on the compromised node. Finally, back on the node, they extracted the bridge token from the request’s authorization header and used it to pop a shell on the api-server. Voilà!
Consequently, Microsoft released a patch to ACI. The bridge pod no longer sends its service account token to nodes when issuing exec requests, preventing the reported cross-tenant attack. Also the bridge now verifies that a pod’s status.hostIP field is a valid IP before sending an exec request.
It’s been a rough month for Microsoft, but this is the way of the digital world today. Before we end, here are some mention worthy events:
Thank you for riding in the Cybersecurity Express, please don’t forget to take any personal belongings and stay safe by installing updates and patches regularly. Thank you for hitching a ride on the CyBourn Cybersecurity Express. Hope to have you on board for our next departure, soon!