Cybersecurityonderzoekers hebben een beveiligingslek ontdekt dat gevolgen heeft voor Microsoft Azure Kubernetes Services. Als dit lek succesvol wordt misbruikt, kan een aanvaller zijn rechten verhogen en toegang krijgen tot inloggegevens voor services die door het cluster worden gebruikt.
“Een aanvaller die opdrachten uitvoert in een Pod die wordt uitgevoerd binnen een getroffen Azure Kubernetes Services-cluster, kan de configuratie downloaden die is gebruikt om het clusterknooppunt in te richten, de TLS-bootstraptokens (Transport Layer Security) extraheren en een TLS-bootstrapaanval uitvoeren om alle geheimen binnen het cluster te lezen”, aldus Mandiant, eigendom van Google.
Clusters die “Azure CNI” gebruiken voor de “Netwerkconfiguratie” en “Azure” voor het “Netwerkbeleid” blijken te worden beïnvloed door de privilege-escalatiebug. Microsoft heeft het probleem inmiddels aangepakt na responsible disclosure.
De aanvalstechniek die het bedrijf voor bedreigingsinformatie heeft bedacht, draait om het verkrijgen van toegang tot een weinig bekend onderdeel genaamd Azure WireServer om een sleutel op te vragen die wordt gebruikt om beveiligde instellingswaarden te versleutelen (“wireserver.key”) en deze te gebruiken om een provisioningscript te decoderen dat verschillende geheimen bevat, zoals de volgende:
- KUBELET_CLIENT_CONTENT (Algemene Node TLS-sleutel)
- KUBELET_CLIENT_CERT_CONTENT (Generiek Node TLS-certificaat)
- KUBELET_CA_CRT (Kubernetes CA-certificaat)
- TLS_BOOTSTRAP_TOKEN (TLS Bootstrap-authenticatietoken)
“KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT en KUBELET_CA_CRT kunnen Base64-gedecodeerd en naar schijf geschreven worden voor gebruik met de Kubernetes-opdrachtregeltool kubectl om authenticatie bij het cluster te verkrijgen”, aldus onderzoekers Nick McClendon, Daniel McNamara en Jacob Paullus.
“Dit account heeft minimale Kubernetes-machtigingen in recent geïmplementeerde Azure Kubernetes Service (AKS)-clusters, maar kan wel knooppunten in het cluster weergeven.”
TLS_BOOTSTRAP_TOKEN kan daarentegen worden gebruikt om een TLS bootstrap-aanval mogelijk te maken en uiteindelijk toegang te krijgen tot alle geheimen die worden gebruikt door workloads die worden uitgevoerd. De aanval vereist niet dat de pod als root wordt uitgevoerd.
“Het aannemen van een proces om restrictieve NetworkPolicies te creëren die alleen toegang verlenen tot vereiste services voorkomt deze hele aanvalsklasse,” zei Mandiant. “Privilege-escalatie via een ongedocumenteerde service wordt voorkomen wanneer de service helemaal niet toegankelijk is.”
De onthulling volgt op een nieuw, zeer ernstig Kubernetes-lek (CVE-2024-7646, CVSS-score: 8,8) dat de ingress-nginx-controller treft en kwaadwillenden in staat kan stellen om ongeautoriseerde toegang te krijgen tot gevoelige clusterbronnen.
“Het beveiligingslek is het gevolg van een fout in de manier waarop ingress-nginx annotaties op Ingress-objecten valideert”, aldus beveiligingsonderzoeker Amit Schendel.
“De kwetsbaarheid stelt een aanvaller in staat om schadelijke inhoud in bepaalde annotaties te injecteren, waarbij de beoogde validatiecontroles worden omzeild. Dit kan leiden tot willekeurige opdrachtinjectie en mogelijke toegang tot de inloggegevens van de ingress-nginx-controller, die in standaardconfiguraties toegang heeft tot alle geheimen in het cluster.”
Het volgt ook op de ontdekking van een ontwerpfout in het Kubernetes git-sync-project dat opdrachtinjectie in Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) en Linode mogelijk zou kunnen maken.
“Deze ontwerpfout kan leiden tot data-exfiltratie van elk bestand in de pod (inclusief serviceaccounttokens) of tot uitvoering van opdrachten met de gebruikersrechten git_sync”, aldus Akamai-onderzoeker Tomer Peled. “Om de fout te misbruiken, hoeft een aanvaller alleen maar een YAML-bestand op het cluster toe te passen, wat een bewerking met lage rechten is.”
Er zijn geen patches gepland voor deze kwetsbaarheid. Daarom is het van groot belang dat organisaties hun git-sync pods controleren om te bepalen welke opdrachten worden uitgevoerd.
“Beide vectoren zijn te wijten aan een gebrek aan input sanitization, wat de noodzaak benadrukt van een robuuste verdediging met betrekking tot user input sanitization,” zei Peled. “Blue teamleden moeten op hun hoede zijn voor ongewoon gedrag van de gitsync-gebruiker in hun organisaties.”
