Funcionários de startups falidas correm risco especial de ter dados pessoais roubados através de antigas contas do Google

Quando perder o emprego porque a startup para a qual você trabalha está à beira do colapso já é ruim o suficiente, agora um pesquisador de segurança descobriu que os funcionários de startups falidas estão em risco específico de terem seus dados roubados. Isso vai desde suas mensagens privadas no Slack até números de Seguro Social e, potencialmente, contas bancárias.

O pesquisador que descobriu o problema é Dylan Ayrey, cofundador e CEO da startup Truffle Security, apoiada pela Andreessen Horowitz. Ayrey é mais conhecido como o criador do popular projeto de código aberto TruffleHog, que ajuda a detectar vazamentos de dados caso os vilões obtenham ferramentas de login de identidade (ou seja, chaves de API, senhas e tokens).

Ayrey também é uma estrela em ascensão no mundo da caça a bugs. Na semana passada, na conferência de segurança ShmooCon, ele deu uma palestra sobre uma falha que encontrou no Google OAuth, a tecnologia por trás do “Entrar com o Google”, que as pessoas podem usar em vez de senhas.

Ayrey deu sua palestra depois de relatar a vulnerabilidade ao Google e a outras empresas que poderiam ser afetadas, e conseguiu compartilhar os detalhes porque o Google não proíbe seus caçadores de bugs de falar sobre suas descobertas. (O projeto Zero, do Google, com mais de uma década, muitas vezes destaca as falhas que encontra em produtos de outras gigantes da tecnologia, como o Microsoft Windows).

Ele descobriu que se hackers maliciosos comprassem os domínios abandonados de uma startup falida, poderiam usá-los para fazer login em software na nuvem configurado para permitir que todos os funcionários da empresa tivessem acesso, como um chat ou aplicativo de vídeo da empresa. A partir daí, muitos desses aplicativos oferecem diretórios da empresa ou páginas de informações do usuário onde o hacker poderia descobrir os e-mails de ex-funcionários.

Com o domínio e esses e-mails, os hackers poderiam usar a opção “Entrar com o Google” para acessar muitos dos aplicativos de software na nuvem da startup, frequentemente encontrando mais e-mails de funcionários.

Para testar a falha que encontrou, Ayrey comprou um domínio de uma startup falida e com ele conseguiu fazer login no ChatGPT, Slack, Notion, Zoom e em um sistema de RH que continha números de Seguro Social.

“Essa é provavelmente a maior ameaça”, disse Ayrey ao TechCrunch, já que os dados de um sistema de RH na nuvem são “o mais fácil para monetizar, e os números de Seguro Social e as informações bancárias e qualquer outra coisa nos sistemas de RH são provavelmente bastante suscetíveis” a serem alvo. Ele disse que contas antigas do Gmail ou Google Docs criadas por funcionários, ou qualquer dado criado com os aplicativos do Google, não estão em risco, e o Google confirmou.

Embora qualquer empresa falida com um domínio à venda possa ser vítima, os funcionários de startups são particularmente vulneráveis porque as startups tendem a usar os aplicativos do Google e muitos softwares na nuvem para gerenciar seus negócios.

Ayrey calcula que dezenas de milhares de ex-funcionários estão em risco, bem como milhões de contas de software SaaS. Isso se baseia em sua pesquisa que encontrou 116.000 domínios de site atualmente disponíveis para venda de startups de tecnologia falidas.

Prevenção disponível, mas não perfeita

Na realidade, o Google tem tecnologia em sua configuração do OAuth que deveria prevenir os riscos descritos por Ayrey, se o provedor de software na nuvem SaaS o utiliza. É chamado de “subidentificador”, que é uma série de números exclusiva para cada conta do Google. Embora um funcionário possa ter vários endereços de e-mail vinculados à sua conta de trabalho do Google, a conta deve ter apenas um subidentificador, sempre.

Se configurado, quando o funcionário tenta fazer login em uma conta de software na nuvem usando o OAuth, o Google enviará tanto o endereço de e-mail quanto o subidentificador para identificar a pessoa. Assim, mesmo se hackers maliciosos recriassem endereços de e-mail com o controle do domínio, eles não deveriam ser capazes de recriar esses identificadores.

Mas Ayrey, trabalhando com um fornecedor de RH SaaS afetado, descobriu que esse identificador “era inconsistente”, como ele colocou, significando que o fornecedor de RH descobriu que ele mudava em uma porcentagem muito pequena dos casos: 0,04%. Isso pode ser estatisticamente próximo de zero, mas para um provedor de RH lidando com grandes números de usuários diários, isso se traduz em centenas de logins falhos por semana, impedindo as pessoas de acessarem suas contas. Por isso, esse provedor na nuvem não quis usar o subidentificador do Google, disse Ayrey.

Google contesta que o subidentificador muda. Como essa descoberta veio do provedor de RH na nuvem, e não do pesquisador, ela não foi enviada ao Google como parte do relatório de bug. O Google diz que se vir alguma evidência de que o subidentificador é inconsistente, a empresa resolverá a questão.

No entanto, o Google também mudou de ideia sobre a importância desse problema. Inicialmente, o Google rejeitou totalmente o bug de Ayrey, fechando rapidamente o caso e dizendo que não era um bug, mas um problema “fraudulento”. O Google não estava totalmente errado. Esse risco vem de hackers controlando domínios e usando contas de e-mail que recriam por meio deles. Ayrey não culpou a decisão inicial do Google, chamando isso de uma questão de privacidade de dados em que o software do OAuth do Google funcionava como pretendido, embora os usuários ainda pudessem ser prejudicados. “Não é tão simples assim”, ele disse.

No entanto, três meses depois, logo após sua palestra ser aceita pelo ShmooCon, o Google mudou de ideia, reabriu o caso e pagou a Ayrey uma recompensa de US$ 1.337. Algo semelhante aconteceu com ele em 2021, quando o Google reabriu o caso depois que ele deu uma palestra muito popular sobre suas descobertas na conferência de segurança Black Hat. O Google até premiou Ayrey e sua parceira de descoberta de bugs, Allison Donovan, o terceiro lugar em seus prêmios anuais para pesquisadores de segurança (juntamente com US$ 73.331).

Google ainda não emitiu uma correção técnica para a falha, nem um cronograma para quando poderá fazer isso – e não está claro se o Google fará alguma mudança técnica para abordar de alguma forma esse problema. A empresa, no entanto, atualizou sua documentação para instruir os provedores na nuvem a usarem o subidentificador. O Google também oferece instruções aos fundadores sobre como as empresas devem encerrar adequadamente o Google Workspace e prevenir o problema.

Por fim, o Google diz que a solução é para os fundadores que estão fechando uma empresa garantirem que todos os seus serviços na nuvem sejam desativados. “Agradecemos a ajuda de Dylan Ayrey em identificar os riscos decorrentes de clientes que se esquecem de excluir serviços SaaS de terceiros ao encerrar suas operações”, disse o porta-voz.

Ayrey, ele próprio fundador, entende por que muitos fundadores podem não ter garantido que seus serviços na nuvem fossem desativados. Encerrar uma empresa é na verdade um processo complicado feito durante um momento que poderia ser emocionalmente doloroso – envolvendo muitos itens, desde a disposição de computadores de funcionários até o fechamento de contas bancárias, pagamento de impostos.

“Quando o fundador tem que lidar com o fechamento da empresa, provavelmente não está em um grande espaço mental para poder pensar em todas as coisas que precisa estar pensando”, diz Ayrey.