Fondo
Mi universidad utiliza un servidor proxy HTTP autenticado (squid) para acceder a Internet.
Hay algunas razones para esto:
- Quieren rastrear el mal uso de la conexión
- Nuestra universidad tiene suscripciones a la mayoría de las revistas de pago, y el inicio de sesión a través del servidor proxy desbloquea esto. Los forasteros y las personas que hacen un túnel 1 en el sistema tampoco deberían poder acceder a estos.
- Quieren asegurarse de que no descarguemos muchas cosas de los sitios web de las revistas; la responsabilidad es la mejor manera de hacerlo.
- Quieren poder bloquear ciertos puertos y sitios. Aparte de 80, 443 y 22, IIRC todos los puertos están bloqueados.
Todos los inicios de sesión en nuestro instituto están en ldap, al igual que el proxy de calamar. Lo que significa que las mismas credenciales se utilizan para muchos otros sistemas (más importantes), y con ellos uno podría causar estragos. Por ejemplo, uno puede alterar qué cursos tomarán las personas, dejar a las personas de los cursos y causar muchos otros problemas.
El problema
El otro día, mientras jugaba con ettercap , descubrí que era bastante fácil canalizarlo con grep y obtener datos de autorización de proxy 2 (que es solo un encabezado codificado en base64) de todas las personas que utilizan Internet en una subred de mi elección.
Me gustaría señalar esto a la atención de las autoridades, ya que es un error bastante grave. También me gustaría idear una solución para ello.
Ahora, es fácil proteger los portales en línea de la suplantación de ARP haciéndolos HTTPS (aún se pueden falsificar, pero IIRC Chrome comienza a quejarse). Sin embargo, no parece haber una forma coherente (en todos los navegadores) de hacer que la autorización de Proxy HTTP sea segura (o un proxy SOCKS, para el caso).
Una solución (no tan buena)
Una solución es usar dos conjuntos de credenciales, una para el proxy y otra para el resto de los inicios de sesión del portal web de la intranet (que pueden hacerse HTTPS). Mantener el proxy a salvo de la suplantación no es tan importante. Alguien que está haciendo un túnel no puede hacer una falsificación ARP a menos que ya tenga acceso, y existen algunas otras comprobaciones que dificultarán la implicación falsa de alguien al usar el proxy en su nombre (registro de IP, etc.). Por otro lado, mantener la seguridad de las páginas del portal web de la intranet es una prioridad, debido a la cantidad de caos que puede causar las credenciales.
Sin embargo, esto no es óptimo, ya que el proxy todavía está abierto al abuso (pero es más difícil abusar de él), y las personas reutilizan las contraseñas.
TL; DR
¿Cómo puede uno (con control sobre la infraestructura de red) evitar la falsificación de ARP en la autenticación de proxy? Estoy abierto a reemplazar el proxy con una entidad similar (aunque debe tener autenticación).
1. Si bien el acceso de shell requiere un inicio de sesión en su departamento respectivo, el túnel requiere una contraseña disponible públicamente. Supongo que eso también debe cambiarse.
2. Esto es más fácil que solo registrar solicitudes POST genéricas y extraer contraseñas, ya que existe un formato específico y capaz de grep para esto y las credenciales de proxy se envían con cada GET y POST que hace una solicitud (lo que significa que puede obtener una cantidad considerable de datos después de ejecutar ettercap por solo un minuto.