Olá pessoal! Hoje, gostaríamos de falar sobre um ataque antigo e quase esquecido chamado religação de DNS. A primeira conversa sobre o assunto começou em 2007, mas especialistas da área de segurança da informação não prestaram a devida atenção em relação às peculiaridades da operação desse ataque, bem como com poucas consequências tangíveis, como parecia então. Hoje, tentaremos convencê-los do contrário, e você, em particular, demonstrando que no mundo moderno esse ataque encontrou um segundo vento e não parece mais tão inofensivo.
O que é a religação DNS?
Considere o seguinte esquema:
Temos o computador de uma vítima com IP 192.168.0.2 na rede local e também possui um roteador com o endereço IP 192.168.0.1. O objetivo do invasor que gerencia o servidor com o endereço 13.37.13.37 e o nome de domínio hacker.com (também, nosso servidor DNS que contém informações sobre o domínio está girando no ip-shnik) é obter acesso ao roteador na rede local.
Para usar a técnica de religação do DNS, precisamos atrair a vítima para o nosso site malicioso. Suponha que tenhamos sucesso.
Vamos agora examinar em detalhes como o ataque funciona.
Primeiro de tudo, o navegador acessa os servidores DNS com uma solicitação de registro A:
A cadeia de servidores DNS leva ao nosso servidor, que, por sua vez, fornece uma resposta padrão contendo o verdadeiro endereço IP do site malicioso e também indica o TTL necessário, neste caso 59.
Em seguida, o navegador faz uma solicitação HTTP padrão para o IP recebido.
Na próxima etapa, o servidor responde com uma página HTML com código javascript acessando nosso próprio domínio.
Agora, até que o TTL expire e o usuário esteja no site, o javascript recebido acima será executado. Quando o TTL terminar, o navegador solicitará novamente um registro A.
No momento, nosso javascript continua em execução, e o servidor DNS que gerenciamos responderá com um registro A com um endereço IP da rede local, onde o invasor deseja acessar.
Como o domínio, porta e protocolo permanecem inalterados, o SOP não é violado e, como resultado, o navegador acessa o domínio pew.hacker.com, no entanto, ele já bate no roteador cobiçado e inatingível.
Como resultado, recebemos com calma uma resposta do roteador e a redirecionamos para nós mesmos, incorporando a funcionalidade correspondente no código javascript carregado anteriormente.
Então, vamos resumir o acima:
- O usuário visita o site, recebendo um endereço IP real e um pequeno TTL
- Enquanto estiver no site, o navegador faz chamadas para o mesmo domínio em que o usuário está localizado. Assim que o cache expira, o navegador solicita novamente o IP do domínio.
- Além disso, nosso servidor DNS emite, em vez do endereço real, o endereço IP do serviço interno (no nosso caso, o roteador)
- Depois que a solicitação passa pelo domínio para o roteador, e o resultado é enviado a nós pelo javascript pré-carregado pelo usuário com antecedência.
Nós descobrimos isso! Muitos podem ter uma pergunta razoável: “E daí?”, Porque, para operação, você precisa conhecer os endereços IP internos dos serviços, manter o usuário por um certo tempo, etc.
Sim, no entanto, com o advento de serviços de streaming, hospedagem de vídeo, bons sites pornográficos antigos e outras plataformas onde as pessoas permanecem por muito tempo, o invasor terá tempo suficiente para realizar o ataque. Quanto aos endereços, eles geralmente são padrão ou facilmente previsíveis.
Mas isso é tudo na teoria, mas o que na prática? Selecionamos as 4 áreas mais relevantes em 2019, onde houve incidentes relacionados ao ataque de religação do DNS, são eles:
- IoT
- Carteiras de criptografia
- Aplicativos de desktop
- Nuvens
Vamos analisar cada tópico em ordem e descobrir se tudo é realmente tão inofensivo?
Iot
Página inicial do Google
O Google home é um assistente inteligente do Google. Este dispositivo possui (ou possuía no passado) uma API que não requer autenticação para controlar o dispositivo. Ele fornece vários recursos, como:
- Reproduzindo conteúdo
- Digitalizar
- Reiniciar
- Conexão a redes Wi-Fi, etc.
Exemplo de cenário de ataque: um invasor pode desarmar o nome do usuário obtendo as coordenadas dos pontos WIFI mais próximos. Obviamente, nenhuma VPN pode salvá-lo.
Alto-falantes wifi Sonos
Essas colunas do Sonos geram um servidor web na rede local UPnP, que dá acesso a várias páginas interessantes:
- 192.168.1.76:1400/support/review - cospe a saída de alguns comandos UNIX
- 192.168.1.76:1400/tools - permite executar alguns comandos UNIX
Nesse caso, o invasor tem a capacidade de executar o comando traceroute para verificar a topologia da rede interna.
Termostato de rádio CT50
Este é um dos nossos casos favoritos. Este modelo de termostato também possui uma API sem qualquer autorização e permite alterar:
- Modo Clima
- Temperatura
- Modo luz de fundo e outras configurações
Como resultado, um atacante pode suar bastante a vítima, mas falando sério, esse ataque a um termostato, por exemplo, em uma instalação médica, pode levar a conseqüências bastante desagradáveis.
Roku tv
As TVs Roku ainda têm a mesma doença - uma API sem autenticação.
A API permite que você:
- Execute vários aplicativos
- Reproduzir conteúdo
- Realize consultas de pesquisa no sistema etc.
Nesse caso, o máximo que ameaça o usuário é o vazamento de dados confidenciais, o que também é desagradável.
Qualquer roteador WIFI
Quase todo mundo tem esse dispositivo de IoT hoje. Não é segredo que muitos usuários comuns não alteram as senhas padrão dos painéis de administração de seus roteadores. Com a ajuda da religação do DNS, nada nos impede de tentar fazer login com credenciais padrão e obter acesso ao painel de administração. Se o IP local não puder ser encontrado, o WebRTC será resgatado.
Resumo da IoT
Destacamos alguns dos recursos que a religação de DNS fornece ao trabalhar com a IoT:
- Capacidade de cancelar o anonimato do usuário
- Capacidade de digitalizar uma rede local
- Zombar de usuário
- Qualquer coisa, dependendo da funcionalidade do dispositivo IoT
Carteiras de criptografia
Geth
Agora vamos falar sobre carteiras de criptomoedas. O primeiro caso examinado é um cliente para carteiras ethereum chamado Geth. Aqui a caixa do Pandora está no serviço JSON-RPC. Para começar, vamos descobrir o que é. JSON-RPC é um protocolo de chamada de procedimento remoto no formato JSON. Tudo se parece com isso:
A maioria dos clientes executa esse serviço no localhost: 8545 e, por sua vez, fornece um conjunto de funções interessantes, como eth_sendTransaction e assim por diante.
Agora, um exemplo de como você pode obter o saldo e o endereço da carteira sem o conhecimento do usuário e usando o ataque de religação do DNS:
Carteira EOSIO keosd
Em seguida, temos um cliente para carteiras EOSIO. O próprio Keosd inicia no localhost: 8900 e assina automaticamente todas as ações do aplicativo por 15 minutos após a inserção dos dados de autorização. Após se aprofundar na API, é possível encontrar novamente funcionalidades interessantes. Para maior clareza, usando a solicitação mostrada abaixo, você pode obter a chave pública do usuário:
Resumo das carteiras de criptografia:
- um invasor pode roubar dinheiro do usuário
- um invasor pode modificar várias configurações do usuário
- a capacidade de descriptografar o usuário
Aplicativos de desktop
Cliente de transmissão
Eu gostaria de iniciar o bloco de incidentes relacionados aos aplicativos da área de trabalho com uma vulnerabilidade relativamente sensacional no cliente de torrent Transmission.
Aqui, o problema está no mesmo JSON-RPC, que examinamos um pouco mais alto. Nesse caso, permite alterar as configurações do usuário, por exemplo, alterar a pasta para baixar arquivos:
Por um lado, parece nada sério, mas se você especificar o compartilhamento smb controlado pelo invasor em vez da pasta (se o cliente usar o cliente Windows), poderá interceptar o hash do usuário, que poderá ser usado no futuro.
Cliente da web uTorrent
Esse camarada possui em seu arsenal o mesmo serviço JSON-RPC que permite alterar os arquivos de configuração do usuário e fazer o download dos arquivos.
A autenticação é necessária neste caso, mas as credenciais estão disponíveis em http://localhost:19575/users.conf . Como isso pode ser usado?
Primeiro, faça o seguinte pedido:
Após receber o token, alteramos a pasta de download para a pasta na qual estão localizados os programas que são executados quando o sistema é iniciado:
E, finalmente, damos o comando para baixar a carga útil necessária:
Como resultado, o evil.exe será iniciado após a próxima reinicialização.
Minikube
O Minikube é um utilitário de linha de comando para configurar e executar um cluster Kubernetes de modo único em uma máquina virtual no computador local.
Ele sempre trava no 192.168.99.100 e a interface baseada na Web está disponível na porta 3000. Como resultado, um invasor tem a oportunidade de criar um contêiner malicioso com uma pasta compartilhada com o sistema principal.
Primeiro de tudo, você precisa obter o token csrf.
Em seguida, você precisa criar um contêiner e, para isso, envie a seguinte solicitação:
Vamos ver o que ele faz. Nele, indicamos que, ao iniciar o contêiner, precisamos encaminhar o shell reverso e também montar a pasta Usuários no sistema principal:
Ruby on Rails
Existe uma gema para a estrutura do Ruby on Rails que permite executar o código Ruby diretamente no navegador.
Vamos tentar descobrir o que precisamos para isso?
Primeiro, precisamos ir para uma página inexistente:
Em seguida, tentamos acessar o console através do navegador:
Bem, finalmente, formamos uma solicitação para iniciar o aplicativo da calculadora (neste exemplo, o vetor para o MAC OS X):
Aplicativo de desktop da Blizzard
Não apenas desenvolvedores e usuários regulares são suscetíveis a ataques como a religação de DNS, mas também jogadores. Aqui, novamente, encontramos um problema de serviço JSON-RPC ocorrendo neste caso no host local na porta 1120. O serviço possibilita fazer atualizações, alterar configurações e outras várias opções de manutenção.
Nesse caso, a autenticação é suportada, mas passá-la fazendo solicitações do host local não é difícil:
Como resultado, você pode conseguir algo semelhante:
Mais detalhes podem ser encontrados aqui .
Resumo de aplicativos da área de trabalho:
- um invasor pode obter o RCE no sistema principal (também não se esqueça do VM Escape)
- um invasor pode obter acesso a dados confidenciais etc.
Nuvens
Bem, e finalmente, a coisa mais interessante permanece - as nuvens. O ponto principal é que os serviços em nuvem costumam ser usados para hospedar software que analisa os usuários que acessam o site. Por exemplo, clicando no link no cabeçalho do Referer com um navegador sem cabeçalho para rastrear o recurso a partir do qual o cliente foi ao site. Esse vetor de ataque também pode ser usado, porque, em essência, um navegador sem cabeça é um navegador da Web completo sem uma interface gráfica, mas com suporte para DOM, JS e tudo mais.
Voltando aos nossos carneiros, o que podemos fazer neste caso? De fato, para um ataque, precisamos atrasar o usuário (neste caso, o bot) na página. Bem, para isso, podemos usar uma imagem na página que tenha um comprimento de conteúdo mais do que realmente é. Como resultado, o bot pensará que a imagem ainda não foi carregada e permanecerá em nossa página e, em seguida, usamos nossa técnica padrão de religação de DNS.
Como resultado, como enviaremos solicitações de um proxy, podemos fazer muitas coisas engraçadas. Por exemplo:
- digitalizar rede interna
- entre nos serviços internos (teoricamente)
- roubar dados de autorização de outros serviços, etc.
Vamos diretamente para a Amazon. O AWS EC2 possui recursos como o Serviço de Metadados da Instância. Ele permite que qualquer entidade do EC2 use a API REST localizada em 169.254.169.254, que revela informações sobre a instância.
Por exemplo, aqui está uma pequena lista de serviços semelhantes para várias nuvens:
Agora, vamos ver um caso em que nos entregamos à AWS.
Primeiro, deixe o bot fazer uma solicitação para a API:
Na resposta, podemos obter informações confidenciais, por exemplo, créditos em um script que é executado quando a máquina é iniciada:
Em seguida, podemos retirar o nome do nó com o qual continuaremos trabalhando:
A seguir, faremos o seguinte apelo pelo nome já conhecido e - bingo!
Recebemos várias informações do usuário, como AccessKeyId, SecretAccessKey, Token etc.
Após receber esses dados, podemos usá-los para autorização através do cliente do console:
O resultado total:
Vamos destacar os pontos fracos comuns que notamos ao usar um ataque de religação de DNS:
- API sem autenticação
- Serviços locais sem autenticação
- Ignorando o parâmetro Host para solicitar
- Usando http em vez de https
Assim, apesar de vários argumentos de especialistas no campo da segurança prática das informações, um ataque desse tipo nasce novamente na era da IoT, serviços em nuvem, criptomoedas e assim por diante, mesmo apesar da necessidade de atrasar o cliente do lado do invasor, porque no mundo dos cinemas on-line, hospedagem de vídeo e outros serviços que fornecem conteúdo ao usuário, não é difícil fazer isso. Portanto, tenha cuidado ao viajar no mundo on-line, ao comprar outro assistente inteligente e ao desenvolver, é claro.
Fontes: