O ponto de partida

A história da família wireless conta o caso do WEP e a lição que ele deixou: a falha não estava na cifra, e sim no jeito como o protocolo a usava. Este artigo conta o que veio depois, porque essa mesma frase acaba descrevendo tudo o que aconteceu em seguida.

O WPA2 substituiu o WEP em 2004 e aguentou firme por treze anos. O four-way handshake dele é a troca de quatro mensagens em que o cliente e o access point (ponto de acesso), que já têm a chave derivada da senha da rede, combinam uma chave de sessão nova. Esse handshake tinha sido examinado por criptógrafos e tinha provas formais de segurança por trás. A nota de um fabricante durante a divulgação de 2017 disse com todas as letras: o handshake tinha sido provado matematicamente seguro pela comunidade científica.

E tinha sido mesmo. Ainda assim, quebrou.

O que o handshake faz e o que o KRACK fez com ele

São quatro mensagens. O access point manda um número aleatório; o cliente manda o seu próprio número aleatório e uma prova de que conhece a chave compartilhada; o access point confirma e, na mensagem três, manda o cliente instalar a chave de sessão, já derivada a essa altura; o cliente confirma o recebimento na mensagem quatro.

A falha está no que acontece quando a mensagem quatro se perde. Rádio não é um meio confiável, então o access point retransmite a mensagem três, e o cliente, seguindo corretamente a especificação, aceita a mensagem e instala a chave de novo. O ataque é só isso. Mathy Vanhoef, do grupo imec-DistriNet da KU Leuven, mostrou que um atacante dentro do alcance do rádio, posicionado entre os dois, podia bloquear de propósito a mensagem quatro, forçar a retransmissão e fazer o cliente reinstalar uma chave que já estava em uso.

Reinstalar a chave faz os contadores associados a ela voltarem aos valores iniciais: o número de pacote de transmissão (transmit packet number), que é o nonce, e o contador de replay da recepção (receive replay counter). E reutilizar o nonce com a mesma chave é justamente a única coisa que a criptografia usada por baixo nunca pode fazer. Com o nonce repetido, dá para recuperar o keystream (o fluxo de chave).

O impacto dependia da cifra em uso, e essa diferença importa na operação. Contra o -CCMP, o atacante conseguia fazer replay de pacotes (reenviá-los) e decifrá-los, mas não forjá-los, o que já bastava para sequestrar (hijack) um fluxo TCP e injetar dados nele. Contra o -TKIP e o GCMP, o impacto era, na palavra dos próprios pesquisadores, catastrófico: dava para fazer replay, decifrar e forjar pacotes. A mesma técnica também quebrou o handshake da chave de grupo (group key handshake), o handshake do PeerKey e o handshake de fast transition do 802.11r, e recebeu dez identificadores diferentes.

Também houve um achado de implementação, pior que o de protocolo. Clientes Android e Linux com certas versões do wpa_supplicant, quando enganados, não reinstalavam a chave verdadeira: instalavam uma chave toda zerada. Contra esses dispositivos, o atacante nem precisava recuperar keystream nenhum.

Por que a prova formal não impediu o ataque

Esta é a parte que vale levar para qualquer conversa sobre verificação formal, e é a versão do argumento que o artigo sobre por que não existe código perfeito faz com o ScreenOS da Juniper.

As provas do four-way handshake eram provas sobre o handshake em si: que um atacante que observa a troca não consegue derivar a chave de sessão, e que as duas partes terminam concordando sobre a mesma chave. Tudo isso continuou verdadeiro. O que as provas não modelavam era a máquina de estados em volta do handshake, ou seja, o que uma implementação deve fazer quando a mesma mensagem chega duas vezes. A especificação não proibia reinstalar uma chave porque ninguém tinha feito essa pergunta, e uma prova só responde à pergunta que fizeram a ela.

A conclusão certa não é que análise formal não serve para nada. É que toda prova tem um escopo, que esse escopo costuma ser o protocolo e não o comportamento da implementação ao longo do tempo, e que é no espaço entre os dois que a indústria continua encontrando problemas.

Uma divulgação que deu certo

O paper (o artigo científico) foi submetido para revisão em 19 de maio de 2017. O CERT/CC avisou os fabricantes em 28 de agosto. A pesquisa veio a público em 16 de outubro, e o paper foi apresentado na conferência da ACM em Dallas, no começo de novembro. Quando tudo se tornou público, já havia patches para os principais sistemas operacionais, firmwares de roteador e chipsets, lançados praticamente ao mesmo tempo.

Dois detalhes merecem atenção. O próprio Vanhoef observou que, na data da publicação, as descobertas já tinham vários meses e que, nesse meio-tempo, ele tinha encontrado técnicas mais fáceis que as do paper; a versão publicada, de propósito, não era a mais afiada que existia. E a correção era retrocompatível: o patch fez os clientes recusarem a reinstalação de uma chave já em uso, o que significa que um cliente com patch fica seguro mesmo num access point sem patch. Foi essa característica que fez a resposta funcionar, e nem sempre ela está disponível.

O WPA3, que durou um ano

A Wi-Fi Alliance anunciou o em 2018. A principal melhoria foi trocar o handshake de pre-shared key (chave pré-compartilhada) pelo Simultaneous Authentication of Equals, conhecido como Dragonfly: uma troca de chaves autenticada por senha, projetada para que um atacante que capture um handshake não consiga levá-lo embora e rodar contra ele um ataque de dicionário offline. Foi uma correção real e importante para uma fraqueza real e importante.

Em abril de 2019, Vanhoef, já na NYU Abu Dhabi, publicou de novo, desta vez com Eyal Ronen, da Universidade de Tel Aviv e da KU Leuven. O paper dos dois, Dragonblood, encontrou várias classes de problema: ataques de downgrade contra o WPA3 em modo de transição (transition mode), em que uma rede que aceita clientes WPA2 e WPA3 pode ser empurrada de volta para o handshake antigo; um downgrade contra o próprio SAE; negação de serviço contra o access point; formas de burlar a autenticação (bypass) em todas as implementações que eles testaram do , um protocolo relacionado; e, como resultado principal, side channels (canais laterais) de timing e de cache no método de codificação da senha, que vazam informação suficiente para permitir justamente o ataque de dicionário offline que o projeto existia para impedir.

Dois detalhes se encaixam bem até demais. O overhead que eles exploraram para a negação de serviço vinha justamente das defesas contra side channels de timing já conhecidos: uma contramedida criando um problema novo. E a avaliação deles sobre o processo, citada pela imprensa, foi que um processo de projeto mais aberto teria impedido os ataques de downgrade ou deixado clara a possibilidade deles. As correções foram incorporadas ao padrão.

O que levar disso para a prática

Três gerações, três falhas, e nenhuma delas na cifra. A falha do WEP estava no jeito como ele usava uma cifra de fluxo (stream cipher). O foi uma máquina de estados aceitando uma retransmissão. O Dragonblood foi uma codificação de senha vazando informação por timing. A criptografia nunca foi a parte fraca, e isso é um bom motivo para desconfiar de qualquer discussão de segurança que gasta o tempo todo com tamanho de chave.

O ataque mora no modo de transição. O WPA3 em modo de transição, que aceita clientes WPA2 para nada quebrar, permite downgrade, exatamente como os ataques ao TLS que ganharam nome próprio mostram para todo protocolo que manteve uma opção mais fraca por compatibilidade. Se o parque realmente não tem nenhum dispositivo que só suporte WPA2, a configuração certa é usar só WPA3; se tem, o honesto é admitir que a rede está protegida no nível do WPA2 e planejar de acordo.

O controle que importou foi aplicar patch nos clientes. A correção do KRACK foi, principalmente, do lado do cliente. Numa empresa, o que precisa entrar no inventário é a população de dispositivos que nunca recebeu patch: coletores de dados portáteis, equipamentos médicos, sistemas de automação predial, impressoras, qualquer coisa cujo fabricante parou de lançar . É a mesma população que a era dos worms aponta repetidas vezes.

E o processo funcionou, devagar e às claras. Um pesquisador achou a falha e a divulgou por meio de um órgão coordenador, os fabricantes lançaram patches antes da publicação, as correções entraram no padrão e, depois, o mesmo pesquisador fez tudo de novo com o substituto. Isso não é uma falha do sistema. É assim que o sistema funciona, e a alternativa, falhas encontradas por gente que não publica nada, é o assunto do resto deste catálogo.

Fontes