Resumo Detalhado do Artigo
Título: Signal sob fogo por armazenar chaves de criptografia em texto simples
Contexto:
O aplicativo de mensagens criptografadas Signal está enfrentando críticas devido a uma questão de segurança em sua aplicação desktop. Pesquisadores de segurança e usuários estão preocupados com a maneira como o aplicativo lida com as chaves de criptografia.
Problema Identificado:
De acordo com os pesquisadores de segurança cibernética Mysk, a versão desktop do Signal armazena as chaves de criptografia em texto simples. Este problema potencialmente expõe os usuários a roubo de dados, pois essas chaves estão acessíveis por qualquer processo no sistema.
Experimento dos Pesquisadores:
Os pesquisadores demonstraram o problema usando um script Python que copiou o diretório de armazenamento local do Signal em um Mac, transferindo os dados para uma nova instalação de macOS em uma máquina virtual. Eles conseguiram restaurar a sessão inteira do Signal, incluindo históricos de chat, sem qualquer aviso do Signal sobre a sessão clonada. As mensagens eram entregues tanto no Mac original quanto na máquina virtual, e o iPhone recebia todas as mensagens, sem detectar a sessão não autorizada.
Reações e Recomendações:
– Naomi Brockwell: Recomenda desvincular qualquer dispositivo desktop das contas Signal, destacando que o problema de armazenamento de chaves em texto simples é conhecido há tempos.
– Resposta do Signal: Joshua Lund, do Signal, em 2018, afirmou que a chave do banco de dados nunca foi destinada a ser secreta e que a criptografia em repouso não é algo que o Signal Desktop tentou ou alegou fornecer.
Resposta Oficial do Signal:
Meredith Whittaker, presidente do Signal, abordou as preocupações levantadas pelos pesquisadores no Twitter:
1. Os problemas relatados dependem de um invasor já ter acesso total ao dispositivo do usuário.
2. O Signal está trabalhando para fortalecer a versão desktop do aplicativo.
3. Os pesquisadores não contataram o Signal diretamente antes de levar as alegações às redes sociais.
Reações nas Redes Sociais:
Alguns usuários criticam o Signal por não ter resolvido o problema, conhecido desde 2018. Outros argumentam que a necessidade de acesso completo ao dispositivo do usuário para explorar a vulnerabilidade não é uma justificativa adequada, pois o acesso a arquivos a nível de usuário já seria suficiente para comprometer a segurança.
Outras Aplicações:
O artigo também menciona que outras aplicações, como WhatsApp e iMessage, enfrentam problemas semelhantes de armazenamento inadequado de dados. No entanto, o iMessage armazena dados em uma sandbox, o que proporciona maior proteção contra processos não autorizados.
Conclusão:
Há uma tensão entre as necessidades imediatas de segurança e as limitações práticas dos desenvolvedores na proteção de dados locais. O artigo sugere que o Signal pode precisar tomar medidas adicionais para criptografar as chaves ou dificultar o acesso aos dados para usuários padrão.
Este resumo cobre os principais pontos abordados no artigo original, destacando as críticas à segurança do Signal e as respostas tanto da comunidade quanto da própria empresa.
15 comentários
Saiu um beta do aplicativo para desktops corrigindo essa vulnerabilidade.
Como disse a pessoa que submeteu o pull request em abril (!), que este caso sirva de lição para que o Signal lide melhor com situações semelhantes no futuro.
Legal! Que bom que reconheceram a falha.Que sirva para outras empresas se justificarem menos e agirem mais.
Entendo as críticas. Quando houve aquele “auê” do Recall da Microsoft, foi pela mesma coisa e a CEO do Signal também fez críticas. Mesmo que a para o comprometimento dessa vulnerabilidade, todo o sistema precisa estar comprometido, quando se refere à segurança (que é o que o Signal se propõe) você precisa mitigar qualquer ameaça possível, e não usar a “desculpa” de que “outros apps também tem isso, então ok” como fez a CEO pelo X.
É o mesmo caso do ChatGPT para macOS, né? E, a exemplo de lá, acho que também com o Signal o alarmismo é desproporcional. Se o seu dispositivo for comprometido, já era. Ou isso, ou você ter que ficar digitando senha ou liberando o acesso às chaves a cada acesso ao aplicativo. O comentário da Meredith vai nessa linha:
As chaves privadas do OpenSSH também são guardadas sem criptografia no sistema. As credenciais do rclone, idem. Se você copia o
rclone.confpara outro sistema, consegue acessar todos os buckets listados. Sem senha nem nada.O sistema operacional é a sua linha de defesa, não aplicativos individuais. Linux, macOS e Windows todos oferecem criptografia do disco inteiro. Se não confia no sistema ou nas proteções dele, talvez não devesse usá-lo.
Se entendi bem, isso seria meio que equivalente a salvar todas as suas senhas de suas contas (e-mail, banco, cartões, etc.) em um arquivo do Word ou um .txt do bloco de notas, certo?
Se olhar por esse lado, ninguém em sã consciência recomendaria essa prática. Por mais que seu sistema operacional seja protegido ou criptografado. Então acho que o mesmo valeria para as chaves de criptografia. Ou a comparação não procede?
Se você usar as senhas apenas e tão somente nesse computador, aí a comparação procede.
Não acho que esse isso seja suficiente para informações sensíveis. Essa situação é análoga a maneira que os apps salvam senhas nos smartphones. O correto é a desencriptação (essa palavra existe?) somente no momento da leitura, usando o Chaveiro do macOS, Senhas e Chaves do Gnome (não lembro o método que o Windows usa) que exigem uma nova senha para autenticar.
Não acho que seja análoga porque a senha é algo com que você lida diretamente; a autenticação do Signal, não. O processo de “desencriptação” (fiquei na mesma dúvida 😄) já é feito, mas pelo Signal. Vem daí a “criptografia de ponta a ponta”: o seu computador é uma das pontas, logo, presume-se que seja confiável para que o Signal possa desembaralhar as mensagens.
Na minha cabeça tudo isso… faz sentido, mas estou aberto a me provarem o contrário. Sempre parto da premissa de que se alguém tiver acesso aos meus dispositivos, já era.
Fazendo um comparativo com o Evernote, que em sua base de dados salva no Windows, é uma pasta de cache que mesmo que copie e cole para outra máquina, você não consegue ter acesso a nada da conta daquela pessoa. O que a matéria deu a entender foi que copiaram e colaram um arquivo e conseguiram fazer login na conta em uma outra máquina, sem que o usuário fosse avisado de um novo login, e que as mensagens chegavam no celular, no computador do usuário, e na máquina que fez o “clone”. Achei isso zoado.
Ok, aqui tem uma explicação de que, ao menos no macOS e no Windows usando um instalador no formato
*.msix, dá para fazer diferente/de um jeito mais seguro. (No Linux é mais complicado, pela explicação do amigo ali.)Já tem uma issue aberta no repositório.
Imagine que alguém tome o seu celular com a tela desbloqueada na rua. Você prefere que o seu app de banco funcione sem pedir nenhuma credencial porque, afinal, se alguém teve acesso ao seu sistema operacional é porque você bobeou?
Não creio que faça sentido guardar chaves críticas em plain text se você pode guardá-las criptografadas. Não é porque alguém teve acesso ao seu sistema que daí pra frente a responsabilidade é sua. Tanto que o Signal já commitou um patch pra resolver o problema: https://github.com/signalapp/Signal-Desktop/pull/6849
Quando se fala criptografia ponta-a-ponta não se está querendo dizer de uma máquina para outra, mas de um cliente (aplicação) para outro. Em outras palavras, o programa A tendo sua segurança comprometida não deveria ter acesso ao programa B porque este decidiu armazenar dados críticos em plain text. Não por acaso os browsers hoje em dia são sandboxes.
A propósito, não encontrei nenhuma referência de que o OpenSSH guarda atualmente as chaves em plain text. Você teria alguma fonte?
Se estiver usando algum sistema *Unix, abra o diretório
~/.ssh/e suas chaves privadas estarão salvas lá. Se copiá-las e importá-las em outra máquina, conseguirá usá-las normalmente.Ah, sim. Mas aí não é chave armazenada em plain text, o que seria um escândalo rsrs
Achei que fosse. Pode me explicar a distinção entre o que o OpenSSH deixa ali e o que seria deixar em plain text?
Peço desculpas porque, relendo agora, acho que eu não fui muito claro. A chave que o OpenSSH guarda é de fato em plain text (dá pra abrir com um editor de texto genérico), porém é uma chave criptografada, e não a senha como o usuário digita, porque isso sim seria um absurdo.