Google Workspace: Amigo ou inimigo da cibersegurança?

Kevin Mitnick, que foi conhecido como o hacker mais famoso do mundo, disse: “Os hackers estão quebrando sistemas por lucro. Antes, tratava-se de curiosidade intelectual, a busca pelo conhecimento e pela emoção, e agora hackear é um grande negócio”. Como defensores, é nosso trabalho tirá-los desse negócio ou, pelo menos, oferecer alguma concorrência.

Neste artigo, quero explorar como ferramentas comuns, como as oferecidas pela suíte do Google Workspace, podem levar a uma violação empresarial em grande escala.

Para este propósito, vou aproveitar uma vulnerabilidade menos conhecida do cabeçalho X-Frame Options associada à função “Enviar comentários” do Google Docs.

O que você aprenderá neste artigo.

- Outro ponto de ataque a ser coberto e abordado
- A importância de usar ferramentas seguras, mesmo para tarefas cotidianas.
- Formas alternativas de contornar os controles de segurança de aplicativos comumente utilizados.
- Como redigir uma política de segurança para enfrentar esse vetor de ataque.

Google Workspace Contribuindo para Vazamentos de Dados e Shadow IT

Em sua essência, o Google Workspace é um conjunto de ferramentas que deveria melhorar a produtividade e facilitar a colaboração, independentemente do fluxo de trabalho. No entanto, se utilizado incorretamente, pode se tornar uma responsabilidade. Com isso em mente, antes de entrar em detalhes específicos, convido você a refletir sobre os seguintes pontos:

Os métodos mais eficazes de comprometimento empresarial não são os mais óbvios.
Ferramentas de código aberto e gratuitas não devem ser implementadas nem usadas em áreas sensíveis.
Google Docs e aplicativos semelhantes podem e serão usados como armas se forem empregados sem restrições e governança.
Custo vs. benefício vs. risco de usar aplicativos potencialmente inseguros, alimentando assim operações não autorizadas, como o Shadow IT.

Cobrir todas as bases é vital para a continuidade dos negócios (e para a integridade), por isso vou mostrar uma forma em que algo aparentemente inocente, como um G-doc, pode levar sua empresa ao colapso.

Breve História de Vulnerabilidades do Google Workspace

Se o seu time está utilizando as ferramentas do Google Workspace para registrar informações sensíveis, seu próximo passo deve ser investigar sobre o tema. Deixe-me poupar o esforço de buscar essa informação. Aqui estão alguns incidentes que você deve considerar.

DeleFriend contra Google Workspace

A exploração do DeleFriend no Google Workspace expôs uma vulnerabilidade de segurança importante, permitindo o acesso não autorizado a dados sensíveis. Essa brecha foi significativa devido ao uso extensivo do Google Workspace em ambientes profissionais e educacionais.

O incidente destacou os riscos associados às integrações de terceiros em plataformas importantes. Em resposta, DeleFriend e Google trabalharam rapidamente para corrigir a falha de segurança, enfatizando a necessidade de medidas de segurança rigorosas nos ecossistemas digitais.

Movimiento Lateral con Google SSO

A vulnerabilidade de movimento lateral no Google Workspace, aproveitando o single sign-on (SSO) do Google, representava uma ameaça crítica de segurança.

Ela permitia que atacantes, com acesso inicial a uma conta do Google, se movessem por vários serviços e aplicativos. Essa exploração colocava em risco a exposição de dados sensíveis, tanto pessoais quanto organizacionais.

Dados do Cloud Identity gratuitos

A exploração do Google Workspace utilizou uma falha no processo de validação de tokens do Cloud Identity gratuito, o que permitia que os atacantes contornassem a autenticação SSO.

Esse descuido técnico permitiu o acesso não autorizado à API, potencialmente expondo dados sensíveis em várias aplicações do Workspace.

A correção do Google consistiu em corrigir o mecanismo de validação de tokens e reforçar os controles de acesso à API para prevenir futuros exploits sofisticados.

Super Admin do G-Suite

A exploração do Super Admin do G-Suite envolveu uma manipulação sofisticada da escalada de permissões dentro da console de administração. Os atacantes exploraram uma vulnerabilidade no processo de atribuição de funções, obtendo privilégios de Super Admin não autorizados.

Essa brecha permitiu um acesso amplo a todas as aplicações do G-Suite e aos dados dos usuários, o que levou o Google a implementar controles rígidos e mecanismos de auditoria para proteger a console de administração contra tais vulnerabilidades.

GhostToken

A exploração do GhostToken no Google Workspace envolveu uma vulnerabilidade complexa no mecanismo de gerenciamento de tokens OAuth 2.0.

Os atacantes manipularam os processos de validação de tokens para obter acesso não autorizado a contas de usuários e dados em diversas aplicações do Workspace. A resposta do Google consistiu em uma revisão integral do sistema OAuth, melhorando a segurança dos tokens e os procedimentos de auditoria para prevenir futuros exploits avançados baseados em tokens.

Comprometimento do Google Workspace – Prova de Conceito

Agora que adicionei um pouco de contexto a esse experimento, deixe-me explicar a configuração e, é claro, o propósito desse exercício.

O objetivo é duplo:

Obtenha acesso a um documento do Google Docs e obtenha dados confidenciais sobre o desenvolvimento de produtos (por exemplo, novos recursos, bugs não resolvidos, código importado em massa do GitHub ou repositórios semelhantes, código defeituoso, maneiras de contornar controles, etc.).
Infiltrando-se ainda mais na rede (ou seja, movimento lateral).

Agora, sobre a configuração; para este trabalho, usei duas máquinas Windows (ou seja, a máquina atacante e a máquina vítima), ambas com as versões mais recentes.

A primeira tarefa é coletar o máximo de informações possível. Esta é uma etapa vital porque as informações permitirão identificar elos fracos, áreas mal protegidas, configurações incorretas, protocolos ausentes ou até mesmo um backdoor que facilita todo o processo.

Uma maneira de fazer isso seria aproveitar recursos claros da web (por exemplo, mídia social para identificar os principais participantes, Google Business para obter insights da empresa e/ou do setor).

Você também pode tentar outras técnicas, como:

Envio de pesquisas falsas para phishing ou spear phishing da vítima;
Ataques de força bruta;
Robar credenciales de usuarios de sitios web de terceros (por ejemplo, LinkedIn);
Força bruta;
Pesquise repositórios de credenciais na dark web;
Downloads drive-by;
Registro de chaves.

Suponha que o agente da ameaça tenha todas as informações necessárias para tentar a infiltração. Para este exercício, vou me concentrar em uma vulnerabilidade menos conhecida inerente ao Google Docs, chamada de déficit de cabeçalho X-Frame-Options, que é outra maneira elegante de dizer que o cabeçalho de resposta HTTP que um navegador deve receber não informa se deve ou não aceitar a exibição de uma página na forma de um <object>, <embed><iframe> , ou um simples <frame>.

Por padrão, o cabeçalho X-Frame pode aceitar dois tipos de diretivas: DENY ou SAMEORIGIN. A sintaxe é importante aqui porque, se você quiser executar um ataque de origem cruzada, a diretiva X-Frame deve ser sempre SAMEORIGIN e não DENY (ou seja, se definida como DENY, a página da Web não será exibida em um quadro).

O próximo passo é acessar o Google Docs, o que não é uma tarefa fácil; O processador de texto do Google pode ser gratuito, mas não está desprotegido.

Como a abordagem direta de interagir, em qualquer nível, com o código de back-end não funciona, a alternativa é configurar um domínio falso e enganar o aplicativo para redirecionar solicitações para nosso C2 recém-criado.

A configuração está concluída. Agora, vamos passar para a próxima fase.

Para que o ataque surtisse efeito, usamos o recurso “Enviar feedback” do Google Docs. A seção de comentários é muito útil para enviar relatórios de bugs, mas também possui uma falha oculta que pode ser usada para realizar um ataque.

A janela “enviar comentários” permite enviar vários anexos, incluindo imagens ou capturas de tela. Sempre que o usuário envia feedback, ele é transmitido automaticamente para o site principal do Google.

Para comentários que contêm capturas de tela, o formulário também envia os valores RGB da imagem.

Aqui está uma demonstração rápida de como isso funciona.

Usando Python, escrevi dois conjuntos de código. Você pode encontrá-los abaixo. – O primeiro lê os pixels da imagem de minha escolha e exibe seus valores RGB, enquanto o segundo ingere os valores RGB e os converte em uma imagem.

Um exemplo muito simples do que acontece no lado do back-end durante a transmissão: conversão de valor RGB.

Voltando ao nosso caso; o comentário empacotado (ou seja, os valores RGB correspondentes à captura de tela contida no formulário de comentário) é enviado para www.google.com e redirecionado para um subdomínio chamado feedback.googleusercontent.com.

O subdomínio ingere o URI de dados da captura de tela anexada e, ao mesmo tempo, envia o URI de dados de volta para o iframe principal correspondente.

Agora, para interceptar a solicitação HTTP que carrega os valores RGB de uma captura de tela, implante uma ferramenta como mitmproxy, kit de ferramentas HTTP ou Burp Proxy para capturar a solicitação. Você pode até usar APIs comerciais ou escrever suas próprias.

Depois de capturar a solicitação, você pode redirecioná-la para um servidor C2 e, bum! Agora você pode visualizar o conteúdo do documento do Google Docs.

Lembre-se de que esse feito só pode ser alcançado se o cabeçalho X-Frame estiver definido como SAMEORIGIN.

Um método simples e eficaz para ouvir seu oponente.

A partir daqui, você é livre para realizar ações adicionais. Por exemplo, neste ponto, você pode usar as informações e ferramentas para alterar a pasta de salvamento padrão no Google Drive ou se tornar um colaborador e ver as alterações no Google Docs em tempo real.

Eu aconselho você a não subestimar o valor do jailbreak do Google Drive e da integração do Google Workspace.

Não se esqueça de que mais de 1 milhão de empresas usam o Google Workspace, o que significa que um ataque bem-sucedido pode conceder a um agente de ameaça acesso a praticamente todos os aplicativos do pacote e, como sabemos, nem todos os documentos confidenciais, privados e confidenciais estão sendo processados por um aplicativo dedicado e seguro.

Como se proteger contra explorações do Google Workspace

Aqui estão algumas coisas que você pode tentar.

Invista em ferramentas dedicadas para documentação de desenvolvimento para evitar violações de segurança.
Certifique-se de que sua equipe esteja usando a ferramenta e não salvando notas dispersas em outras ferramentas.
Execute verificações regulares de vulnerabilidades para garantir que sua rede esteja limpa.
Lembre-se sempre de que os vetores de ataque mais discretos têm o impacto mais sério.
Implante uma solução MXDR (Managed Extended Detection and Response) para cobrir todos os vetores de ataque.

Por que usar o Heimdal® MXDR?

O serviço MXDR da® Heimdal é alimentado pela renomada Heimdal® XDR – Unified Security Platform que reúne mais de 10 soluções de segurança cibernética que cobrem superfícies de ataque complexas.

O MXDR Adapt é especialmente valioso para organizações com uma infraestrutura de TI grande e complexa, como corporações multinacionais, instituições financeiras, provedores de saúde, agências governamentais e outras organizações que lidam com dados confidenciais.

O Heimdal® também é uma ótima opção para pequenas e médias empresas porque muitas vezes não têm orçamento para manter uma equipe interna de segurança cibernética ou investir em várias ferramentas de segurança. No entanto, com o MXDR Adapt, eles podem acessar uma variedade de recursos avançados de segurança a um custo acessível.

Se você gostou deste artigo, siga-nos no LinkedIn, Twitter, Facebook e YouTube para mais notícias e tópicos sobre segurança cibernética.