In che modo questo "captive portal" intercetta e manipola le mie richieste HTTP?

29

A volte uso un servizio Wifi gratuito per accedere a Internet.
Come la maggior parte / tutti i fornitori di servizi come questo, questo servizio utilizza un captive portal . Quindi se provi a fare una richiesta HTTP (richiedi una pagina web) nel tuo browser e non sei autorizzato sulla rete, vedrai sempre solo la pagina che dice "Benvenuto nella rete Free-wifi. i nostri termini, ecc ... "
Non mi interessa abusare del servizio per la connessione wifi gratuita - Voglio sapere quali informazioni (transazioni HTTP) sono esposte / non sicure quando utilizzo questo servizio e quali modifiche persistenti stanno apportando al mio sistema, ad esempio nascondendo i cookie nel mio browser ( utilizzando host anonimi).
Così mi sono collegato al loro punto di accesso wifi, a quel punto hanno assegnato al mio computer un indirizzo IP e un servizio DNS ecc.

$ nmcli device show wlp2s0
IP4.ADDRESS[1]:                         192.168.12.199/22
IP4.GATEWAY:                            192.168.12.1
IP4.ROUTE[1]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]:                             123.123.xxx.xxx
IP4.DNS[2]:                             123.123.xxx.xxx

Quindi proverò una richiesta HTTP: provate a "navigare in una pagina web" finché non siete ancora autorizzati. (Essendo HTTP questa richiesta / risposta non sarà criptata, nessun controllo di identità sul server che gestisce la richiesta [via. SSL conferma dell'autorità di certificazione tramite firme chiave pubblica / privata ecc.])

$ curl 'http://placeimg.com/' -H 'Host: placeimg.com'  
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' 
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'  -v -L
*   Trying 216.243.142.217...
* Connected to placeimg.com (216.243.142.217) port 80 (#0)
> GET / HTTP/1.1
> Host: placeimg.com
>
< HTTP/1.1 302 Found
< Location: http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F357812412D8
<
* Ignoring the response-body
* Connection #0 to host placeimg.com left intact
* Issue another request to this URL:  
       'http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F35792412D8'
* Connection 0 seems to be dead!
* Closing connection 0
*   Trying 1.1.2.1...
* Connected to 1.1.2.1 (1.1.2.1) port 80 (#1)
> GET /reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F8 HTTP/1.1
> Host: 1.1.2.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
>
< HTTP/1.1 200 OK
< Date: Mon, 08 Aug 2016 02:50:16 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
< Content-type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta name="viewport" content="width=device-width"/>
        <title>Login</title>
        <h1>WiFi - Free Internet Access</h1>
This service is provided primarily for the purposes of accessing Email and light web browsing ..
....
</div>
</body>
</html>

Ho troncato e redatto l'output, ma in sostanza sembra che, quando il mio browser (curl) effettua una richiesta che la rete stia fornendo l'accesso a un vero server DNS, l'ho verificato ulteriormente eseguendo questo: while connesso al servizio .

$dig +short google.com
203.118.141.95
203.118.141.123
... (basically real ip addresses for google.com)

Quindi sembra che il servizio fornisca informazioni reali e veritiere sul DNS,

Ma anche se l'indirizzo IP che il mio browser sta indirizzando sembra valido, la risposta HTTP che ritorna non è dal server previsto (è un server che è stato inserito dal servizio WiFi). La risposta è

  • 302 dice al mio browser di fare una nuova richiesta, al 1.1.2.1/reg.php server e URL
  • la risposta da quel server / URL è la pagina "captive portal".

Quando si effettua una richiesta HTTPS

$ curl 'https://google.com/' -H 'Host: google.com' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -v -L
*   Trying 216.58.220.142...
* connect to 216.58.220.142 port 443 failed: Connection refused
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Failed to connect to google.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: Connection refused

La richiesta fallisce - presumo perché il mio computer non accetterà una connessione da un host remoto che non può autenticare?
Quindi la mia domanda è, questa è un'intercettazione di tipo "uomo nel mezzo" a livello TCP / IP? in altre parole, quando lo stack di rete sul mio computer tenta di stabilire una connessione TCP con il server placeimg.com , avviando un handshake a 3 vie, il gateway dei servizi Wifi o il nodo di rete rispondono al mio SYN con un ACK / SYN e dicendo sì, sono il server con cui vuoi parlare - completa la nostra connessione TCP , quindi una volta stabilito il suo preprogrammato per inviare automaticamente il reindirizzamento HTTP e poi, poiché il mio browser sta effettivamente generando la richiesta successiva a 1.1.2.1 stesso - tutto il "business divertente" può fermarsi e tutto il suo normale comportamento HTTP / HTML da quel punto in avanti. (es. compilazione e invio di moduli standard come faresti su qualsiasi sito web normale)
In caso contrario, in che modo questo gateway intercetta e reinstrada le mie richieste mentre sono un utente "non autenticato"?

    
posta the_velour_fog 08.08.2016 - 05:51
fonte

2 risposte

33

So my question is, is this a "man in the middle" type interception at the TCP/IP level?

Sì, si tratta di un'intercettazione di tipo uomo nel mezzo che è facile per il punto di accesso perché in realtà si trova nel mezzo della connessione a Internet. Tali reindirizzamenti verso il portale di acquisizione sono fatti facilmente con un filtro di pacchetti.

Il solito modo è che una volta autorizzata (login, termini accettati, qualunque cosa ...) una regola temporanea verrà aggiunta al filtro del pacchetto del punto di accesso che ha la preferenza alla regola di reindirizzamento e consente l'accesso diretto su Internet

    
risposta data 08.08.2016 - 06:20
fonte
9

When make a HTTPS request The request outright fails - I'm assuming because my computer won't accept a connection from a remote host it can't authenticate?

Sembra che non stiano nemmeno cercando di intercettare la tua connessione HTTP e invece la stanno solo bloccando.

Alcuni portali in cattività cercheranno di intercettare la connessione HTTP risultante in un errore del certificato nel tuo client.

Ho visto anche alcuni portali in cattività che lasciano gli HTTP anche per gli utenti non autenticati.

So my question is, is this a "man in the middle" type interception at the TCP/IP level? in other words, when the network stack on my computer tries to establish a TCP connection with the placeimg.com server, by starting a 3 way handshake, is the Wifi services gateway or network node responding to my SYN with an ACK/SYN and saying yes I'm that server you wanted to talk to - lets complete our TCP connection, then once established its pre-programmed to automatically send the HTTP redirect and then, because my browser is actually generating the next request to 1.1.2.1 itself - all the "funny business" can stop and its all normal HTTP/HTML behaviour from that point forward. (ie. standard form filling and submissions as you would on any normal website)

Sì, questo è il modo normale per farlo. Se il server captive portal è basato su Linux, gli obiettivi "REDIRECT" o "DNAT" possono essere utilizzati per deviare il traffico verso il server web di portali in cattività che può quindi emettere il reindirizzamento. Altri sistemi di firewalling stateful hanno probabilmente opzioni simili.

Questi sistemi sono generalmente abbastanza flessibili, quindi se l'operatore del portale vuole offrire l'accesso a determinate parti di Internet (ad esempio un gateway di pagamento in modo da poterli pagare) senza autenticazione, può farlo tranquillamente.

Quando esegui l'autenticazione con successo, il captive portal può mettere in atto una regola che sostituisce la regola di reindirizzamento che ti consente un normale accesso a Internet.

Tieni presente che tutti i cookie (non protetti) impostati per il sito web che hai provato a visitare verranno inviati al server web del captive portal. Spetta all'implementatore del captive portal se fa effettivamente qualcosa con loro.

    
risposta data 08.08.2016 - 18:50
fonte

Leggi altre domande sui tag