Valutazione delle minacce per un captive portal

Ci sono due modi in cui i portali / hotspot in cattività sono ignorati:

1. O usando un tunneling di qualche tipo, di solito usando il protocollo DNS perché i client hanno la porta in uscita 53 aperta, o tramite http / https, o usando icmp per tunnel o altri wats simili. @Ori ha fornito esempi di questo.

2. Un altro modo consiste nel bypassare direttamente il meccanismo di autenticazione: in definitiva tutti gli hotspot devono autenticare un client, e questo è (solitamente) fatto tramite MAC o indirizzo IP o cookie. In determinate occasioni, questi possono essere falsificati o annusati per ottenere una sessione già autenticata mediante la rappresentazione. Potrebbero persino essere configurati determinati dispositivi nella rete, con mac o indirizzo IP hardcoded che sono pre-autenticati, ad es. stampanti e puoi prendere il loro indirizzo.

Stavamo discutendo una tecnica in un altro thread che probabilmente avrebbe portato a termine questo. Sia NSTX che ICMPTX traggono vantaggio dalle lacune comuni dei protocolli di cui dispongono le organizzazioni. NSTX è il candidato più probabile dal momento che non è probabile che l'organizzazione con il captive portal impedisca l'accesso al proxy / server DNS che si sta utilizzando per risolvere il nome del captive portal.

Se puoi inviare una query DNS per risolvere il tuo server dei nomi, allora sei praticamente impostato. Ciò richiede di gestire la propria macchina DNS esternamente, ma con EC2 a costo di quanto si calcola sei fuori di 20 dollari al mese per portare a termine questa attività.

NSTX utilizza essenzialmente il meccanismo di query DNS come canale dati. I pentesters hanno usato questa tecnica per un po ', e l'idea non è nuova (le reti bot hanno persino usato la risoluzione del nome C DYNDNS per creare strutture C & C passive.) È un mondo sporco, ma gli amministratori DNS hanno fatto un ottimo lavoro di creazione una rete ombra per far passare il tuo traffico.

Un riferimento rapido: link

Buon vecchio Howto: link

Dalle implementazioni del captive portal che ho visto, dopo l'associazione con l'AP e accettando / autenticando tramite il captive portal, l'indirizzo MAC è il denominatore è un elenco di tipi consentiti.

Lo scenario migliore è se esiste una lista bianca per utenti specifici che non devono passare attraverso il captive portal. Se ti accorgi che qualcuno non è incasinato dal portale, falsifichi il loro indirizzo mac ed è molto probabile che verrai automaticamente sballottato in un VLan attivo o rimosso da qualsiasi gruppo di sandbox che altrimenti verrebbe forzato.

Oltre a quanto sopra, che è una possibilità remota, la prospettiva NSTX e ICMPTX presentata da @Ori è un'idea eccellente.

Non ho mai incontrato un captive portal che riuscisse a impedire la trasmissione del traffico da parte di qualcuno. A parte la tecnica di avere un host esterno complicato per trasmettere i tuoi dati attraverso i tunnel DNS e ICMP, cambiare il tuo indirizzo MAC per rispecchiare l'indirizzo di qualcun altro ti tratterà di una connessione.

Credo che l'unico modo per controllarlo sia quello di stabilire una connessione VPN. Presumo che non lo vediamo in pratica perché è un fastidio per l'utente finale configurare e presenta una perdita limitata alla tariffa per l'accesso. Rispetto ai clienti che scelgono di non pagare per una connessione a causa della seccatura di configurazione sicura, questa è generalmente considerata una perdita accettabile.