vanhoefm/macstealerMacStealer: Wi-Fi Client Isolation Bypass
Este repositório contém o MacStealer. Ele pode testar redes Wi-Fi quanto a bypasses de isolamento de cliente (CVE-2022-47522). Nosso ataque pode interceptar (roubar) tráfego destinado a outros clientes na camada MAC, mesmo que os clientes estejam impedidos de se comunicar entre si. Essa vulnerabilidade afeta redes Wi-Fi com insiders maliciosos, onde nosso ataque pode contornar o isolamento de cliente, que às vezes também é conhecido como isolamento de AP. O ataque também pode ser usado para contornar a inspeção dinâmica de ARP (DAI) e, provavelmente, também pode ser usado para contornar outros métodos que impedem que clientes ataquem uns aos outros. O ataque também é conhecido como ataque de sobreposição de contexto de segurança (security context override attack); consulte a Seção 5 do nosso artigo do USENIX Security '23 (repositório).
Exemplos concretos de redes possivelmente afetadas são:
Redes corporativas onde os usuários podem não confiar uns nos outros e onde técnicas como isolamento de cliente ou inspeção de ARP são usadas para impedir que usuários ataquem uns aos outros. Por exemplo, redes de empresas com contas tanto para convidados quanto para funcionários, redes como eduroam e govroam, etc.
Hotspots públicos protegidos por Passpoint (antigamente Hotspot 2.0). Esses são hotspots aos quais você pode se conectar de forma automática e segura. Por exemplo, eles podem autenticá-lo perfeitamente usando o cartão SIM do seu celular.
Redes WPA2 ou WPA3 domésticas com isolamento de cliente habilitado. Isso inclui redes com um SSID separado para convidados ou para dispositivos inseguros (IoT). Também inclui redes onde várias senhas são usadas para isolar ainda mais os dispositivos, o que também é conhecido como Multi-PSK, Identity PSK, PSK por estação, ou EasyPSK. Consulte a discussão sobre o modelo de ameaça para obter mais informações.
Hotspots públicos baseados em WPA3 SAE-PK. Esses são hotspots protegidos por uma senha pública compartilhada, mas onde um adversário não pode abusar dessa senha publicamente conhecida.
Ressaltamos que nosso ataque não consegue contornar VLANs. Em outras palavras, com base nos experimentos atuais, nosso ataque não pode ser usado para explorar um dispositivo em outra VLAN.
O repositório de outros resultados do nosso USENIX Security '23 também está disponível.
A ideia central por trás do ataque é que a forma como os clientes são autenticados não tem relação com a forma como os pacotes são roteados para o cliente Wi-Fi correto. Ou seja, a autenticação é feita com base em senhas, nomes de usuário, identidades 802.1X e/ou certificados, mas, uma vez que o cliente se conecta, o roteamento dos pacotes é feito com base em endereços MAC. Um insider malicioso pode abusar disso para interceptar dados destinados a um cliente Wi-Fi desconectando uma vítima e então se conectando usando o endereço MAC da vítima (usando as credenciais do adversário). Quaisquer pacotes que ainda estivessem a caminho da vítima, como dados de um site que a vítima ainda estava carregando, agora serão recebidos pelo adversário.
Mais precisamente, o ataque consiste em três etapas:
Fazer a vítima solicitar dados: O adversário primeiro espera até que a vítima (cliente)
estabeleça uma conexão Wi-Fi com o Access Point (AP) vulnerável. Assumimos que a vítima
enviará então uma solicitação a um servidor na Internet. Por exemplo, a vítima pode enviar uma
solicitação HTTP para o site (em texto claro) example.com. O objetivo do adversário é
interceptar a resposta que será enviada pelo site.
Conectar-se usando o endereço MAC da vítima: Depois que a vítima solicita dados, por exemplo
enviando um pacote de solicitação HTTP, o adversário desconecta à força a vítima da
rede antes que a resposta chegue ao
AP vulnerável. Em nosso exemplo, isso significa que a vítima é desconectada antes que a resposta de
example.com chegue ao AP. Uma vez que a vítima é desconectada, o adversário falsifica
o endereço MAC da vítima e se conecta à rede usando suas próprias credenciais. Isso significa
que o adversário é um insider malicioso que pode se conectar à rede usando suas próprias
credenciais, por exemplo, usando seu próprio nome de usuário e senha em uma rede Wi-Fi corporativa.
Interceptar a resposta: Uma vez que o adversário se conectou usando o endereço MAC da vítima,
o AP associará as chaves de criptografia recém-geradas do adversário ao endereço MAC da vítima.
Como resultado, quando a resposta do servidor chegar à rede Wi-Fi, ou qualquer tráfego de entrada
destinado à vítima em geral, o roteador encaminhará esses pacotes de entrada para o endereço MAC da
vítima. Em nosso exemplo, isso significa que a resposta de example.com é encaminhada pelo roteador
para o endereço MAC da vítima. No entanto, o adversário agora está usando esse endereço MAC. Isso
significa que o AP criptografará a resposta usando as chaves do adversário. Em outras palavras, o
adversário agora receberá qualquer tráfego pendente que ainda esteja a caminho da vítima.
Ressaltamos que o tráfego interceptado pode ser protegido por criptografia de camadas superiores, como TLS e HTTPS. No entanto, mesmo que a criptografia de camadas superiores esteja sendo usada, nosso ataque ainda revela o endereço IP com o qual uma vítima está se comunicando. Isso, por sua vez, revela os sites que uma vítima está visitando, o que pode ser informação sensível por si só.
Por padrão, o ataque não intercepta tráfego enviado pela vítima, mas apenas tráfego enviado para a vítima. No entanto, um adversário pode tentar ataques subsequentes para também interceptar o tráfego enviado pela vítima. Em particular, ao interceptar uma resposta DNS destinada à vítima, o adversário pode falsificar uma resposta DNS e interceptar todo o tráfego IP tanto enviado para a vítima quanto enviado pela vítima.
Executar o ataque acima só faz sentido quando o isolamento de cliente está habilitado na rede alvo. Caso contrário, se o isolamento de cliente estiver desabilitado, um insider malicioso pode simplesmente atacar diretamente outros clientes usando técnicas como ARP spoofing (consulte os testes de isolamento de cliente).
O ataque é idêntico contra redes corporativas WPA1, WPA2 e WPA3. Isso porque o ataque não explora nenhuma propriedade criptográfica do Wi-Fi, mas sim abusa da forma como uma rede determina para qual cliente os pacotes devem ser enviados, ou seja, roteados.
Para obter detalhes adicionais sobre o ataque, consulte o ataque de sobreposição de contexto de segurança (Seção 5) em nosso artigo Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues.
Para mitigar nosso ataque, um AP pode impedir temporariamente que clientes se conectem se estiverem usando um endereço MAC que esteve recentemente conectado ao AP. Isso impede que um adversário falsifique um endereço MAC e intercepte quadros pendentes ou enfileirados destinados a uma vítima. Quando for possível garantir que o usuário por trás de um endereço MAC não mudou, o cliente pode ser autorizado a se reconectar imediatamente. Observe que essa verificação deve ser feita em todos os APs que fazem parte do mesmo sistema de distribuição e, mais especificamente, em todos os APs entre os quais os clientes podem fazer roaming mantendo seu endereço IP atual.
Para reconhecer com segurança usuários conectados recentemente, um AP pode armazenar um mapeamento entre o endereço MAC de um cliente e suas associações de segurança em cache (por exemplo, seu PMK em cache). Um cliente pode ser autorizado a (re)conectar imediatamente usando um endereço MAC usado recentemente ao provar que possui a associação de segurança em cache vinculada a esse endereço MAC, por exemplo, conectando-se usando o PMK em cache correto.
Ao usar multi-PSK, também conhecido como PSK por estação ou Identity PSK, o AP pode manter um mapeamento dos endereços MAC conectados recentemente e da senha (única) que eles usaram. Quando um cliente se conecta, o AP verifica se seu endereço MAC foi usado recentemente. Se não foi, ou se foi e o cliente está usando a mesma senha de antes, o cliente pode se conectar normalmente. No entanto, se o mesmo endereço MAC for usado com uma senha diferente, o cliente é forçado a esperar um período predefinido antes de conseguir se conectar com sucesso.
Ao usar SAE-PK para proteger hotspots, o único método que conhecemos para reconhecer com segurança que um endereço MAC está sendo reutilizado pelo mesmo usuário de antes é confiar nas associações de segurança em cache (por exemplo, o PMK em cache vinculado ao endereço MAC).
As defesas acima assumem que, após um certo atraso, não chegarão mais pacotes pendentes para a vítima. Para evitar vazamentos além desse atraso, os clientes podem usar criptografia de ponta a ponta (como TLS) com os serviços com os quais se comunicam.
Ao usar autenticação 802.1X baseada em EAP, um método alternativo e melhor para reconhecer com segurança usuários conectados recentemente é baseado na identidade EAP que eles usaram durante a autenticação 802.1X. Um AP pode aprender com segurança a identidade EAP a partir do servidor RADIUS que autenticou o cliente e manter um mapeamento dos endereços MAC conectados recentemente e suas identidades EAP correspondentes. Quando um cliente se conecta, o AP verifica se seu endereço MAC foi usado recentemente. Se não foi, ou se foi e o cliente está usando a mesma identidade EAP de antes, o cliente pode se conectar normalmente. No entanto, se o mesmo endereço MAC for usado com uma identidade EAP diferente, o cliente é forçado a esperar um período predefinido antes de conseguir se conectar com sucesso.
Um desafio é que o AP pode nem sempre saber a identidade 802.1X de um cliente devido a questões de privacidade. Por exemplo, essas informações podem estar disponíveis apenas no servidor AAA doméstico, e o AP receberá apenas uma Chargeable User Identity do servidor RADIUS. Essa identidade não permite que o AP reconheça duas associações do mesmo dispositivo/credenciais porque seu valor pode mudar constantemente. O AP recebe a identidade anônima no EAP-Response/Identity, como anonymous@realm, e pode confiar nela para pelo menos reconhecer usuários de realms diferentes.
Para impedir que usuários no mesmo realm ataquem uns aos outros, sem revelar a identidade de um cliente ao AP, são necessárias cooperação e mudanças no servidor RADIUS. Em particular, o servidor RADIUS pode ser atualizado para ajudar a detectar se o endereço MAC foi usado recentemente por outro usuário no mesmo realm (na rede local em questão). O servidor RADIUS precisaria então ser informado quando um cliente se desconecta, para saber quando um endereço MAC foi usado pela última vez por um de seus usuários, e precisa ser informado do endereço MAC de qualquer cliente que esteja tentando se conectar.
Uma última observação é que, embora essa abordagem de confiar na identidade EAP impeça que usuários diferentes ataquem uns aos outros, ela não impediria que um dispositivo comprometido atacasse outro dispositivo do mesmo usuário. Ou seja, os ataques seriam impedidos apenas entre usuários diferentes, mas não entre dispositivos diferentes do mesmo usuário.
É importante notar que nosso ataque não se limita a interceptar pacotes destinados a clientes Wi-Fi. Um adversário também poderia tentar se associar a um endereço MAC de um gateway padrão ou de outro servidor na rede local. Para evitar tais ataques, o AP ou o controlador pode proibir que clientes usem um endereço MAC igual ao do gateway padrão. De modo mais geral, a detecção de endereço MAC duplicado pode ser usada quando um cliente Wi-Fi estiver se conectando à rede, para impedir que clientes Wi-Fi usem um endereço MAC que também esteja em uso por outros dispositivos na rede.
Usar a Proteção de Quadros de Gerenciamento (MFP) tornaria o ataque mais difícil, mas não impossível. Em trabalho anterior, encontramos algumas maneiras pelas quais clientes podem ser desconectados/desautenticados mesmo quando a MFP está sendo usada. Com base nessa experiência, sempre parece existir algum método para desconectar à força um cliente da rede, mesmo quando a MFP está sendo usada. Em outras palavras, é difícil impedir completamente ataques de desconexão e desautenticação. Dito isso, a MFP seria um obstáculo extra a ser superado ao executar o ataque na prática, portanto pode ser uma mitigação útil para tornar o ataque mais difícil (mas não impossível) na prática.
Com base em experimentos preliminares, o ataque não funciona entre VLANs diferentes. Em outras palavras, o insider malicioso que executa o ataque deve estar na mesma VLAN que a vítima. Uma mitigação, portanto, é colocar diferentes grupos de usuários em VLANs diferentes. No entanto, um insider malicioso ainda seria capaz de executar o ataque (ou seja, contornar o isolamento de cliente) contra outros usuários na mesma VLAN.
Observe que, ao usar multi-PSK (também conhecido como PSK por estação ou identity PSK), você pode colocar clientes em VLANs diferentes dependendo da senha que eles usam. Em outras palavras, você pode usar uma VLAN para cada senha. Isso impede que clientes com senhas diferentes ataquem uns aos outros.
A ferramenta MacStealer funciona com qualquer placa de rede suportada pelo Linux. Testamos o MacStealer no Ubuntu 22.04. Para instalar as dependências necessárias no Ubuntu 22.04, execute:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential net-tools python3-venv \
aircrack-ng rfkill
Agora clone este repositório, compile as ferramentas e configure um ambiente virtual python3:
git clone https://github.com/vanhoefm/macstealer.git macstealer
cd macstealer/research
./build.sh
./pysetup.sh
As instruções acima só precisam ser executadas uma vez.
Depois de obter novo código usando git, você precisa executar ./build.sh e ./pysetup.sh novamente.
Consulte o registro de alterações para obter uma visão geral detalhada das atualizações do MacStealer
desde o início da divulgação coordenada.
Toda vez que você quiser usar o MacStealer, primeiro precisa carregar o ambiente virtual python3 como root. Isso pode ser feito usando:
cd research
sudo su
source venv/bin/activate
Você agora deve desabilitar o Wi-Fi no seu gerenciador de rede
para que ele não interfira no MacStealer. Opcionalmente, verifique usando sudo airmon-ng check para ver
quais outros processos podem estar usando a placa de rede sem fio e podem interferir no MacStealer.
O próximo passo é editar o client.conf com as informações da rede que você deseja testar.
Esta é uma configuração para o wpa_supplicant
que deve conter dois blocos de rede: um representando a vítima e um representando
o atacante. Um exemplo de arquivo de configuração para testar a rede fictícia kuleuven é:
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test: fill in properties of the network to test
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Victim login: fill in login credentials representing the victim
identity="[email protected]"
password="SuperSecret"
}
network={
# Don't change this field, the script relies on it
id_str="attacker"
# Network to test: you can copy this from the previous block
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Attacker login: fill in login credentials representing the attacker
identity="[email protected]"
password="SomePassword"
}
Na parte "rede a testar", você deve fornecer o nome da rede que está sendo testada e sua configuração de segurança. Consulte wpa_supplicant.conf para documentação sobre como escrever/editar arquivos de configuração e para exemplos de blocos de rede para vários tipos de redes Wi-Fi. No primeiro bloco de rede, em "login da vítima", você deve especificar credenciais de login válidas que representem a vítima simulada. No segundo bloco de rede, você pode fornecer exatamente as mesmas informações em "rede a testar", mas deve fornecer credenciais de login que representem o atacante simulado.
No exemplo acima, o MacStealer testará um ataque em que o adversário é [email protected]
e esse adversário tentará interceptar o tráfego enviado para a vítima [email protected].
Por padrão, o script usa o arquivo de configuração client.conf. Você pode usar um
arquivo de configuração diferente fornecendo o parâmetro --config network.conf, onde você pode substituir
network.conf pelo arquivo de configuração que deseja usar.
Este repositório também contém os seguintes arquivos de configuração de exemplo:
multipsk.conf: Um arquivo de configuração para testar uma rede que
usa multi-PSK, onde uma senha é usada por dispositivos confiáveis e uma segunda senha é
fornecida aos convidados.
saepk.conf: Um arquivo de configuração para testar um hotspot público que
usa SAE-PK.
Observe que também é possível editar o(s) bloco(s) de rede para testar um AP/BSS específico.
Por padrão, o MacStealer enviará um pacote TCP SYN para 8.8.8.8 na porta 443 em todos os testes, que é um
servidor DNS do Google. Se você quiser usar um servidor ou porta diferente, pode fornecê-los usando
o parâmetro --server. Por exemplo:
./macstealer.py wlan0 --server 208.67.222.222
Você também pode adicionar a porta que deve ser usada nos pacotes TCP SYN:
./macstealer.py wlan0 --server 208.67.222.222:80
Substitua wlan0 pelo nome da sua interface Wi-Fi e o endereço IP pelo servidor
que você deseja usar.
Este servidor deve retransmitir respostas TCP SYN/ACK e, idealmente, deve ainda enviar um
SYN/ACK retransmitido mais de 10 segundos após o MacStealer ter transmitido o TCP SYN inicial. Você pode
testar esse comportamento de retransmissão usando o parâmetro --ping da seguinte forma:
./macstealer.py wlan0 --server 208.67.222.222 --ping
O MacStealer exibirá o seguinte caso o servidor tenha o comportamento de retransmissão exigido:
[22:53:15] Received SYN/ACK 15.265095233917236 seconds after sending SYN.
[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.
Caso o servidor fornecido não envie respostas TCP SYN/ACK, ou não as retransmita tardiamente o suficiente, o MacStealer exibirá o seguinte:[22:52:05] SYN/ACK recebido 1.0727121829986572 segundos após o envio do SYN. [22:52:24] >>> Teste de ping concluído. Considere usar um servidor que retransmita o SYN/ACK por mais tempo.
A razão pela qual o servidor ainda deve retransmitir um SYN/ACK após mais de 10 segundos é porque às vezes pode levar vários segundos para se reconectar como o atacante simulado. Esse processo de reconexão deve ser concluído antes que o servidor envie o último pacote TCP SYN/ACK retransmitido.
A tabela a seguir contém comandos comuns que você executará ao testar uma rede, junto com uma breve descrição do que cada comando faz. Abaixo da tabela, os detalhes de cada comando são explicados.
Se a rede que está sendo testada usa Proteção de Quadros de Gerenciamento (802.11w), a ferramenta presume que o adversário ainda pode desconectar a vítima da rede à força. Essa suposição é baseada em pesquisas recentes que mostraram que ataques de desconexão normalmente ainda são possíveis, embora menos diretos ou gerais, ao usar MFP.
Antes de testar vulnerabilidades, você pode usar os dois comandos a seguir para confirmar que o MacStealer consegue se conectar à rede tanto como vítima quanto como atacante:
./macstealer.py wlan0 --ping: conecta-se à rede usando as credenciais da vítima.
Uma vez conectado, um TCP SYN é enviado ao servidor (que por padrão é 8.8.8.8 e pode ser alterado).
O MacStealer verificará se o SYN/ACK é (re)transmitido e quantas vezes. Você pode usar
isso para confirmar que as credenciais da vítima estão corretas e para verificar se o servidor
configurado está retransmitindo corretamente as respostas SYN/ACK.
./macstealer.py wlan0 --ping --flip: igual ao teste acima, mas agora o script se conectará
usando as credenciais do adversário. Você pode usar isso para confirmar que as credenciais do
adversário estão corretas.
./macstealer.py wlan0: Teste a variante padrão do ataque de roubo de endereço MAC. O atacante
se reconectará ao mesmo AP/BSS da vítima.
./macstealer.py wlan0 --other-bss: O atacante se conectará a um AP/BSS diferente da mesma
rede. Uma rede que é (também) vulnerável a este teste é mais fácil de explorar na prática. Se apenas
um único AP/BSS estiver ao alcance do rádio, o script expirará ao se conectar como atacante.
Explorar a vulnerabilidade de roubo de endereço MAC só faz sentido se o isolamento de cliente estiver ativado ou quando técnicas como inspeção de ARP são usadas para impedir que clientes ataquem uns aos outros. Caso contrário, um adversário pode usar ataques mais fáceis, como envenenamento ARP para interceptar tráfego. Para testar se o isolamento de cliente está ativado ou se a inspeção de ARP é usada pela rede, você pode usar os seguintes comandos:
./macstealer.py wlan0 --c2c wlan1: Com esses argumentos, o MacStealer testa se a rede
permite tráfego cliente-a-cliente de envenenamento ARP do atacante (wlan1) em direção à vítima (wlan0).
Aqui wlan1 é uma segunda interface de rede sem fio. O script então testará se pacotes ARP
maliciosos podem ser enviados do atacante para a vítima.
./macstealer.py wlan0 --c2c-eth wlan1: Isso é semelhante ao teste acima, mas em vez de enviar
pacotes ARP maliciosos, o atacante enviará pacotes DNS para a vítima.
A vulnerabilidade de roubo de endereço MAC deve ser considerada um risco na prática se o tráfego cliente-a-cliente for bloqueado em qualquer um dos dois testes acima (ou seja, quando o isolamento de cliente estiver ativado ou quando outras técnicas, como inspeção de ARP, forem usadas para impedir que usuários ataquem uns aos outros).
Por padrão, o MacStealer tentará se conectar ao mesmo AP/BSS usando ambas as interfaces, então é
importante que ambas as placas de rede possam ver as mesmas redes (ou seja, certifique-se de que ambas as
interfaces de rede suportem as mesmas bandas de frequência e canais). Se você quiser que ambos os clientes
se conectem a um AP/BSS diferente, use o parâmetro --other-bss.
Você pode usar o parâmetro --flip-id para testar se o tráfego da vítima (wlan0) é permitido
em direção ao atacante (wlan1).
Caso o MacStealer pareça não estar funcionando, verifique o seguinte:
Verifique se nenhum outro processo está usando a placa de rede (por exemplo, encerre seu gerenciador de rede).
Você pode ver a saída kernel reports: match already configured se outro processo
também estiver usando a placa de rede.
Se tudo funcionou anteriormente, tente desconectar seu adaptador Wi-Fi, reinicie seu computador ou máquina virtual e tente novamente.
Confirme se você está se conectando à rede correta. Verifique novamente o client.conf.
Se você atualizou o código usando git, execute ./build.sh e ./pysetup.sh novamente (veja Pré-requisitos).
Se você estiver usando uma máquina virtual, tente executar o MacStealer a partir de uma instalação Linux nativa.
Execute o MacStealer com o parâmetro extra -dd para obter saída de depuração adicional do wpa_supplicant
e do próprio MacStealer.
Os testes de isolamento de cliente padrão verificarão se o tráfego na camada Ethernet é permitido entre clientes. Também é possível testar se o tráfego na camada IP é permitido entre clientes usando o seguinte comando:
./macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]
Quando o tráfego na camada IP entre clientes é permitido, ainda é possível que clientes ataquem uns aos outros. Por exemplo, ataques de redirecionamento ICMP podem então ainda ser possíveis. Tais ataques são mais complicados do que o envenenamento ARP, mas idealmente ainda devem ser prevenidos bloqueando também o tráfego na camada IP entre clientes.
Os seguintes testes podem ser executados para testar propriedades gerais de uma rede. Esses testes não estão diretamente relacionados a vulnerabilidades, mas podem ser usados para entender melhor o comportamento de uma rede.
./macstealer.py wlan0 --same-id [--other-bss] [--flip]: Teste se as conexões TCP permanecem ativas após
desconectar e reconectar a um Ponto de Acesso. Se as conexões não permanecerem ativas após a reconexão,
a rede provavelmente não é vulnerável aos ataques de roubo de endereço MAC. No entanto, uma grande desvantagem
desse comportamento é que clientes legítimos precisam abrir novas conexões TCP sempre que se reconectam
a essa rede, fazendo com que a rede pareça lenta e não confiável (portanto, uma defesa melhor deve ser usada
em vez disso).
Você pode usar o parâmetro --other-bss para se reconectar a um AP/BSS diferente da mesma rede.
Você pode usar o argumento --flip para realizar este teste sob a identidade do atacante em vez
da identidade da vítima.
./macstealer.py wlan0 --flip: Teste o ataque normal de roubo de endereço MAC, mas inverta o
papel do atacante e da vítima. Em outras palavras, o atacante usará as "credenciais da vítima"
fornecidas no arquivo de configuração, e a vítima usará as "credenciais do adversário".
./macstealer.py wlan0 --c2c wlan1 --same-id [--flid-id]: Teste se o tráfego cliente-a-cliente é
permitido entre dois dispositivos do mesmo usuário. Veja testes de isolamento de cliente
para documentação sobre o parâmetro wlan1.
Você pode usar o argumento --flip para realizar este teste sob a identidade do atacante em vez
da identidade da vítima.
--delay seconds: Você pode usar o parâmetro --delay para especificar um atraso, em segundos, antes de se reconectar como
o atacante.
-d ou -dd: Adicionar um desses parâmetros aumenta a verbosidade de depuração do script
e da instância subjacente do wpa_supplicant.
Por padrão, o MacStealer selecionará automaticamente um AP/BSS da rede para se conectar e testar.
Caso você tenha uma rede com vários APs/BSSes, você pode testar um específico especificando esse
AP/BSS no bloco de rede da vítima usando a palavra-chave bssid. Por exemplo, você pode usar:
...
network={
# Não altere este campo, o script depende dele
id_str="victim"
# Rede para testar: preencha as propriedades da rede a ser testada
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Login da vítima: preencha as credenciais de login que representam a vítima
identity="[email protected]"
password="SuperSecret"
# Este é um AP/BSS específico
bssid=00:11:22:33:44:55
}
...
Com a configuração acima, o MacStealer testará 00:11:22:33:44:55. Isso significa que ele se
conectará tanto como vítima quanto como atacante a este AP.
Você também pode combinar isso com o parâmetro --other-bss. Nesse caso, a vítima se
conectará a 00:11:22:33:44:55, e o atacante se conectará a um AP/BSS diferente da mesma rede.
Outra opção é especificar um BSS/AP explícito no bloco de rede da vítima e do atacante.
Observe que o MacStealer procurará pelo AP/BSS fornecido por no máximo 30 segundos. Se não conseguir encontrar o AP/BSS especificado, a ferramenta será encerrada.
Você pode testar uma rede SAE-PK usando o seguinte arquivo de configuração. Observe que para redes SAE-PK não há diferença em como a vítima e o atacante se autenticam, ou seja, ambos usam a mesma senha.
# Não altere esta linha, caso contrário o MacStealer não funcionará
ctrl_interface=wpaspy_ctrl
# WPA3/SAE: suporta tanto o loop hunting-and-pecking quanto hash-to-element
sae_pwe=2
network={
# Não altere este campo, o script depende dele
id_str="attacker"
# Rede para testar - login do atacante
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
network={
# Não altere este campo, o script depende dele
id_str="victim"
# Rede para testar - login da vítima
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
Na prática, o isolamento de cliente também é usado em redes protegidas por uma senha pré-compartilhada. Por exemplo, vários roteadores têm uma opção para criar uma rede para convidados ou dispositivos (IoT) inseguros, onde os clientes dessa rede são isolados para que não possam atacar uns aos outros. No entanto, a vantagem de segurança de usar o isolamento de cliente nesse cenário pode ser questionada. O isolamento de cliente serve para evitar que um insiders malicioso ataque outros. Mas se o insider malicioso souber a senha pré-compartilhada, ele pode simplesmente criar um clone rogue (gêmeo do mal), enganar as vítimas para que se conectem a essa cópia maliciosa da rede e então atacar outros clientes! Em outras palavras, usar o isolamento de cliente em uma rede protegida por senha não fornece segurança forte, um cliente malicioso pode criar um AP rogue para ainda assim atacar outros clientes.
Dito isso, pode-se argumentar que criar um AP rogue pode ser detectado pelo administrador da rede, o que significa que o isolamento de cliente de fato torna os ataques mais difíceis. Além disso, quando um dispositivo leve é (remotamente) comprometido, ele pode não ter os recursos para (facilmente) agir como um AP rogue. Isso torna mais difícil, mas não impossível, realizar ataques quando o isolamento de cliente é usado. No geral, embora o isolamento de cliente não forneça garantias de segurança fortes em uma rede protegida por senha, pode-se argumentar que ele aumenta a dificuldade prática de realizar ataques.
Nosso ataque MacStealing é mais fácil de realizar do que criar um AP rogue. Tudo o que o insider malicioso, por exemplo, um dispositivo IoT leve e comprometido, precisa fazer é falsificar um endereço MAC e (re)conectar-se à rede. Tal ataque também é mais difícil de detectar. Com base nessa observação, nosso novo ataque torna a situação pior e, portanto, pode-se argumentar que nosso ataque também deve ser considerado relevante em redes protegidas por uma senha pré-compartilhada.
Conclusão: ao usar o isolamento de cliente em uma rede protegida por senha, você está assumindo que um insider malicioso não criará um AP rogue. Caso contrário, o uso do isolamento de cliente é sem sentido do ponto de vista da segurança. O ataque MacStealing pode ser realizado sem criar um AP rogue e, portanto, torna os ataques mais fáceis.
O objetivo do nosso ataque não é contornar listas de negação/permissão de endereços MAC em Pontos de Acesso. Falsificar endereços MAC para contornar a filtragem de endereços MAC é um ataque diferente e já conhecido.
O objetivo do nosso ataque não é sequestrar a conexão paga de alguém em hotspots Wi-Fi. Por exemplo, alguns hotspots abertos (ou protegidos) exigem que o usuário pague antes de ter permissão para acessar a Internet. Muitas vezes, um assinante pagante é reconhecido com base em seu endereço MAC, e um adversário pode falsificar o endereço MAC de uma vítima para obter acesso à Internet. Este não é o propósito do nosso ataque; o objetivo do MacStealer é contornar o isolamento de cliente.
Nosso ataque também afeta redes que se defendem contra a vulnerabilidade Hole 196. Por exemplo, redes Passpoint (anteriormente Hotspot 2.0) são obrigadas a prevenir a vulnerabilidade Hole 196, mas ainda são vulneráveis ao nosso ataque.
Nosso ataque funciona em redes que se defendem contra o envenenamento ARP. Em redes Wi-Fi mal protegidas, um adversário pode trivialmente realizar envenenamento ARP para interceptar o tráfego de uma vítima, e nosso ataque não é realmente prático. No entanto, redes modernas, que podem ter insiders maliciosos, dependem do isolamento de cliente ou de outros métodos para prevenir ataques de máquina-no-meio. Nosso atacante contorna todas essas defesas modernas e ainda assim permite que um adversário intercepte o tráfego em direção a uma vítima.
Para resumir, nosso ataque afeta redes Wi-Fi onde clientes são impedidos de atacar uns aos outros, permitindo que um adversário intercepte o tráfego de outro cliente.
A maioria dos fornecedores está usando CVE-2022-47522 para se referir à vulnerabilidade de bypass de isolamento de cliente Wi-Fi que é discutida neste repositório git. Essa vulnerabilidade corresponde ao ataque na Seção 5 de nosso artigo.
Infelizmente, outros fornecedores também estão usando este CVE para se referir à vulnerabilidade (estritamente falando, não relacionada) que é discutida na Seção 3 de nosso artigo. Na verdade, a descrição real do CVE, como pode ser encontrada na MITRE, em nossa opinião, descreve apenas o ataque na Seção 3 do nosso artigo. Na prática, parece que CVE-2022-47522 é usado para se referir a todos os ataques em nosso artigo, mesmo que sejam tecnicamente diferentes.
Versão 1.2 (em andamento)
README melhorado: esclarecido o uso do identificador CVE.
README melhorado: foco da introdução em contornar o isolamento de cliente, defesas atualizadas com observações sobre 802.1X e sobre prevenir o roubo do endereço MAC do gateway padrão.
Adicionado o parâmetro --delay para especificar um atraso em segundos antes de se reconectar como o atacante.
Versão 1.1 (18 de janeiro de 2023)
Por padrão, use 8.8.8.8 como servidor em vez de 216.58.208.100 (ambos são servidores do Google).
Testes de isolamento de cliente atualizados: por padrão, teste usando envenenamento ARP na camada Ethernet. Também forneça opção para enviar dados UDP com encaminhamento na camada Ethernet e um teste com encaminhamento na camada IP.
README melhorado: atualizados os tipos de rede que podem ser afetados. Incluída uma discussão sobre se redes WPA2 ou WPA3 protegidas por senha são afetadas. Explicação dos diferentes comandos para testar o tráfego cliente-a-cliente nas camadas Ethernet ou IP.
README melhorado: discussão sobre MFP, discussão sobre VLANs como mitigação, esclarecimento sobre quais APs a verificação de identidade deve ser feita, especificação da porta do servidor,
Saída do MacStealer melhorada.
Versão 1.0 (3 de janeiro de 2023):
| Comando | Descrição curta |
|---|
./macstealer.py wlan0 --ping | Conecte-se como vítima e teste o comportamento de retransmissão do servidor. |
./macstealer.py wlan0 --ping --flip | Conecte-se como atacante e teste o comportamento de retransmissão do servidor. |
./macstealer.py wlan0 | Teste a variante padrão do ataque de roubo de endereço MAC. |
./macstealer.py wlan0 --other-bss | Faça o atacante se conectar a um AP diferente do da vítima. |
./macstealer.py wlan0 --c2c wlan1 | Teste o tráfego cliente-a-cliente na camada Ethernet (envenenamento ARP). |
./macstealer.py wlan0 --c2c-eth wlan1 | Teste o tráfego cliente-a-cliente na camada Ethernet (DNS). |