Auditar la WiFi del hotel con resaca y un jailbroken iPhone

Durante estas vacaciones de Semana Santa regresé a mi querida isla de Tenerife para disfrutar de unos días de vacaciones con la familia. Como el objetivo de estos días era desconectar de la frenética actividad a que nos lleva esta vida en el mundo de la seguridad informática, decidí dejar el ordenador portátil en casa, y disfrutar de estos días de playa, relax y algo de copas en alguno de los locales de moda de la isla.

Figura 1: Uno de los locales de moda en la isla de Tenerife.

Tras una noche de fiesta me desperté a eso de las 9:15 con la cabeza apunto de estallar, a causa del famoso Ron Arehucas de Canarias, pero mi insomnio crónico no me dejaba dormir, así que como no tenía ninguna computadora a mano, cogí el teléfono móvil y me puse a teclear para ver qué había pasado por Internet. Tras revisar los feeds RSS de seguridad y leer un post del blog del Maligno, reparé en que el hotel en el que me alojaba disponía de una red WiFi privada según nos habían dicho. Como no tenía mucho que hacer, me entretuve en saber cuál sería el nivel de seguridad que ellos entendían por privado.

Figura 2: Portal Cautivo WiFi del hotel.

Al abrir el navegador tras conectarme a la red inalámbrica, apareció el clásico portal cautivo en el que debía introducir mis credenciales. Lo primero que me llamó la atención fue el nombre del host que aparecía en la URL de login: “gateway.example.com”. Lo siguiente que hice fue consultar el direccionamiento de la red WiFi a la que me había conectado en el apartado de Ajustes de mi iPhone, para ver si el portal estaba aplicando aislamiento de clientes a nivel IP:

Figura 3: Direccionamiento de la red WiFi del hotel

Como se puede observar en la imagen, la máscara de subred que se aplica para esta red es “255.255.0.0”, por lo que hablamos de una red de clase B con direccionamiento “192.168.0.0” y no sólo el portal cautivo o la puerta de enlace son accesibles, sino también el resto de equipos.

Además del nombre del hotel, he tapado el nombre que aparece en el apartado de dominios de búsqueda, pues parece que corresponde al de la empresa que instaló y configuró esta red. No obstante, centré mi atención en el nombre de servidor del portal, “gateway.example.com”, así que abrí la aplicación Terminal instalada en mi dispositivo con jailbreak para realizar un ping al host:

Figura 4: Dirección del servidor gateway.example.com

La respuesta al comando ping situaba la dirección IP del portal en la “192.168.2.1”, así que el siguiente paso fue hacer una petición directamente al servidor sin utilizar el nombre de host, para ver si se veía algo diferente:

Figura 5: Portal de administración de Hotspot 4ipnet

Lo que se veía en el navegador ahora ya no era la página de inicio de sesión en el portal cautivo, sino la página de administración del dispositivo que implementaba dicho portal, y que como se puede observar era del fabricante “4ipnet”. No pude reprimirme, y el siguiente paso fue buscar rápidamente en Google las credenciales por defecto, que tanto juego dan en muchos casos, para el usuario administrador de estos dispositivos:

Figura 6: Manuales de dispositivos 4ipnet con credenciales por defecto

Quería comprobar, que en efecto los administradores habrían cambiado la clave por defecto. Y en efecto, afortunadamente la combinación “admin” “admin” que se puede observar en la mayoría de manuales para los productos de 4ipnet me devolvió un mensaje de “Contraseña incorrecta. Siga probando :( “

Como también tenía instalada en mi iPhone el escaner de red para iPhone Scanny, y como este tipo de dispositivos ofrece habitualmente más servicios además del HTTP para la administración de los mismos, decidí comprobar qué otros puertos estaban abiertos:

Figura 7: Escaneo de puertos del servidor con Scanny

Además de HTTP, HTTPs y PPTP, también se podía acceder al host mediante ssh. En ese momento recordé que al buscar la contraseña por defecto para los dispositivos de este fabricante, visualizando el avance del texto para el primero de los resultados se podía entrever que además del usuario admin, existía una cuenta de root.

Si el administrador de la red WiFi privada del hotel había cambiado la password de administrador, lo suyo es que hubiera hecho los deberes y cambiado también de la de root. Si no fuera así, para un posible atacante de esta red WiFi privada sería tan fácil como elegir él mismo cómo quiere configurarse la red. Volví a abrir el Terminal, para intentar conectarme por ssh al hotspot utilizando la cuenta de root, y la clave por defecto “admin”..... Owned! Cual fue mi sorpresa al ver que éste me recibía con los brazos abiertos:

Figura 8: La clave de root no estaba cambiada

En este instante me levanté sobresaltado, con el móvil en la mano y el post de El Lado del Mal que había comenzado a leer en la pantalla. La red WiFi privada había pasado a ser un entorno inseguro donde simplemente con el móvil desde la cama y en unos minutos, un atacante podría tener acceso completo a la consola del servidor que administra la red WiFi del hotel, para desde ahí poder hacer cualquier tipo de maldad: robar información, instalar una backdoor, saltar a otros servidores o clientes de la red... al estilo NSA. Nada de cosas "complicadas" como atacar WPA/WPA2, hacer cracking de las claves WPA/WPA2 o romper un hash MS-Chapv2 PPTP por diccionario o CloudCracker en una conexión PPTP.

No iba a conectarme a esa WiFi nunca, así que recopilé todos los datos y esperé a que una buena ducha luchara contra los efectos del alcohol para notificar en la recepción del hotel que deberían cambiar esa password

Autor: Deepak Daswani
http://deepakdaswani.es
http://twitter.com/dipudaswani

Fuente:
http://www.elladodelmal.com/2014/05/auditar-la-wifi-del-hotel-con-resaca-y.html

Un día de viaje: El blues (de la WiFi) del autobús

Muy buena entrada del maligno y sus colaboradores:

_______________________________________________________________________________

La disponibilidad de tecnologías WiFi “abiertas” cara al público que provén de Internet de forma gratuita, se ha convertido en una de las mayores facilidades que se le puede ofrecer a un usuario malintencionado para que lleve a cabo cualquier tipo de ataque sin dejar rastro de la identidad del mismo. Lugares como universidades, bibliotecas, restaurantes, bares, aeropuertos, etcétera, ofrecen conexión a los usuarios para que naveguen a sus anchas.

No hace mucho tiempo, volviendo en autobús de un viaje que tuve que realizar por motivos de trabajo, me dio por ojear el servicio WiFi que ofrecía la empresa para conectarse a Internet durante la duración del trayecto (que no era poco). Y como era de esperar existían multitud de direcciones IP (usuarios) que estaban utilizando dicho servicio.

Dejando de lado la multitud de ataques que se podrían realizar a los usuarios que están utilizando el servicio, ya que se supone que la WiFi precisamente se encuentra “abierta” para que todos los usuarios del autobús puedan conectarse y navegar sin ningún problema, decidí mirar qué “cacharro” era el que nos estaba ofreciendo el servicio y qué medidas de seguridad implementaba.

Figura 1: Portal del Router de Internet Móvil

Al primer intento de una de las contraseñas por defecto, ya me di cuenta que la respuesta se ofrecía por JavaScript y sin realizar ninguna petición a otra página, por lo que, la contraseña debería estar “incrustada” en el propio código de la página de acceso.

Figura 2: Alerta de contraseña incorrecta por Javascript

Con la ayuda de Firebug y un par de búsquedas vamos a intentar localizar la cadena exacta que nos interesa. Identificamos cómo existen varios tags “iframe” que están apuntando a distintos portales, los cuales pueden contener la cadena que estamos buscando. Entre ellos existe el fichero “/en/logo_idx.asp” que es el que contiene toda la parte de login.

Figura 3: Inclusión del iframe de autenticación

Cargamos el portal “/en/logo_idx.asp” dentro de nuestro navegador y visualizamos dónde se encuentra la cadena “Introduce tu contra..”, ya que se encontrará cerca de la zona del botón de submit, del que nos interesa saber qué función está realizando con la contraseña que introducimos nosotros en el “textbox”.

Figura 4: Función que se ejecuta cuando se envía la contraseña

Como se puede observar en la imagen anterior, al realizar el evento “onclick” del botón “Entrar” se está ejecutando a una función JavaScript llamada “LoginForm()”. Si buscamos dicha función en la pestaña de Scripts de Firebug, nos encontraremos con el siguiente código.

Figura 5: Contenido de la función JavaScript "LoginForm()"

Vemos que se está validando mediante la función “IF” el valor del elemento “password” con una variable llamada “admin_passwd”, la cual se encontrará inicializada en alguna parte del código. Mediante una simple búsqueda del nombre de la variable, damos con el valor que se inicializa la misma y con el correspondiente password del router.

Figura 6: Inicialización de la variable "admin_passwd"

A partir de aquí ya podemos acceder al portal del router y visualizar y/o modificar los parámetros de configuración.

Figura 7: Configuración Avanzada del Router Internet Móvil de Huawei

Y seguro que con toda esta información a muchos de vosotros se os ocurren muchos ataques man in the middle que se pueden realizar a los compañeros de viaje, pero ya bastante cansado es un viaje en autobús, como para que encima te roben la cuenta de Twitter, Tuenti o Facebook.

Figura 8: Usuarios conectados al servicio, potenciales víctimas

Como ya habréis leído y/o escuchado centenares de veces, la seguridad de las redes WiFi “abiertas” que ofrecen servicio a cualquier usuario sin ningún tipo de protección son de alto riesgo para los usuarios, pero quedan mucho más en entredicho si ni el propio fabricante del dispositivo utilizado para motarlas se preocupa de con qué grado de seguridad se están desarrollando sus dispositivos.

Un Saludo!! ;)

Autor: Daniel Romero, consultor de seguridad en Informática64

Fuente: http://www.elladodelmal.com/2011/12/un-dia-de-viaje-el-blues-de-la-wifi-del.html