Um pesquisador de segurança publicou detalhes sobre dois problemas de segurança do Tor e promete lançar mais três.
Na semana passada, um pesquisador de segurança publicou detalhes técnicos sobre duas vulnerabilidades que afetam a rede Tor e o navegador Tor.
Nas postagens do blog na semana passada e hoje, o Dr. Neal Krawetz disse que estava publicando detalhes sobre dois supostos zero dias após o Projeto Tor falhar repetidamente em abordar vários problemas de segurança que ele relatou nos últimos anos.
O pesquisador também prometeu revelar pelo menos mais três dias Tor zero, incluindo um que pode revelar o endereço IP do mundo real dos servidores Tor.
Abordado para comentar as intenções do Dr. Krawetz, o Projeto Tor não respondeu a uma solicitação de comentário e forneceu detalhes adicionais sobre sua posição sobre o assunto.
A PRIMEIRA EMISSÃO DE SEGURANÇA
O Dr. Krawetz, que opera vários nós do Tor e possui um longo histórico de localização e relatório de erros do Tor, divulgou o primeiro problema de segurança do Tor na semana passada.
Em uma postagem de blog datada de 23 de julho, o pesquisador descreveu como empresas e provedores de serviços de Internet poderiam impedir que os usuários se conectassem à rede Tor examinando as conexões de rede em busca de “uma assinatura de pacote distinta”, exclusiva do tráfego do Tor.
O pacote pode ser usado como uma maneira de impedir que as conexões do Tor iniciem e efetivamente banam completamente o Tor – um problema que os regimes opressivos provavelmente abusarão.
Hoje, em uma postagem de blog compartilhada com o ZDNet, o Dr. Krawetz divulgou um segundo problema. Este, como o primeiro, permite que os operadores de rede detectem o tráfego do Tor.
No entanto, embora o primeiro problema possa ser usado para detectar conexões diretas com a rede Tor (para os nós de proteção do Tor), o segundo pode ser usado para detectar conexões indiretas.
Essas são as conexões que os usuários fazem com as pontes do Tor, um tipo especial de ponto de entrada na rede Tor que pode ser usado quando empresas e ISPs bloqueiam o acesso direto à rede Tor.
As pontes do Tor atuam como pontos proxy e retransmitem as conexões do usuário à própria rede Tor. Por serem servidores Tor sensíveis, a lista de pontes Tor é constantemente atualizada para dificultar o bloqueio dos ISPs.
Mas Krawetz diz que as conexões com as pontes Tor também podem ser facilmente detectadas, usando uma técnica semelhante de rastreamento de pacotes TCP específicos.
“Entre a minha entrada anterior no blog e esta, agora você tem tudo o que precisa para aplicar a política [de bloquear o Tor em uma rede] com um sistema de inspeção de pacotes com estado em tempo real. Você pode impedir que todos os usuários se conectem ao Tor rede, sejam eles conectados diretamente ou usando uma ponte “, disse Krawetz.
Ambas as questões são especificamente preocupantes para usuários de Tor residentes em países com regimes opressivos.
DISSATISFAÇÃO PARA A POSIÇÃO DE SEGURANÇA DO PROJETO TOR
A razão pela qual o Dr. Krawetz está publicando essas questões no Tor é que ele acredita que o Projeto Tor não leva a segurança de suas redes, ferramentas e usuários com seriedade o suficiente.
O pesquisador de segurança cita incidentes anteriores quando tentou relatar bugs ao Projeto Tor apenas para saber que eles estavam cientes do problema, trabalhando em uma correção, mas nunca implantando a correção. Isso inclui:
- Um bug que permite que os sites detectem e coloquem impressões digitais nos usuários do navegador Tor pela largura da barra de rolagem, sobre a qual o Projeto Tor conhece desde pelo menos junho de 2017.
- Um bug que permite que os adversários da rede detectem servidores de ponte Tor usando sua porta OR (roteamento Onion), relatado há oito anos.
- Um bug que permite que invasores identifiquem a biblioteca SSL usado pelos servidores Tor, relatado em 27 de dezembro de 2017.
Todas essas questões ainda não foram resolvidas, o que levou o Dr. Krawetz no início de junho de 2020 a abandonar sua colaboração com o Projeto Tor e adotar a atual abordagem de envergonhar publicamente a empresa e agir.
I'm giving up reporting bugs to Tor Project. Tor has serious problems that need to be addressed, they know about many of them and refuse to do anything.
I'm holding off dropping Tor 0days until the protests are over. (We need Tor now, even with bugs.) After protests come 0days.
— Dr. Neal Krawetz (@hackerfactor) June 4, 2020
“Estou desistindo de relatar bugs para o Tor Project. Tor tem sérios problemas que precisam ser resolvidos, eles conhecem muitos deles e se recusam a fazer qualquer coisa.
Estou adiando a entrega do Tor 0 dias até os protestos terminarem. (Precisamos do Tor agora, mesmo com bugs.) Depois dos protestos, chegam 0 dias.” Diz o Tweet.
Atualizado às 20:30 ET, 30 de julho:
O Projeto Tor respondeu às duas postagens do Dr. Krawetz. É uma resposta longa detalhando cada problema, que estamos reproduzindo na íntegra abaixo. Em resumo, a resposta do Projeto Tor é que eles estão cientes dos problemas relatados pelo pesquisador, mas diferem nas ameaças que representam para os usuários, alegando que não podem ser aplicados em escala. A resposta completa está abaixo:
“Estamos trabalhando na primeira questão levantada na postagem do blog publicada em 7/23 (largura da barra de rolagem) aqui: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22137. O blog post afirma que a largura da barra de rolagem de um usuário do Navegador Tor pode ser usada para
distinguir qual sistema operacional eles estão usando. Existem outras maneiras de descobrir o sistema operacional de um usuário do Navegador Tor. Isso é conhecido e documentado publicamente. Quando o Tor Browser não comunica o sistema operacional de seu usuário, a usabilidade diminui. Os sites comumente usados deixam de funcionar (por exemplo, Google Docs). A desvantagem de segurança da detecção do sistema operacional é leve (você ainda pode se misturar com todos os outros que usam esse sistema operacional), enquanto a troca de usabilidade é bastante extrema. O Tor Browser tem como objetivo final eliminar esses vazamentos de privacidade sem quebrar as páginas da web, mas é um processo lento (especialmente em um navegador como o Firefox) e vazar as mesmas informações de várias maneiras não é pior do que vazá-las uma vez. Portanto, enquanto apreciamos (e precisamos) relatórios de erros como esse, estamos lentamente analisando os vários vazamentos sem interromper ainda mais a Web, e isso leva tempo.
“A segunda afirmação no primeiro post publicado em 7/23 descreve uma maneira de reconhecer o tráfego Tor de baunilha com base em como ele usa TLS com regras de firewall. O tráfego do Tor de impressão digital é um problema bem conhecido e documentado. É um problema que foi discutido por mais de uma década (exemplo: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/106-less-tls-constraint.txt.) Corrigindo a maneira como o tráfego do Tor pode ter impressões digitais pelo uso do TLS é um passo muito pequeno na corrida armamentista pela censura. Decidimos que não devemos imitar certs SSL normais, porque é uma luta que não podemos vencer. Nosso objetivo é ajudar as pessoas a se conectarem ao Tor a partir de redes censuradas A pesquisa mostrou que fazer com que seu tráfego pareça com outra forma de tráfego geralmente leva a falhas (http://www.cs.utexas.edu/~amir/papers/parrot.pdf) .A estratégia que Tor decidiu seguir é melhor e mais amplamente aplicável, e essa estratégia está desenvolvendo melhores transportes conectáveis.O Tor possui toda uma equipe anti-censura enfrentando esse problema e tem recursos destinados a esse propósito específico.
“A postagem do blog publicada em 30/7 está correta ao sugerir que uma árvore de decisão bem calibrada pode ser altamente eficaz na detecção de obfs4; isso é uma fraqueza do obfs4. No entanto, o que funciona na sala de estar de alguém não necessariamente funciona na nação. escala: executar uma árvore de decisão em muitos fluxos TCP é caro (mas não impossível) e é preciso trabalhar para calibrá-la.Quando se considera a eficácia disso, também é preciso levar em conta a falácia da taxa básica: a proporção entre o tráfego evitado e o tráfego não contornado não é 1: 1, o que significa que a taxa de falsos positivos / negativos de 1% (o que parece baixo!) ainda pode resultar em falsos positivos superando significativamente os positivos verdadeiros.Dito isso, o obfs4 é certamente vulnerável a essa classe de ataque. O post diz “No entanto, não conheço divulgação pública para detectar e bloquear obfs4.” Há trabalhos na literatura acadêmica. Ver artigo de Wang et al. No CCS’15: https://censorbib.nymity.ch/#Wang2015a Veja também o pape NDSS’20 de Frolov et al. r: https://censorbib.nymity.ch/#Frolov2020a A publicação do blog cita o documento FOCI’18 de Dunna para apoiar sua alegação de que o GFW pode detectar obfs4. Isso deve ser um mal-entendido. Na página 2, o artigo diz: “Achamos que os dois transportes conectáveis mais populares (Meek [7] e Obfs4 [18]) ainda são eficazes para evitar o bloqueio do Tor pela GFW (Seção 5.1)”. A postagem do blog também cita outra postagem para apoiar a mesma reivindicação: https://medium.com/@phoebecross/using-tor-in-china-1b84349925da. Esta postagem do blog indica corretamente que as pontes obfs4 distribuídas pelo BridgeDB estão bloqueadas, enquanto as pontes privadas obfs4 funcionam. Isso significa que os censores não estão bloqueando o protocolo obfs4, mas são capazes de interceptar informações de ponte de nossos distribuidores. É preciso distinguir o protocolo da maneira como distribuímos terminais.
“As descobertas publicadas hoje (7/30) são variantes dos ataques existentes (o que é ótimo!), Mas não em 0 dias. Vale a pena investigar, mas são apresentadas com poucas evidências de que eles funcionam em escala”.
O Projeto Tor também discordou da classificação do Dr. Krawetz das questões que ele detalhou no blog como zero-dia. O título foi atualizado de acordo.
Fonte: (https://www.zdnet.com/)
