Evaluación de amenazas para un portal cautivo

Hay dos formas diferentes de omitir los portales / hotspots cautivos:

1. Ya sea mediante el uso de túneles de algún tipo, generalmente utilizando el protocolo DNS porque los clientes tienen el puerto saliente 53 abierto, oa través de http / https, o usando icmp para hacer un túnel u otras fuentes similares. @Ori ha proporcionado ejemplos de esto.

2. Otra forma es evitando directamente el mecanismo de autenticación: en última instancia, todos los hotspots tienen que autenticar a un cliente, y esto se hace (generalmente) a través de la dirección MAC o IP o las cookies. En ciertas ocasiones, estos pueden ser falsificados o rastreados para obtener una sesión ya autenticada por suplantación. Incluso se pueden configurar ciertos dispositivos en la red, con una dirección mac o ip codificada previamente autenticadas, por ejemplo. impresoras, y puede tomar su dirección.

Estábamos discutiendo una técnica en otro hilo que probablemente lograría esto. NSTX e ICMPTX aprovechan los agujeros de protocolo comunes que tienen las organizaciones. NSTX es el candidato más probable ya que no es probable que la organización con el portal cautivo impida el acceso al servidor / proxy DNS que está utilizando para resolver el nombre del portal cautivo.

Si puedes emitir una consulta de DNS para resolver tu servidor de nombres, entonces ya estás listo. Esto requiere que usted administre su propia máquina de DNS de manera externa, pero con el costo de EC2, lo que sí hace es calcular que está perdiendo 20 dólares al mes para realizar esta tarea.

NSTX utiliza esencialmente el mecanismo de consulta de DNS como un canal de datos. Los pentesters han estado usando esta técnica por un tiempo, y la idea no es nueva (las botnets incluso han usado la resolución C-Name de DYNDNS para crear estructuras de C & C pasivas). Es un mundo sucio, pero los administradores de DNS han hecho un gran trabajo de creación. Una red de la sombra para pasar su tráfico alrededor.

Una referencia rápida: enlace

Good ol 'Howto: enlace

De las implementaciones del portal cautivo que he visto, después de asociarme con el AP y de aceptar / autenticar a través del portal cautivo, la dirección MAC es el denominador es una lista de posibles tipos.

El mejor escenario es si hay una lista blanca para que usuarios específicos no tengan que pasar por el portal cautivo. Si se da cuenta de que el portal no tiene acceso a una caja de arena, falsifique su dirección mac y es muy probable que lo lancen automáticamente en un VLan activo o que sea eliminado de cualquier grupo de caja de arena que de otra forma se vería obligado.

Aparte de lo anterior, que es una posibilidad remota, la perspectiva NSTX e ICMPTX presentada por @Ori es una excelente idea.

Nunca he encontrado un portal cautivo que haya tenido éxito en prevenir la transmisión de tráfico por parte de alguien. Aparte de la técnica de tener un host externo cómplice para transmitir sus datos a través de túneles DNS e ICMP, cambiar su dirección MAC para reflejar la dirección de otra persona lo tratará a una conexión.

Creo que la única forma de controlar esto es exigir que se establezca una conexión VPN. Supongo que no lo vemos en la práctica porque es una molestia para el usuario final configurar y presenta una pérdida limitada a la tarifa por acceso. En comparación con los clientes que deciden no pagar por una conexión debido a la molestia de una configuración segura, esto generalmente se considera una pérdida aceptable.