Cybersecurity researchers have discovered three vulnerabilities in Microsoft’s Azure Data Factory Apache Airflow an integration that, if successfully exploited, could allow an attacker to perform a variety of covert activities, including data theft and malware deployment.
“Exploitation of these flaws could allow attackers to gain permanent access as shadow administrators to an entire Airflow Azure Kubernetes Service (AKS) cluster,” Palo Alto Networks Unit 42 said in an analysis published earlier this month.
The vulnerabilities, though classified as low severity by Microsoft, are listed below –
- Incorrectly configured Kubernetes RBAC in Airflow cluster
- Incorrect configuration of Azure Azure internal service secret handling and
- Weak authentication for Geneva
In addition to gaining unauthorized access, an attacker could exploit flaws in the Geneva service to potentially falsify log data or send fake logs to avoid suspicion when creating new packages or accounts.
The initial access technique involves creating a directed acyclic graph (DAY) and upload it to a private GitHub repository connected to the Airflow cluster, or modify an existing DAG file. The ultimate goal is to run the reverse shell on the external server once it’s imported.
To do this, a threat actor would first need to obtain write permission to the storage account containing the DAG files using a compromised service principal or file sharing signature (SAS) token. Also, they can hack a Git repository using a credential leak.
Although the resulting shell was detected as running in the context of the Airflow user in a Kubernetes module with minimal permissions, further analysis revealed a service account with cluster administrator permissions connected to the Airflow launcher.
This misconfiguration, combined with the fact that the module could be accessed over the Internet, meant that an attacker could download the Kubernetes command-line tool kubectl and ultimately gain full control of the entire cluster by “deploying a privileged package and breaking into the base node.”
An attacker can then use root access to the host virtual machine (VM) to delve into the cloud environment, gain unauthorized access to internal resources managed by Azure, including Geneva, some of which provide write access to storage accounts and hubs events.
“This means that a sophisticated attacker could modify Airflow’s vulnerable environment,” said security researchers Ofir Balasiano and David Orlovsky. “For example, an attacker can create new packages and new service accounts. They can also apply the 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 critical third-party services to prevent such access.”
The disclosure came as Datadog Security Labs detailed an escalation scenario Azure Keystore which can allow users with the Key Vault Contributor role to read or modify Key Vault content such as API keys, passwords, authentication certificates, and SAS tokens for Azure storage.
Issue Key data Vault, effectively bypassing the restriction.
“A policy update may contain the ability to list, view, update, and generally manage data in the keystore,” security researcher Cathy Knowles said. “This created a scenario where a user with the Key Vault Contributor role could access all Key Vault data despite not having permission (Role-Based Access Control) to manage permissions or view the data.”
Microsoft since then updated its documentation to highlight the access policy risk, stating: “To prevent unauthorized access and management of your keystores, keys, secrets, and certificates, it is critical to restrict member role access to keystores according to the access policy’s permission model.”
The development also follows the discovery of an issue with Amazon Bedrock CloudTrail logging that made it difficult to distinguish between legitimate and malicious requests made to large language models (LLMs), allowing attackers to conduct reconnaissance without triggering any warning.
“In particular, failed calls to the Bedrock API were logged in the same way as successful calls, without specifying any specific error codes,” Alessandro Brucata, researcher at Sysdig. said.
“Lack of error information in API responses can hinder detection efforts by generating false positives in CloudTrail logs. Without this detail, security tools can misinterpret normal activity as suspicious, leading to unnecessary alerts and potential monitoring of genuine threats.”
