Falha gravissima no WPA2

Publicado em por

Todos os equipamentos que utilizam WIFI estão vulneraveis, fiquem atentos a atualizações dos equipamentos de todos os clientes (Celulares, roteadores e qualquer coisa que use o WIFI + WAP ou WPA2

Essa é uma tradução do site:

https://www.krackattacks.com

INTRODUÇÃO

Descobrimos graves pontos fracos no WPA2, um protocolo que assegura todas as redes Wi-Fi protegidas modernas. Um intruso dentro do alcance de uma vítima pode explorar estas deficiências usando k ey r einstallation um tta ck s (KRACKs). Concretamente, os atacantes podem usar esta nova técnica de ataque para ler informações anteriormente assumidas como criptografadas com segurança. Isso pode ser abusado para roubar informações confidenciais, como números de cartão de crédito, senhas, mensagens de bate-papo, e-mails, fotos e assim por diante. O ataque funciona contra todas as redes Wi-Fi protegidas modernas. Dependendo da configuração da rede, também é possível injetar e manipular dados. Por exemplo, um invasor pode injetar ransomware ou outro malware em sites.

Os pontos fracos estão no padrão Wi-Fi, e não em produtos ou implementações individuais. Portanto, qualquer implementação correta do WPA2 provavelmente será afetada. Para evitar o ataque, os usuários devem atualizar os produtos afetados assim que as atualizações de segurança estiverem disponíveis. Observe que, se seu dispositivo suportar Wi-Fi, provavelmente será afetado . Durante nossa pesquisa inicial, descobrimos que o Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys e outros, são afetados por alguma variante dos ataques. Para obter mais informações sobre produtos específicos, consulte o banco de dados de CERT / CC ou contate seu fornecedor.

A pesquisa por trás do ataque será apresentada na conferência de Segurança de Computadores e Comunicações (CCS) e na conferência Black Hat Europe . Nosso trabalho de pesquisa detalhado já pode ser baixado.

DEMONSTRAÇÃO

Como prova de conceito, executámos um ataque de reinstalação chave contra um smartphone Android. Nesta demonstração, o invasor é capaz de descriptografar todos os dados que a vítima transmite. Para um atacante isso é fácil de realizar, porque o nosso ataque de reinstalação é excepcionalmente devastador contra Linux e Android 6.0 ou superior. Isso ocorre porque o Android e o Linux podem ser enganados para (re) instalar uma chave de criptografia totalmente zero ( veja abaixo para obter mais informações ). Ao atacar outros dispositivos, é mais difícil descifrar todos os pacotes, embora um grande número de pacotes possa, contudo, ser descriptografado. Em qualquer caso, a seguinte demonstração destaca o tipo de informação que um invasor pode obter ao executar ataques de reinstalação de chaves contra redes Wi-Fi protegidas:

Nosso ataque não se limita a recuperar credenciais de login (ou seja, endereços de e-mail e senhas). Em geral, todos os dados ou informações que a vítima transmite podem ser descriptografados. Além disso, dependendo do dispositivo que está sendo usado e da configuração da rede, também é possível descriptografar os dados enviados para a vítima (por exemplo, o conteúdo de um site). Embora sites ou aplicativos possam usar o HTTPS como uma camada adicional de proteção, avisamos que essa proteção extra pode (ainda) ser ignorada em um número preocupante de situações. Por exemplo, o HTTPS foi anteriormente ignorado no software não-navegador , nos iOS e OS X da Apple , em aplicativos Android , em aplicativos Android novamente , em aplicativos bancários, e até mesmo em aplicativos VPN .

DETALHES

Nosso principal ataque é contra o handshake de 4 vias do protocolo WPA2. Este aperto de mão é executado quando um cliente deseja se juntar a uma rede Wi-Fi protegida e é usado para confirmar que o cliente e o ponto de acesso possuem as credenciais corretas (por exemplo, a senha pré-compartilhada da rede). Ao mesmo tempo, o handshake de 4 vias também negocia uma nova chave de criptografia que será usada para criptografar todo o tráfego subseqüente. Atualmente, todas as redes Wi-Fi protegidas modernas usam o handshake de 4 vias. Isso implica que todas essas redes são afetadas por (alguma variante) de nosso ataque. Por exemplo, o ataque funciona contra redes Wi-Fi pessoais e corporativas, contra o WPA mais antigo e o padrão WPA2 mais recente, e mesmo contra redes que usam apenas o AES. Todos os nossos ataques contra WPA2 usam uma nova técnica chamada ataque de reinstalação chave (KRACK):

Principais ataques de reinstalação: descrição de alto nível

Em um ataque de reinstalação chave, o adversário truque uma vítima para reinstalar uma chave já em uso. Isso é conseguido manipulando e reproduzindo mensagens criptográficas de handshake . Quando a vítima reinstalar a chave, os parâmetros associados, como o número incremental do pacote de transmissão (ou seja, nonce) e o número do pacote de recebimento (ou seja, o contador de repetição), são redefinidos para o valor inicial. Essencialmente, para garantir a segurança, uma chave só deve ser instalada e usada uma vez. Infelizmente, achamos que isso não é garantido pelo protocolo WPA2. Ao manipular handshakes criptográficos, podemos abusar dessa fraqueza na prática.

Principais ataques de reinstalação: exemplo concreto contra o handshake de 4 vias

Conforme descrito na introdução do documento de pesquisa, a idéia por trás de um ataque de reinstalação chave pode ser resumida da seguinte maneira. Quando um cliente se junta a uma rede, ele executa o handshake de 4 vias para negociar uma nova chave de criptografia. Ele instalará esta chave depois de receber a mensagem 3 do handshake de 4 vias. Uma vez instalada a chave, ela será usada para criptografar quadros de dados normais usando um protocolo de criptografia. No entanto, como as mensagens podem ser perdidas ou descartadas, o ponto de acesso (AP) retransmitirá a mensagem 3 se não receber uma resposta adequada como confirmação. Como resultado, o cliente pode receber a mensagem 3 várias vezes. Cada vez que recebe esta mensagem, ela irá reinstalar a mesma chave de criptografia e, assim, redefinir o número incremental do pacote de transmissão (nonce) e receber o contador de repetição usado pelo protocolo de criptografia. Mostramos issoum invasor pode forçar esses reinícios não-coletando colecionando retransmissões da mensagem 3 do handshake de 4 vias . Ao forçar a reutilização não é assim, o protocolo de criptografia pode ser atacado, por exemplo, os pacotes podem ser reproduzidos, descifrados e / ou forjados. A mesma técnica também pode ser usada para atacar a chave de grupo, PeerKey, TDLS e handshake rápido de transição do BSS.

Impacto prático

Em nossa opinião, o ataque mais difundido e praticamente impactante é o principal ataque de reinstalação contra o handshake de 4 vias. Baseamos esse julgamento em duas observações. Primeiro, durante nossa própria pesquisa, descobrimos que a maioria dos clientes foi afetada por ela. Em segundo lugar, os adversários podem usar este ataque para descriptografar pacotes enviados pelos clientes, permitindo que interceptem informações confidenciais como senhas ou cookies. O decodificação de pacotes é possível porque um ataque de reinstalação de chave faz com que os nonces de transmissão (às vezes também chamados de números de pacotes ou vetores de inicialização) sejam redefinidos para zero. Como resultado, a mesma chave de criptografia é usada com valores não válidos que já foram usados ​​no passado . Por sua vez, isso faz com que todos os protocolos de criptografia do WPA2 reutilizem o fluxo de chavesao encriptar pacotes. Caso uma mensagem que reutilize o fluxo de chave tenha conteúdo conhecido, torna-se trivial derivar o fluxo de chave usado. Este fluxo de chave pode então ser usado para descriptografar mensagens com o mesmo motivo. Quando não há conteúdo conhecido, é mais difícil de descriptografar pacotes, embora ainda seja possível em vários casos (por exemplo, texto em inglês ainda pode ser descriptografado ). Na prática, encontrar pacotes com conteúdo conhecido não é um problema, portanto, deve assumir-se que qualquer pacote pode ser descriptografado.

A capacidade de descriptografar pacotes pode ser usada para descriptografar pacotes TCP SYN. Isso permite que um adversário obtenha os números de seqüência TCP de uma conexão e remova as conexões TCP . Como resultado, mesmo que o WPA2 seja usado, o adversário agora pode executar um dos ataques mais comuns contra redes Wi-Fi abertas: injetando dados mal-intencionados em conexões HTTP não criptografadas. Por exemplo, um invasor pode abusar disso para injetar ransomware ou malware em sites que a vítima está visitando.

Se a vítima usa o protocolo de criptografia WPA-TKIP ou GCMP, em vez de AES-CCMP, o impacto é especialmente catastrófico.Contra esses protocolos de criptografia, a não utilização de reutilização permite que um adversário não apenas descifrar, mas também forjar e injetar pacotes . Além disso, como o GCMP usa a mesma chave de autenticação nas duas direções de comunicação, e essa chave pode ser recuperada se não forem reutilizadas, ela é especialmente afetada. Note-se que o suporte para o GCMP está sendo lançado no âmbito do nome Wireless Gigabit (WiGig), e espera-se que seja adotado a uma alta taxa nos próximos anos.

A direção em que os pacotes podem ser descriptografados (e possivelmente forjados) depende do aperto de mão que está sendo atacado. Simplificado, ao atacar o aperto de mão de 4 vias, podemos decifrar (e forjar) pacotes enviados pelo cliente. Ao atacar o aperto de mão Fast BSS Transition (FT), podemos decifrar (e forjar) os pacotes enviados para o cliente. Finalmente, a maioria dos nossos ataques também permite a repetição de frames unicast, broadcast e multicast. Para mais detalhes, veja a Seção 6 do nosso trabalho de pesquisa .

Observe que nossos ataques não recuperam a senha da rede Wi-Fi . Eles também não recuperam (nenhuma parte) da nova chave de criptografia que é negociada durante o handshake de 4 vias.

Android e Linux

Nosso ataque é especialmente catastrófico contra a versão 2.4 e acima do wpa_supplicant, um cliente Wi-Fi comumente usado no Linux. Aqui, o cliente instalará uma chave de criptografia totalmente zero em vez de reinstalar a chave real. Esta vulnerabilidade parece ser causada por uma observação no padrão Wi-Fi que sugere limpar a chave de criptografia da memória uma vez que ela foi instalada pela primeira vez. Quando o cliente agora recebe uma mensagem retransmitida 3 do handshake de 4 vias, ele irá reinstalar a chave de criptografia agora limpa, efetivamente instalando uma chave totalmente zero. Como o Android usa wpa_supplicant, o Android 6.0 e acima também contém essa vulnerabilidade. Isso torna trivial interceptar e manipular o tráfego enviado por esses dispositivos Linux e Android . Observe que atualmente50% dos dispositivos Android são vulneráveis ​​a esta variante excepcionalmente devastadora do nosso ataque.

Identificadores CVE atribuídos

Os seguintes identificadores de Vulnerabilidades e exposições comuns (CVE) foram designados para rastrear quais produtos são afetados por instâncias específicas do nosso ataque de reinstalação chave:

  • CVE-2017-13077 : Reinstalação da chave de criptografia pairwise (PTK-TK) no handshake de 4 vias.
  • CVE-2017-13078 : Reinstalação da chave de grupo (GTK) no handshake de 4 vias.
  • CVE-2017-13079 : Reinstalação da chave de grupo de integridade (IGTK) no aperto de mão de 4 vias.
  • CVE-2017-13080 : reinstalação da chave de grupo (GTK) no handshake da chave do grupo.
  • CVE-2017-13081 : reinstalação da chave do grupo de integridade (IGTK) no handshake da chave do grupo.
  • CVE-2017-13082 : Aceitando uma Solicitação de Reassociação Rápida de Transição BSS retransmitida (FT) e reinstalando a chave de criptografia pairwise (PTK-TK) ao processá-la.
  • CVE-2017-13084 : reinstalação da chave STK no aperto de mão PeerKey.
  • CVE-2017-13086 : reinstalação da tecla Tunelled Direct-Link Setup (TDLS) PeerKey (TPK) no handshake TDLS.
  • CVE-2017-13087 : reinstalação da chave de grupo (GTK) ao processar um quadro de resposta do modo de suspensão de rede sem fio (WNM).
  • CVE-2017-13088 : reinstalação da chave de grupo de integridade (IGTK) ao processar uma moldura de resposta do Modo de espera do Gerenciamento de rede sem fio (WNM).

Observe que cada identificador CVE representa uma instanciação específica de um ataque de reinstalação de chave. Isso significa que cada ID CVE descreve uma vulnerabilidade específica do protocolo e, portanto, muitos fornecedores são afetados por cada ID CVE individual . Você também pode ler a nota de vulnerabilidade VU # 228519 do CERT / CC para obter detalhes adicionais sobre quais produtos são conhecidos como afetados.

PAPEL

Nosso trabalho de pesquisa por trás do ataque é intitulado Ataques de Reinstalação de Chave: Forçando a Reutilização de Nonce no WPA2 e será apresentado na conferência de Segurança de Computadores e Comunicações (CCS) na quarta – feira, 1 de novembro de 2017 .

Embora este documento seja tornado público agora, já foi submetido para revisão em 19 de maio de 2017. Depois disso, apenas foram feitas pequenas alterações. Como resultado, as descobertas no documento já são de vários meses. Entretanto, encontramos técnicas mais fáceis para realizar nosso ataque de reinstalação chave contra o aperto de mão de 4 vias. Com a nossa nova técnica de ataque, agora é trivial explorar implementações que apenas aceitam retransmissões criptografadas da mensagem 3 do handshake de 4 vias. Em particular, isso significa que atacar o macoss e o OpenBSD é significativamente mais fácil do que o discutido no documento .

Gostaríamos de destacar os seguintes addendos e erratas:

Adenda: wpa_supplicant v2.6 e Android 6.0+

O wpa_supplicant v2.6 do Linux também é vulnerável à instalação de uma chave de criptografia totalmente zero no handshake de 4 vias. Isso foi descoberto por John A. Van Boxtel. Como resultado, todas as versões do Android superiores a 6.0 também são afetadas pelo ataque e, portanto, podem ser enganadas na instalação de uma chave de criptografia totalmente zero. O novo ataque funciona injetando uma mensagem forjada 1, com a mesma ANonce usada na mensagem original 1, antes de encaminhar a mensagem retransmitida 3 para a vítima.

Adendo: outros handshakes vulneráveis

Após nossa pesquisa inicial conforme relatado no artigo, descobrimos que o handshake TDLS e a moldura WNM Sleep Mode Response também são vulneráveis ​​a ataques de reinstalação de chaves.

Errata selecionada

  • Na Figura 9 no estágio 3 do ataque, o quadro transmitido do adversário ao autenticador deve dizer um ReassoReq em vez de ReassoResp.

FERRAMENTAS

Nós criamos scripts para detectar se uma implementação do handshake de 4 vias, handshake de chave de grupo ou Handshake de transição Fast BSS (FT) é vulnerável a ataques de reinstalação de chaves. Esses scripts serão lançados assim que tivermos o tempo necessário para limpar suas instruções de uso.

Nós também fizemos um script de prova de conceito que explora a presença de chave (re) instalação total em certos dispositivos Android e Linux. Este script é o que usamos no vídeo de demonstração . Será lançado uma vez que todos tiveram uma chance razoável de atualizar seus dispositivos (e tivemos a chance de preparar o repositório de código para lançamento). Observamos que a confiabilidade do nosso script de prova de conceito pode depender da proximidade da vítima com a rede real. Se a vítima estiver muito próxima da rede real, o script pode falhar porque a vítima sempre se comunicará diretamente com a rede real, mesmo que a vítima seja (forçada) em um canal Wi-Fi diferente da rede.

Q & A

Precisamos agora de WPA3?

Não, felizmente as implementações podem ser corrigidas de uma maneira compatível com versões anteriores . Isso significa que um cliente remendado ainda pode se comunicar com um ponto de acesso não pisado e vice-versa. Em outras palavras, um cliente ou ponto de acesso remendado envia exatamente as mesmas mensagens de aperto de mão que antes e exatamente no mesmo momento. No entanto, as atualizações de segurança assegurará que uma chave só esteja instalada uma vez, impedindo nosso ataque. Então, novamente, atualize todos os seus dispositivos assim que as atualizações de segurança estiverem disponíveis.

Devo mudar minha senha Wi-Fi?

Alterar a senha da sua rede Wi-Fi não impede (ou mitiga) o ataque. Portanto, você não precisa atualizar a senha da sua rede Wi-Fi. Em vez disso, você deve certificar-se de que todos os seus dispositivos estão atualizados e você também deve atualizar o firmware do seu roteador. No entanto, depois de atualizar seus dispositivos clientes e seu roteador, nunca é uma má idéia mudar a senha Wi-Fi.

Estou usando WPA2 com apenas AES. Isso também é vulnerável?

Sim, essa configuração de rede também é vulnerável. O ataque funciona contra WPA1 e WPA2, contra redes pessoais e corporativas e contra qualquer conjunto de cifras que esteja sendo usado (WPA-TKIP, AES-CCMP e GCMP). Então todos devem atualizar seus dispositivos para evitar o ataque!

Você usa a palavra “nós” neste site. Quem somos nós?

Eu uso a palavra “nós” porque é o que eu estou acostumado a escrever em documentos. Na prática, todo o trabalho é feito por mim, comigo sendo Mathy Vanhoef. Meu incrível supervisor é adicionado sob uma autoria honorária ao documento de pesquisa para sua excelente orientação geral. Mas todo o trabalho real foi feito sozinho. Portanto, a lista de autores de trabalhos acadêmicos não representa divisão de trabalho 🙂

O meu dispositivo é vulnerável?

Provavelmente. Qualquer dispositivo que use Wi-Fi provavelmente seja vulnerável. Entre em contato com seu fornecedor para obter mais informações.

E se não houver atualizações de segurança para o meu roteador?

Nosso principal ataque é contra o aperto de mão de 4 vias, e não aproveita os pontos de acesso, mas em vez disso almeja os clientes. Portanto, pode ser que o seu roteador não exija atualizações de segurança. Recomendamos que você entre em contato com seu fornecedor para obter mais detalhes. Em geral, você pode tentar mitigar os ataques contra roteadores e pontos de acesso ao desativar a funcionalidade do cliente (que é, por exemplo, usado nos modos de repetição) e desativar 802.11r (roaming rápido). Para usuários domésticos comuns, sua prioridade deve ser a atualização de clientes, como laptops e smartphones.

Como você descobriu essas vulnerabilidades?

Ao trabalhar na versão final (ou seja, pronta para câmera) de outro artigo , verifiquei algumas afirmações sobre a implementação do handshake de 4 vias da OpenBSD. Em certo sentido, eu estava relaxando, porque eu deveria estar apenas acabando o papel, em vez de olhar para o código. Mas lá estava eu, inspecionando algum código que já li cem vezes, para evitar ter que trabalhar no próximo parágrafo. Foi naquela época que uma chamada particular para ic_set_key chamou minha atenção. Esta função é chamada ao processar a mensagem 3 do handshake de 4 vias, e instala a chave pairwise para o driver. Enquanto olhava aquela linha de código, pensei “Ha. Pergunto-me o que acontece se essa função for chamada duas vezes “. No momento em que eu (corretamente) adivinhei que chamá-lo duas vezes pode reiniciar os não associados à chave. E uma vez que a mensagem 3 pode ser retransmitida pelo ponto de acesso, na prática, ele pode ser chamado duas vezes. “É melhor anotar isso. Outros vendedores também podem chamar essa função duas vezes. Mas vamos primeiro terminar este artigo … “ . Algumas semanas depois, depois de terminar o trabalho e completar algum outro trabalho, investiguei esta nova idéia com mais detalhes. E o resto é história.

O handshake de 4 vias foi matematicamente comprovado como seguro. Como é possível o seu ataque?

A resposta breve é ​​que a prova formal não garante que uma chave seja instalada uma vez. Em vez disso, ele garante apenas que a chave negociada permaneça secreta e que as mensagens de aperto de mão não podem ser forjadas.

A resposta mais longa é mencionada na introdução do nosso trabalho de pesquisa: nossos ataques não violam as propriedades de segurança comprovadas na análise formal do handshake de 4 vias. Em particular, essas provas indicam que a chave de criptografia negociada permanece privada e que a identidade do cliente e do ponto de acesso (AP) é confirmada. Nossos ataques não vazam a chave de criptografia. Além disso, embora os quadros de dados normais possam ser forjados se o TKIP ou GCMP for usado, um invasor não pode forjar mensagens de handshake e, portanto, não pode representar o cliente ou o AP durante os apertos de mão. Portanto, as propriedades que foram comprovadas na análise formal do handshake de 4 vias permanecem verdadeiras. No entanto, o problema é que as provas não modelam a instalação da chave. Em outras palavras, os modelos formais não definiram quando uma chave negociada deveria ser instalada. Na prática, isso significa que a mesma chave pode ser instalada várias vezes,

Alguns ataques no papel parecem difíceis

Temos um trabalho de acompanhamento, tornando nossos ataques (contra o MacOS e o OpenBSD, por exemplo) significativamente mais gerais e mais fáceis de executar. Então, embora concordemos que alguns dos cenários de ataque no documento são bastante impraticáveis, não deixe isso enganar você para acreditar que ataques de reinstalação chave não podem ser abusados ​​na prática.

Se um atacante pode fazer um ataque do homem no meio, por que ele não pode simplesmente descriptografar todos os dados?

Conforme mencionado na demonstração, o atacante primeiro obtém uma posição de homem-em-meio (MitM) entre a vítima e a rede Wi-Fi real (chamada de posição MitM baseada em canal ). No entanto, esta posição MitM não permite ao atacante decodificar pacotes! Esta posição apenas permite que o invasor reprima, bloqueie ou reproduza pacotes com criptografiaconfiáveis . Então, neste momento do ataque, ele ou ela ainda não pode decifrar os pacotes. Em vez disso, a capacidade de atrasar e bloquear pacotes de forma confiável é usada para executar um ataque de reinstalação de chave. Depois de executar um ataque de reinstalação chave, os pacotes podem ser descriptografados.

As pessoas estão explorando isso na natureza?

Não estamos em condições de determinar se esta vulnerabilidade foi (ou está sendo) ativamente explorada na natureza. Dito isto, as reinstalações chave podem ocorrer de forma espontânea sem que um adversário esteja presente! Isso pode acontecer, por exemplo, se a última mensagem de um aperto de mão for perdida devido ao ruído de fundo, causando uma retransmissão da mensagem anterior. Ao processar esta mensagem retransmitida, as chaves podem ser reinstaladas, resultando em não ser reutilizado, como em um ataque real.

Devo usar temporariamente o WEP até que meus dispositivos estejam corrigidos?

NÃO! Continue usando WPA2.

O padrão Wi-Fi será atualizado para resolver isso?

Parece haver um acordo de que o padrão Wi-Fi deve ser atualizado para impedir explicitamente nossos ataques. Essas atualizações provavelmente serão compatíveis com versões anteriores de WPA2. O tempo indicará se e como o padrão será atualizado.

O Wi-Fi Alliance também aborda essas vulnerabilidades?

Para aqueles que não estão familiarizados com o Wi-Fi, a Wi-Fi Alliance é uma organização que certifica que os dispositivos Wi-Fi estão em conformidade com certos padrões de interoperabilidade. Entre outras coisas, isso garante que os produtos Wi-Fi de diferentes fornecedores funcionam bem juntos.

A Aliança Wi-Fi tem um plano para ajudar a remediar as vulnerabilidades descobertas no WPA2. Resumidos, eles irão:

  • Exigir testes para essa vulnerabilidade dentro de sua rede global de laboratórios de certificação.
  • Forneça uma ferramenta de detecção de vulnerabilidades para uso por qualquer membro da Aliança Wi-Fi (esta ferramenta é baseada em minha própria ferramenta de detecção que determina se um dispositivo é vulnerável a alguns dos ataques de reinstalação de chave descobertos).
  • Divulgue dados detalhados sobre esta vulnerabilidade, incluindo remédios, para fornecedores de dispositivos. Além disso, os fornecedores são encorajados a trabalhar com os fornecedores de soluções para integrar rapidamente todos os patches necessários.
  • Comunique a importância para os usuários garantir que instalaram as últimas atualizações de segurança recomendadas dos fabricantes de dispositivos.

Por que você usou match.com como um exemplo no vídeo de demonstração?

Os usuários compartilham muita informação pessoal em sites como o match.com. Portanto, este exemplo destaca todas as informações confidenciais que um invasor pode obter, e, com o exemplo desse exemplo, as pessoas também podem perceber o impacto potencial (pessoal). Nós também esperamos que este exemplo faça as pessoas conscientes de todas as informações que estes sites de encontros podem estar coletando .

Como evitar esses tipos de erros?

Precisamos de inspeções mais rigorosas sobre implementações de protocolos. Isso requer ajuda e pesquisas adicionais da comunidade acadêmica! Juntamente com outros pesquisadores, esperamos organizar workshop (s) para melhorar e verificar a correção das implementações de protocolos de segurança.

Por que o nome de domínio krackattacks.com?

Em primeiro lugar, estou ciente de que os ataques Krack é um pleonasmo , pois Krack significa k ey r einstallation um tta ck e, portanto, já contém a palavra ataque. Mas o nome do domínio rima, então é por isso que ele é usado.

Você recebeu recompensas de erro por isso?

Eu ainda não solicitei nenhuma recompensa de erro, nem já recebi uma.

Como esse ataque se compara a outros ataques contra o WPA2?

Este é o primeiro ataque contra o protocolo WPA2 que não depende da adivinhação de senhas. Na verdade, outros ataques contra a rede habilitada para WPA2 são contra tecnologias circundantes, como Wi-Fi Protected Setup (WPS) , ou são ataques a padrões mais antigos, como o WPA-TKIP . Dito de outra forma, nenhum dos ataques existentes foi contra o handshake de 4 vias ou contra conjuntos de cifras definidos no protocolo WPA2. Em contraste, nosso ataque de reinstalação chave contra o handshake de 4 vias (e contra outros handshakes) destaca vulnerabilidades no próprio protocolo WPA2.

Outros protocolos também são afetados pelos principais ataques de reinstalação?

Esperamos que determinadas implementações de outros protocolos possam ser vulneráveis ​​a ataques semelhantes. Portanto, é uma boa idéia auditar implementações de protocolos de segurança com este ataque em mente. No entanto, consideramos improvável que outros padrões de protocolo sejam afetados por ataques semelhantes (ou, pelo menos, esperamos). No entanto, ainda é uma boa idéia para auditar outros protocolos!

Existe uma versão de resolução mais alta do logotipo?

Sim, há . E um grande obrigado é para a pessoa que fez o logotipo!

Quando você notificou os fornecedores sobre a vulnerabilidade?

Enviamos notificações para fornecedores cujos produtos nos testávamos em torno de 14 de julho de 2017. Depois de nos comunicar com esses fornecedores, percebemos quão generalizadas as fraquezas que descobrimos são (só então eu realmenteme convenci de que era realmente um protocolo de fraquezas e não um conjunto de erros de implementação). Nesse ponto, decidimos deixar o CERT / CC ajudar com a divulgação das vulnerabilidades. Por sua vez, o CERT / CC enviou uma ampla notificação aos fornecedores em 28 de agosto de 2017.

Por que o OpenBSD liberou silenciosamente um patch antes do embargo?

O OpenBSD foi notificado da vulnerabilidade em 15 de julho de 2017, antes que CERT / CC participasse da coordenação. Muito rapidamente, Theo de Raadt respondeu e criticou o prazo provisório de divulgação: “No mundo de código aberto, se uma pessoa escreve um diff e tem que se sentar nele por um mês, isso é muito desencorajador” . Notei que eu escrevi e incluí um diferencial sugerido para o OpenBSD já, e que, no momento, o prazo provisório de divulgação era no final de agosto. Como um compromisso, permiti que eles corrigissem silenciosamente a vulnerabilidade. Em retrospectiva, esta foi uma decisão ruim, já que outros podem redescobrir a vulnerabilidade inspecionando seu patch silencioso. Para evitar este problema no futuro, o OpenBSD receberá notificações de vulnerabilidade mais perto do fim de um embargo.

Então, você espera encontrar outras vulnerabilidades Wi-Fi?

“Eu acho que estamos apenas começando.”  – Master Chief, Halo 1