0
0
A Microsoft corrigiu um par perigoso de vulnerabilidades em seu banco de dados Azure para servidor flexível pós-terrorismoQL que deu aos atacantes acesso não autorizado a bancos de dados em ambientes hospedados em nuvem.
O primeiro é um erro de escalada de privilégios em uma modificação que a Microsoft fez ao motor PostgreSQL. O segundo é um bug que aproveita a escalada de privilégios habilitada pelo primeiro para dar aos atacantes acesso a contas cruzadas.
Os atores de ameaças poderiam ter usado as falhas para contornar mecanismos de autenticação e obter acesso total aos dados dos clientes em vários bancos de dados em uma região sem deixar qualquer vestígio de sua presença, descobriram recentemente pesquisadores do fornecedor de segurança na nuvem Wiz Research.
“Um invasor poderia criar uma cópia completa de um banco de dados de destino no Azure PostgreSQL [Servidor Flexível], essencialmente exfiltrando todas as informações armazenadas no banco de dados”, diz Ami Luttwak, co-fundador e CTO da Wiz. As vulnerabilidades teriam permitido que os invasores contornassem firewalls configurados para proteger os bancos de dados hospedados, a menos que uma organização o tivesse configurado apenas para acesso privado. “Mas essa não é a configuração padrão”, diz Luttwak.
Em um aviso na quinta-feira, a Microsoft descreveu o problema de segurança como impactando organizações que haviam implantado suas instâncias do PostgreSQL Flexible Server usando a opção de rede de acesso público. A empresa disse que amenizou o problema em 13 de janeiro de 2022, menos de 48 horas após Wiz ter notificado o problema. A Microsoft disse que sua análise não mostrou nenhuma evidência de que os atacantes tenham explorado as vulnerabilidades para acessar dados de clientes. Embora as organizações que usam o serviço não precisem tomar nenhuma ação, a Microsoft recomendou que eles permitam o acesso à rede privada para suas instâncias do Servidor Flexível para minimizar a exposição a problemas semelhantes.
Luttwak diz que vulnerabilidades como essas destacam por que as organizações precisam ter um modelo de segurança em profundidade ao implantar e executar cargas de trabalho em nuvem. Ele diz: “Aqui, um simples erro de desenvolvedor – uma validação errada do prefixo – levou a uma capacidade potencial para os invasores obterem acesso aos dados dos clientes.” A única maneira de mitigar tais riscos é ter múltiplas camadas de proteção para que um único bug não permita um compromisso, diz Luttwak.
Os pesquisadores do Wiz encontraram os bugs como parte de um esforço de pesquisa mais amplo para encontrar vulnerabilidades de acesso a contas cruzadas em serviços em nuvem. Essas são uma classe de vulnerabilidades que essencialmente dão aos invasores uma maneira de quebrar mecanismos de isolamento de inquilinos em ambientes de nuvem para acessar outras contas e dados de clientes. O esforço de Wiz segue a descoberta da empresa em agosto de 2021 de uma vulnerabilidade crítica — apelidada de ChaosDB — no Azure Cosmos DB da Microsoft, que deu à empresa acesso irrestrito a bancos de dados e contas pertencentes a milhares de clientes do serviço Azure, muitos dos quais eram empresas da Fortune 500.
“Após a vulnerabilidade do ChaosDB que divulgamos no ano passado, focamos especificamente em bancos de dados gerenciados por nuvem, pois eles representam o maior risco de manter dados confidenciais de clientes”, observa Luttwak.
Falhas de acesso de contas cruzadas no Cloud
Wiz decidiram se concentrar no Azure PostgreSQL Flexible Server porque é um serviço de banco de dados gerenciado por nuvem amplamente utilizado, onde as instâncias de banco de dados são executadas em um ambiente interno de nuvem de propriedade do provedor de serviços. Os pesquisadores começaram tentando descobrir uma maneira de aumentar os privilégios dentro de sua própria instância do PostgreSQL Flexible Server e descobriram uma vulnerabilidade em algumas modificações que a Microsoft havia feito ao motor ostensivamente para endurecer seu modelo de privilégio.
“O bug de escalonamento de privilégios não é uma vulnerabilidade pós-², mas sim é resultado de modificações que o Azure introduziu no motor PostgreSQL em seu final”, diz Luttwak. “É provável que essas modificações tenham sido introduzidas para ajudar o Azure a gerenciar melhor as instâncias dos clientes e reduzir o atrito.”
Uma vez que os pesquisadores obtiveram privilégios de execução de código em sua instância de Servidor Flexível Pós-GreSQL, eles descobriram que tinham acesso à rede a outras contas dentro da sub-rede através de sua interface de rede interna. Para testar se o acesso funcionaria, os pesquisadores criaram outra instância flexível pós-laql usando uma conta separada e tentaram acessá-la a partir de seu primeiro banco de dados. Quando isso funcionou, eles procuraram uma maneira de usar de forma semelhante sua instância para acessar outras contas sem autenticar a elas. Isso levou à descoberta de uma vulnerabilidade que lhes permitiu fazer exatamente isso, usando um certificado falso.
Luttwak explica a exploração como alavancar uma função de alta disponibilidade do Azure que usa o recurso de replicação do PostgreSQL para replicar bancos de dados entre servidores.
“O serviço de replicação se conecta à instância do banco de dados e tem as permissões para replicá-lo para outros nãos” através de uma rede compartilhada, diz ele. Os pesquisadores do Wiz descobriram que poderiam obter cópias completas de outros bancos de dados autenticando como o serviço de replicação para outras instâncias postgreSQL usando um certificado emitido para um domínio arbitrário em vez do certificado de serviço de replicação do Azure.
“Na verdade, não conseguimos acesso ao certificado de serviço de replicação”, diz Luttwak. “Mas encontramos uma maneira de contorná-lo, já que o PostgreSQL estava apenas procurando uma chave privada com um certo prefixo.”
Isso permitiu que Wiz simplesmente criasse um certificado de aparência legítima que passasse a autenticação, observa Luttwak.
Ele diz que as duas vulnerabilidades — agora corrigidas — precisariam ser acorrentadas para ter um impacto significativo. Isso porque a primeira vulnerabilidade só fornece acesso local a uma instância de banco de dados. Mas sem ele, um atacante não teria os privilégios necessários para o acesso a contas cruzadas.
FONTE: DARK READING