Onderzoekers op het gebied van cyberbeveiliging hebben drie zwakke punten in de beveiliging van de Azure Data Factory Apache Airflow-integratie van Microsoft ontdekt die, indien succesvol misbruikt, een aanvaller in staat hadden kunnen stellen verschillende geheime acties uit te voeren, waaronder data-exfiltratie en de implementatie van malware.
“Door deze fouten te misbruiken kunnen aanvallers blijvende toegang krijgen als schaduwbeheerders tot het gehele Airflow Azure Kubernetes Service (AKS) cluster”, aldus Palo Alto Networks Unit 42 in een analyse die eerder deze maand werd gepubliceerd.
De kwetsbaarheden, hoewel door Microsoft als laag ernstig geclassificeerd, worden hieronder vermeld:
- Verkeerd geconfigureerde Kubernetes RBAC in Airflow-cluster
- Verkeerd geconfigureerde geheime verwerking van de interne Genève-service van Azure, en
- Zwakke authenticatie voor Genève
Naast het verkrijgen van ongeautoriseerde toegang, zou de aanvaller misbruik kunnen maken van de tekortkomingen in de dienst van Genève om mogelijk met loggegevens te knoeien of valse logs te verzenden om te voorkomen dat er argwaan ontstaat bij het maken van nieuwe pods of accounts.
De initiële toegangstechniek omvat het maken van een gericht acyclisch grafiekbestand (DAG) en het uploaden ervan naar een privé GitHub-opslagplaats die is verbonden met het Airflow-cluster, of het wijzigen van een bestaand DAG-bestand. Het einddoel is om een reverse shell naar een externe server te lanceren zodra deze is geïmporteerd.
Om dit voor elkaar te krijgen, moet de bedreigingsactor eerst schrijfrechten verkrijgen voor het opslagaccount met DAG-bestanden door gebruik te maken van een gecompromitteerde service-principal of een SAS-token (Shared Access Signature) voor de bestanden. Als alternatief kunnen ze inbreken in een Git-repository met behulp van gelekte inloggegevens.
Hoewel bleek dat de op deze manier verkregen shell draaide onder de context van de Airflow-gebruiker in een Kubernetes-pod met minimale machtigingen, identificeerde verdere analyse een serviceaccount met clusterbeheerdersmachtigingen die was verbonden met de Airflow runner-pod.
Deze verkeerde configuratie, gekoppeld aan het feit dat de pod via internet bereikbaar kon zijn, betekende dat de aanvaller de Kubernetes-opdrachtregeltool kubectl kon downloaden en uiteindelijk de volledige controle over het hele cluster kon overnemen door “een geprivilegieerde pod in te zetten en uit te breken op de onderliggende knooppunt.”
De aanvaller kan vervolgens de root-toegang tot de virtuele hostmachine (VM) gebruiken om dieper in de cloudomgeving te duiken en ongeautoriseerde toegang te krijgen tot door Azure beheerde interne bronnen, waaronder Geneva, waarvan sommige schrijftoegang verlenen tot opslagaccounts en event hubs.
“Dit betekent dat een geavanceerde aanvaller een kwetsbare Airflow-omgeving kan wijzigen”, aldus beveiligingsonderzoekers Ofir Balassiano en David Orlovsky. “Een aanvaller kan bijvoorbeeld nieuwe pods en nieuwe serviceaccounts aanmaken. Ook kan hij zelf wijzigingen aanbrengen in de clusternodes en vervolgens valse logs naar Genève sturen zonder dat er alarm wordt geslagen.”
“Dit probleem benadrukt het belang van het zorgvuldig beheren van servicemachtigingen om ongeoorloofde toegang te voorkomen. Het benadrukt ook het belang van het monitoren van de activiteiten van kritieke services van derden om dergelijke toegang te voorkomen.”
De openbaarmaking komt op het moment dat Datadog Security Labs een scenario voor escalatie van bevoegdheden in Azure Key Vault heeft beschreven waarmee gebruikers met de rol Key Vault Contributor de inhoud van Key Vault kunnen lezen of wijzigen, zoals API-sleutels, wachtwoorden, authenticatiecertificaten en Azure Storage SAS-tokens .
Het probleem is dat hoewel een gebruiker met de rol Key Vault Inzender geen directe toegang had tot Key Vault-gegevens via een sleutelkluis die was geconfigureerd met toegangsbeleid, er werd ontdekt dat de rol wel machtigingen had om zichzelf toe te voegen aan het Key Vault-toegangsbeleid en toegang Key Vault-gegevens, waardoor de beperking effectief wordt omzeild.
“Een beleidsupdate zou de mogelijkheid kunnen bevatten om de gegevens in de sleutelkluis op te sommen, te bekijken, bij te werken en in het algemeen te beheren”, aldus beveiligingsonderzoeker Katie Knowles. “Hierdoor ontstond een scenario waarin een gebruiker met de rol Key Vault Inzender toegang kon krijgen tot alle Key Vault-gegevens, ondanks dat hij geen (op rollen gebaseerde toegangscontrole) toestemming had om machtigingen te beheren of gegevens te bekijken.”
Microsoft heeft sindsdien zijn documentatie bijgewerkt om het risico van het toegangsbeleid te benadrukken en stelt: “Om ongeautoriseerde toegang en beheer van uw sleutelkluizen, sleutels, geheimen en certificaten te voorkomen, is het essentieel om de toegang van de rol Inzender tot sleutelkluizen te beperken onder het toestemmingsmodel voor toegangsbeleid .”
De ontwikkeling volgt ook op de ontdekking van een probleem met Amazon Bedrock CloudTrail-logboekregistratie, waardoor het moeilijk werd om kwaadaardige zoekopdrachten te onderscheiden van legitieme zoekopdrachten in grote taalmodellen (LLM’s), waardoor kwaadwillende actoren verkenningen konden uitvoeren zonder enige waarschuwing te genereren.
“In het bijzonder werden mislukte Bedrock API-oproepen op dezelfde manier geregistreerd als succesvolle oproepen, zonder enige specifieke foutcodes op te geven”, aldus Sysdig-onderzoeker Alessandro Brucato.
“Het gebrek aan foutinformatie in API-reacties kan detectie-inspanningen belemmeren door valse positieven te genereren in CloudTrail-logboeken. Zonder dit detail kunnen beveiligingstools normale activiteiten verkeerd als verdacht interpreteren, wat leidt tot onnodige waarschuwingen en mogelijk toezicht op echte bedreigingen.”
