Felizmente, o Uber informou sobre essa invasão e agiu rapidamente.
Na semana passada, um hacker de 18 anos usou técnicas de engenharia social para comprometer a rede do Uber. Ele comprometeu o login de um funcionário no Slack e o usou para enviar uma mensagem aos funcionários do Uber anunciando haver sofrido uma invasão de dados.
O Uber confirmou o ataque no Twitter em poucas horas, informando mais detalhes nesta página. A empresa alega que nenhum dado dos usuários corria risco, eles notificaram as autoridades e todos os seus serviços foram restaurados ao estado operacional. (Houve algumas breves interrupções de várias ferramentas de software, mas elas também estão online novamente). O Uber acha que agora o hacker faz parte de um grupo de hackers chamado Lapsus$.
O que é interessante sobre esse incidente foi a velocidade com que várias publicações e analistas de segurança forneceram cobertura, a rapidez com que o Uber notificou o mundo e quantos detalhes já temos sobre o que aconteceu.
Compare isso com a outra invasão do Uber em 2016, quando as informações pessoais de cerca de 57 milhões de clientes e motoristas foram roubadas. Essa invasão não foi divulgada por mais de um ano e resultou na demissão do diretor de segurança, Joseph Sullivan. Ele está sendo atualmente julgado por supostamente pagar aos hackers US$ 100.000 para encobrir as coisas e pelo atraso na divulgação da invasão. Os hackers foram supostamente forçados a assinar acordos de confidencialidade, uma maneira estranha de lidar com a invasão, com certeza.
Como aconteceu a invasão?
A invasão da semana passada é explicada neste tópico do Twitter, sendo incomum devido ao nível de detalhes compartilhado pelo invasor, que supostamente compartilhou as capturas de tela mostradas no tópico.
Esses detalhes incluem consoles que controlam as contas Amazon Web Services e o Google Workspace do Uber, além de outros sistemas críticos. Um analista de segurança, que reagiu à invasão em seu próprio tópico no Twitter disse que o hacker tem controle administrativo quase total sobre os sistemas de computadores da empresa, incluindo o código-fonte do software e os sistemas internos de mensagens.
O hacker – que o Uber agora acredita ser membro do grupo de hackers Lapsus$, que por sua vez está por trás de várias outras violações de alto perfil – posteriormente conversou com vários repórteres e admitiu que obteve acesso usando técnicas de engenharia social em um terceirizado da empresa. Eles criaram um portal de autenticação multifator (MFA) falso para lançar um ataque man-in-the-middle, enganando essa pessoa para revelar as suas credenciais de autenticação, alegando ser do departamento de TI do Uber.
O hacker então fez login na VPN corporativa e percorreu a rede, procurando alvos, incluindo um script PowerShell que continha acesso de administrador a uma plataforma de gerenciamento de acesso privilegiado. Um destino foram os relatórios de recompensas de bugs do HackerOne do Uber, o que pode ser muito prejudicial: eles conheceriam vulnerabilidades que ainda não foram corrigidas e poderiam obter um pagamento premium caso ameaçassem compartilhá-las na dark web.
Lições aprendidas
Aqui estão algumas dicas importantes a serem lembradas após essa invasão:
-
Nem todos os métodos de MFA são criados igualmente
O Uber não estava usando senhas e tokens de hardware FIDO2 para proteger as suas contas internas mais críticas. Estes são mais resistentes a ataques de phishing, como o que aconteceu aqui. Os invasores podem facilmente criar páginas de login falsas que podem coletar informações de um usuário para funcionários desavisados.
-
A engenharia social ainda é uma ameaça
Você pode ter todos os tipos de sistemas de segurança, mas lutar contra a natureza humana básica ainda é difícil. Foi fácil ver como o hacker conquistou a confiança e comprometeu o funcionário do Uber. A Ars Technica destaca: "Muitas organizações e culturas continuam acreditando que seus membros são espertos demais para cair em ataques de phishing. Eles gostam da conveniência dos aplicativos autenticadores em comparação com as formas FIDO2 de MFA, que exigem a posse de um telefone ou chave física. Esses tipos de violações continuarão sendo um fato da vida até que essa mentalidade mude".
-
As credenciais de login do administrador não devem ser codificadas em nenhum lugar
Especialmente não devem estar em nenhum script. Isso significa essencialmente que você tem autenticação de fator zero, pois qualquer pessoa que leia o script pode descobrir as credenciais.
-
Ter um canal de comunicação alternativo é crucial
Este canal deve estar fora da banda da sua rede para se comunicar entre sua equipe de resposta a violações. Depois que o hacker comprometeu o Slack, eles enviaram várias mensagens reivindicando o feito que não foram levadas a sério pelos funcionários de segurança do Uber, que acharam que aquilo era uma brincadeira (e não era).
Felizmente, o Uber relatou essa invasão e agiu rapidamente. A empresa tomou várias medidas para bloquear seu repositório de código, alterar credenciais e identificar outras contas comprometidas. Eles continuam a atualizar o conteúdo da sua página na internet.
