<story><title>Cross-Account Container Takeover in Azure Container Instances</title><url>https://unit42.paloaltonetworks.com/azure-container-instances/</url></story><parent_chain></parent_chain><comment><author>ctvo</author><text>What is going on at Azure?! First the Cosmos DB vulnerability [1] three weeks ago and now this?! It’s starting to look like a systemic issue at Microsoft.&lt;p&gt;tl;dr&lt;p&gt;- Microsoft uses an old version of runc (from 20216), with known vulnerabilities. runc is a container runtime. Researchers, using work from 2019, were able to break out of the container into the Kubernetes node.&lt;p&gt;- Microsoft, to fix a known vulnerability (instead of patching!) in Kubernetes with `kubectl exec` has a custom solution (`bridge-pod`) that handles sending `kubectl exec` commands to nodes.&lt;p&gt;- In Microsoft&amp;#x27;s custom solution, the HTTP request to run `kubectl exec` on the node sent from `bridge-pod` includes an access token with overly broad privileges in the header (not necessary in this case). If you monitor traffic once you&amp;#x27;ve escape the container on the node, you can extract this access token if you send a command to your own container from the Azure CLI.&lt;p&gt;- Access token grants `pod&amp;#x2F;exec` rights to anything in the cluster&lt;p&gt;The egregious part is the `bridge-pod` and it&amp;#x27;s implementation. This wasn&amp;#x27;t just outdated software left unpatched, it was badly implemented hacks to work around their inability to patch.&lt;p&gt;1 - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.wiz.io&amp;#x2F;blog&amp;#x2F;chaosdb-how-we-hacked-thousands-of-azure-customers-databases&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.wiz.io&amp;#x2F;blog&amp;#x2F;chaosdb-how-we-hacked-thousands-of-a...&lt;/a&gt;</text></comment>
<story><title>Cross-Account Container Takeover in Azure Container Instances</title><url>https://unit42.paloaltonetworks.com/azure-container-instances/</url></story><parent_chain></parent_chain><comment><author>dlor</author><text>The root cause was a chain of known exploits due to very out of date software:&lt;p&gt;* RunC v1.0.0-rc2 was released on Oct. 1, 2016, and was vulnerable to at least two container breakout CVEs.&lt;p&gt;* ACI was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9. These versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities.&lt;p&gt;Running multitenant workloads in Kubernetes is notoriously difficult, and staying on top of patches is simply table-stakes.</text></comment>