Protexe unha VPN contra KRACK? Que corrixe o parche

Se compras unha VPN porque un titular dicía que KRACK rompe o cifrado Wi-Fi, estás reparando a capa equivocada. Aquela revelación de 2017 describía unha familia de ataques de reinstalación de chaves contra o handshake de catro vías de WPA2, e a reparación chegou como actualizacións do sistema operativo, parches de controladores sen fíos e firmware de routers. Un túnel pode ocultar o teu tráfico da rede local, pero non pode reparar un handshake que remata por debaixo del. Así que a primeira pregunta non é que VPN comprar; é cal dos teus dispositivos segue executando unha pila sen fíos sen parchear.

A mesma distinción responde á preocupación polo orzamento. Quen non pode permitirse unha subscrición nunca quedou fóra do remedio real, porque o remedio era unha actualización gratuíta. O que custa diñeiro é substituír hardware que xa non recibe ningunha.

Que manipulou realmente o ataque

WPA2 deriva unha chave por parella nova no momento da asociación mediante un handshake de catro vías. O punto de acceso envía un nonce, o cliente responde co seu, ambas as partes calculan a chave transitoria por parella e o punto de acceso confirma cunha mensaxe que o cliente recoñece. Un ataque de reinstalación de chaves interfire nesa secuencia en lugar de adiviñar a frase de paso, e obriga a un cliente a instalar unha chave que xa instalara. Cada reinstalación pode reiniciar o nonce de transmisión e o contador de repetición de recepción ligados a esa chave.

Cando eses contadores retroceden, parte do tráfico que debería ser rexeitado volve ser aceptable. Segundo a variante e a implementación, un atacante dentro do alcance de radio podía reproducir tramas, descifralas ou inxectalas. O handshake de chave de grupo e o de transición rápida tiñan as súas propias variantes, e por iso o aviso enumeraba varios nomes de ataque en lugar dun.

Android 6.0 e posteriores foi o peor caso. As súas versións de wpa_supplicant podían ser forzadas a instalar unha chave de todo ceros, o que facía o descifrado moito máis doado que en plataformas onde a reinstalación só reiniciaba contadores. Ese detalle separou unha debilidade teórica dunha práctica na plataforma de teléfono máis común da época.

A corrección vive na pila sen fíos

A corrección orixinal dixo aos supplicants e aos puntos de acceso que ignorasen unha mensaxe de handshake retransmitida unha vez que a chave xa estaba instalada. As compilacións parcheadas de wpa_supplicant e hostapd levábana, e as distribucións retrotraérona a ramas antigas, así que a cadea que imprime wpa_supplicant -v é un punto de partida e non un veredicto. Le o aviso de seguridade da distribución e confirma o parche concreto, non só o número de versión. Unha compilación que declara unha versión antiga pode estar corrixida, e unha que declara unha nova pode seguir sen un parche do fabricante.

Os dous extremos da ligazón necesitan atención. Un router reparado non parchea o portátil que se asocia con el, e un portátil reparado non parchea o router. Os fabricantes publicaban avisos por produto, e as correccións de router adoitan ir por detrás das actualizacións de teléfono porque cada modelo necesita a súa propia compilación de firmware. Se a última versión dun dispositivo é anterior ao aviso, trátao como non parcheado ata que o fabricante diga o contrario.

Para o equipo que non podes actualizar, as opcións son estreitas e pouco glamurosas. Retírao, manteno fóra de redes que leven tráfico sensible, ou confínao a un segmento onde os seus únicos pares sexan igual de prescindibles. Ningunha desas opcións implica unha subscrición, e ningunha mellora escollendo outro provedor de túnel.

Que cobre un túnel

Unha VPN move a fronteira. O teu dispositivo cifra cada paquete e envíao a un servidor VPN, que o descifra e o reenvía. Quen manipula a ligazón Wi-Fi ve paquetes externos do túnel, non a carga útil de dentro, así que un ataque de reinstalación que expón tramas da capa de ligazón non expón automaticamente o contido da conexión tunelizada. Esa protección mantense mesmo mentres a pila sen fíos de abaixo segue sendo vulnerable, e é exactamente por iso que os dous controis se confunden.

O matiz é «tunelizado». O túnel dividido, unha lista de omisión ou unha excepción de portal cativo envían parte do tráfico fóra do túnel, e ese tráfico non obtén ningún beneficio del. Tamén ocorre co tráfico doutros dispositivos da mesma rede que nunca instalaron o cliente. Un túnel é unha decisión por dispositivo e por ruta, non unha propiedade da sala, e unha VPN a nivel de router só cobre o que realmente pasa polo router.

O que o túnel non pode facer é reparar o controlador, deter unha inundación de desautenticación ou impedir que un atacante interfira a canle. Tampouco pode protexer unha conexión que nunca entra nel. Son problemas de dispoñibilidade e de capa de ligazón, e quedan coa pila sen fíos por forte que sexa o conxunto de cifrados do túnel.

HTTPS e o túnel protexen saltos distintos

Unha soa carga de páxina pode implicar tres proteccións separadas: a ligazón Wi-Fi, o túnel ao servidor VPN e a sesión TLS ao sitio web. Cada unha négase de forma independente. TLS cun certificado válido e unha versión de protocolo moderna dache cifrado autenticado entre navegador e sitio mesmo cando o primeiro salto é hostil, porque a comprobación do certificado é o que impide que un impostor substitúa a súa propia chave.

Esa comprobación ten puntos débiles nos bordos. Unha redirección de HTTPS a HTTP, unha páxina que carga scripts por HTTP simple ou un usuario que fai clic a través dun aviso de certificado sacan tráfico da sesión protexida. HSTS e as páxinas intermedias do navegador existen porque eses erros son frecuentes, non porque TLS sexa fráxil.

Manter HTTPS e un túnel non fai que a implementación sen fíos deixe de ser vulnerable. As tramas seguen sendo descifradas por un controlador defectuoso; a diferenza é que atopa o atacante dentro e se ese contido xa estaba protexido por outra cousa.

Orde de reparación para unha rede mixta

Comeza polo punto de acceso, porque é o dispositivo que controlas e do que depende cada cliente. Despois percorre os sistemas operativos dos clientes, dos máis antigos aos máis novos, xa que as plataformas que deixaron de recibir actualizacións son as que nunca se parchearán. Só cando ese inventario estea feito ten sentido unha decisión sobre a VPN, e é unha decisión sobre exposición, non sobre reparación. Facelo ao revés, primeiro o túnel e logo o firmware, deixa o defecto real no seu sitio mentres dure a subscrición.

Anota que verificaches, incluída a versión de firmware e a data. «Actualizado» non é un estado que ninguén poida auditar despois.

Tres comprobacións cobren a maior parte do traballo, e van nesta orde. Non saltes a terceira só porque as dúas primeiras saíron limpas.

• Firmware do router: compara a versión instalada coa páxina de avisos do fabricante, non co botón de actualización.
• SO do cliente: confirma o nivel de parches que inclúe a corrección sen fíos para cada teléfono, portátil e tableta.
• Restos: enumera os dispositivos sen ruta de parche e decide retirar, illar ou aceptar.

Se a lista de restos é longa, unha rede de convidados con illamento de clientes gaña tempo mentres se substitúe o hardware. Despois proba un cliente coñecido en cada banda, anota o resultado e volve comprobar tras a seguinte versión de firmware. O inventario de hardware é o que fai rápido o próximo aviso; o túnel é o que cobre o oco mentres tanto.