Prevención de ataques WiFi malvados en sistemas integrados

Question

Prevención de ataques WiFi malvados en sistemas integrados

#1 de PMG (1 votos)

7

Recientemente he estado observando algunos de los módulos WiFi de gama baja utilizados en dispositivos IoT, como el TLGUA06 y ESP2866.

Como se esperaba, es posible autenticar estos dispositivos mediante el envío de un marco de autenticación. Esto es según las especificaciones de WiFi.

Sin embargo, ambos dispositivos volverán a unirse a una red abierta con el mismo ESSID. No hay ningún requisito para clonar el MAC del AP ni nada.

Esto obviamente lleva a ataques de gemelos malvados. Combinado con el uso común de protocolos inseguros, un atacante puede interceptar fácilmente o comunicaciones MITM.

OSX se queja cuando intenta este ataque, al igual que muchas versiones de Windows. Mi iPhone se queja, pero mi teléfono con Android no.

¿Por qué estos dispositivos no protegen contra los ataques de los gemelos malvados? Entiendo que esto puede ser un compromiso entre seguridad y confiabilidad, pero no hay configuraciones o controles que permitan a un fabricante elegir hacer un sistema más seguro.

¿Me he perdido otra razón por la que estos ataques son posibles?

¿Qué estrategias pueden usarse para protegerse contra los ataques de los gemelos malvados?

wifi

pregunta Cybergibbons 20.12.2015 - 18:54

fuente

1 respuesta

Lea otras preguntas en las etiquetas wifi

¿Por qué Java permite el cifrado AES-256 bit en sistemas sin políticas de fuerza ilimitada de JCE si se usa PBE? Mejores prácticas para implementar HTTPS en dispositivos integrados

score 1 · Answer 1

Hay dos partes en esta respuesta.

La mayoría de los navegadores y sistemas operativos móviles tendrán una tienda de CA con docenas de compañías de CA y cientos de certificados con los cuales validar TLS. Los ataques de Evil Twin se basan en que usted no almacena en la memoria caché las solicitudes que necesitan TLS con qué certificados, de modo que puede MitM para pasar una solicitud sin certificado. Esta lista se actualiza con el tiempo, pero es bastante pesada para un sistema incrustado ligero.

Las plataformas IoT como Electric Imp utilizan un coprocesador de cifrado dedicado con almacenamiento seguro como ATSHA204 u otro chip de estilo TPM2. Todas las solicitudes se enrutan a través de una puerta de enlace conocida (como Amazon Bucket de Electric Imp) con una clave conocida antes de salir a Internet. (Creo que Kindle también hace esto con su navegador "Experimental"). Si el apretón de manos falla, la conexión se cae. Dependiendo de cómo se haga esto, el lado del servidor puede detectar evidencia de mal comportamiento e informar sobre el mal comportamiento al usuario como usted sugiere. La clave almacenada en el dispositivo puede ser única para cada instancia del hardware y está asociada / bendecida en la fábrica antes de que se envíe al consumidor.

Básicamente, estás cambiando a un gemelo malvado por un padre de confianza que distribuye todas tus comunicaciones.

Todas las comunicaciones salientes pasan por un punto final conocido contra el cual la validación es más simple. Ese punto final puede llevar solicitudes más sofisticadas a recursos externos. Para solicitudes de bajo ancho de banda, es simple y adecuado para una gran cantidad de aplicaciones actuales de IoT.

Lo apropiado de este modelo depende de su aplicación. Si usted es el canal del clima y está creando un dispositivo que cambia de color según la temperatura del clima, existen algunas preocupaciones.

Si su dispositivo lee en voz alta el correo electrónico de sus clientes (como el que se encuentra en los automóviles BMW), existe una gran preocupación con respecto a que usted toque esos datos. Nokia se metió en problemas con esto hace unos años.