Capturei 2,5 milhões de pacotes em 3 horas usando o Wireshark no modo monitor, em um único canal no espectro 802.11ac 5GHz, canal 36.
Abri Estatísticas > Conversas no Wireshark, para ver todos os endereços MAC que estavam conversando entre si por Wi-Fi. Posteriormente, salvei a lista de "Conversas" fornecida pelo Wireshark, como uma planilha do Google, compartilhada abaixo para referência e análise.
https://docs.google.com/spreadsheets/d/1RE72s7DYXDhRdMopXQ9zIqNkww6OhzUeZbLeQvYqpPc/edit?usp=sharing
Os dispositivos válidos que vi durante as verificações de "Dispositivos próximos a mim" de aplicativos de gerenciamento de Wi-Fi no Android estão listados na folha "Device_Validity". Os mesmos são coloridos em verde na planilha de Conversação principal. No entanto, apenas as primeiras 1.000 linhas (de 169.242) foram formatadas de alguma maneira, para manter o desempenho razoável.
Agora, para o problema: estou vendo nos logs do Wireshark várias versões modificadas dos endereços MAC dos meus dispositivos e dos dispositivos de meus vizinhos .
Por mutado, quero dizer que, se 18:56:80:7e:0d:c9for um endereço MAC válido, estou vendo as seguintes variantes nos endereços de origem/destino ou transmissor/receptor dos pacotes observados no Wireshark:
18:56:80:7e:0d: 49 - onde apenas os últimos 1 ou 2 octetos são alterados. Isso pode ser válido se o dispositivo tiver várias interfaces de rede com endereços MAC levemente modificados.
19 :56:80:7e:0d:c9 - onde os primeiros N octetos são alterados. Isso pode acontecer quando os pacotes passam por extensores de alcance . Embora AFAIK geralmente 3 octetos sejam alterados, não apenas 1.
Mutações aparentemente aleatórias do endereço MAC original conforme abaixo:
18:56:80:7e:0d: a9
18:56:80:7e:0d: 29 - quantas interfaces um dispositivo pode ter?
18:56:80:7e: 4d:76
18:56:80:7e: 6d:39
18:56:80:7e: ad:05 - Existem tantos dispositivos adicionais do mesmo fabricante nas proximidades, que de alguma forma foram perdidos durante as verificações de “Dispositivos próximos a mim” que mencionei acima? É possível, mas improvável
00 :56:80:7e:0d:c9 - Prefixo alterado duas vezes, uma para 19:56 e outra para 00:56. Quantos extensores de alcance existem? E, novamente, apenas mudando o primeiro octeto?
02 :56:80:7e:0d:c9 - Prefixo alterado novamente.
02 :56:80:7e: ad:2b - 3 octetos alterados em ambas as extremidades.
98:6f :80:7e:0d: 05 - 3 octetos alterados em ambas as extremidades.
01:18:56:80:7e:0d - todos os octetos deslocados para a direita e preenchidos com 01 à esquerda.
4b:27 :80:7e:0d: 63 - outra substituição múltipla.
18:56:80:7e: b9:c4 - e muitos muitos mais
Encontrei as 14 mutações acima realizando uma pesquisa simples pela substring do octeto 80:7ena planilha do Google e observando apenas 55 dos 7354 resultados que apareceram. Muitas outras mutações ainda podem ser encontradas, simplesmente procurando por diferentes substrings de octetos de endereços MAC válidos ou examinando mais resultados da pesquisa.
Além disso, se você classificar a planilha do Google fornecida por uma das colunas "Endereço não resolvido" e analisar a vizinhança de qualquer MAC válido, verá que os endereços continuam mudando até que quase todos os octetos sejam diferentes .
E isso é para apenas um dispositivo . Mutações semelhantes são encontradas em vários dispositivos, tanto meus quanto do meu vizinho. Segue mais um conjunto de exemplos:
5c:f9:38:a7:d9:32 - Original
d0 :f9:38:a7:d9:32
32 :f9:38:a7:d9:32
30:fa:38:a7:d9:32
fe :f9: 38:a7:d9:32
5e :f9:38:a7:d9: 5a
00:5c:f9:38:a7:d9 - deslocado para a direita e prefixado
f9:38:a7:d9:32:98 - deslocado para a esquerda e sufixado
59 :f9:38:a7:d9: f2 - e a d9: b2
5c:f9:38:a7: 71:2d - dispositivo inexistente
5c:f9:38:a7: 41:45 - dispositivo inexistente
e muito mais
Esses são os padrões que cataloguei para apenas dois dispositivos , entre mais de uma dúzia de dispositivos dentro do alcance do meu monitor. Para qualquer um dos dispositivos na guia Device_Validity da planilha, esses padrões de máscara/deslocamento de bits são facilmente observados pesquisando substrings de octetos específicos na guia Conversations.
Padrão de tráfego de rede:
Esses endereços MAC deslocados ou mascarados não estão participando de solicitação/resposta de beacon, quadros de autenticação/deauth e assim por diante, ou outros lugares onde você espera que novos dispositivos ou mesmo dispositivos "atacantes" continuem aparecendo ou desaparecendo. Em vez disso, eles normalmente enviam/recebem pacotes únicos para RTS/CTS aleatórios, Block-Ack, Null Function e Beamforming (quadros de anúncio VHT/HE NDP), repentinamente no meio do tráfego válido. Repito, apenas quadros pontuais , não conversas inteiras.
Eventualmente, resultando em dezenas de milhares de endereços MAC mutantes únicos, trocando pacotes únicos, com dispositivos válidos ou com outros endereços MAC mutantes.
Dadas todas as evidências acima,
Qual é a fonte mais provável de tantos endereços MAC _mutados_ de dispositivos válidos
Observe que eventualmente acabamos com dezenas de milhares de endereços MAC em uma área, modificados de apenas uma dúzia de endereços MAC válidos fisicamente presentes na vizinhança sem fio. O número de dispositivos foi validado pelas varreduras "Dispositivos próximos a mim" mencionadas anteriormente (essas varreduras procuram dispositivos associados e não associados nas proximidades).
Possíveis teorias:
- Alta probabilidade - erros de pacote - que por algum motivo não são sinalizados como erros no Wireshark. Por que eles aparecem no Wireshark? Por que eles não são rejeitados pela placa de rede / sistema operacional? (especificamente, macOS 10.14.5 em um MacBook Air em meados de 2013)
- Baixa probabilidade - Ator malicioso - O que eles poderiam conseguir injetando quadros de beacon, RTS/CTS e outros? Além disso, parece um grande esforço para conseguir... exatamente o quê?
- O que mais?
Estes são erros. Seu WNIC 802.11 no modo monitor está fazendo o possível para receber e relatar todos os quadros que pode ver no canal que você o configurou, mas devido à falta de confiabilidade do meio sem fio, sempre haverá muitos pacotes que ele pode ver onde está o SNR não é forte o suficiente para receber e decodificar cada bit corretamente.
Eles não estão sendo rejeitados porque você colocou o WNIC no modo monitor 802.11, e o modo monitor é frequentemente usado por engenheiros 802.11 para depurar problemas 802.11, incluindo problemas de erro de pacote, então os engenheiros gostam de poder ver os erros em vez de ter automaticamente rejeitados pelo WNIC.
Eles não estão sendo sinalizados pelo Wireshark porque, bem, porque lidar com erros de FCS sempre foi uma grande dor com NICs e sniffers (isso remonta aos primeiros dias da Ethernet com fio, portanto, é anterior ao 802.11). Alguns NICs têm a capacidade de passar quadros com falha de FCS para o host e outros não. Alguns NICs têm a capacidade de incluir o FCS nos pacotes que passam para o host e outros não. Nunca houve uma boa maneira de o sniffer descobrir automaticamente com qual tipo de NIC está lidando, portanto, ele não sabe se deve esperar ver FCSes ou quadros ruins ou não.
Portanto, o Wireshark, pelo que me lembro, assume como padrão a posição segura de assumir que os quadros NÃO têm FCSes anexados, portanto, não faz verificações de validação do FCS, portanto, não sinaliza quadros ruins. O Wireshark possui várias configurações para permitir que você controle como ele lida com os FCSes.
Veja, por exemplo: