Kubernetes RBAC mal configurados no Azure Airflow Podem Expor Todo o Cluster à Exploração

ZNX Postagens

Pesquisadores de segurança cibernética descobriram três pontos fracos de segurança no Azure Data Factory da Microsoft Fluxo de ar Apache integração que, se explorada com sucesso, poderia ter permitido que um invasor obtivesse a capacidade de realizar várias ações secretas, incluindo exfiltração de dados e implantação de malware.

“A exploração dessas falhas pode permitir que os invasores obtenham acesso persistente como administradores de sombra em todo o cluster do Airflow Azure Kubernetes Service (AKS)” Palo Alto Networks Unit 42 disse em uma análise publicada no início deste mês.

As vulnerabilidades, embora classificadas como de baixa gravidade pela Microsoft, estão listadas abaixo –

  • Kubernetes RBAC mal configurados no cluster do Airflow
  • Manipulação secreta mal configurada do serviço interno de Genebra do Azure
  • Autenticação fraca para Genebra

Além de obter acesso não autorizado, o invasor pode aproveitar as falhas no serviço de Genebra para potencialmente adulterar dados de log ou enviar logs falsos para evitar levantar suspeitas ao criar novos pods ou contas.

A técnica de acesso inicial envolve a elaboração de um grafo acíclico direcionado (DAG). Arquivo e enviá-lo para um repositório privado do GitHub conectado ao cluster do Airflow ou alterar um arquivo DAG existente. O objetivo final é lançar um shell reverso para um servidor externo assim que for importado.

Para fazer isso, o agente de ameaças terá que primeiro obter permissões de gravação para a conta de armazenamento que contém arquivos DAG, utilizando um principal de serviço comprometido ou um token de assinatura de acesso compartilhado (SAS) para os arquivos. Alternativamente, eles podem invadir um repositório Git usando credenciais vazadas.

Embora o shell obtido dessa maneira tenha sido executado no contexto do usuário do Airflow em um pod do Kubernetes com permissões mínimas, uma análise mais aprofundada identificou uma conta de serviço com permissões de administrador de cluster conectadas ao pod do corredor do Airflow.

O invasor poderia então aproveitar o acesso root à máquina virtual (VM) do host para se aprofundar no ambiente de nuvem, obter acesso não autorizado a recursos internos gerenciados pelo Azure, incluindo o Geneva, alguns dos quais concedem acesso de gravação a contas de armazenamento e hubs de eventos.

“Isso significa que um atacante sofisticado poderia modificar um ambiente vulnerável do Airflow”, disseram os pesquisadores de segurança Ofir Balassiano e David Orlovsky. “Por exemplo, um invasor pode criar novos pods e novas contas de serviço. Eles também podem aplicar alterações nos próprios nós do cluster e, em seguida, enviar logs falsos para Genebra sem disparar um alarme.”

“Esta questão destaca a importância de gerenciar cuidadosamente as permissões de serviço para impedir o acesso não autorizado. Ele também destaca a importância de monitorar as operações de serviços críticos de terceiros para impedir esse acesso.”

A divulgação ocorre quando o Datadog Security Labs detalhou um cenário de escalonamento de privilégios em Vault Chave Azure isso pode permitir que os usuários com a função Key Vault Contributor leiam ou modifiquem o conteúdo do Key Vault, como chaves de API, senhas, certificados de autenticação e tokens SAS do Armazenamento do Azure.

O problema é que, enquanto um usuário com a função Key Vault Contributor não tinha acesso direto aos dados do Key Vault em um cofre de chaves configurado com políticas de acesso, descobriu-se que a função vinha com permissões para se adicionar às políticas de acesso do Key Vault e acessar os dados do Key Vault, ignorando efetivamente a restrição.

“Uma atualização de política pode conter a capacidade de listar, visualizar, atualizar e geralmente gerenciar os dados dentro do cofre de chaves”, disse Katie Knowles, pesquisadora de segurança disse. “Isso criou um cenário em que um usuário com a função Key Vault Contributor poderia obter acesso a todos os dados do Key Vault, apesar de não ter permissão [Role-Based Access Control] para gerenciar permissões ou visualizar dados.”

A Microsoft tem desde então atualizou sua documentação para enfatizar o risco da política de acesso, afirmando: “Para impedir o acesso não autorizado e o gerenciamento de seus cofres de chaves, chaves, segredos e certificados, é essencial limitar o acesso à função do Colaborador a cofres de chaves no modelo de permissão da Política de Acesso.”

O desenvolvimento também segue a descoberta de um problema com o registro do Amazon Bedrock CloudTrail que dificultou a diferenciação de consultas maliciosas de consultas legítimas feitas em grandes modelos de linguagem (LLMs), permitindo que os malfeitores realizassem reconhecimento sem levantar nenhum alerta.

“Especificamente, as chamadas falhadas da API Bedrock foram registradas da mesma maneira que as chamadas bem-sucedidas, sem fornecer nenhum código de erro específico”, disse o pesquisador da Sysdig, Alessandro Brucato disse.

“A falta de informações de erro nas respostas da API pode dificultar os esforços de detecção, gerando falsos positivos nos logs do CloudTrail. Sem esse detalhe, as ferramentas de segurança podem interpretar erroneamente a atividade normal como suspeita, levando a alertas desnecessários e supervisão potencial de ameaças genuínas”

Fonte: https://thehackernews.com/