Se han identificado vulnerabilidades en los paquetes abiertos de IWD (Intel inet Wireless Daemon) y wpa_supplicant, utilizados para conectar sistemas Linux clientes a redes inalámbricas, que permiten eludir los mecanismos de autenticación:
- En IWD, la vulnerabilidad (CVE-2023-52161) se manifiesta únicamente cuando se activa el modo de punto de acceso, lo cual es atípico para IWD, que normalmente se utiliza para establecer conexiones a redes inalámbricas. Esta vulnerabilidad permite conectarse a un punto de acceso creado sin conocer la contraseña, por ejemplo, cuando el usuario permite explícitamente el acceso a Internet a través de su dispositivo (Hotspot). El problema se ha solucionado en la versión IWD 2.14.
La vulnerabilidad se debe a la falta de una verificación adecuada del orden de los pasos en el proceso de conciliación de cuatro etapas, utilizado en la primera conexión a una red inalámbrica protegida. Dado que IWD acepta mensajes para cualquier etapa de la conciliación de conexión sin verificar si se ha completado la etapa anterior, un atacante puede enviar directamente el mensaje de la cuarta etapa omitiendo el envío del mensaje de la segunda etapa y obtener acceso a la red, saltándose la etapa en la que se realiza la verificación de autenticación.
En este caso, IWD intenta verificar el código MIC (Message Integrity Code) para el mensaje recibido de la cuarta etapa. Dado que el mensaje de la segunda etapa con los parámetros de autenticación no se ha recibido, al procesar el mensaje de la cuarta etapa, la clave PTK (Pairwise Transient Key) se establece en un valor nulo. Por lo tanto, el atacante puede calcular el MIC utilizando el PTK nulo, y este código de verificación será aceptado por IWD como válido. Tras completar esta conciliación de conexión incompleta, el atacante obtendrá acceso completo a la red inalámbrica, ya que el punto de acceso aceptará los tramas que envía, cifradas con la clave PTK nula.
- El problema identificado en wpa_supplicant (CVE-2023-52160) permite a un atacante atraer al usuario a una red inalámbrica falsa que es un clon de la red a la que el usuario intenta conectarse. Si el usuario se conecta a la red falsa, el atacante puede interceptar el tráfico en tránsito no cifrado del usuario (por ejemplo, accesos a sitios sin HTTPS).
Debido a una deficiencia en la implementación del protocolo PEAP (Protected Extensible Authentication Protocol), un atacante puede eludir la segunda fase de autenticación al conectarse a un dispositivo del usuario que está configurado incorrectamente. Eludir esta segunda fase de autenticación permite al atacante crear un clon falso de una red Wi-Fi de confianza y conectar al usuario a una red ficticia sin verificar la contraseña.
Para que un ataque sea exitoso, en wpa_supplicant debe deshabilitarse la verificación del servidor en el lado del usuario. un certificado TLS Además, el atacante debe conocer el identificador de la red inalámbrica (SSID, Service Set Identifier). El atacante debe estar dentro del alcance del adaptador inalámbrico de la víctima, pero fuera del alcance del punto de acceso de la red inalámbrica clonada. El ataque es posible en redes con WPA2-Enterprise o WPA3-Enterprise, donde se utiliza el protocolo PEAP.
Los desarrolladores de wpa_supplicant han declarado que no consideran el problema como una vulnerabilidad, ya que se manifiesta solo en redes inalámbricas configuradas incorrectamente, donde la autenticación EAP se utiliza junto con el protocolo PEAP (EAP-TTLS) sin verificar el certificado TLS. servidoresLas configuraciones sin verificación de certificado no están protegidas contra ataques activos. Aquellos que han identificado la vulnerabilidad afirman que tales configuraciones incorrectas son típicas y están ampliamente extendidas, lo que pone en riesgo muchos dispositivos de consumo basados en Linux, Android y Chrome OS, que utilizan wpa_supplicant.
Para abordar el problema en wpa_supplicant, se ha lanzado un parche que agrega una fase obligatoria de autenticación, además de la verificación del certificado TLS. Según los desarrolladores, el cambio propuesto es solo una solución alternativa que complica la realización de ataques al utilizar autenticación manual y es inútil al aplicar opciones como EAP-GTC. Para resolver realmente el problema, los administradores de redes deben ajustar sus configuraciones adecuadamente, es decir, establecer una cadena de confianza para verificar el certificado del servidor mediante el parámetro ca_cert.
Fuente: opennet.ru
