0
0
O Google corrigiu uma falha crítica em seu serviço de banco de dados do Google Cloud Platform que os pesquisadores usavam para obter acesso a dados confidenciais e segredos, bem como escalar privilégios para violar outros serviços de nuvem, incluindo potencialmente aqueles em ambientes de clientes.
Pesquisadores da Dig Security identificaram a vulnerabilidade por meio de uma lacuna na camada de segurança em torno do serviço CloudSQL do GCP, que suporta vários mecanismos de banco de dados diferentes – incluindo MySQL, PostgreSQL e SQL Server – para uso no ambiente, revelaram em um post no blog em 25 de maio.
A vulnerabilidade permitiu que eles escalassem os privilégios iniciais e adicionassem um usuário à função DbRootRole, que é uma função de administrador no GCP, revelaram Ofrir Balassiano e Ofrir Shaty da Dig Security no post.
A partir daí, eles exploraram outro erro crítico de configuração na arquitetura de permissões de funções, para aumentar ainda mais seu privilégio, eventualmente concedendo ao usuário mal-intencionado uma função de administrador do sistema para obter controle total sobre o SQL Server. Depois disso, eles puderam acessar o sistema operacional que hospeda o banco de dados.
“Neste ponto, poderíamos acessar arquivos confidenciais no sistema operacional do host, listar arquivos e caminhos confidenciais, ler senhas e extrair segredos da máquina”, escreveram os pesquisadores no post.
Esse último aspecto da vulnerabilidade pode ter dado a um invasor que explora a falha acesso a recursos em ambientes de clientes que aproveitam o GCP, disseram eles.
Descobrindo a falha em fevereiro, a Dig Security seguiu práticas coordenadas de divulgação usando o programa de prêmios de vulnerabilidade do Google para notificar a empresa sobre o problema. As empresas trabalharam juntas nos dois meses seguintes, e o Google abordou e resolveu os problemas em abril, recompensando a Dig por meio de seu programa de recompensa por bugs em 25 de abril, disseram os pesquisadores.
Navegando pelas permissões SQL do Google Cloud Platform
A exploração completa da vulnerabilidade foi um processo de várias etapas, a primeira das quais foi possível por meio das permissões padrão no GCP SQL Server, explicaram os pesquisadores.
Há dois níveis de permissões que um usuário pode obter no GCP SQL Server — aqueles no nível do servidor e aqueles no nível do banco de dados — um ponto que é importante para entender como a falha funciona, disseram eles.
As permissões de servidor contêm operações que são feitas no nível da instância dentro da nuvem, enquanto as permissões de banco de dados são para operações feitas dentro da própria instância do banco de dados, explicaram os pesquisadores. Dentro desses, “CONTROL SERVER” é a permissão mais poderosa que um usuário pode ser concedida no nível da instância, enquanto “CONTROL DATABASE” é a permissão mais poderosa que um usuário pode ser concedida no nível do banco de dados, disseram eles.
O logon padrão do SQL Server fornece a um usuário a função GCP “CustomerDbRootRole”, que não permite usar o comando “create/alter” para fazer qualquer coisa no nível do servidor. Ele também não tem permissões em objetos sys, o que significa que o usuário não pode criar objetos em nenhum banco de dados do sistema, explicaram. Então, para completar o ataque, eles precisavam elevar seus privilégios.
Explorando a falha do SQL Server
Os pesquisadores identificaram uma lacuna na camada de segurança criada para o SQL Server no GCP que lhes permitiu escalar seus privilégios padrão iniciais e adicionar o usuário criado à função DbRootRole, que é uma função de administrador do GCP, explicaram no post.
Uma vez que os pesquisadores alcançaram esse papel, eles puderam realizar várias tarefas que antes não conseguiam; no entanto, como não é uma função sysadmin, eles ainda não tinham permissões totais no SQL Server, disseram.
Eles acabaram descobrindo um caminho para o sucesso usando um erro crítico de configuração – um problema comum encontrado em ambientes de nuvem – na arquitetura de permissões de funções, o que lhes permitiu escalar ainda mais os privilégios, concedendo ao usuário uma função sysadmin que permitia controle total no SQL Server, disseram eles. Isso é o que lhes deu acesso total ao sistema operacional que hospeda o banco de dados e todos os seus arquivos confidenciais, senhas, segredos e outros dados importantes, disseram os pesquisadores.
Além disso, o host tem acesso aos agentes de serviço que se conectam a recursos em ambientes de clientes, colocando em risco as empresas que usam o GCP para executar sistemas em seus próprios ambientes, disseram os pesquisadores.
“Obter acesso a dados internos, como segredos, URLs e senhas, pode levar à exposição de dados de provedores de nuvem e dados confidenciais de clientes, o que é um grande incidente de segurança”, escreveram no post.
Usando seu acesso ao sistema operacional, os pesquisadores também descobriram URLs internos do Google relacionados ao repositório de imagens do Docker que lhes permitiam acessar o repositório interno, que o Google também corrigiu em sua remediação, disseram eles.
Mitigando o risco de segurança cibernética na nuvem
Configurações incorretas na nuvem ainda são motivos comuns para falhas na segurança da nuvem, representando riscos para os clientes. No caso da falha que os pesquisadores do Dig encontraram, um problema que tornou o Google Cloud complicado de proteger é que o SQL Server não é de código aberto, o que significa que uma camada de segurança teve que ser construída em torno dele, diz Balassiano ao Dark Reading.
De fato, à medida que mais dados são armazenados em ambientes de nuvem, as organizações devem aplicar controles de segurança de dados, independentemente do que seus provedores de nuvem estão oferecendo para se proteger, mesmo que o ambiente do provedor tenha uma falha, diz ele.
“Plataformas de segurança de dados que oferecem uma combinação de DSPM (gerenciamento de postura de segurança de dados) e DDR (detecção e resposta de dados) podem reduzir as chances de agentes mal-intencionados conseguirem exfiltrar dados sem uma resposta rápida”, diz Balassiano.
Para evitar a exploração potencial de uma falha como a que a equipe encontrou, as organizações podem se beneficiar da implantação de uma solução DSPM que localiza seus dados mais confidenciais e garante que eles estejam protegidos, diz ele. Isso significa que, mesmo que haja uma violação, os dados são criptografados e a exposição é contida.
“Para se antecipar à violação, eles também devem aplicar DDR, que evita o uso indevido de dados e a exfiltração de dados, fornecendo detecção e resposta em tempo real”, acrescenta Balassiano.
FONTE: DARK READING