Quando nomes de host internos vazam para a nuvem

• Foi descoberto um caso em que a interface web de um equipamento NAS doméstico envia nomes de host internos, de uso exclusivo local, para um serviço externo
• Um script de relatório de erros do sentry.io incluído na UI web do NAS envia o nome de host interno para fora junto com o stack trace
• Foi observado um comportamento estranho em que o sentry.io tenta fazer uma conexão TLS reversa para esse nome de host, mas não envia a requisição de fato
• Graças a um DNS curinga configurado antecipadamente, foi possível detectar o vazamento, e há risco de exposição grave de informações ao usar nomes de host sensíveis
• Há um problema de segurança potencial em que esse mecanismo pode ser abusado para induzir varreduras de DNS contra hosts arbitrários

---

Instalação do NAS e configuração do nome de host interno

• Foi comprado um equipamento NAS, os drives foram instalados e ele foi conectado à rede doméstica, operando em modo HTTPS
• Foi instalado um certificado TLS curinga para uma subzona de um domínio sem significado na internet pública (ex.: *.nothing-special.whatever.example.com)
• Foi adicionada ao arquivo /etc/hosts uma entrada apenas local, como 172.16.12.34 nas.nothing-special.whatever.example.com, para acessar pelo navegador

Descoberta de acessos inesperados vindos de fora

• Alguns dias após a instalação do NAS, começaram a chegar requisições do mundo externo com o mesmo nome de host
• Esse nome de host era um nome totalmente interno, existente apenas no arquivo /etc/hosts do notebook
• Como já havia sido configurada previamente uma entrada DNS curinga para todo *.nothing-special.whatever.example.com, apontando para uma máquina sob seu controle, foi possível detectar o vazamento
• Toda vez que o NAS era carregado, um host da GCP tentava se conectar apresentando esse nome de host interno como SNI

Causa do vazamento: relatório de erros do sentry.io

• A interface web do NAS inclui uma função de phone home e, como parte disso, envia stack traces para o sentry.io
• Quando o navegador fazia o callback para o sentry.io, ele também transmitia junto o nome de host usado para o equipamento de armazenamento interno
• Foi confirmado que o sentry.io cria uma conexão TLS de volta para esse nome de host, mas não envia nenhuma requisição HTTP real

Implicações de segurança e resposta

• Se o nome de host incluir informações sensíveis (ex.: mycorp-and-othercorp-planned-merger-storage), existe risco de vazamento grave de informações
• Usando esse mecanismo de relatório do Sentry, seria possível induzir varreduras de DNS contra hosts externos arbitrários (o método concreto fica por conta do leitor)
• Como medida de mitigação, foi executado o Little Snitch para bloquear todo esse domínio para todos os aplicativos

[GN⁺]

Comentários do Hacker News

• Parece que as pessoas estão entendendo isso errado. Não é um problema de logs de CT, e sim relacionado a certificados curinga
  O Sentry, ao coletar traces do lado do cliente, extraiu o hostname que enviou a requisição e tentou consultá-lo de novo, sendo bloqueado

  • Talvez tenha sido uma tentativa de buscar o favicon para exibir na UI de traces
  • Mas, com essa arquitetura, pode surgir uma vulnerabilidade de segurança em que o Sentry consegue enviar requisições para IPs arbitrários. Em especial, ele pode acessar repetidamente IPs que reportam tráfego malicioso automaticamente
  • As pessoas estão se confundindo porque o post do blog foi escrito de forma confusa e pouco clara

• Hostnames, por natureza, não são informação privada
  Eles são expostos externamente por vários caminhos, como consultas DNS ou certificados TLS
  Para esconder serviços privados, é melhor colocar o segredo no caminho da URL em vez do hostname
  Por exemplo, fileservice.example.com/my-hidden-service-007-abc123/ é transmitido só via HTTPS, então a exposição é bem menor

  • Claro, mesmo nesse caso, o caminho ainda pode ser enviado a serviços externos como o Sentry, então é importante usar URLs opacas e criar o hábito de não colocar segredos na URL
  • Também houve a pergunta: “Se usar só HTTP, essa exposição diminui?”

• Fiquei curioso se “clown GCP Host” era um termo técnico. No fim, descobri que o autor estava usando isso para satirizar a cloud
  O ponto central do problema é que a interface web do NAS enviava logs ao Sentry contendo hostnames internos
  Numa situação dessas, eu provavelmente trocaria por um SO open source confiável ou bloquearia chamadas ao Sentry com DNS filtering, como PiHole

  • “clown” é uma forma de zombar da cloud das Big Techs; segundo disseram, em IRCs antigos também se usava “clown computing”
    Alguém explicou que usa DNS local e um proxy TLS para bloquear completamente o tráfego de saída
  • Outra pessoa acrescentou que “clown” é um termo antigo para satirizar grandes provedores de nuvem e seus usuários
  • Alguém brincou que, em vez de “clown”, às vezes usa a palavra “weenie”
  • Também apareceu o humor de que “o circo foi embora, mas os palhaços ficaram”

• Por casos assim, considero o uBlock Origin o padrão mínimo de segurança na web
  É grave demais como a maioria das páginas carrega uma infinidade de scripts de terceiros e acaba vazando dados
  Não é a solução definitiva, mas é o melhor que podemos fazer agora

  • Eu também instalei AdGuard Home no roteador, e ele bloqueia de 15% a 20% do tráfego. Dá para sentir o quão pesados são rastreamento e anúncios

• Para evitar esse tipo de problema, é bom colocar um proxy reverso Nginx na frente e injetar cabeçalhos CSP
  Isso não impede que o NAS faça requisições externas por conta própria, mas pode bloquear requisições feitas pelo navegador em seu nome
  Por exemplo, até requisições de avatar da Steam (https://avatars.steamstatic.com/HASH_medium.jpg) podem ser bloqueadas pela política CSP
  Se precisar, dá para liberar só algumas coisas. Também se pode adicionar Referrer-Policy: no-referrer para que o hostname não fique registrado em logs externos

  • Alguém apontou a redundância da expressão “ATM machine”
  • E outra pessoa respondeu em tom de piada: “NPM é bem simples”

• Comprei um Synology NAS e me arrependi várias vezes
  Fora o software da comunidade, quase não dá para fazer nada
  Aplicar SSL com Let's Encrypt também é complicado, e como os caminhos são fora do padrão, é difícil achar onde fica a configuração
  Há muitas reclamações: versão antiga do rsync, falta de utilitários básicos etc. Teria sido melhor usar um NAS baseado em Linux ou BSD

  • Também houve quem dissesse estar satisfeito, porque o Synology é muito estável quando usado apenas como servidor de arquivos. Ainda assim, por causa das políticas fechadas, essa pessoa planeja migrar para um UniFi NAS
  • Também houve a reação de que “querer um servidor e reclamar que um NAS não é um servidor” é contraditório
  • Alguém compartilhou que existe um guia para instalar Debian recente em Synology NAS no fórum Doozan
  • Também surgiu o conselho de “deixar como servidor de arquivos/iscsi e não mexer, porque é muito estável”
  • Em contraste, outra pessoa disse que comprou um modelo RS217 por US$ 100 e foi uma das melhores compras que fez. Usa Synology Office no lugar do Google Docs e ficou impressionada com o acabamento da interface

• Configurei o Sentry recentemente e esse sistema tem um recurso que tenta montar monitoramento de uptime automaticamente
  Quando ele reconhece um host, passa a enviar pings periodicamente e, se o host responder de forma estável por alguns dias, mostra um aviso como “Quer configurar monitoramento de uptime para este host?”

  • Alguém comentou apenas: “oportunidade de expansão”

• Eu, pessoalmente, bloqueio o domínio inteiro do Sentry
  Não é uma solução geral, mas no meu ambiente isso é o melhor

• Servidores de reverse DNS às vezes tentam resolver até endereços de rede interna (ULA, RFC1918)
  Combinando esses dados com outras informações, dá para inferir o estado interno da rede
  Também comentaram que “já capturaram áudio UDP durante coleta na darknet”

  • Em resposta, alguém perguntou: “Esse áudio UDP era tráfego SIP de que ano?”

• No passado, investiguei um fenômeno parecido no Heroku
  Quando se cria um app novo, ele recebe um subdomínio aleatório, mas mesmo sem fazer consulta DNS já chegam requisições de scanners de vulnerabilidade
  Ao perguntar ao Heroku, disseram que isso acontece porque a URL do app novo é publicada em logs de transparência de certificados (CT)

  • Alguém comentou que isso é como colocar uma placa de ‘por favor, me ataquem’ em cada serviço novo, e apontou que os logs de CT deveriam registrar só hashes, não os certificados reais
    Também foi compartilhado o link Como funciona Certificate Transparency
  • Outra pessoa disse: “Eu uso um domínio curinga e assim evito esse problema”, e publicou uma captura de tela (link da imagem)