Descobertos indícios de interceptação de tráfego criptografado do Jabber.ru na Hetzner e na Linode
(notes.valdikss.org.ru)- Foi confirmado que conexões XMPP STARTTLS na porta 5222 estavam sendo interceptadas por um proxy MiTM transparente em um servidor dedicado da Hetzner e em VPSs da Linode do serviço russo XMPP jabber.ru/xmpp.ru
- O atacante obteve vários certificados TLS via Let’s Encrypt e encerrou a conexão criptografada no meio do caminho; o problema veio à tona quando a porta 5222 do jabber.ru na Hetzner passou a apresentar um certificado expirado
- Não foram encontrados sinais de comprometimento dos servidores nem de ARP spoofing no mesmo segmento de rede, e as instâncias da Linode mostraram rota e MAC do gateway diferentes dos de VMs normais, indicando possível reconfiguração da rede de hospedagem
- O MiTM foi confirmado ao menos entre 21 de julho e 19 de outubro de 2023, podendo ter começado em 18 de abril de 2023; 100% das conexões na porta 5222 foram afetadas, enquanto a porta 5223 ficou de fora
- As comunicações do jabber.ru/xmpp.ru nesse período devem ser consideradas comprometidas, e criptografia de ponta a ponta como OMEMO, OTR e PGP só protegia se ambos os lados tivessem verificado as chaves
Interceptação revelada por um certificado expirado
jabber.rué um serviço russo de XMPP iniciado em 2000, também conhecido comoxmpp.ru- Em 16 de outubro de 2023, ao acessar o serviço, apareceu a mensagem “Certificate has expired”, embora todos os certificados instalados no servidor estivessem atualizados
- O comportamento anômalo apareceu apenas na porta 5222 do XMPP STARTTLS e não foi observado em outras portas, como a 5223 usada para XMPP sobre TLS
- Os servidores afetados eram 1 servidor dedicado da Hetzner na Alemanha e 2 servidores virtuais da Linode
- No tráfego da porta 5222, foi observado que o servidor recebia não o ClientHello original do cliente, mas um ClientHello substituído
Resultado da investigação sobre comprometimento interno do servidor
- A investigação se concentrou na possibilidade de invasão do servidor e de spoofing na rede local
- No lado do servidor, os itens a seguir foram verificados, mas nada de anormal foi encontrado
- logs em geral
- horários de modificação de executáveis e bibliotecas
- processos em execução, mapas de memória e dangling file descriptor
- existência de bibliotecas de sequestro
LD_PRELOADem espaço de usuário usandobusyboxcompilado estaticamente - existência de módulos de sequestro em nível de kernel, com dump da memória do kernel via LiME e análise com volatility
- Nos logs do kernel do servidor dedicado da Hetzner, a única exceção encontrada foi um registro de interrupção do link físico de rede por 19 segundos em 18 de julho de 2023
- Os servidores da Linode eram usados apenas como túneis de rota alternativa até o servidor da Hetzner e executavam apenas serviços básicos como SSH e NTP
- Dentro do túnel Hetzner↔Linode, o ServerHello legítimo do servidor da Hetzner era visível, mas era alterado ao sair pela interface de rede da Linode em direção ao cliente
- Ou seja, houve o mesmo tipo de interceptação de conexão criptografada tanto na Hetzner quanto na Linode
Sinais anômalos observados na rede da Linode
- Do ponto de vista de rede, os itens a seguir foram examinados, mas não foram encontrados sinais de sequestro na rede ao redor do servidor
- presença de ARP spoofing no endereço MAC do gateway
- se um único IP respondia várias vezes a requisições ARP no segmento L2
- regras de roteamento anômalas injetadas via ICMP redirect etc.
- regras de Netfilter
- existência de túneis difíceis de detectar, como IPsec
- As máquinas Linode afetadas não conseguiam localizar nem dar ping em IPs vizinhos do mesmo segmento de rede via ARP, mas esses IPs vizinhos funcionavam normalmente a partir de redes externas
- Uma VM de terceiro na Linode, não afetada, conseguia dar ping em hosts vizinhos e estava conectada a um roteador da Cisco Systems
- Já as VPSs afetadas estavam conectadas a um gateway com endereço MAC cujo fabricante não pôde ser identificado
- Essa diferença reforça a possibilidade de que as VMs Linode afetadas estivessem em uma configuração de rede diferente das instâncias normais da Linode, ou isoladas em uma VLAN separada
Certificados forjados e rastros no Certificate Transparency
- No banco de dados de certificate transparency do crt.sh, foram encontrados rogue certificates que não haviam sido emitidos pelos servidores do jabber.ru
- O serviço XMPP legítimo usava dois tipos de certificado
xmpp.ru, *.xmpp.rujabber.ru, *.jabber.ru
- Os certificados emitidos maliciosamente tinham configuração um pouco diferente da dos certificados legítimos
- faltava o wildcard no Subject Alternative Name, ou
jabber.ru, xmpp.rueram agrupados em um único certificado
- A configuração de MiTM do lado da Linode para o domínio
xmpp.ruestava parcialmente incorreta- O servidor original era configurado para oferecer tanto o certificado
jabber.ruquanto oxmpp.ru, conforme o domínio XMPP solicitado - O lado do MiTM oferecia apenas o certificado
xmpp.ru
- O servidor original era configurado para oferecer tanto o certificado
- O horário de emissão do certificado em 18 de julho de 2023 quase coincide com o momento em que o link de rede do servidor da Hetzner caiu por alguns segundos
- Um scanner de rede externo confirmou que, desde pelo menos 21 de julho de 2023, os servidores da Linode apresentavam o certificado
04:b7:85…na porta 5222 - Esse scanner não cobria a faixa da Hetzner
Equipamento na frente da porta 5222 e diferenças de rota
- Foram feitos testes adicionais de rede a partir do exterior contra as VPSs da Linode
- Hosts vizinhos no mesmo segmento da Linode podiam ser alcançados no hop 13 a partir de uma conexão de internet residencial
- A porta 5222 interceptada do servidor Linode
dawn.jabber.rutambém podia ser alcançada no hop 13 - Porém, portas não interceptadas no mesmo servidor, como a SSH na porta 22, só podiam ser alcançadas no hop 14, passando por um hop adicional não público
- Esse resultado indica que o endereço IP da VM Linode estava atrás de um equipamento extra, que tratava diretamente a porta TCP 5222 e roteava as demais portas para o destino real
- Dentro da VPS, não era possível criar novas conexões com source port 5222
- O roteador não respondia a pacotes originados dessa source port
- Também não enviava ICMP error nem Time-to-Live Exceeded para outgoing packet com TTL=0 ou TTL=1
Forma de encerramento do STARTTLS e assinatura de detecção
- Em testes com testssl.sh, o proxy interceptador permitia anonymous ciphers tanto no
xmpp.ruda Linode quanto nojabber.ruda Hetzner - Trata-se de uma má configuração incomum e que pode servir como assinatura para detectar MiTM em XMPP
- Bibliotecas SSL/TLS comuns geralmente são compiladas sem suporte a anonymous cipher, e mesmo quando isso é explicitamente permitido no arquivo de configuração, muitas vezes é difícil fazer o serviço realmente usá-los
- O servidor original não tinha anonymous cipher configurado
- O mesmo comando
testssl.shfoi usado para examinar cerca de 20 serviços XMPP populares, mas não foram encontrados sinais anômalos como suporte a Anonymous NULL Ciphers
Conclusões confirmadas e impacto para usuários
- O atacante obteve vários certificados SSL/TLS via Let’s Encrypt para os domínios jabber.ru e xmpp.ru desde 18 de abril de 2023
- O ataque Man-in-the-Middle para descriptografar o tráfego XMPP de clientes do jabber.ru/xmpp.ru foi confirmado ao menos entre 21 de julho e 19 de outubro de 2023
- Existe a possibilidade de ter começado em 18 de abril de 2023, mas isso não foi confirmado
- O escopo do impacto foi 100% das conexões XMPP STARTTLS na porta 5222, sem incluir a porta 5223
- O atacante falhou ao reemitir os certificados TLS, e o proxy MiTM passou a apresentar um certificado expirado na porta 5222 do jabber.ru na Hetzner
- O ataque MiTM foi interrompido logo após a investigação e os testes de rede em 18 de outubro de 2023, e após a abertura de tickets de suporte na Hetzner e na Linode
- Ainda assim, em pelo menos um servidor da Linode, persistiu escuta passiva na forma de um hop extra de roteamento
- Não houve sinais de invasão dos servidores, e tudo indica que as redes da Hetzner e da Linode foram reconfiguradas para viabilizar esse ataque contra os endereços IP do serviço XMPP
- As comunicações do jabber.ru/xmpp.ru nesse período devem ser consideradas comprometidas
- O atacante podia agir como se estivesse executando ações a partir de uma conta autenticada, mesmo sem conhecer a senha da conta
- Era possível baixar o roster da conta, acessar todo o histórico de mensagens não criptografadas armazenado no servidor, enviar novas mensagens e alterar mensagens em tempo real
- Comunicações com criptografia de ponta a ponta como OMEMO, OTR e PGP só estavam protegidas contra a interceptação quando ambos os lados verificavam as chaves criptográficas
- Os usuários devem verificar no repositório PEP se há novas chaves OMEMO/PGP não autorizadas e trocar suas senhas
Prevenção e monitoramento que operadores podem adotar
- Novas emissões de certificados são registradas em Certificate Transparency, então é possível configurar monitoramento de Certificate Transparency
- Com RFC 8657, CAA Record Extensions for Account URI and ACME Method Binding, é possível restringir o método de emissão de certificados e os identificadores de conta autorizados
- É possível monitorar, por serviços externos, mudanças nos certificados SSL/TLS de todos os serviços
- Também é possível monitorar alterações no endereço MAC do gateway padrão
- O channel binding do XMPP pode detectar MiTM mesmo quando o interceptador apresenta um certificado válido
- Cliente e servidor precisam suportar o mecanismo de autenticação SCRAM PLUS
- Isso não estava ativado no jabber.ru durante o ataque
- Recomendações adicionais do desenvolvedor do ACME Hugo Landau estão reunidas em More recommendations from ACME developer Hugo Landau
Respostas da Hetzner e da Linode
- Em 20 de outubro de 2023, ainda não havia sido recebida resposta suficiente da Hetzner e da Linode
- Na atualização de 3 de novembro de 2023, as duas empresas continuavam sem dar uma resposta adequada sobre o incidente
- A Hetzner respondeu que, para servidores root dedicados e servidores Cloud, fornece apenas hardware, acesso à rede e a infraestrutura necessária, e que não poderia oferecer medidas adicionais de resolução
- A Linode encerrou o ticket dizendo que havia recebido os logs, mas não observou atividade ilegal que afetasse o serviço
- A operação do serviço considera mais provável que Hetzner e Linode tenham sido obrigadas a aplicar essa configuração por conta de interceptação legal determinada pela polícia alemã
- Como outra possibilidade, admite-se que redes internas de Hetzner e Linode possam ter sido invadidas especificamente para atacar o jabber.ru, mas esse cenário é considerado muito menos crível, embora não completamente impossível
1 comentários
Opiniões no Hacker News
Parece muito provável que isso esteja relacionado a uma investigação de cibercrime russa. Se você lê o Krebs ou já frequentou fóruns russos mais obscuros, xmpp.ru deve soar familiar; de fato há esse contexto
Não estou tentando atribuir algo ao operador, mas, quando se opera um serviço anônimo, ele acaba assumindo esse tipo de característica
https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
https://blog.talosintelligence.com/picking-apart-remcos/
https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
O texto em si é realmente interessante e parece um exemplo prático de por que todos deveriam usar um serviço de monitoramento de transparência de certificados
Concordo com a maioria das propostas de mitigação. Se você for um alvo de alto risco, vale considerar sobrepor uma camada adicional de autenticação que não dependa de autoridades certificadoras confiáveis: coisas como Tor onion services, SSH e WireGuard
Concordo que todos os certificados SSL/TLS emitidos entram no escopo da transparência de certificados, e o crt.sh também tem feed RSS
Usar CAA geralmente é uma boa ideia, mas tenho dúvidas se ajudaria neste caso. Isso porque o atacante poderia simplesmente solicitar exatamente a configuração de certificado permitida pelo CAA; talvez ajudasse se fosse possível restringir de forma mais forte um método específico de validação
Também concordo que mudanças em certificados SSL/TLS de todos os serviços devem ser monitoradas por um serviço externo. Alvos de alto risco devem sempre saber quais certificados são válidos e verificá-los
Quanto a monitorar mudanças no endereço MAC do gateway padrão, um ataque mais sofisticado poderia manter o mesmo endereço MAC
Eu não sabia que o “channel binding” do XMPP também consegue detectar um ataque man-in-the-middle que apresente um certificado válido
Claro, isso pressupõe que o nameserver esteja protegido por DNSSEC. Caso contrário, a consulta DNS também pode ser interceptada quando a autoridade certificadora fizer a consulta
Para todas as considerações de segurança, veja a RFC 8657. Essa RFC foi projetada para ser mais fácil de ler do que o normal
Meu post de blog com contexto: https://www.devever.net/~hl/acme-caa-live
Se eles executaram perfeitamente um ataque man-in-the-middle real e esqueceram de renovar o certificado, isso é bem alemão :-)
Ou talvez alguém tenha seguido ordens de forma extremamente literal. Havia uma ordem para configurar o certificado, mas não um requisito para renová-lo automaticamente :)
Arquivo: https://archive.ph/C0jYJ
As teorias são interessantes e, se forem verdadeiras, explicam como eles obtiveram o certificado. A lição aqui talvez seja manter várias sondas em múltiplos provedores, verificar todas as impressões digitais TLS e receber alertas quando uma impressão digital desconhecida aparecer, além de verificar a existência nos logs de transparência de certificados
openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdinSHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16Como todos os certificados SSL/TLS emitidos estão sujeitos à transparência de certificados, é bom configurar um monitoramento de transparência de certificados, como o Cert Spotter, para receber alertas por e-mail quando um novo certificado for emitido para o domínio
Ao restringir os métodos de validação e especificar o identificador exato da conta que pode emitir novos certificados usando as extensões de registro CAA da RFC 8657 — Account URI e ACME Method Binding —, é possível impedir a emissão de certificados para o domínio por outras autoridades certificadoras, contas ACME ou métodos de validação
Deve-se monitorar, por meio de um serviço externo, todas as mudanças nos certificados SSL/TLS de todos os serviços, além de monitorar mudanças no endereço MAC do gateway padrão
Fiquei um pouco curioso porque o endereço MAC não era um endereço administrado localmente. Parece possível que alguém tenha escolhido intencionalmente essa faixa de endereços
https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
Ao pesquisar por
"90:de:01" linodee"90:de:00" linode, parece que endereços desse bloco foram atribuídos recentemente a outras VMs da Linode. Não tenho uma VM da Linode para comparar diretamente agora, mas parece que o tráfego foi roteado para outra VM na infraestrutura da LinodeÉ uma especulação sem base, mas acho que o Jabber virou alvo porque é conhecido por ser usado em mercados da darknet para tráfico de drogas ou outras atividades ilegais
Isso mostra que não dá para confiar só em “está criptografado, então tudo bem”. No mínimo, as mensagens deveriam ser criptografadas com PGP
Também fico curioso se o PGP pode ser quebrado por computadores quânticos e se no futuro surgirá algum reforço contra esse tipo de ataque. Se mensagens forem coletadas em massa em formato criptografado, no fim a descriptografia pode ser só questão de tempo
E parece que algo assim acontece com quase todo tráfego web que conseguem obter. Veja https://en.wikipedia.org/wiki/Utah_Data_Center
Claro que trocar chaves com segurança com um vendedor anônimo de drogas na internet é algo propenso a erros
https://therecord.media/genesis-market-takedown-cybercrime
O PGP tem muitos problemas, e muita gente recomenda evitá-lo. Ex.: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780
Comunicações com criptografia de ponta a ponta como OMEMO, OTR e PGP só ficam protegidas contra interceptação quando ambos os lados verificam as chaves de criptografia. O atacante teria que montar um ataque de intermediário separado para cada método de criptografia de ponta a ponta usado
Alguns clientes XMPP que vi nem deixavam usar se você não marcasse explicitamente que verificou uma determinada identidade criptográfica
Ainda assim, é um bom lembrete. Se você nunca olhou e lidou com um número absurdamente longo, ou algo equivalente, é difícil dizer que a criptografia de ponta a ponta realmente foi estabelecida
Há uma parte dessa história que não entendo. Se era interceptação legal, por que Hetzner e Linode configurariam uma interceptação por intermediário com certificados e chaves LE separados?
Eles poderiam simplesmente ter extraído a chave privada TLS diretamente da RAM ou do armazenamento do VPS. Mesmo em um servidor físico dedicado, seria possível reiniciar sem aviso, fazer um dump da RAM e extrair a chave privada
A extração da chave privada não apareceria nos logs de CT, então seria muito mais discreta e, na prática, difícil de detectar
Outra possibilidade é que um lado fosse “busca” e o outro “interceptação”, com níveis de autorização diferentes. Mas não conheço bem a situação jurídica atual na Alemanha
Isso soa como um método tão padrão para órgãos de aplicação da lei que deve existir equipamento pronto para isso
Um usuário já havia postado isso no Reddit há 3 dias: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...
Fico me perguntando se existe alguma forma de exigir legalmente um comentário da Hetzner/Linode sobre essa situação. Parece bastante provável que por trás da interceptação haja alguma agência governamental ou polícia
Por outro lado, se não for interceptação legal, não acho que a Hetzner teria permitido. Isso também seria uma violação da lei