Seguridad WiFi en el HUCA (II)

Disclaimer: Esta información es dada con fines meramente didácticos y lúdicos. No pretende ser ninguna guía de hacking ni cracking. Cada persona es responsable de lo que hace y deja de hacer.

En esta entrada voy a seguir con mi estudio sobre la seguridad en el sistema de registro del WiFi para invitados en el Hospital Universitario Central de Asturias, HUCA.
Resumimos los resultados que obtuvimos en la primera entrada, Seguridad WiFi en el HUCA (I):

1. Observamos que existe una red sin cifrado llamada Invitados.
2. Si intentamos navegar, se nos re-dirige siempre a la página de login para usuarios autorizados.
3. Haciendo ping recibimos respuesta desde servidores de Internet.
4. Hemos intentado cambiar las direcciones DNS por las de Google en un primer intento de poder saltarse este re-direccionamiento. No funciona.

Conclusiones:

• Nos encontramos ante un portal cautivo, redirigiendo todo el tráfico HTTP que generemos a una página de login.

• Tenemos salida a servidores externos mediante del Hospital mediante el comando ping, como los de Google, lo que nos lleva a dos conclusiones más:

1. Se resuelven bien los dominios DNS aunque no estemos registrados como usuarios en el sistema.
2. El único impedimento que tenemos para navegar libremente es el re-direccionamiento que nos hace el portal cautivo para obligarnos a identificarnos como usuarios autorizados

Como ya avancé en el primer post, una solución que se me ocurrió fue hacer un túnel de DNS o DNS tunneling, ya que el sistema DNS del Hospital resuelve los nombres sin distinguir si estan autorizados o no, o si han hecho login o no. A grosso modo y sin entrar en detalles, esta técnica encapsula todo el tráfico que generemos a través del puerto 53 que como ya habréis adivinado, es el que usa el protocolo DNS.

En este momento, dejamos de lado nuestro móvil Android y utilizamos un ordenador. Aunque utilizo Windows7, el concepto es el mismo para otros SO y no debería tener mayor dificultad.

Opté por la solución más sencilla para mí y quizás menos elegante, pero más segura de cara a esta investigación al estar todas las comunicaciones encriptadas.

La solución es utilizar un servicio de VPN que me permita usar el puerto 53 y a poder ser con conexión cifrada.. Tenemos dos alternativas gratuitas: nos lo montamos nosotros en nuestra casa con un servidor y conexión a Internet, o confiamos esta tarea a algún VPN público de Internet.

Examinando varias opciones, encontré el servicio gratuito de VPNBOOK bastante atractivo. Ofrece posibilidad de utilizar openVPN como cliente, no hace falta registro, y algunos servidores hasta ofrecen posibilidad de P2P. ¡Perfecto!

Su página web tiene un tutorial para instalar OpenVPN y configurarlo con VPNBOOK, aunque esta desactualizado y tuve que improvisar para configurarlo correctamente.
Tiene tutoriales para Windows, Mac, Linux, Android...

Uno de los problemas que encontré siguiendo su tutorial para Windows 7 fue encontrar el propio software openVPN. Aquí os lo podéis descargar:

Una vez instalado, y agregamos los certificados a sus servidores. En su tutorial los agrega directamente desde la aplicación openVPN. Yo no encontré esa opción en la versión que descargué así que los copie directamente en esta ruta:

C:\Program Files\OpenVPN\config\

Copiamos los certificados descargados en la carpeta correspondiente de openVPN

Una vez copiados los certificados, arrancamos la GUI de openVPN y nos quedará un icono de color gris con un candado en la barra de tareas.


Precaución: Desconozco el motivo pero en mi Windows7 por defecto openVPN se ejecuta en modo usuario en vez de administrador. Ni siquiera me salta el popup pidiendo permiso para ejecutarse como administrador.

Al ejecutarse en modo usuario el programa fallará al realizar comandos como route para configurar el DNS tunneling. 

Si comprobamos que nos conectamos bien al servidor de VPNBOOK pero seguimos sin poder saltarnos el portal cautivo, este es el problema. Revisando el log de conexión encontraremos fallos de este tipo cuando se crea el túnel DNS.

ROUTE: route addition failed using CreateIpForwardEntry: Access is denied.
Route addition via IPAPI failed [adaptive]
Route addition fallback to route.exe


La solución es obligar a Windows a que ejecute openVPN con derechos de administrador, por ejemplo haciendo clic con el botón derecho encima del acceso directo y eligiendo Ejecutar como administrador:

Ejecutando openVPN como administrador

Si hacemos clic con el botón derecho en el icono de la barra de tareas, nos saldrán los diferentes servidores y puertos disponibles de openVPN:

Elegimos alguno que nos permita usar el puerto 53, por ejemplo el de Canadá:

Lista de servidores y puertos disponibles en VPNBOOK

Nos aparece un pop-up pidiendo el nombre de usuario y contraseña. Se actualizan más o menos cada semana. Para ello nos dirigimos con nuestro móvil a la página de VPNBOOK o a su twitter.

Apuntamos el username y el password

Introducimos el username y password en openVPN

Introducimos nuestra contraseña y si todo va bien el icono se volverá de color verde y nos saldrá este mensaje:

Conexión correcta con servidor de Canadá por UDP puerto 53

Para comprobar que funciona, arrancamos nuestro navegador y cargamos cualquier página. ¡Funciona! Nos hemos saltado el portal cautivo de login del Hospital.

Por último, hacemos una comprobación de cuál es nuestra dirección IP:
Entramos en http://www.geoiptool.com/ y efectivamente, estamos saliendo a Internet desde el otro lado del charco.

Localizando nuestra nueva IP en los EEUU

En el siguiente post comentaré la utilidad del DNS tunneling aunque seamos usuarios autorizados en la red del Hospital o incluso en otra red de tipo empresarial. 

Pista: tiene que ver con los bloqueos a ciertas páginas web como YouTube, TV online, etc.

Enlaces:

VPNBOOK - Servicio VPN gratuito con soporte para openVPN y DNS tunneling.
Tutorial para configurar VPNBOOK
openVPN - Herramienta para poder crear una conexión VPN.
Descarga directa de openVPN
Twitter de VPNBOOK - Aquí estan  los username y passwords actualizados.