Cybersecurity researchers have uncovered three security weaknesses in Microsoft’s Azure Data Factory Apache Airflow integration that, if successfully exploited, could have allowed an attacker to gain the ability to conduct various covert actions, including data exfiltration and malware deployment.
“Exploiting these flaws could allow attackers to gain persistent access as shadow administrators over the entire Airflow Azure Kubernetes Service (AKS) cluster,” Palo Alto Networks Unit 42 said in an analysis published earlier this month.
The vulnerabilities, albeit classified as low severity by Microsoft, are listed below –
Besides obtaining unauthorized access, the attacker could take advantage of the flaws in the Geneva service to potentially tamper with log data or send fake logs to avoid raising suspicion when creating new pods or accounts.
The initial access technique involves crafting a directed acyclic graph (DAG) file and uploading it to a private GitHub repository connected to the Airflow cluster, or altering an existing DAG file. The end goal is to launch a reverse shell to an external server as soon as it’s imported.
To pull this off, the threat actor will have to first gain write permissions to the storage account containing DAG files by utilizing a compromised service principal or a shared access signature (SAS) token for the files. Alternatively, they can break into a Git repository using leaked credentials.
Although the shell obtained in this manner was found to be running under the context of the Airflow user in a Kubernetes pod with minimal permissions, further analysis identified a service account with cluster-admin permissions connected to the Airflow runner pod.
This misconfiguration, coupled with the fact that the pod could be reachable over the internet, meant that the attacker could download the Kubernetes command-line tool kubectl and ultimately take full control of the entire cluster by “deploying a privileged pod and breaking out onto the underlying node.”
The attacker could then leverage the root access to the host virtual machine (VM) to burrow deeper into the cloud environment, gain unauthorized access to Azure-managed internal resources, including Geneva, some of which grant write access to storage accounts and event hubs.
“This means a sophisticated attacker could modify a vulnerable Airflow environment,” security researchers Ofir Balassiano and David Orlovsky said. “For example, an attacker could create new pods and new service accounts. They could also apply changes to the cluster nodes themselves and then send fake logs to Geneva without raising an alarm.”
“This issue highlights the importance of carefully managing service permissions to prevent unauthorized access. It also highlights the importance of monitoring the operations of critical third-party services to prevent such access.”
The disclosure comes as the Datadog Security Labs detailed a privilege escalation scenario in Azure Key Vault that could permit users with the Key Vault Contributor role to read or modify Key Vault contents, such as API keys, passwords, authentication certificates, and Azure Storage SAS tokens.
The problem is that while a user with the Key Vault Contributor role had no direct access to Key Vault data over a key vault configured with access policies, it was discovered that the role did come with permissions to add itself to Key Vault access policies and access Key Vault data, effectively bypassing the restriction.
“A policy update could contain the ability to list, view, update and generally manage the data within the key vault,” security researcher Katie Knowles said. “This created a scenario where a user with the Key Vault Contributor role could gain access to all Key Vault data, despite having no [Role-Based Access Control] permission to manage permissions or view data.”
Microsoft has since updated its documentation to emphasize the access policy risk, stating: “To prevent unauthorized access and management of your key vaults, keys, secrets, and certificates, it’s essential to limit Contributor role access to key vaults under the Access Policy permission model.”
The development also follows the discovery of an issue with Amazon Bedrock CloudTrail logging that made it difficult to differentiate malicious queries from legitimate ones made to large language models (LLMs), thereby allowing bad actors to conduct reconnaissance without raising any alert.
“Specifically, failed Bedrock API calls were logged in the same manner as successful calls, without providing any specific error codes,” Sysdig researcher Alessandro Brucato said.
“The lack of error information in API responses may hinder detection efforts by generating false positives in CloudTrail logs. Without this detail, security tools may misinterpret normal activity as suspicious, leading to unnecessary alerts and potential oversight of genuine threats.”
