Violação do código-fonte do LastPass – relatório de resposta a incidente divulgado

Se a grande história deste mês parece destinada a ser Violação de dados do Uber, onde um hacker supostamente conseguiu vagar amplamente pela rede da empresa de compartilhamento de viagens…

..a grande história do mês passado foi a Violação do LastPass, em que um invasor aparentemente teve acesso a apenas uma parte da rede LastPass, mas conseguiu fugir com o código-fonte proprietário da empresa.

Felizmente para o Uber, o invasor parecia determinado a fazer um grande e rápido estouro de relações públicas capturando capturas de tela, espalhando-as liberalmente online e provocando a empresa com mensagens gritantes, como UBER FOI HACKEADO, diretamente em seus próprios fóruns do Slack e de recompensas de bugs:

O invasor ou invasores do LastPass, no entanto, parecem ter operado de forma mais furtiva, aparentemente enganando um desenvolvedor do LastPass para instalar malware que os cibercriminosos usaram para pegar carona no repositório de código-fonte da empresa:

O LastPass agora publicou um relatório oficial de acompanhamento sobre o incidente, com base no que foi capaz de descobrir sobre o ataque e os atacantes após a invasão.

Achamos que vale a pena ler o artigo do LastPass, mesmo que você não seja um usuário do LastPass, porque achamos que é um lembrete de que um bom relatório de resposta a incidentes é tão útil para o que admite que você não conseguiu descobrir quanto para o que você era.

O que agora sabemos

As frases em negrito abaixo fornecem um resumo do que o LastPass está dizendo:

• O atacante “obteve acesso ao ambiente de [d]desenvolvimento usando o endpoint comprometido de um desenvolvedor.” Estamos assumindo que isso se deve ao invasor que implantou malware de espionagem de sistema no computador de um programador.
• O truque usado para implantar o malware não pôde ser determinado. Isso é decepcionante, porque saber como seu último ataque foi realmente realizado torna mais fácil garantir aos clientes que seus procedimentos revisados ​​de prevenção, detecção e resposta provavelmente o bloquearão na próxima vez. Muitos vetores de ataque em potencial vêm à mente, incluindo: software local não corrigido, “shadow IT” levando a uma configuração local insegura, um erro de clique de phishing, hábitos de download inseguros, traição na cadeia de fornecimento de código-fonte confiada pelo codificador em questão, ou um anexo de e-mail com armadilha aberta por engano. Tiramos o chapéu para o LastPass por admitir o que equivale a um “desconhecido conhecido”.
• O atacante “utilizou seu acesso persistente para se passar pelo desenvolvedor assim que o desenvolvedor se autenticou com sucesso usando a autenticação multifator”. Presumimos que isso significa que o hacker nunca precisou adquirir a senha ou o código 2FA da vítima, mas simplesmente usou um ataque de roubo de cookies, ou extraiu o token de autenticação do desenvolvedor do tráfego de rede genuíno (ou da RAM do computador da vítima) para pegar carona no acesso usual do programador:

• O LastPass não percebeu a invasão imediatamente, mas detectou e expulsou o invasor em quatro dias. Como observamos em um artigo recente sobre os riscos de ambiguidade do carimbo de data/hora nos logs do sistema, ser capaz de determinar a ordem exata em que os eventos ocorreram durante um ataque é uma parte vital da resposta a incidentes:

• O LastPass mantém suas redes de desenvolvimento e produção fisicamente separadas. Essa é uma boa prática de segurança cibernética porque evita que um ataque à rede de desenvolvimento (onde as coisas estão inevitavelmente em um estado contínuo de mudança e experimentação) se transforme em um comprometimento imediato do software oficial que está diretamente disponível para os clientes e o restante da empresa .
• O LastPass não mantém nenhum dado do cliente em seu ambiente de desenvolvimento. Novamente, essa é uma boa prática, pois os desenvolvedores estão, como o nome do trabalho sugere, geralmente trabalhando em software que ainda precisa passar por uma revisão completa de segurança e processo de garantia de qualidade. Essa separação também torna crível que o LastPass afirme que nenhum dado do cofre de senhas (que teria sido criptografado com as chaves privadas dos usuários de qualquer maneira) poderia ter sido exposto, o que é uma afirmação mais forte do que simplesmente dizer “não conseguimos encontrar nenhuma evidência de que foi exposto”. Manter os dados do mundo real fora de sua rede de desenvolvimento também impede que codificadores bem-intencionados capturem inadvertidamente dados que deveriam estar sob proteção regulatória e os usem para fins de teste não oficiais.
• Embora o código-fonte tenha sido roubado, nenhuma alteração de código não autorizada foi deixada para trás pelo invasor. Claro, temos apenas a afirmação do LastPass para continuar, mas dado o estilo e o tom do restante do relatório de incidentes, não podemos ver nenhuma razão para não levar a empresa ao pé da letra.
• Código-fonte passando da rede de desenvolvimento para a produção “só pode acontecer após a conclusão de processos rigorosos de revisão de código, teste e validação”. Isso torna crível que o LastPass afirme que nenhum código-fonte modificado ou envenenado teria chegado aos clientes ou ao resto do negócio, mesmo que o invasor tenha conseguido implantar código não autorizado no sistema de controle de versão..
• O LastPass nunca armazena ou mesmo conhece as chaves privadas de descriptografia de seus usuários. Em outras palavras, mesmo que o invasor tenha fugido com dados de senha, teria acabado como repolho digital picado. (O LastPass também fornece um explicação pública de como ele protege os dados do cofre de senhas contra cracking offline, incluindo o uso do PBKDF2-HMAC-SHA256 do lado do cliente para salgar-hashing-e-esticar sua senha offline com 100,100 iterações, tornando tentativas de quebra de senha muito mais difícil, mesmo que os invasores fujam com cópias armazenadas localmente do seu cofre de senhas.)

O que fazer?

Achamos razoável dizer que nosso suposições iniciais estavam corretas, e que embora este seja um incidente embaraçoso para o LastPass, e possa revelar segredos comerciais que a empresa considerava parte de seu valor para o acionista…

… esse hack pode ser pensado como o próprio problema do LastPass para lidar, porque nenhuma senha de cliente foi alcançada, muito menos quebrada, neste ataque:

Este ataque, e o próprio relatório de incidente do LastPass, também são um bom lembrete de que “dividir e conquistar”, também conhecido pelo termo jargão Confiança zero, é uma parte importante da ciberdefesa contemporânea.

Como o especialista da Sophos Chester Wisniewski explica em sua análise do hack Uber recente, há muito mais em jogo se os criminosos que tiverem acesso a alguns da sua rede podem percorrer onde quiserem na esperança de obter acesso a todos os disso: