- jabber.ru e xmpp.ru sofreram um ataque MitM que combinou interceptação de tráfego no caminho do provedor de hospedagem com a emissão indevida de um certificado de Validação de Domínio, expondo uma lacuna de defesa em serviços TLS não web
- O monitoramento de logs de Certificate Transparency e a sondagem de chaves públicas TLS ajudam a encontrar sinais anormais, mas a detecção completa é difícil diante de certificados não registrados em CT e de MitM seletivo
- Implantar ACME-CAA (RFC 8657) junto com DNSSEC permite autorizar a emissão de certificados apenas para uma conta específica de uma CA específica, de modo que não basta ao atacante simplesmente usar a mesma CA
- Ao contrário dos navegadores web, muitos clientes não web não exigem provas de CT (SCT), e os Baseline Requirements do CA/Browser Forum também não tornam obrigatório o registro em CT para todos os certificados
- Operadores devem avaliar ACME-CAA, DNSSEC, monitoramento de CT, Tor onion service e distribuição de jurisdição, e usuários devem tratar criptografia de ponta a ponta e verificação de fingerprint como linha básica de defesa
Estrutura central do incidente
- Os operadores de jabber.ru e xmpp.ru informaram que o serviço sofreu um ataque man-in-the-middle
- O ataque combinou dois elementos
- Hetzner e Linode interceptaram o tráfego destinado às máquinas do serviço
- O atacante obteve de forma indevida um certificado de Validação de Domínio para esse serviço
- A avaliação é de que há alta probabilidade de coordenação pelo Estado alemão, ou pela Alemanha em conjunto com um ou mais outros países
- Outras possibilidades ainda existem
- Hetzner e Linode podem ter atendido voluntariamente, sem coerção legal, a um pedido de escuta de um poder estrangeiro
- Porém, isso resultaria em uma avaliação muito negativa para as duas empresas e pode ser ilegal, então é considerado menos provável
Métodos de detecção e limites
- O primeiro método é monitorar os logs de Certificate Transparency (CT) para encontrar emissões de certificados não solicitadas pelo operador
- Existem alguns serviços que fazem isso
- Ferramentas que filtrem bem apenas certificados não solicitados ainda têm espaço para melhorar
- O segundo método é conectar-se periodicamente ao serviço para verificar se a chave pública do servidor TLS corresponde ao valor esperado
-
Áreas que o monitoramento de CT pode deixar passar
- Mesmo certificados emitidos por uma CA legítima nem sempre são obrigatoriamente registrados em logs de CT
- Os CA/Browser Forum Baseline Requirements ainda não colocam o registro em CT como requisito obrigatório para a CA
- Navegadores web rejeitam certificados sem prova criptográfica de registro em CT, então o registro em CT acaba sendo exigido na prática
- A maioria dos aplicativos clientes não web não verifica nem exige prova de registro em CT no certificado
- Em teoria, o atacante pode obter um certificado não registrado em CT
-
Possibilidade de evasão com MitM seletivo
- Mesmo tentando detectar MitM por meio de sondagens do serviço, o atacante pode identificar conexões de detecção e deixar de aplicar MitM nelas
- No mínimo, as sondagens deveriam ser feitas via Tor para evitar cenários em que sejam facilmente identificadas
- A pilha TLS pode ser fingerprintada por sinais como a ordem de enumeração de TLV, tornando possível distinguir clientes XMPP reais de agentes de sondagem
- Em vez de bloquear apenas sondas conhecidas, o atacante pode fazer MitM apenas no tráfego de pessoas específicas de interesse
- Nenhum dos dois métodos de detecção oferece confiabilidade total
Risco reduzido com ACME-CAA
- Certificados TLS existem para impedir ataques MitM, mas o próprio modelo de Validação de Domínio pelo qual a CA verifica o controle do domínio é vulnerável a MitM
- O risco aumenta se o atacante puder interceptar não apenas parte, mas todo o tráfego destinado ao site vítima
- ACME-CAA(RFC 8657) pode mitigar esse problema em certos cenários
- A ideia central é usar um registro DNS para definir que apenas uma conta específica de uma CA específica pode emitir certificados para o domínio
- Não basta simplesmente usar a mesma CA
- É necessário ter acesso à mesma conta dentro daquela CA
- No Let's Encrypt, isso exige acesso à chave privada ACME usada na solicitação do certificado
- Com base no método de ataque conhecido, avalia-se que a implantação dessa extensão teria impedido o ataque
-
Cuidados na implantação
- Para que o ACME-CAA funcione corretamente, é necessário implantar DNSSEC
- Sem DNSSEC, a consulta DNS da própria CA também pode ser interceptada
- Quem controla a chave de assinatura do DNSSEC consegue contornar essa barreira
- Uma zona DNS protegida por DNSSEC pode ser operada sem entregar a chave de assinatura a terceiros
- Nesse caso, o provedor de hospedagem DNS não tem autoridade para comprometer a zona
- Essa abordagem é considerada a melhor estratégia de implantação
- O atacante pode tentar pressionar o registrador do domínio ou o registro do TLD para alterar a chave de assinatura DNSSEC registrada no domínio
- Essa ação provavelmente chamaria atenção
- Por causa das características de cache do DNS, pode ser difícil impedir que sondagens repetidas detectem a troca de chave
- O atacante também pode tentar pressionar a própria CA a emitir incorretamente o certificado
- Continua existindo vulnerabilidade se uma CA terceirizada violar as regras ou cometer erros
- Os CA/Browser Forum Baseline Requirements exigem que a CA verifique o DNSSEC
- Porém, uma CA terceirizada ainda pode emitir um certificado mesmo sem estar autorizada no registro CAA
- Como o registro em CT não é obrigatório, esse certificado talvez nem seja detectado
Fluxo que um atacante mais habilidoso poderia escolher
- O atacante deste incidente deixou o certificado ilegal expirar, então não era um adversário perfeito
- Com a disseminação de criptografia barata e fácil, espera-se que ataques de nível estatal se tornem mais sofisticados e mais frequentes
- Um atacante estatal mais habilidoso poderia seguir o fluxo abaixo
- Solicitar um certificado não registrado explorando o fato de que a CA não é obrigada a registrar em CT
- Pressionar o provedor de hospedagem a fazer MitM em todo o tráfego destinado à máquina vítima
- Distinguir heurísticamente tráfego de interesse e tráfego de detecção usando fingerprint da pilha TLS e IP de origem
- Usar o MitM para fazer a CA acreditar que o atacante é o controlador legítimo do domínio da vítima
- Se o domínio usar ACME-CAA e DNSSEC, tentar pressionar o provedor de hospedagem DNS, o registrador, o registro do TLD e a CA
Buracos na infraestrutura TLS atual
-
Falta de exigência de CT em clientes TLS não web
- Navegadores web exigem que certificados de CA incluam prova criptográfica de registro em logs de CT
- A maioria dos outros clientes TLS não exige prova de CT e pode aceitar certificados não registrados
- É provável que muitos clientes XMPP também entrem nesse caso
- A verificação de CT não é um recurso que se ativa automaticamente só por linkar com OpenSSL; ela precisa de implementação separada
- Softwares usados em comunicações sensíveis deveriam considerar suporte à exigência de CT
-
Ausência de obrigação de registro em CT para certificados
- Os CA/Browser Forum Baseline Requirements, que são as regras da indústria seguidas pelas CAs, não exigem que certificados sejam registrados em logs de CT
- Considera-se necessário avançar para exigir o registro em CT de todos os certificados
- Se a exigência de CT for implantada universalmente, esse problema pode se tornar tecnicamente irrelevante
-
Falta de serviços de monitoramento de CT
- São necessários mais serviços de monitoramento de CT
- Hoje, um dos principais serviços de alerta de CT é o SSLMate's Cert Spotter
- O preço pode ser pesado para serviços mantidos por voluntários
- O monitoramento de CT deve ser projetado para reduzir falsos positivos e alertar apenas sobre emissões anormais ou aparentemente não autorizadas
-
Falta de transparência no DNSSEC
- Hoje não existe uma infraestrutura criptográfica implantada para detectar mudanças nas chaves DNSSEC configuradas em um domínio
- Se registradores de domínio e registros de TLD forem pressionados ou comprometidos e alterarem as chaves DNSSEC do domínio, a proteção do ACME-CAA pode enfraquecer
- É desejável uma solução de transparência que torne públicas alterações em chaves de zonas DNSSEC
- Essa solução não precisa registrar todos os registros da zona; bastaria registrar mudanças de chave da zona, como registros DS
Recomendações para operadores de serviço
- Para serviços que possam ser alvo de ataques de nível estatal, recomenda-se aplicar contramedidas em ordem de melhor custo-benefício
-
ACME-CAA e DNSSEC
- Implantar ACME-CAA pode dificultar que o atacante engane a CA para emitir um certificado do domínio
- O guia de implantação pode ser consultado em artigo de implantação do ACME-CAA
- As Security Considerations do RFC também trazem observações importantes
- Se for implantar ACME-CAA, é preciso implantar DNSSEC junto
- Se possível, deve-se escolher um provedor DNSSEC em que não seja necessário entregar a chave de assinatura ao provedor
-
Serviços de proxy e monitoramento de CT
- Avalia-se que usar um serviço como Cloudflare coloca o operador em uma situação parecida com fazer MitM de si mesmo
- É preciso assinar um serviço de monitoramento de logs de CT ou verificar os logs manualmente de forma periódica
- SSLMate's Cert Spotter oferece monitoramento automático pago
- Como o Cert Spotter é open source, também é possível hospedá-lo por conta própria
- crt.sh oferece busca manual em logs de CT
-
Distribuição de jurisdição e Tor onion service
- Pode-se considerar distribuição de jurisdição, colocando registrador do domínio, registro do TLD, hospedagem DNS, CA e provedor de hospedagem em países diferentes
- A escolha pode considerar países ou blocos geopolíticos com baixa probabilidade de cooperação entre si
- Oferecer um Tor onion service permite contornar infraestrutura centralizada como TLS e CA
- Em um Tor onion service, a chave pública do serviço é o próprio endereço
- O usuário precisa obter o endereço onion correto por um canal confiável
- Um terceiro pode induzir o usuário a um endereço onion incorreto
-
Sondagem automática via Tor
- Sondagem automática via Tor não é solução completa, mas pode capturar erros amadores que acontecem no mundo real
- O uso de Tor reduz a chance de a sonda ser facilmente identificada
- Para diminuir a chance de fingerprint TLS, é melhor que o software cliente use uma biblioteca TLS amplamente utilizada
- Se possível, é ainda melhor usar o cliente real
- No caso de um serviço XMPP, pode-se usar um cliente XMPP real
- Mesmo quando funciona, isso só detecta a intrusão depois do comprometimento, e nesse ponto os usuários já podem ter sido prejudicados
-
Outros vetores de ataque e pior hipótese
- Se o MitM ficar mais difícil, o atacante tende a recorrer a outros caminhos, como comprometer a própria máquina, roubar chaves privadas ou exfiltrar dados sensíveis
- Um atacante estatal pode pressionar o provedor de VM a fazer dump de memória no nível do hypervisor
- Mesmo servidores dedicados podem ser comprometidos com acesso físico do atacante
- O operador deve recomendar criptografia de ponta a ponta aos usuários e assumir que o serviço pode ter sido comprometido apesar dos melhores esforços
- Avalia-se que criptografia “de ponta a ponta” entregue por aplicação web não oferece proteção significativa
Medidas necessárias para CA, desenvolvedores de clientes e usuários
-
CA/Browser Forum
- Deve exigir o registro de todos os certificados em logs de CT ou ao menos apresentar uma proposta nesse sentido
-
Desenvolvedores de clientes de aplicação
- Devem adicionar e ativar por padrão um recurso que exija Signed Certificate Timestamps (SCTs) no certificado TLS
- O usuário precisa conseguir saber que está recebendo essa proteção
- Como a exigência de prova de CT tem alguma variabilidade, discussões relacionadas também devem ser consideradas
- O software deve ser oferecido como open source, para permitir auditoria pública
- Também é preciso considerar risco de cadeia de suprimentos e a possibilidade de a própria empresa desenvolvedora ser legalmente forçada a comprometer o software
- Canais de distribuição que o desenvolvedor não controla diretamente, como repositórios de pacotes de distribuições Linux, podem ajudar a reduzir danos
-
Usuários finais
- Mesmo que o operador do serviço aja de boa-fé, deve-se assumir que o serviço pode ser comprometido apesar dos melhores esforços
- Se a vida de alguém depende de o serviço não ser comprometido, esse serviço não deve ser considerado confiável
- Em XMPP, deve-se usar tecnologias de criptografia de ponta a ponta como OMEMO ou OTR
- Sempre se deve verificar a fingerprint do interlocutor
- Não se deve fazer criptografia de ponta a ponta com software baseado na web, ou no mínimo deve-se presumir comprometimento
- Se o provedor do serviço oferecer Tor onion service, vale considerar o uso, mas o endereço onion deve ser obtido de uma fonte confiável
-
CAs e autores de padrões
- Se a CA ainda não oferecer suporte a ACME-CAA(RFC 8657), deve considerar implementá-lo
- Mesmo uma CA não baseada em ACME pode implementar ACME-CAA
- Ainda que as regras do CA/Browser Forum permitam certificados não registrados em CT, a CA pode adotar uma política de registrar todos os certificados em CT
- Autores de padrões podem ao menos reavaliar a possibilidade de transparência DNSSEC para registros DS
Avaliação sobre confidential computing
- Se a preocupação inclui comprometimento da máquina pelo próprio provedor de hospedagem, a tecnologia atual de confidential computing não é considerada solução suficiente
- A implantação pode ser melhor do que não fazer nada, mas não deve ser tratada como segura
- Avalia-se que as tecnologias atuais, incluindo AMD e Intel, dependem de chaves-mestras do fornecedor que podem viabilizar backdoors no sistema
- Um atacante de nível estatal pode pressionar o fornecedor a entregar essas chaves, e então essa abordagem deixa de funcionar
- Pode ser possível um modelo de confidential computing que não dependa de chaves-mestras do fornecedor, mas a abordagem atual não atinge esse nível
Materiais relacionados
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: recomendações de mitigação específicas para XMPP
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: relatório do incidente original
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 comentários
Comentários do Hacker News
O resumo do ataque em https://notes.valdikss.org.ru/jabber.ru-mitm/ é interessante
O invasor emitiu vários certificados SSL/TLS para jabber.ru e xmpp.ru com a Let’s Encrypt a partir de 18 de abril de 2023, e foi confirmado que, de 21 de julho a 19 de outubro, pelo menos 100% do tráfego de clientes XMPP STARTTLS na porta 5222 sofreu ataque man-in-the-middle
Depois, ao falhar na reemissão dos certificados, passou a apresentar um certificado expirado na porta 5222 do jabber.ru, e logo após o início da investigação e dos contatos com a Hetzner/Linode o ataque parou, embora em alguns servidores da Linode tenha permanecido uma escuta manual adicional por meio de hops extras de roteamento
Os próprios servidores aparentemente não foram comprometidos, e parece que as redes da Hetzner e da Linode foram reconfiguradas para mirar os IPs do serviço XMPP
Nem essa página nem as páginas linkadas aqui mencionam certificate pinning; não sei se é porque o XMPP não suporta isso, mas se suportasse talvez esse tipo de ataque pudesse ter sido evitado
Infelizmente, o jabber.ru usa um software de servidor de 2016, então essa versão antiga não oferece suporte
Hoje em dia, o certificate pinning traz muitos problemas porque os certificados têm vida curta e são renovados com frequência. Se você pedir ao usuário para permitir um novo certificado todo mês, ele acabará clicando em “Accept” até para certificados de atacantes sem pensar duas vezes
O channel binding funciona independentemente do certificado e garante que o fluxo TLS termine na entidade esperada
É estranho focar na ausência de suporte a CT/SCT em clientes XMPP. Esse ataque usou certificados válidos emitidos pela Let’s Encrypt e também registrados nos logs de CT, então CT/SCT não teria detectado isso
Se houvesse registros CAA rígidos, em um cenário teórico de emissão por outra autoridade certificadora isso poderia ser capturado pela validação de SCT, mas na prática não havia nem CAA, e o channel binding é mais amigável à privacidade e menos dependente de terceiros
Ou seja, conseguiu responder ao protocolo ACME via HTTP hospedado ou gravar registros DNS TXT, o que sugere que a vítima já havia perdido o controle do servidor de processo ou do servidor de nomes
Entendo que certificate pinning só é possível quando você controla o cliente e embute nele os certificados permitidos, contornando toda a infraestrutura de chave pública da web
Em um cenário em que clientes genéricos se conectam, não há como saber quais certificados devem ser aceitos, e é exatamente para isso que existe a infraestrutura de chave pública da web
Claro, mesmo que você forneça seu próprio cliente, o problema apenas sobe um nível, porque o local de onde os clientes baixam o cliente customizado pode ser comprometido e passar a distribuir um cliente malicioso
Nesta lista falta a defesa mais óbvia. É preciso habilitar e, se possível, exigir SCRAM-xxxxx-PLUS como método de autenticação
A ideia das variantes PLUS é simples e eficaz. Em vez de validar apenas com o salt, a validação fica vinculada a uma conexão TLS específica, então a autenticação só é válida dentro de uma única conexão TLS
Isso também é chamado de channel binding
Fico curioso sobre quem são os usuários finais de xmpp.ru e jabber.ru. A ideia seria capturar tráfego entre soldados ou espiões russos? Não gosto de vigilância em massa, mas não entendo por que mirar especificamente em domínios russos
O mais plausível é um cenário de tentar pegar spammers ou operadores de botnet. Jabber/XMPP ainda é bem popular nesse meio do lado russo, e em textos como os do Krebs on Security dá para ver com frequência capturas de tela ou logs mencionando vários servidores como @exploit.in, @jabber.ru etc.
Ainda assim, qualquer que seja a intenção, vigilância em massa continua sendo algo em geral repugnante
Não sei qual é exatamente a proporção entre uso criminoso e não criminoso nesses dois servidores, mas, como no Tor, onde conteúdo claramente ilegal se mistura com usos legítimos, provavelmente também há bastante conversa totalmente comum ali
Por isso, não sou muito favorável a invadir a privacidade para monitorar cibercriminosos arbitrários em países fora da jurisdição, onde a extradição já seria difícil desde o início
Entendo que a Hetzner talvez não tivesse muita escolha a não ser cooperar, se quisesse evitar virar uma Lavabit, mas, como alguém que costumava recomendá-la com frequência, eu ficaria bastante decepcionado se a Hetzner soubesse do ataque man-in-the-middle e o tivesse permitido ou ajudado. Fora isso, considero-a uma das melhores empresas de hospedagem
É transparente, e em geral tem uptime, confiabilidade e suporte melhores do que a maioria dos provedores de nuvem, sem cobrar caro demais. Também merece elogios pelo esforço de tornar o design ecológico uma escolha economicamente inteligente
O “reduzir > reutilizar > reciclar” aparece no reduzir, visível no design KISS. Por exemplo, o telhado alto e inclinado para ajudar na dissipação natural de calor[2], os chassis de servidor que parecem mais um suporte estrutural mínimo com cobertura para fluxo de ar do que um chassi de verdade, e o design de placa-mãe padrão com o soquete girado em 90° para resfriar VRM, CPU e memória com uma única ventoinha[3]
O “reutilizar” aparece nos leilões de servidores. Em vez de descartar hardware antigo, eles o alugam em formato de leilão holandês, evitando tanto o custo de hardware novo quanto o custo ambiental de fabricar tudo de novo a cada geração
Eu usaria ainda mais se eles tivessem servidores dedicados fora da Europa
[1]: O próprio “legal” é difícil de definir. O jornalista de um país é o “agente estrangeiro” de outro, e o “combatente da liberdade” de um país é o “terrorista” de outro
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
O texto diz que “CT é opcional”, mas isso no fim não deveria ser uma decisão do cliente XMPP? Agora que os navegadores praticamente exigem isso, o que impede clientes XMPP de também exigirem CT?
Também não entendo se isso significaria depender de algum armazenamento de confiança que emite certificados que não funcionam no navegador
O problema é que o comportamento de exigir CT quase nunca vem ativado por padrão em bibliotecas TLS. Então o desenvolvedor do cliente XMPP precisa ativar isso deliberadamente, e imagino que atualmente a maioria, ou talvez todos, não façam isso. Claro, isso pode mudar
Este texto propõe usar OTR no XMPP, mas infelizmente o OTRv3 usa criptografia antiga, e o OTRv4 ainda não foi finalizado
https://dustri.org/b/time-to-sunset-otr.html
Para a pergunta “o que um atacante perfeito faria?”, se ele puder obter acesso físico ao computador, parece que haveria alguma forma de extrair dados do dispositivo por meio de uma espécie de interceptação do barramento
Na época da internet discada e da banda larga lenta e de alta latência isso fazia sentido, mas hoje há muitos lugares com fibra rápida e baixa latência até pontos de peering
Quanto mais nos afastamos de data centers e nuvem, mais a infraestrutura da internet pode funcionar do jeito para o qual foi originalmente projetada, e menos ela precisa passar por pontos centralizados de agregação, que hoje são pontos graves de falha e grandes riscos de segurança
Fui ver sobre CAA, mas meu provedor de DNS atual não oferece suporte a esse registro. Existe algum motivo para isso ter precisado ser um tipo novo, em vez de um registro TXT mais comum?
Se não der, é preciso pedir suporte. Registros CAA são um tipo cada vez mais usado, então não oferecer suporte hoje em dia não é exatamente sinal de um bom serviço
Não conheço a discussão de design do CAA, mas é bem provável que isso tenha sido debatido na lista de e-mails da IETF correspondente
Provedores de DNS devem oferecer suporte a vários tipos de RR, e os donos de domínio precisam votar com os registros NS
Há uma lista de provedores de DNS com suporte a CAA em https://github.com/StackExchange/dnscontrol/blob/master/docu...
Pode valer a pena testar se é possível montar um servidor mestre oculto e deixar o provedor apenas como secundário. Já contornei essa limitação desse jeito na Linode
Ficou faltando a opção de operar sua própria autoridade certificadora e escolher com cuidado os certificados-raiz
O provedor pode acessar o host, então é possível inspecionar a operação de fora e o usuário não perceber
Por exemplo, teriam que implantar um módulo de kernel que sobrevivesse até mesmo a uma atualização do kernel e se ocultasse de forma altamente sofisticada. O texto também aborda a análise de dumps brutos de memória
Qual seria a solução técnica fundamental contra esse tipo de ataque por parte de Estados ou atores poderosos equivalentes? Haveria alguma forma de realizar o sonho quase excêntrico de um software que possa ser distribuído livremente, mas que ninguém além do autor possa censurar, interferir ou adulterar?
Um sistema P2P bem construído sobre a infraestrutura atual da internet já seria uma resposta suficiente, ou seria necessário implantar também uma internet mesh global sem fio, de baixa largura de banda?
Espero que o Freenet 2023 evolua para uma experiência de desenvolvedor sem atritos para aplicações P2P