Copy Sync Corrige Vulnerabilidade Crítica de Man-in-the-Middle na Troca de Senhas e Links
O serviço Copy Sync, projetado para troca segura de informações sensíveis entre dispositivos, implementou uma correção para uma falha de segurança "man-in-the-middle" (MITM). A atualização aborda a forma como as chaves de criptografia eram obtidas, garantindo maior proteção contra interceptação de dados.
MundiX News·20 de junho de 2026·6 min de leitura·👁 4 views
Um mês atrás, apresentei o Copy Sync, um serviço de troca de informações sensíveis e privadas entre dispositivos, concebido para que meu servidor não pudesse ler suas senhas e links. O texto é criptografado diretamente no seu dispositivo, e o que chega ao servidor é um conjunto de dados cifrados, para os quais eu não possuo a chave.
Muitos questionaram nos comentários: "de onde os dispositivos obtêm as chaves de criptografia?" Essa é uma pergunta pertinente. E na própria publicação original, admiti que havia um ponto fraco. É exatamente isso que estou corrigindo agora.
A Vulnerabilidade Existente
Em termos simples, para que um dispositivo (Dispositivo A) criptografe uma mensagem para outro dispositivo (Dispositivo B), ele precisa da "chave pública" do Dispositivo B. Pense nisso como uma caixa de correio aberta, onde qualquer um pode depositar uma carta, mas apenas o proprietário pode retirá-la. A questão era: de onde o Dispositivo A obtinha essa "caixa de correio"?
Ele a solicitava ao meu servidor. E é aí que reside o problema. E se o servidor (ou alguém que o tenha comprometido) substituísse a chave pública legítima do seu dispositivo por uma falsa? Nesse cenário:
Seu Dispositivo A criptografaria a mensagem para a "caixa de correio" falsa.
O servidor interceptaria, leria a mensagem, a reempacotaria na "caixa de correio" real e a enviaria adiante.
Seu Dispositivo B receberia a mensagem como se nada tivesse acontecido.
Ambos os seus dispositivos estariam satisfeitos, mas alguém no meio teria lido tudo. Isso é conhecido como ataque "man-in-the-middle" (MITM). O mais frustrante é que a criptografia em si não era o problema; ela era perfeita. O problema era que a mensagem estava sendo criptografada para o destino errado, e essa substituição foi orquestrada por quem não deveríamos confiar: meu próprio servidor.
É inaceitável que meu serviço, que promovia a ideia de "nada para ler", pudesse, neste cenário, ter acesso aos seus dados. Isso precisa mudar.
A Solução Implementada
A solução é um método antigo e comprovado, similar ao que é usado no Signal e WhatsApp quando exibem o "código de segurança". A ideia é simples:
Cada chave (ou "caixa de correio") possui uma "impressão digital" curta – um conjunto de letras e números que pode ser calculado de forma única a partir da chave. É como uma impressão digital humana: cada chave tem a sua, e ela é sempre a mesma para uma dada chave.
Você abre o Copy Sync em ambos os seus dispositivos e compara as impressões digitais visualmente. Se elas coincidirem, significa que os dispositivos estão usando a mesma chave real, e ninguém se intrometeu no meio. Se o servidor tentou substituir a chave, as impressões digitais serão diferentes, e você será alertado. Essa impressão digital não pode ser falsificada, pois está intrinsecamente ligada à chave.
Cinco segundos de verificação e um ataque MITM, que antes permitia "ler tudo sem ser notado", se torna "detectado na primeira comparação".
A Implementação Crucial da Confiança
Agora, o ponto mais importante, o motivo principal desta publicação: quando você compara as impressões digitais e pressiona "Comparado", essa confirmação precisa ser armazenada. Eu tive a tentação de tornar isso "conveniente": salvar essa confirmação no servidor para que ela se sincronizasse entre os dispositivos.
Eu não fiz isso. Consciente e deliberadamente.
Pense bem: contra quem estamos nos protegendo? Contra o servidor. Se eu confiasse ao mesmo servidor o armazenamento da marcação "esta chave é confiável", um invasor simplesmente marcaria a chave falsa como "verificada", e toda a proteção se tornaria um teatro. Não se pode colocar a guarda da porta para vigiar a própria porta que se está trancando.
Portanto, a marcação "comparado" vive exclusivamente no seu navegador e nunca é enviada ao servidor. Isso tem um efeito colateral positivo: a marcação está ligada à chave em si. Se o servidor tentar substituir a chave amanhã, a marcação "verificado" será automaticamente removida, e o dispositivo exibirá novamente "não comparado". Você notará que algo mudou. A substituição de chave reseta automaticamente a confiança – isso não é um bug, é a proteção em ação.
O preço é justo: você precisará comparar em cada dispositivo separadamente. Mas isso é infinitamente melhor do que confiar a "verificação" à entidade que você está verificando.
Bônus: Conexão de Segundo Dispositivo via QR Code
Adicionei também uma conveniência. Anteriormente, para adicionar um segundo dispositivo, era necessário inserir uma senha. Agora, o primeiro dispositivo exibe um QR code; você o escaneia com o segundo dispositivo e pronto, você está conectado. Sem senhas.
E aqui está um detalhe importante no mesmo espírito: o QR code transmite apenas um "passe" de uso único (válido por 5 minutos e funciona apenas uma vez).
As chaves de criptografia não são transmitidas por ele. O segundo dispositivo cria suas próprias chaves diretamente em seu local, e elas nunca saem de lá. Assim, mesmo que o QR code seja interceptado, ele não fornecerá acesso aos seus dados.
Transparência sobre o que ainda Falta
Assim como na publicação anterior, sou transparente sobre as desvantagens:
Comparação manual: Funciona apenas se você realmente comparar as impressões digitais. Se não comparar, a proteção não será eficaz. Não estou forçando isso, mas é um instrumento, não um escudo automático.
Serviço ainda não notifica automaticamente: O serviço não avisa se a chave mudou; ele apenas remove a marcação "verificado". Uma notificação automática "ei, a chave mudou!" é a próxima tarefa.
Continua sendo um projeto pessoal (pet-project): A versão web está funcionando, mas extensões e aplicativos móveis ainda estão nos planos. O código continua totalmente aberto – você pode verificar por si mesmo, em vez de apenas acreditar na minha palavra.
Links Úteis:
Site:copysync.ru (crie dois dispositivos, conecte o segundo via QR e compare as impressões digitais – você verá tudo com seus próprios olhos)
Estou aberto a perguntas e críticas, especialmente daqueles com conhecimento em segurança. Se você encontrar uma forma de contornar a verificação, isso é mais valioso para mim do que um simples "like".
E uma pergunta para vocês: vocês já compararam o "código de segurança" no Signal ou WhatsApp? Ou é algo que todos veem, mas ninguém realmente clica?
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Um mês atrás, apresentei o Copy Sync, um serviço de troca de informações sensíveis e privadas entre dispositivos, concebido para que meu servidor não pudesse ler suas senhas e links. O texto é criptografado diretamente no seu dispositivo, e o que chega ao servidor é um conjunto de dados cifrados, para os quais eu não possuo a chave.
Muitos questionaram nos comentários: "de onde os dispositivos obtêm as chaves de criptografia?" Essa é uma pergunta pertinente. E na própria publicação original, admiti que havia um ponto fraco. É exatamente isso que estou corrigindo agora.
A Vulnerabilidade Existente
Em termos simples, para que um dispositivo (Dispositivo A) criptografe uma mensagem para outro dispositivo (Dispositivo B), ele precisa da "chave pública" do Dispositivo B. Pense nisso como uma caixa de correio aberta, onde qualquer um pode depositar uma carta, mas apenas o proprietário pode retirá-la. A questão era: de onde o Dispositivo A obtinha essa "caixa de correio"?
Ele a solicitava ao meu servidor. E é aí que reside o problema. E se o servidor (ou alguém que o tenha comprometido) substituísse a chave pública legítima do seu dispositivo por uma falsa? Nesse cenário:
Seu Dispositivo A criptografaria a mensagem para a "caixa de correio" falsa.
O servidor interceptaria, leria a mensagem, a reempacotaria na "caixa de correio" real e a enviaria adiante.
Seu Dispositivo B receberia a mensagem como se nada tivesse acontecido.
Ambos os seus dispositivos estariam satisfeitos, mas alguém no meio teria lido tudo. Isso é conhecido como ataque "man-in-the-middle" (MITM). O mais frustrante é que a criptografia em si não era o problema; ela era perfeita. O problema era que a mensagem estava sendo criptografada para o destino errado, e essa substituição foi orquestrada por quem não deveríamos confiar: meu próprio servidor.
É inaceitável que meu serviço, que promovia a ideia de "nada para ler", pudesse, neste cenário, ter acesso aos seus dados. Isso precisa mudar.
A Solução Implementada
A solução é um método antigo e comprovado, similar ao que é usado no Signal e WhatsApp quando exibem o "código de segurança". A ideia é simples:
Cada chave (ou "caixa de correio") possui uma "impressão digital" curta – um conjunto de letras e números que pode ser calculado de forma única a partir da chave. É como uma impressão digital humana: cada chave tem a sua, e ela é sempre a mesma para uma dada chave.
Você abre o Copy Sync em ambos os seus dispositivos e compara as impressões digitais visualmente. Se elas coincidirem, significa que os dispositivos estão usando a mesma chave real, e ninguém se intrometeu no meio. Se o servidor tentou substituir a chave, as impressões digitais serão diferentes, e você será alertado. Essa impressão digital não pode ser falsificada, pois está intrinsecamente ligada à chave.
Cinco segundos de verificação e um ataque MITM, que antes permitia "ler tudo sem ser notado", se torna "detectado na primeira comparação".
A Implementação Crucial da Confiança
Agora, o ponto mais importante, o motivo principal desta publicação: quando você compara as impressões digitais e pressiona "Comparado", essa confirmação precisa ser armazenada. Eu tive a tentação de tornar isso "conveniente": salvar essa confirmação no servidor para que ela se sincronizasse entre os dispositivos.
Eu não fiz isso. Consciente e deliberadamente.
Pense bem: contra quem estamos nos protegendo? Contra o servidor. Se eu confiasse ao mesmo servidor o armazenamento da marcação "esta chave é confiável", um invasor simplesmente marcaria a chave falsa como "verificada", e toda a proteção se tornaria um teatro. Não se pode colocar a guarda da porta para vigiar a própria porta que se está trancando.
Portanto, a marcação "comparado" vive exclusivamente no seu navegador e nunca é enviada ao servidor. Isso tem um efeito colateral positivo: a marcação está ligada à chave em si. Se o servidor tentar substituir a chave amanhã, a marcação "verificado" será automaticamente removida, e o dispositivo exibirá novamente "não comparado". Você notará que algo mudou. A substituição de chave reseta automaticamente a confiança – isso não é um bug, é a proteção em ação.
O preço é justo: você precisará comparar em cada dispositivo separadamente. Mas isso é infinitamente melhor do que confiar a "verificação" à entidade que você está verificando.
Bônus: Conexão de Segundo Dispositivo via QR Code
Adicionei também uma conveniência. Anteriormente, para adicionar um segundo dispositivo, era necessário inserir uma senha. Agora, o primeiro dispositivo exibe um QR code; você o escaneia com o segundo dispositivo e pronto, você está conectado. Sem senhas.
E aqui está um detalhe importante no mesmo espírito: o QR code transmite apenas um "passe" de uso único (válido por 5 minutos e funciona apenas uma vez).
As chaves de criptografia não são transmitidas por ele. O segundo dispositivo cria suas próprias chaves diretamente em seu local, e elas nunca saem de lá. Assim, mesmo que o QR code seja interceptado, ele não fornecerá acesso aos seus dados.
Transparência sobre o que ainda Falta
Assim como na publicação anterior, sou transparente sobre as desvantagens:
Comparação manual: Funciona apenas se você realmente comparar as impressões digitais. Se não comparar, a proteção não será eficaz. Não estou forçando isso, mas é um instrumento, não um escudo automático.
Serviço ainda não notifica automaticamente: O serviço não avisa se a chave mudou; ele apenas remove a marcação "verificado". Uma notificação automática "ei, a chave mudou!" é a próxima tarefa.
Continua sendo um projeto pessoal (pet-project): A versão web está funcionando, mas extensões e aplicativos móveis ainda estão nos planos. O código continua totalmente aberto – você pode verificar por si mesmo, em vez de apenas acreditar na minha palavra.
Links Úteis:
Site:copysync.ru (crie dois dispositivos, conecte o segundo via QR e compare as impressões digitais – você verá tudo com seus próprios olhos)
Estou aberto a perguntas e críticas, especialmente daqueles com conhecimento em segurança. Se você encontrar uma forma de contornar a verificação, isso é mais valioso para mim do que um simples "like".
E uma pergunta para vocês: vocês já compararam o "código de segurança" no Signal ou WhatsApp? Ou é algo que todos veem, mas ninguém realmente clica?
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
