Sfondo
La mia università utilizza un server proxy HTTP autenticato (squid) per accedere a Internet.
Ci sono alcuni motivi per questo:
- Vogliono tenere traccia dell'uso improprio della connessione
- La nostra università ha abbonamenti alla maggior parte dei periodici paywalled e l'accesso tramite il server proxy sblocca questo. Gli estranei e le persone che tunnel 1 nel sistema non dovrebbero essere in grado di accedere a questi entrambi.
- Vogliono assicurarsi che non scarichiamo script - scarichiamo un sacco di materiale dai siti web dei periodici - la responsabilità è il modo migliore per farlo.
- Vogliono essere in grado di bloccare determinate porte e siti. A parte 80, 443 e 22, IIRC tutte le porte sono bloccate.
Tutti gli accessi al nostro istituto sono su ldap, così come il proxy del calamaro. Il che significa che le stesse credenziali vengono utilizzate per molti altri (più cruciali) sistemi, e con loro si potrebbe causare il caos. Ad esempio, si può scherzare con quali corsi si prenderanno le persone, far cadere persone dai corsi e causare molti altri problemi.
Il problema
L'altro giorno, mentre stavo scherzando con ettercap , ho scoperto che era abbastanza facile collegarlo con grep e ottenere i dati di autorizzazione del proxy 2 (che è solo un'intestazione codificata in base64) da tutte le persone che usano Internet in una sottorete di mia scelta.
Vorrei portarlo all'attenzione delle autorità, poiché si tratta di un bug piuttosto grave. Mi piacerebbe anche escogitare una soluzione per questo.
Ora, è facile proteggere i portali online dallo spoofing ARP rendendoli HTTPS (ancora falsificabili, ma IIRC Chrome inizia a lamentarsi). Tuttavia, non sembra esserci un modo coerente (attraverso i browser) per rendere sicura l'autorizzazione del Proxy HTTP (o un proxy SOCKS, per quello).
Una soluzione (non così buona)
Una soluzione consiste nell'utilizzare due serie di credenziali: una per il proxy e una per il resto degli accessi al portale Web della intranet (che può essere reso HTTPS). Mantenere il proxy sicuro dalla rappresentazione non è un grosso problema. Qualcuno che esegue il tunneling non può falsificare ARP a meno che non abbia già accesso, e ci sono alcuni altri controlli che renderanno difficile implicare falsamente qualcuno abusando del proxy nel loro nome (registrazione IP, ecc.). D'altra parte, la protezione delle pagine del portale Web della intranet è prioritaria, a causa della quantità di danni che possono essere causati con le credenziali.
Tuttavia, questo non è ottimale, dal momento che il proxy è ancora aperto agli abusi (è solo più difficile abusarne) e le persone riutilizzano le password.
TL; DR
In che modo uno (con controllo sull'infrastruttura di rete) impedisce lo spoofing ARP sull'autenticazione proxy? Sono aperto a sostituire il proxy con un'entità simile (deve avere però l'autenticazione).
1. Mentre l'accesso alla shell richiede un accesso al proprio dipartimento, il tunneling richiede una password accessibile al pubblico. Immagino che sia qualcosa che dovrebbe essere cambiato.
2. Questo è più semplice della semplice registrazione delle richieste POST generiche e dell'estrazione delle password poiché esiste un formato specifico, in grado di convertire in grep e le credenziali del proxy vengono inviate con ogni GET e POST ne richiedono una (il che significa che io può ottenere una quantità considerevole di dati dopo aver eseguito ettercap per un minuto.