Pacotes abertos do IWD (Intel inet Wireless Daemon) e wpa_supplicant, usados para conectar sistemas Linux clientes a redes sem fio, apresentam vulnerabilidades que permitem contornar os mecanismos de autenticação:
- No IWD, a vulnerabilidade (CVE-2023-52161) se manifesta apenas quando o modo ponto de acesso está ativado, o que é atípico para o IWD, que normalmente é utilizado para organizar conexões com redes sem fio. A vulnerabilidade permite que um usuário se conecte ao ponto de acesso criado sem conhecer a senha, por exemplo, quando o usuário explicitamente permite o acesso à rede através de seu dispositivo (Hotspot). O problema foi resolvido na versão IWD 2.14.
A vulnerabilidade é causada pela falta de uma verificação adequada da ordem de todas as etapas durante o processo de quatro estágios de negociação de conexão, utilizado na primeira conexão a uma rede sem fio protegida. Como o IWD aceita mensagens para quaisquer etapas de negociação de conexão, sem verificar se a etapa anterior foi concluída, um atacante pode, ignorando o envio da mensagem da segunda etapa, enviar diretamente a mensagem da quarta etapa e obter acesso à rede, saltando a etapa onde a verificação de autenticação é realizada.
Nesse caso, o IWD tenta verificar o código MIC (Message Integrity Code) para a mensagem recebida da quarta etapa. Como a mensagem da segunda etapa com os parâmetros de autenticação não foi recebida, ao processar a mensagem da quarta etapa, a chave PTK (Pairwise Transient Key) é configurada como valor nulo. Consequentemente, o atacante pode calcular o MIC usando a PTK nula, e esse código de verificação será aceito pelo IWD como válido. Após a conclusão de tal negociação de conexão incompleta, o atacante terá acesso total à rede sem fio, já que o ponto de acesso aceitará os pacotes enviados por ele, criptografados com a chave PTK nula.
- O problema identificado no wpa_supplicant (CVE-2023-52160) permite que um atacante engane o usuário para se conectar a uma rede sem fio falsa, que atua como um clone da rede à qual o usuário pretende se conectar. Se o usuário se conectar à rede falsa, o atacante pode realizar a interceptação do tráfego transitório não criptografado do usuário (por exemplo, acessos a sites sem HTTPS).
Devido a uma falha na implementação do protocolo PEAP (Protected Extensible Authentication Protocol), um atacante pode conseguir pular a segunda fase da autenticação ao conectar um dispositivo do usuário mal configurado. Pular a segunda fase da autenticação permite que o atacante crie uma cópia falsa de uma rede Wi-Fi confiável e conecte o usuário a uma rede falsa sem verificar a senha.
Para que o ataque seja bem-sucedido no wpa_supplicant, a verificação do servidor deve estar desativada do lado do usuário. certificado TLS O atacante deve conhecer o identificador da rede sem fio (SSID, Service Set Identifier). Além disso, o atacante deve estar ao alcance do adaptador sem fio da vítima, mas fora do alcance do ponto de acesso da rede sem fio clonada. O ataque é possível em redes WPA2-Enterprise ou WPA3-Enterprise, onde o protocolo PEAP é utilizado.
Os desenvolvedores do wpa_supplicant afirmaram que não consideram o problema uma vulnerabilidade, uma vez que ele ocorre apenas em redes sem fio mal configuradas, onde a autenticação EAP é usada juntamente com o protocolo PEAP (EAP-TTLS) sem verificação do certificado TLS. servidorConfigurações sem verificação de certificado não têm proteção contra ataques ativos. Aqueles que identificaram a vulnerabilidade afirmam que tais configurações incorretas são típicas e amplamente disseminadas, colocando em risco muitos dispositivos de consumidores baseados em Linux, Android e Chrome OS, que utilizam o wpa_supplicant.
Para bloquear o problema no wpa_supplicant, foi lançada uma correção que adiciona um modo de obrigatoriedade para passar pela segunda fase de autenticação, além da verificação do certificado TLS. Segundo os desenvolvedores, a alteração proposta é apenas um paliativo que torna mais difícil a realização de ataques ao usar autenticação manual e inútil ao aplicar opções como EAP-GTC. Para realmente resolver o problema, os administradores de redes devem ajustar suas configurações adequadamente, ou seja, configurar a cadeia de confiança para verificar o certificado do servidor usando o parâmetro ca_cert.
Fonte: opennet.ru
