Evil Twin Access Point Secured-Unecured

5

Se hizo una pregunta muy similar aquí pero no obtuve ninguna respuesta, así que voy a hacer una nueva pregunta con algunas ideas más.

El problema del Evil Twin Attack más común es que el AP falso no está asegurado y me he dado cuenta de que, incluso con un ataque deauth al AP real, el cliente no se conectará automáticamente al AP falso debido a las diferentes Configuración 802.1x. La única forma sería que el cliente se conecte por su propia voluntad.

Estoy usando hostapd para crear el AP falso. Entonces, ¿cómo podría aceptar la solicitud de autenticación incluso si la frase de contraseña del cliente no coincide con la configurada en el archivo de configuración del AP falso ( hostapd.conf )?

Porque el PSK generado a partir del AP falso sería diferente del generado por el cliente.

    
pregunta loopOfNegligence 08.03.2017 - 17:55
fuente

2 respuestas

4

Ya he respondido sobre cómo clonar AP (fusionar con el original en una lista de redes inalámbricas) en aquí creo.

Si el malvado mellizo es una Red abierta (esperando a que el usuario la seleccione manualmente de la lista de redes), tendría que seguir enviando varios marcos hasta que se agote el tiempo de reconexión.

Si desea aceptar automáticamente la solicitud de autenticación (que se pasará al servidor RADIUS-AAA) del cliente, debe tener exactamente la misma configuración en el AP.

  • Mayor intensidad de la señal (hay un parámetro que indica qué AP es mejor para conectar la "agresividad de itinerancia")
  • El mismo ESSID (el nombre de la red que buscan las sondas o la baliza que emite el AP)
  • Algoritmo de cifrado (WPA2, a juzgar por la etiqueta en su pregunta)
  • El cifrado (CCMP)

Lo que se traduce aproximadamente en esto en el hostapd.conf (estos son ALGUNOS parámetros)

auth_server_addr=192.168.0.1         // RADIUS SERVER (Enterprise / 802.1x)
auth_server_port=1234                // RADIUS SERVER (Enterprise / 802.1x)
auth_server_shared_secret=verySecret // RADIUS SERVER (Enterprise / 802.1x)
wpa_key_mgmt=WPA-EAP                 // RADIUS SERVER (Enterprise / 802.1x)
ieee8021x=1                          // RADIUS SERVER (Enterprise / 802.1x)
wpa=2                                // Encryption Algorithm (WPA2)
wpa_pairwise=CCMP                    // Cipher (CCMP)
ssid=evilTwin                        // ESSID
rsn_preauth=1

Aquí está el enlace de donde tomé este ejemplo (para más información).

Ahora, esto obviamente fallará en algún momento porque necesita el servidor RADIUS, está hablando de 802.1x, por lo que también debe configurar el archivo eapol-config (si está usando freeRADIUS ) que cambia todo al elegir uno de los 22 métodos EAP compatibles ( EAP-PEAP, EAP-TTLS, EAP-TLS, EAP-MD5, EAP-FAST, etc.)

  

Porque el PSK generado a partir del AP falso sería diferente del generado por el cliente.

La clave utilizada para el cifrado de datos se llama PMK y se extravía del TLS Masster Secret en EAP-TLS, aquí puede encontrar más información específica para EAP-TLS

Espero que esto responda a tu pregunta porque aún falta lo que quieres lograr y todo lo relacionado con el servidor RADIUS.

    
respondido por el Azteca 09.03.2017 - 00:20
fuente
0
  

El problema del Evil Twin Attack más común es que el AP falso no está asegurado y me he dado cuenta de que, incluso con un ataque deauth al AP real, el cliente no se conectará automáticamente al AP falso debido a las diferentes Configuración 802.1x. La única forma sería que el cliente se conecte por su propia voluntad.

     

Entonces, ¿cómo podría aceptar la solicitud de autenticación incluso si la frase de contraseña del cliente no coincide con la establecida en el archivo de configuración del AP falso (hostapd.conf)?

El ataque Evil Twin requiere que coincidan con la configuración de la red atacada lo más cerca posible. Entonces, si la red que está atacando está usando la autenticación 802.1X, debe usar la autenticación 802.1X en su AP falso.

A partir de ahí, debe configurar su AP falso como el cliente NAS para enviar solicitudes de autenticación a un servidor RADIUS de su control. En su servidor RADIUS, crearía una configuración que devolvería un ACEPTO DE RADIO a cualquier intento de autenticación (la capacidad para hacer esto y la implementación real varían según el servidor de RADIUS). No importa si tiene las credenciales reales del usuario porque no va a procesar realmente la autenticación, sino que la acepta ciegamente (esto significa que también estaría aceptando credenciales falsas o incorrectas).

El truco sería falsificar el nombre y el certificado del servidor de autenticación de la red real. Dependiendo de la configuración del cliente, si no coincide con ninguno de los dos, el dispositivo cliente no se autenticará en absoluto o solicitará al usuario una confirmación antes de autenticarse.

    
respondido por el YLearn 03.10.2017 - 07:22
fuente

Lea otras preguntas en las etiquetas