Microsoft corrige 4 falhas SSRF em serviços de nuvem separados do Azure

Views: 243
0 0
Read Time:4 Minute, 49 Second

A Microsoft corrigiu vulnerabilidades em quatro serviços separados de sua plataforma de nuvem Azure, dois dos quais poderiam permitir que invasores executassem um ataque de falsificação de solicitação do lado do servidor (SSRF) – e, portanto, potencialmente executassem a execução remota de código – mesmo sem autenticação para uma conta legítima, pesquisadores descobriram.

Pesquisadores da Orca Security identificaram quatro serviços do Azure vulneráveis ​​ao SSRF – Azure API Management, Azure Functions, Azure Machine Learning e Azure Digital Twins, revelaram em uma postagem de blog publicada em 17 de janeiro . Além disso, eles conseguiram explorar as falhas no Azure Functions e no Azure Digital Twins enviando solicitações em nome do servidor, mesmo sem ter que se autenticar em uma conta do Azure, disseram eles.

Um SSRF permite que um invasor abuse de um aplicativo do lado do servidor, fazendo solicitações para ler ou atualizar recursos internos, bem como enviar dados para fontes externas. Isso pode permitir uma série de atividades disruptivas na rede, inclusive para que agentes de ameaças lancem vários ataques.  

Esse tipo de ataque pode ser particularmente perigoso em um ambiente de nuvem se os invasores puderem usá-lo para acessar o Cloud Instance Metadata Service, ou IMDS, do host, “que expõe informações detalhadas sobre as instâncias – incluindo nome do host, grupo de segurança, endereço MAC e nome do usuário dados”, explicou Lidor Ben Shitrit, pesquisador de segurança em nuvem da Orca Security, na postagem do blog. Isso permite que os invasores recuperem tokens, movam para outro host e até mesmo executem código, acrescentou.

Mitigações de SSRF integradas

Felizmente, no caso das vulnerabilidades do SSRF descobertas no Azure , os pesquisadores não conseguiram explorá-las para alcançar os pontos de extremidade do IMDS graças a várias atenuações do SSRF — incluindo a definição de requisitos específicos para acessar o ponto de extremidade do IMDS e exigir um “cabeçalho de identidade” para o serviço de aplicativo e o Azure Funções – que a Microsoft já implementou em seu ambiente de nuvem, disseram eles.

“Ao implementar essas medidas, a Microsoft reduziu significativamente o dano potencial dos ataques SSRF em sua plataforma Azure”, escreveu Shitrit.

No entanto, as falhas ainda podem ter sido exploradas para realizar outras atividades de ameaça, disse ele. Isso inclui a varredura de portas locais e a localização de novos serviços, endpoints e arquivos, “fornecendo informações valiosas sobre servidores e serviços possivelmente vulneráveis ​​para explorar a entrada inicial e a localização de possíveis informações de destino”, escreveu Shitrit na postagem do blog.

“A maior conclusão… é que um serviço de nuvem, se não for devidamente protegido, pode ser explorado por agentes mal-intencionados como um meio de descobrir endpoints internos sensíveis e outros serviços”, disse ele ao Dark Reading. Isso pode resultar em uma violação significativa da segurança da nuvem, diz Shitrit.

Os pesquisadores descobriram as quatro falhas separadamente durante um período de dois meses, entre meados de outubro e meados de dezembro, e divulgaram cada uma delas à Microsoft logo após serem descobertas. Em cada caso, a empresa respondeu rapidamente, demorando entre dias ou semanas para mitigá-los individualmente. No momento, nenhuma outra ação do cliente é necessária e os pesquisadores não viram nenhum sinal de que as falhas foram exploradas na natureza, disse Shitrit.

Potencial completo de SSRF

Existem três tipos de falhas SSRF, disseram os pesquisadores. O SSRF cego permite que um invasor manipule um servidor para fazer solicitações, mas não obtém uma resposta de um servidor, dificultando a determinação do sucesso de um ataque. O SSRF semi-cego é semelhante em sua capacidade de fazer solicitações de servidor, mas um invasor recebe alguma resposta do servidor que permite a coleta limitada de informações no sistema de destino.

As quatro falhas do Azure SSRF identificadas pelos pesquisadores se enquadram na terceira categoria de SSRF, chamada SSRF não cega ou completa – o tipo de cenário de ataque mais potente para um ator de ameaça, disseram os pesquisadores.

Esse tipo de ataque ocorre quando um invasor pode manipular um servidor para fazer solicitações e receber a resposta completa do servidor, permitindo que um invasor reúna mais informações sobre o sistema de destino para potencialmente lançar novos ataques, disse Shitrit.

“Para lhe dar uma ideia de como essas vulnerabilidades são exploráveis, as falhas SSRF não cegas podem ser aproveitadas de várias maneiras diferentes – incluindo SSRF via XXE, SSRF via arquivo SVG, SSRF via proxy, SSRF via renderização em PDF, SSRF via string de consulta vulnerável no URL – e muito mais”, escreveu ele na postagem do blog.

Proteção e Mitigação

Não importa que tipo de vulnerabilidade SSRF esteja presente em um servidor, cada um deve ser tratado com seriedade pelas organizações porque qualquer tipo pode ser usado para obter acesso não autorizado a informações confidenciais ou lançar novos ataques contra um alvo, disseram os pesquisadores.

“Portanto, é importante que as organizações protejam adequadamente seus servidores e redes para evitar esses tipos de ataques”, escreveu Shitrit no post do blog.

Shitrit fez duas recomendações específicas para as equipes de segurança mitigar os riscos das vulnerabilidades do SSRF. A primeira é “nunca confiar na entrada do usuário”, diz ele, porque pode ser uma tentativa de cometer o SSRF, disse ele.

“Nesse caso, vi que as requisições internas enviadas pelo servidor poderiam ser manipuladas pelo usuário de forma a atingir as requisições/endpoints internos para que pudessem chegar a locais indesejados”, conta Shitrit ao Dark Reading.

A segunda mitigação é definir e definir uma lista de permissão/lista branca de URLs que podem ingressar em um servidor, ele aconselha. Isso garantirá que, se um usuário com intenção nefasta estiver tocando em um SSRF não autenticado para manipular uma solicitação, o terminal retornará um erro “não permitido”, diz Shitrit.

FONTE: DARK READING

POSTS RELACIONADOS