Relatório livre ESG: gerenciamento de dados sem emenda com Avere FXT
Se você pensar em uma troca Internet, você provavelmente pensa em infra-estrutura que é bem protegida, bem gerida, e difícil de se comprometer. Na realidade, contudo, pode ser diferente. De acordo com a pesquisa feita por Daniel Kharitonov, da Universidade de Stanford, trabalhando com o TraceVector Oscar Ibatullin, existem vulnerabilidades suficientes em roteadores e afins que a troca Internet torna um alvo que é ao mesmo tempo atraente e exploráveis.
O ataque que demonstrar neste papel em Arxiv pode ser montado contra roteadores e switches comuns e "não requer um conhecimento extraordinário de redes ou habilidades de programação especializadas."
Como se costuma dizer em abstrato ", plataformas de rede modernos são capazes de replicação tráfego alvejado e redirecionamento para análise e modificação on-line e off-line, que pode ser uma ameaça muito maior do que a perda do serviço ou outros riscos freqüentemente associadas com tais façanhas."
Assim como Kharitonov e Ibatullin trabalhar sua magia negra?
Eles começam por assumir que um atacante está ciente de uma vulnerabilidade de execução remota de código em um switch ou roteador em uma troca de Internet. Isto não é como um esforço de imaginação, uma vez que os patches rolar em uma base regular. O segundo desafio, mais misterioso é explorar o acesso remoto ao kit para realizar a análise ou modificação do tráfego de passagem através do roteador (digamos).
Como eles escrevem, "o principal desafio é entregar o" interessante "o tráfego para eles de uma maneira que não perturbe o fluxo de dados e permite a conexão eavesdropped para continuar".
Que é bastante fácil se você tiver acesso de comando para os dispositivos de rede. Switches e roteadores podem ser configurados para redirecionar o tráfego de entrada brevemente com as seguintes etapas:
- Capturar o tráfego "interessante" na interface de ingresso em um filtro em cativeiro;
- Flick que o tráfego (com encaminhamento baseado em filtros ou roteamento baseado em política) para o motor de análise do atacante (que se refere o artigo como o "host ajuda"):
- Retorne o tráfego com endereços de origem e destino sem modificações.
Observe que, com exceção do "host ajuda", este é apenas explorando recursos de roteadores, com a única exceção de que uma falha de execução remota de código tem de existir. No entanto, há uma desvantagem:
"Por um lado, se o host remoto ajuda reside (ou atrás), uma rede que suporta fonte verificação via filtro ou um encaminhamento caminho reverso (RPF) recurso, isto torna o fluxo direto do IP2 para IP1 usando IP0 como fonte impossível. Se isso acontecer, o atacante terá que estabelecer um host ajuda na mesma rede onde a origem ou destino de tráfego reside. "
Mais eficaz, os pesquisadores sugerem, é a utilização de recursos de replicação de tráfego que já existem em dispositivos. As pessoas que projetaram espelhos de porta prevê-se que eles devem ser protegidos contra a exploração maliciosa, então eles geralmente restringir onde o tráfego espelhado deve ser enviada - mas com o controle de roteadores vulnerável o suficiente, isso pode ser derrotado.
"Se um atacante controla roteadores R1, R2 e R3, um [encaminhamento de filtro com base - The Register] FBF entrada para pacotes de entrada de IP0 para IP1 pode ser comparada a um próximo hop em direção a S1 com controle de acesso de mídia multicast codificado (MAC) como endereço de destino. Isto irá forçar S1 para replicar o pacote em todas as portas (uma conduta normal para grupos multicast desconhecidos). Os roteadores R2 e R3 vão receber o pacote, R2 irá encaminhá-lo como de costume;. R3 e irá enviá-lo em um túnel em direção a IP2 [a máquina controlada pelo atacante - El Reg] via entrada FBF "
Isso envolve mais do kit, observam os pesquisadores, mas também tem uma maior chance de sucesso.
Outros obstáculos no caminho do atacante existem, mas não são insuperáveis: um potencial invasor precisa ter acesso a SDKs de fornecedores, ou teria que reverter tubos de comunicação engenheiro, e teria que trabalhar como programar o kit com "efêmeros" mudanças de estado que não aparecem em seus logs de configuração. "Esta tarefa é muito menos complexo do que parece, porque a análise inicial é fácil de fazer em um sistema de teste, basta acompanhar os logs e mensagens de processos de manipulação de um PBR rotina ou alteração de configuração FBF". ®
Nenhum comentário:
Postar um comentário