Hace muy poco que hemos desplegado a toda la planta una nueva versión de la App de SmartWiFi para Android y App de SmartWiFi para iOS que ya puedes descargar y utilizar. En breve tendrás también la nueva versión para la Living App de SmartWiFi en la tele, con la posibilidad de poder comprobar desde la televisión si tienes protegida la conexión a Internet con Conexión Segura y, además, pudiendo activarla con un solo comando desde la Living App de la televisión.
Figura 1: SmartWiFi: Perfiles y Control Parental de Horario en la nueva versión de la app
Hoy quería aprovechar para hablaros de dos nuevas funcionalidades que hemos metido en las apps de SmartWiFi para Android y para iPhone, como son los Perfiles y el Control Parental de Horario, que ya están desplegadas y funcionando si tienes el router SmartWiFi en tu casa.
Figura 2: Nueva opción de Perfiles en SmartWiFi App
La parte de perfiles, la encontrarás en el nuevo icono "Perfiles" en el menú inferior de la app. Tras presionarlo, aparecerá la bienvenida a perfiles, que te permite configurar una funcionalidad de pausa que puedes tener en hasta un máximo tres perfiles con asignación de tres dispositivos como máximo por cada perfil.
Figura 3: Elección nombre y de avatar de perfiles
Para entenderlo bien, primero creamos el nombre y elegimos un avatar para este perfil, y luego le asignamos un número de dispositivos - hasta tres - a este perfil, que puede ser "habitación de niños", "dispositivos de los niños", "Consolas de juegos", o lo que quieras.
Figura 4: Selección de dispositivos a asignar al perfil
Desde la app podremos ver en todo momento la lista de perfiles que están creados y si están pausados o no en cada instante, como podéis ver este ejemplo en el que hemos dejado sin consola de juegos a un grupo por un tiempo.
Figura 5: Lista de perfiles creados con pausa horarias
Si queremos ver en concreto el detalle del perfil, podremos seleccionar cada uno de ellos y saber qué dispositivos tiene, y si tiene una pausa horaria establecida.
Figura 6: Detalle de un perfil
En cualquier momento se puede asignar o desasignar un dispositivo a un perfil, tan fácilmente como entrar en la opción de "Gesitonar" y añadir o quitar. Aquí estamos añadiendo un nuevo dispositivo a este perfil ya creado.
Figura 7: Asignar un nuevo perfil a un dispostivo
Por cada perfil podrás planificar los horarios de pausa - bloqueo en la red WiFi - des-pausado, donde ya no estará bloqueado, todo dispositivo que tenga asociado dicho perfil, tal y como puedes ver en la imagen siguiente.
Figura 8: Creación de horarios de desconexión WiFi
Durante la creación del control horario, que puede ser editado a posteriori, puedes visualizar el listado de los controles creados creados. En todo momento recibirás notificaciones para avisar que se va a aplicar el control horario, y se puede configurar para que la notificación se haga al inicio y al final del control horario.
Figura 9: Configuración de horarios de pausa de un perfil
Todas estas opciones, además de ser una herramienta fantástica de Control Parental, sirven también para evitar que un equipo esté funcionando fuera de horarios de trabajo, o cuando no hay nadie en casa, siendo una herramienta perfecta de mitigación de lo que un posible atacante puede hacer cuando nadie está utilizando los dispositivos, ya que todos ellos estarán sin conexión WiFi.
Este no es un tema nuevo, pero he de reconocer que a mí, personalmente, me pasó desapercibido y quería compartirlo con vosotros. Se trata de "cómo evitar que Google utilice tu red WiFi en sus servicios de localización". Algo que no es nuevo, pero que en su momento tuvo su impacto en los medios de comunicación y que hoy en día, tras la aprobación del GDPR en Europa se ha quedado en una zona gris.
Figura 1: Cómo evitar que Google utilice tu red WiFi en sus servicios de localización
Para los que no conozcáis la historia, hay que volver atrás en el tiempo a cuando Google quería mejorar los servicios de localización de sus plataformas móviles. Es decir, cómo saber dónde se encuentra un teléfono Android con mucha más exactitud. Para ello, se decidió utilizar un sistema basado en las bases de datos de Wardriving.
Wardriving y el Google Street Car
Hace ya tiempo, el Wardriving se convirtió en una diversión de los hackers muy extendida. La idea era meter en un mapa todas las redes WiFi de la ciudad para que cualquiera que quisiera, pudiera conectarse a Internet. Es decir, el concepto era geoposicionar redes WiFi por toda la ciudad. Eso se podía hacer andando, en coche o en bicicleta.
Figura 3: Iconografía para redes WiFi descubiertas
Se creó una iconografía completa que se ponía en forma de pegatinas, dibujos pintados en las paredes o apps que te decían en qué lugares de la ciudad podrías encontrar redes WiFi con las que te pudieras conectar a Intenet, ya fuera porque eran redes abiertas, o inseguras con WEP, o con contraseñas fáciles de WPA o WPA2.
Figura 4: Iconografía de Wardriving por las ciudades
De hecho, la competición en muchos de los congresos y conferencias de hackers era conseguir el máximo posible de redes WiFi con la información de conexión a la red para la base de datos de Wardriving. Congresos tan importantes como DefCON o EkoParty, tenían sus secciones específicas dedicadas solo al Wardriving. Debido a esto, yo os recomendaba hacer esto antes de ir a hacer un Ethical Hcking a una empresa porque los empleados suelen conectarse a muchas redes WiFi cercanas a sus oficinas.
Figura 5: Memes con el asunto de Google Steet Vier Car y el sniffig de redes WiFi
Aquello se cerró, no sin que hubiera un lío en muchos países, e incluso Google tuvo que compartir los datos que había ido escaneando en cada uno de los países con los cuerpos de seguridad que tuvieron que revisar la información que había capturado de esas redes abiertas para ver, si en algún caso, habían capturado conexiones a Internet de los usuarios de la red sin cifrar que llevara información sensible y que, Google, hubiera almacenado sin conocimiento de los usuarios. Google borró los datos, y dijo que había sido culpa de una librería estándar mal usada.
Lo mismo, pero en Android
Por supuesto, la idea de copiar el concepto del Wardriving de la comunidad hacker para ir escaneando desde el Google Street Car todas las redes WiFi de la ciudad estaba bien, pero no era comparabale para nada si utilizaban los terminales smartphone con Android, que cada vez empezaban a tener más cuota de mercado frente a los líderes en el mundo móvil, donde iPhone, Motorola, Nokia o BlackBerry comenzaban a dejar paso a Android cada día más. En el libro de Hacking y Seguridad de Comunicaciones Móviles (2ª Edición) se hablan de estas técnicas para todo tipo de conexiones.
Así, los terminales Android (y también los terminales iPhone) utilizan un sistema de mantenimiento de los servicios de localización construido de la siguiente forma. Por un lado, aprovechándose los cada vez mejores servicios de GPS de los terminales reportan las potencias de señales capturadas por cada terminal móvil de todos los elementos que emiten señales, ya sean BlueTooth, conexiones a redes de telefonía 2G, 3G y 4G, o redes WiFi. La idea es guardar de cada uno de ellos:
- El identificador físico que lo define de forma unívoca: BSSID, SSID, MACs, etc...
- La potencia de la señal con que llega al terminal móvil.
- La posición GPS que se puede obtener del servicio puro GPS.
- Timestamp de cuándo se hace la captura de datos.
- Información del terminal smartphone que hace la captura de datos.
Todos estos datos llegan a una base de datos donde se almacenan en Google. Con esos datos, utilizando algoritmos de triangulación y calibración, permiten a Google saber:
- Dónde se encuentra realmente cada terminal móvil más allá de lo que marque el servicio GPS.
- Saber dónde se encuentra cada terminal incluso si el sistema GPS falla.
- Saber dónde se encuentra cada terminal con un servicio de menor latencia que el GPS.
- Alimentar la base de datos con dónde se encuentra cada antena de telefonía exactamente.
- Saber exactamente donde se encuentra cada red WiFi - incluida la tuya - del mundo.
Sin esta base de datos que da soporte a los servicios de localización de Google, aplicaciones tan populares como Waze o Google Maps funcionan regular. Puedes hacer la prueba tú mismo de forma sencilla. Basta con que pongas una ruta de tu casa a al trabajo en cualquiera de estas dos aplicaciones y quites la WiFi - la apagas en tu terminal iPhone o Android - y verás como, usando solo el GPS, los servicios de localización funcionan regular y tienen márgenes de error muy altos.
Pero a muchas personas esto no les gusta, ya que también se guarda información de horarios de encendido y apagado del Access Point, de la seguridad de la red, de los fabricantes detrás de los dispositivos, y un buen número de insights que se podrían sacar.
Cómo sacar tu red WiFi de la bae de datos de Google Location Services
Esos datos también se utilizan para alimentar la ubicación en caso de anuncios mostrados por ubicaciones geográficas, o para otro tipo de servicios basados en ubicación. Es decir, gracias a la información que mantiene de las redes WiFi que captura usando los terminales Android como sensores, las conexiones a Internet de estos para enviarlos a sus servidores, y que tú tienes una red WiFi en tu casa, disfrutan de unos servicios de localización mejores que los que tuvo la industria de navegadores GPS para coches en su momento.
Figura 8: Gracias las bases de datos WiFi, Google Maps tiene una precisión y velocidad mucho mayor que un GPS "tradicional"
Pero claro, Google (y Apple) no han pedido permiso a nadie para capturar esos datos tuyos. Supongamos que tú no quieres tener nada que ver con Google y no quieres que usen tu infraestructura tecnológica para hacer sus negocios. Pues entonces, tal y como está el panorama hoy en día, tienes que ser tú el que haga Opt-Out de su base de datos haciendo algo que no es muy sencillo para todos lo usuarios:
No sé si este es el mecanismo más correcto o no. Y lo cierto es que si fuera un Opt-in, es decir, que Google indexara solo la información de las redes WiFi acabadas en _map, probablemente no tendría suficiente densidad de redes WiFi para construir unos servicios de localización potentes, pero lo cierto es que a día de hoy, Google y Apple se han construido la red de localización más potente del mundo gracias a que utilizan todos sus dispositivos, y cuando digo todos me refiero a todos - smartphone, SmartTVs, smartWatches, etc... -, en sensores para capturar información del espectro de señales a su alrededor y almacenan esa información para explotarla en su beneficio.
En el artículo de hoy vamos a ver cómo construir un código que nos permita tener una utilidad al estilo Airodump, tan común en el hacking de redes Wireless, pero creándolo en Python 3 para los amantes de Python para Pentesters y el Hacking con Python. Para esta primera versión nos interesa obtener los puntos de acceso y/o los dispositivos conectados a estos y hacer una descripción de las redes inalámbricas que tenemos cerca.
Figura 1: AiroPy: Cómo crear tu Airodump con Python y Scapy
Este tipo de soluciones nos puede venir bien en cualquier Ethical Hacking, pero conocer cómo se funcionan también nos sirve para crear nuevas tecnologías. Por ejemplo, el SSID Pinning que desarrollamos en ElevenPaths utiliza algo similar para detectar las redes cercanas y el perfilado de las mismas.
En nuestro caso, para llegar a la solución que os voy a explicar, me voy a basar en el código que nos dejan en charlesreid1 con su Airodump Clone, que a su vez se basa en el código ‘WifiJammer’ de DanMclnerney.
El código va a ser bastante extenso como para ponerlo aquí, por lo que puedes consultarlo completamente en mi GitHub, ya que aquí solo se va a hablar de la idea y de cómo poder usarlo en diferentes entornos
¿Qué necesitamos para lanzar el script?
Antes de hacer funcionar el script, tenemos que tener en cuenta los siguientes aspectos que necesitamos en nuestro entorno de pruebas.
Tarjeta de red que permita el modo monitor, las Alfa suelen funcionar bien.
Un sistema GNU/Linux (para probar el código se ha usado Ubuntu 18.04)
Python 3
Instalar las dependencias (requirements.txt): scapy-python3 & termcolor
No son muchos los requisitos, y si te dedicas al mundo de la seguridad, probablemente ya estés familiarizado con todos estos procesos.
Opciones y configuración del script
Tendrá una parte de configuración, que se encargará de recoger las distintas opciones. Los importantes se listan a continuación:
• ‘interface’: Nos sirve para escoger una interfaz o si no se especifica dejar al programa buscar una.
• ‘america’: Para configurar el número de canales , si agregamos esta ‘flag’ 11, si no 13.
• ‘channel’: Si lo elegimos se centrará en ‘esnifar’ el tráfico en dicho canal, si no, se pondrá a saltar entre los distintos canales.
• ‘show_aps’: Si es True nos mostrará los puntos de acceso.
• ‘show_stations’: Si es True nos mostrará los clientes en los puntos de acceso.
• ‘filter_macs’: Si queremos que solo se muestren determinados dispositivos. Por ejemplo Huawei, Samsung, etcétera. Será un número de 0 a 7, de los que se ven en el archivo mac_vendors.py y que están basados en los usados por cada fabricante. En el caso de Apple, están los de iPhone & iPad tal y como se explica en el libro de Hacking iOS: iPhone & iPad [2ª Edición]
La última opción, son prefijos de MACs obtenidas de terceros, no están verificadas, se verá más adelante. Entre las opciones show_aps y show_stations tenemos que elegir una o ambas, pero no nos sirve ‘ninguna’.
Entendiendo las partes en las que se divide el código
El código base ya traía una serie de comentarios que indicaban las partes y que me parece adecuado para entenderlo. Si lo repasamos vemos que consta de la siguiente funcionalidad:
• Configuración de la Interfaz: Aquí entra en juego el argumento ‘interface’. Si se le especifica que una interfaz, se comprobará si está en modo monitor, si no lo está la intentará poner, en caso que no indiquemos interfaz, se encargará de buscar alguna en modo monitor, si no encuentra, escogerá una (la más ‘fuerte’) y la intentará poner en modo monitor.
• Salto de canales: Se lleva a cabo con un hilo. A partir de ‘america’ se configura el máximo de canales a 11 u 13, y gracias a iw se va a ir saltando entre los distintos canales (más información sobre la herramienta en la figura 1)
Figura 5: Manual Page de iw
• La salida por pantalla del script: Se pinta por una parte los clientes y por otra los puntos de acceso (por ello las 2 opciones indicadas antes). Cada vez que va a refrescar la pantalla se produce una limpieza con ‘clear’.
• La captura de paquetes: En esta parte se hace uso de Scapy, para capturar los paquetes y administrarlos en nuestro listado de ‘clientes’ y puntos de acceso hay que tener en cuenta varias cosas:
▪ No duplicar direcciones MAC, por lo que debemos filtrar y comprobar si ya se ha procesado. ▪ Evitar ‘ruido’, por ejemplo la dirección de broadcast.
• El iniciador del código: Se encarga de lanzar un hilo para ir saltando por los canales y de iniciar el sniffer de Scapy.
La herramienta Scapy es una de las que se explica y utiliza en el libro de Ataques en redes de datos IPv4&IPv6 3ª Edición y muchos de los ataques que allí se explican se hacen o se pueden hacer con Scapy. De hecho, en este blog se ha hablado de ella en algunos artículos de hacking de redes:
Como manualmente revisar cerca de 25.000 líneas no es muy viable, con un pequeño código en Python leo los dos ficheros y compruebo el contenido para verificar que ambos coinciden con los datos que va a tener mi diccionario. El código se puede ver en la imagen siguiente:
Figura 7: Código para generar diccionario de direcciones MAC asociadas a vendors
No busca ser el más eficiente, sólo lo necesitaba para una acción en la generación del fichero. El resultado se puede ver en el fichero mac_vendors.py. Es probable que el listado no incluya todo, pero es bastante completo. Con ello nos basta para filtrar el contenido según los dispositivos, siempre y que al usuario le interese, si no se muestra todo.
Además, con la API de macvendors, podemos mostrar al usuario por pantalla el dispositivo de los clientes, se hace uso de la versión gratuita, limitada a 1.000 peticiones al día (y máximo de 1 por segundo).
Prueba de Concepto
Ya se ha visto por encima cómo funciona este script, es hora de verlo en acción con unas pequeñas pruebas de concepto - ya sabéis, las PoCs (Proof of Concept). Vamos a ver un par de ejemplos. El prime ejemplo es tan sencillo y útil como realizar una búsqueda de los clientes conectados a puntos de acceso con una instrucción como la siguiente: sudo python3 airopy.py -i wlx00c0ca81fb80 --stations
Figura 9: sudo python4 airopy.py - i wlx00c0ca81fb80 --stations
El segundo ejemplo es de cómo realizar una búsqueda de los puntos de acceso que hay alrededor de la máquina en la que estamos trabajando, con un comando como: sudo python3 airopy.py -i wlx00c0ca81fb80 --aps
Figura 10: sudo python3 airopy.py -i wlx00c0ca81fb80 --aps
Se podrían poner más ejemplos para que se muestren tanto los Access Points como las Stations, pruebas fijando el canal de escucha, etcetera. Pero creo que con estás dos capturas se puede apreciar el funcionamiento del script. Ahora lo puedes probar tú a gusto, y extender en funcionalidades. Nos vemos en la próxima entrada. ¡Hasta pronto!
Autor: Josué Encinar García (@JosueEncinar), autor del blog BoomerNiX y Security Researcher en ElevenPaths y en el equipo de Ideas Locas de la unidad CDO de Telefónica.
Alexander Graham Bell patentó el teléfono en 1876 y este fue el comienzo de una revolución en las comunicaciones por cable. Esta se acentuó aún más cuando Guillermo Marconi llevó estas mismas comunicaciones a otro nivel utilizando la radiotransmisión a grandes distancias sin la utilización de cables, es decir, inalámbrica. Es curioso como sobre ambos existe un halo de incertidumbre sobre sus inventos. En el caso de Bell parece ser que el teléfono ya había sido desarrollado por Antonio Meucci y en el caso de Marconi, este había basado muchos de sus descubrimientos en las investigaciones y patentes de otro grande, Nikola Tesla.
Figura 1: Cómo un mago hizo el primer "Man in the Middle" wireless al gran Guillermo Marconi
Dejando de lado esta controversia, hay otra curiosidad que afectó a ambos descubrimientos en su época: los dos sufrieron, nada más inventarse, los primeros llamémosles “incidentes de seguridad” de la historia de las comunicaciones. Es decir, hoy os contamos cómo un grupo de adolescentes en 1878 y un “Man in The Middle” al mismísimo Guillermo Marconi en 1903 se convirtieron en los cimientos de la seguridad en las comunicaciones.
En 1878, las primeras redes de telefonía de Bell ya estaban comenzando a expandirse por toda Norteamérica. En concreto, ese mismo año se instaló el primer conmutador telefónico en Nueva York. Estos conmutadores eran habitaciones llenas de paneles y clavijas donde un grupo de personas (en un principio, adolescentes) eran quienes hacían las tareas de interconexión, seleccionando la correspondiente clavija en el conector asociado a la persona o empresa a la cual se quería llamar. En el vídeo siguiente, que formó parte de la exposición de la Historia de las Telecomunicaciones en el Espacio Fundación Telefónica se puede ver cómo era ese trabajo.
Figura 3: Experiencias de una telefonista
Al principio, como hemos comentado antes, estas personas eran chicos adolescentes, ya que debido a su juventud se suponía que serían capaces de hacer las tareas de interconexión de una manera más rápida, la cual requería reflejos y velocidad. Parece ser que poner al cargo de estos paneles de conexión a chicos de esa edad fue un tremendo desastre (según el libro “Hacking in the Computer World”).
Uno de los jefes de Bell los llamaba de manera improcedente “Indios Salvajes” ya que estos eran muy rudos con los clientes (por ejemplo, en vez de decir “Hello” decían “Ahoy!”), escuchaban las conversaciones, gastaban bromas, desconectaban llamadas en curso o directamente las cruzaban por lo que los clientes acababan hablando con desconocidos. Incluso el día de San Patrick (San Patricio, fiesta muy asociada a beber grandes cantidades de alcohol) se lo tomaron libre sin avisar a sus superiores.
Una combinación del uso de una nueva tecnología, curiosidad, poder y sobre todo anonimato, fueron la tormenta perfecta que finalmente terminó en esta forma de actuar (aunque trabajar en turnos de 12 horas seguidas puede que también influyera un poco). Esta misma combinación de adolescente curioso y tecnología se repetirá varias veces a lo largo de la historia con diferentes resultados, algunos buenos (hackers) y otros no tan buenos (ciberdelicuentes).
Llegan las "Chicas del Cable"
Finalmente, estos chicos de Bell fueron sustituidos esta vez por chicas, las cuales marcaron la imagen icónica de “operadora” que todos hemos visto en los libros de historia. Aunque esto no dejo libre de pecado a las operadoras, las cuales, de vez en cuando barrían para casa, como contamos en su día en el artículo de nuestro blog, en el que explicábamos que esto causó finalmente la invención del conmutador de teléfono automático para remover el factor humano.
Figura 5: Operadoras en un centro de conmutación de llamadas de New York
Hay que destacar que entre todas esas chicas seguro que había mujeres hacker con las mismas ganas de aprender y entender la tecnología que sus homólogos varones, pero estamos hablando de 1878, donde la mujer sufría una gran discriminación social y estaba vetada en los trabajos técnicos. ¡Cómo hubiera avanzado la sociedad si este veto sin sentido nunca hubiera existido y personalidades como Ada Lovelace hubieran podido realizar sus investigaciones sin ningún tipo de obstáculos! De toda esta situación, y de cómo las telefonistas podían utilizar su posición de "woman in the middle" comenzó la trama de la famosa serie de Netflix basada en la compañía Telefónica de España.
Figura 6: Trailer de Las Chicas del Cable
Hemos visto como las primeras comunicaciones por cable tuvieron su primer incidente de seguridad sólo dos años después de la invención del teléfono. El segundo de los incidentes, del que vamos a hablar hoy, demuestra que lo mismo ocurrió en el amanecer de las comunicaciones inalámbricas, afectando directamente al invento de Marconi, pero peor aún, también fue un ataque directo a su reputación (aunque finalmente parece que no le afectó demasiado). Vamos a ver la historia con detalle, la cual se puede considerar el primer ataque a una línea de comunicaciones de la historia.
El "man in the middle" wireless a Guillermo Marconi
Al principio, la seguridad de que esta información llegaba intacta a sus receptores se basaba simplemente en el acuerdo de confidencialidad firmado por el operador del servicio y de la capacidad de cualquier receptor de entender el código Morse. Pero en 1903 ocurrió un hecho que afectó al mismísimo Marconi y que sería un punto de inflexión para la seguridad de las comunicaciones, que luego daría un gran salto con la invención de la máquina Enigma y su revolucionario cifrado.
Figura 7: Guillermo Marconi junto a su invención
En concreto, el 4 de junio de 1903, Guillermo Marconi se preparaba para mostrar al público su grandioso sistema de envío seguro de mensajes a grandes distancias. Entre sus características, incluía un sistema de ajuste de la señal (tunning) el cual en teoría, lo protegía contra interferencias (naturales o, como veremos ahora, intencionadas). Marconi se encontraba a 482 kilómetros (en Cornwall) del Royal Institution de Londres preparado para enviar mensajes a su colega Flemming, el cual estaba esperando a recibirlos en dicho teatro.
De repente, en vez de recibir e imprimir el mensaje enviado por Marconi, lo que apareció fue la palabra “Rats” (ratas), y luego la frase:
“There was a young man from Italy, who diddled the public quite prettily”
que más o menos quiere decir:
“Hubo un joven italiano, el cual timó elegantemente al público”
Alguien había interceptado la comunicación y había cambiado el contenido del mensaje por esa palabra. Ese alguien era Nevil Maskelyne, un mago (un mago de verdad, de los que hacía magia) e inventor, y algo problemático, el cual era el manager de una compañía de telecomunicaciones rival de Marconi, y con el ya había tenido algunas disputas sobre patentes de sistemas de telégrafos inalámbricos.
Así que decidió que la mejor manera de dejar en evidencia el sistema de su competidor era atacándolo y demostrando empíricamente lo inseguro que era, y de paso también, hundir su reputación. Maskelyne no sólo llegó a bloquear los mensajes de Marconi, sino que fue capaz de enviar los suyos propios.
Pero ¿cómo lo hizo? Lo primero fue buscar una ubicación cercana al teatro de Londres para de esa forma, poder emitir una señal más potente que la que le llegaría a Flemming procedente de Cornwall. La señal emitida por Marconi estaba, en teoría, ajustada a una frecuencia muy concreta, es decir, para poder recibir o interferir en la señal era necesario ajustar otra emisora exactamente a esa misma frecuencia.
Esto lo conseguía con una técnica llamada “syntonic tunning” (o ajuste sintónico) la cual permitía cambiar el ajuste de frecuencia utilizando una antena basada en una resistencia variable (básicamente lo que llamamos hoy día “dial”). Por cierto, esta técnica no era invención suya sino de Oliver Lodge, aunque Marconi acabaría por comprar la patente unos años después.
Maskelyne parece ser que utilizó esa misma técnica (ahora veremos que al final no le hizo falta) para detectar la señal de Marconi y enviar a su vez el mensaje que antes hemos comentado. Con una señal de 2.5 amperios, no sólo fue capaz de bloquear la señal enviada por Marconi sino que además, durante ese bloqueo, fue capaz de enviar su propio mensaje, un ataque "man in the middle" en toda regla.
Flemming anotó el mensaje recibido y más tarde se quejó al diario Times por “gamberrismo científico”, iniciando un cruce de cartas entre Flemming y Maskelyne donde discutieron sobre el origen del mensaje, la cual incluso Flemming llegó a insinuar que fue una simple interferencia. Aunque al final se descubrió que Flemming no había usado un recibidor sintónico, éste era demasiado grande para la demo, por lo que no estaba sintonizado a una frecuencia concreta, y esto hubiera podido evitar la recepción de los mensajes que Makeslyne mandó, aunque no hubiera podido evitar que Makeslyne bloqueara los mensajes de Marconi.
Lo más curioso de este incidente entre Marconi y Maskelyne (y que esto sirva de moraleja), es que ni Flemming ni Marconi usaron ese novedoso sistema de ajuste sintónico ya que hubiera requerido de mucha más tecnología y un coste mayor aunque sí que anunció a bombo y platillo que lo usaría. De todas formas, aunque hubiera utilizado esta tecnología sintónica, no hubiera podido bloquear la señal de Makeslyne. Es decir, Marconi antepuso la efectividad a la seguridad, pero además engañó un poco a la gente diciendo que la transmisión era “segura” aplicando una técnica que finalmente, no llegó a utilizar en la demostración.
Adolescentes realizando gamberradas tecnológicas gracias a la protección que ofrece el anonimato y un ingeniero que antepone que los sistemas funcionen a la seguridad seguro que es algo que os suena hoy día ¿verdad? ;) Si te interesa este tema, recuerda que en el Espacio de la Fundación Telefónica tienes aún la oportunidad realizar un viaje en el tiempo y comprobar de primera mano toda la tecnología de la historia de las comunicaciones en nuestro país en la exposición “Historia de las Telecomunicaciones”, donde se exhiben algunos de estos aparatos históricos.
Y recuerda, en nuestro libro “Microhistorias: Anécdotas y curiosidades de la informática (y los hackers)” encontrarás más historias como estas, las cuales creemos firmemente que son imprescindibles tanto para que sirvan de motivación, así como para aprender a enfrentarnos al futuro aprendiendo del pasado, como hemos podido comprobar en este artículo de hoy.
Las criptodivisas están de moda, eso es algo indudable, y si no que se lo digan a mis compañeros de ElevenPathsFelix y Yaiza que llevan años estudiando el blockchain y las criptodivisas, tal y como se puede ver en su charla de Rooted de 2015 y en su libro BlockChain & BitCoins: La tecnología y su investigación. Este boom que tenemos en nuestros días con las criptodivisas, la minería y la especulación es un cartel luminoso para muchos ciberdelincuentes. En este artículo no se pretende valorar la seguridad del Blockchain, las criptodivisas o los mecanismos de protección que tienen en su mano los usuarios que manejan su capital.
Figura 1: CoffeeMiner: Te tomas tu café, te conectas a la WiFi y minan BitCoins con tu CPU
Lo curioso es ver cómo se automatizan ciertos ataques que ayudan, en este caso, a la minería. La herramienta CoffeeMiner, la cual se puede estudiar en su Github, pretende ser una prueba de concepto, con propósito académico según indica su propio autor, de lo que pueden llegar a hacernos a cualquiera de nosotros mientras nos tomamos un café en nuestro bar favorito y aprovechamos ese placer para leer las noticias en nuestro dispositivo digital.
Figura 2: How I meet your e-wallet
CoffeeMiner es una prueba de concepto que permite realizar un ataque de Man in the Middle y seleccionar diferentes targets que serán envenenados. A partir de aquí, el tráfico de las víctimas pasará por el atacante y éste podrá inyectar un código JavaScript en cualquier documento HTML que la víctima solicite, ya que esta petición pasará por el atacante. Este JavaScript contiene un minero en su código, por lo que todos los dispositivos conectados a la red podrían ser víctimas y estar minando sin ser conscientes de ello.
El esquema de cómo funciona CoffeeMiner es sencillo. Un atacante que tome un café en una cafetería y haya diversos clientes conectados a la red WiFi de dicha cafetería podría aprovecharse y obtener un beneficio logrando que los clientes minen para él. Este ataque es extensible a redes cableadas, ya que el secreto de todo esto está en que el tráfico pase por una máquina concreta, la del atacante.
Si el atacante está en una red cableada, podría aprovecharse de técnicas como el ARP Spoofing o cualquier otro de los Ataques de redes IPv4 o IPv6 y, posteriormente, utilizar la inyección de JavaScript. Es más, si el atacante pusiera su propio Rogue AP, no haría falta envenenar ninguna caché, ya que podría, directamente, inyectar el código JavaScript porque él es el Gateway.
Figura 4: Esquema de ataque con CoffeeMiner
En otras ocasiones hemos visto como herramientas como Bettercap o MITMf permiten realizar acciones similares de forma sencilla, orientado a la auditoría de seguridad. CoffeeMiner también puede entenderse como una herramienta de auditoría, aunque es una prueba de concepto con propósito académico.
El código de CoffeeMiner
En el sitio web del autor de CoffeeMiner se explica el código de la aplicación/automatización basada en mitmproxy. Para realizar el ataque MITM se utiliza la vieja herramienta arpspoof, con su famosa sintaxis arpspoof –i [interfaz de red] –t [target 1] [target 2] y la instrucción contraria para hacer el envenenamiento en ambas direcciones.
Posteriormente, se utiliza mitmproxy para analizar el tráfico que circula a través de un equipo, pudiendo editar el tráfico. Esto se utilizará para inyectar el JavaScript, el cual está preparado o contiene para que la víctima, a través de su navegador, mine. La línea que se inyectará tendrá el siguiente aspecto:
El código queda de la siguiente manera, teniendo en cuenta que se utiliza la librería que integra mitmproxy:
Figura 5: Código de CoffeeMiner
Como la parte de “Injector” añade una línea al HTML legítimo con el que se consigue llamar al JavaScript malicioso, el atacante tendrá que contar con un servidor web dónde se alojará el fichero JavaScript malicioso. CoffeeMiner proporciona un sencillo código para automatizar esto, aunque con un servidor Apache sería algo trivial.
Figura 6: Código de servidor web para servir el fichero JavaScript de minado
Por último, la parte de CoinHive. Éste es un proyecto cuyo eslogan es aprovechar la computación de tu negocio para sacarle un provecho. Esto puede tener un buen fin, pero también puede haber usuarios maliciosos que quieran aprovecharse de esto. A continuación, os dejamos un video de ejemplo realizado por el autor de la herramienta:
Figura 7: Demo de CoffeeMiner
Sin duda es un proyecto que hace una crítica a la facilidad y el riesgo que tenemos los usuarios que accedemos a redes no seguras o redes con usuarios “de paso”. Por esta razón, debemos estar atentos a qué redes accedemos y en qué sitios confiamos. En este caso, no se apoderarán de datos sensibles nuestros, pero sí que utilizarán nuestra CPU para que puedan ganar unos dólares. Una buena solución sería utilizar una VPN desde la propia red WiFi dónde nos conectemos, para que estemos ante una red aislada. También se podría utilizar plugins como NoScript para evitar la ejecución de código JavaScript. Otra opción sería utilizar una red virtual dentro de la WiFi y poder evitar que hagan uso de nuestra CPU.
Una vez que hemos repasado todos estos entresijos de la parte teórica del proceso de "Salto de Canal" en las redes WiFi que vimos en la primera parte de este artículo, ya estamos preparados para crear una pequeña herramienta que realice ese trabajo, así que vamos a ver en esta parte cómo hacerlo. Comencemos con las problemáticas que hemos visto anteriormente una a una.
Figura 16: Hacking Wi-Fi: Cómo funciona el "Salto de Canal" (Parte 2 de 2)
A la hora de hacer un sniffing, tenemos que poder “escuchar” en todos los canales para poder capturar todos los paquetes que viajan por el aire, pero como esto no es posible, puesto que las interfaces inalámbricas tan solo pueden estar escuchando en un canal concreto en un momento determinado, lo que tenemos que hacer es ir cambiando de canal a intervalos reducidos de tiempo. De esta forma, aunque no estemos en todos los canales, virtualmente parecerá que sí.
También es importante recordar que la técnica de salto de canal no persigue capturar en sí todos los paquetes que viajan por el aire, más bien persigue el objetivo de localizar o detectar los dispositivos vivos que están trasmitiendo por el medio. Y, una vez localizados, centrarse en un objetivo concreto, es decir, realizar el sniffing a un solo canal.
Por lo comentado hasta ahora, el tiempo que pasemos en un canal es muy importante, de ahora en adelante lo llamaremos “timming”.
Es importante ser conscientes de que muchas estaciones o clientes no están continuamente transmitiendo. Por lo que debemos de utilizar un “timming” lo suficientemente pequeño para barrer toda la banda de frecuencia, pero al mismo tiempo lo suficientemente grande para llegar a capturar los paquetes transmitidos. En las PoCs que he creado he utilizado un “timming” de 0.4 y 0.6. Pero es posible utilizar tiempos menores.
El solapamiento
A la hora de ir saltando de canal, lo más coherente como primera impresión, por sencillez, sería pensar en recorrer mediante un bucle todos los canales de formas secuencial. Es decir, recorrer los canales desde el 1 pasando por el 2, 3, 4... hasta recorrer los 14 canales. Sin embargo, esto no sería lo más eficiente. Como comentamos en los puntos anteriores, la banda de 2.4 Ghz tiene el inconveniente de los solapamientos entre canales - peor todavía si se utiliza el estándar IEEE 802.11n que utiliza un ancho de banda de 40 Mhz -. El solapamiento provoca que sea posible capturar tráfico que pertenece a los otros canales contiguos. Esto no interesa.
Para evitar este problema se suele ir saltando, como mínimo, de tres en tres canales. Si se analiza el funcionamiento de airodump-ng se puede corroborar que sigue un mecanismo basado en saltos no secuenciales.
Figura 17: Arrays de canales en airodump-ng
En el “header” de airodump-ng (aquí el C) se pueden ver los ARRAYs de las listas predefinidos con saltos de canales no secuenciales según el estándar utilizado. Está sería una de las formas correctas. Es posible, utilizando una imagen que muestre los solapamientos entre canales de los estándares IEEE 802.11 bgna buscar otra serie de saltos sin solapamiento.
Canales comunes y no comunes
Otro de los problemas que podemos encontrarnos es que, según la región o el país, vamos a poder utilizar unos canales u otros, dependiendo de la interfaz que se utilice y de la configuración de la región. Por lo que al definir una lista con los canales debemos de tener en cuenta cuales son los canales comunes a todos los países y cuáles no.
Ordenarlos de forma que si un canal no común no se utiliza no rompa la eficiencia ante el solapamiento de la lista. Es decir, si tenemos la siguiente lista: 1, 14, 2. Y no utilizamos el canal 14. Al final se va a realizar el salto del canal 1 al 2 y esto no sería correcto al ser canales contiguos y solapables. Recordad que los canales comunes en todos los países van desde el 1 hasta el 11. El 12 y 13 se utilizan en la mayoría de países y el 14 solo en Japón.
¿Qué canales?
Por el mismo problema que el caso anterior, es posible que no todos los canales funcionen al realizar el cambio de canal (aparezcan errores). Por lo que se estaría realizando saltos a canales no válidos. La solución más óptima, en mi opinión, sería comprobar antes de realizar el sniffing que canales son válidos y cuáles no.
¿Qué bandas?
Lo mismo que el caso anterior, pero en esta ocasión referente a las bandas de frecuencia y a los canales. También se podrá solucionar haciendo una comprobación previa.
Mi módulo, SaltoCanal
El objetivo que se persigue es crear un módulo independiente que pueda ser utilizado por otras herramientas de forma totalmente modular y abstracta. Que esté pensando para utilizar en una Raspberry Pi con la interfaz inalámbrica que trae de serie bajo la distribución modificada de Kali Linux. Como lenguaje de programación he decido utilizar Python. Por diversos motivos. Entre ellos:
Es el recomendado por los fundadores de la Raspberry Pi.
Por ser un lenguaje de programación de alto nivel. Un lenguaje de sintaxis sencilla y clara.
Es un lenguaje con gran documentación y herramientas.
Es fácil de aprender. Cualquiera que no conozca el lenguaje pero que sepa programar puede comprender fácilmente el código. Por lo que facilita el aprendizaje a terceros.
Es un lenguaje interpretado o de script, fuertemente tipado y dinámico, es multiplataforma y es orientado a objetos.
Además, es un lenguaje bastante potente y con muchas librerías que nos ayudan a realizar casi cualquier cosa.
Otro de los motivos más importantes es que se integra muy bien con Scapy. Librería que estoy utilizando para el desarrollo del proyecto que tengo entre manos. Aquí os dejo el enlace a GitHub del código del script:
Este código está sujeto a cambios, no puedo decir que esté testeado a fondo. Por lo que seguro que habrá que corregir algunas cosas.
SaltoCanal
Utiliza los siguientes módulos:
Thread de threading.
Os.
Sys.
Popen, PIPE de subprocess.
SIGINT, signal de signal.
Sleep de time.
Y un módulo propio, manejo_interfaz, para realizar ciertas operaciones que son
comunes sobre las interfaces inalámbricas. Las constantes que utiliza son dos listas de canales ordenadas mediante un sistema ideal para evitar el solapamiento:
Esta constante se utilizará para descartar la salida cuando se invoque a popen.
La clase SaltoCanal
El modulo es una clase que hereda de threading.Thread. Sus métodos son:
Métodos públicos:
__init__: Para instanciar el objeto. comprobar_canales: Para comprobar que canales podemos utilizar. fijar_canal: Para fijar la interfaz en un canal concreto. tiempo_canal: El “timming”, el tiempo que se utiliza un canal al realizar el salto de canal. lista_VIC: Very Important Channel. Crea una lista con los canales más importantes para
el usuario. fijar_canales: Para fijar los canales en una lista dada por el usuario. pausar: Para pausar el hilo. continuar: Para continuar con el hilo si está pausado. terminar: Para finalizar el hilo. run: Para ejecutar el hilo.
Métodos privados: __get_pausar: Devuelve la variable pausa. __lista_canales_valida: Para comprobar que los datos de entrada del __init__ son
correctos. __comprobar_interfaz: Comprueba que existe la interfaz proporciona por el usuario y
que está se encuentra en modo MONITOR o RFMON. __cambiar_canal: Método que cambia el canal de la interfaz mediante un proceso. __comprobar_canales: Comprueba los canales válidos que se pueden utilizar y devuelve
una lista de ellos.
Pasemos ahora a detallar cada método. __init__()
Como ya sabréis es un método reservado para instanciar los objetos de la clase (el constructor en Java). Por ejemplo, sc = SaltoCanal(“wlan1”). A este método solo es obligatorio pasarle la interfaz. Todas las demás variables son optativas.
La variable espera se utiliza para indicar el tiempo de escucha en un canal concreto.
La variable check se utiliza para realizar la comprobación de canales. Es decir, para verificar aquellos que funcionan y descartar los que no.
Las variables _24Ghz y _5Ghz indican que listas de bandas de frecuencia se van a utilizar.
Por último, verbose, para que la clase imprima por pantalla información al respecto.
Como el objetivo es utilizar esta clase desde otros scripts puede resultar más eficiente que sea mudo. Por lo que nos bastará por comprobar los códigos de salida para conocer el motivo. Dentro del método se verifican que los datos de entrada sean coherentes, es decir, que al menos se pase una de las bandas de frecuencia, esto se hace con el método privado: “__lista_canales_valida()”.
También comprobamos que la interfaz facilitada por el usuario es correcta o existe y está en modo monitor o RFMON. Para ello se llama al método privado “__comprobar_interfaz()” que a su vez utilizará otros métodos (existe_interfaz() y esta_modo_monitor()) utilizando un módulo externo que fue creado por mí y que tiene como nombre manejo_interfaz. Con ellos verificaremos que existe la interfaz y que está en modo monitor. Miraros este módulo para ver cómo se comprueban estas cosas.
Cabe resaltar que es aquí donde se inicializa el hilo (“Thread”) y que se crea como daemon. Que básicamente es para que el hilo principal pueda terminar sin esperar a nadie más. Se inicializan el resto de variables que utilizaremos para el correcto funcionamiento del hilo.
comprobar_canales()
Este método se utiliza para comprobar que canales se pueden utilizar y cuáles no. Por lo que devolverá una lista con los canales válidos. Este proceso solo se realiza si el check está a True. Para ello, utiliza el método privado “__comprobar_canales()”.
__comprobar_canales():
Este método recorre la lista de canales que se le pasan para verificar si son válidos. Utilizando el método “__cambiar_canal()” que devuelve True o False si existen algún error. En caso de no existir, se guarda en una lista el canal, en caso contrario, se descarta.
También comprueba si todos los canales han fallado, por lo que si esto ocurre el programa finaliza con un error, puesto que no existen canales válidos.
__cambiar_canal():
Este método recibe un canal y lanza un Popen. Un Popen es un módulo que nos permite lanzar programas externos y tener cierto control sobre ellos. Mediante la variable del módulo “stderr” comprobamos si existen errores.
Como se puede observar, estamos utilizando iw para realizar el cambio de canal, como comentamos anteriormente. La sintaxis sería: “iw dev self.interfazset channel canal”, siendo la variable interfaz la facilitada por el usuario, y canal el canal que queremos utilizar. No hay más magia en todo esto.
fijar_canal()
Este método permite fijar un canal en vez de andar saltando de canales. Solo funcionará si el hilo está parado.
tiempo_canal()
Este método permite cambiar el “timming”, el tiempo que pasaremos utilizando un canal.
fijar_canales()
Este método fija el salto de canales a una lista proporcionada por el usuario. Puede resultar útil cuando el usuario tan solo quiere realizar un sniffing a tan solo a una pequeña lista de canales concretos o fijar una lista de canales propia.
lista_VIC()
Very Important Channel. Este método me parece también muy interesante. Como comentamos en la teoría, existen canales más importantes que otros, como son el canal 1, 6 y 11 que no se solapan entre ellos, por lo que puede interesar pasar más tiempo en ellos porque podrían estar más poblados.
Bueno, en realidad, este es uno de sus usos, pero puede tener muchos dependiendo de la imaginación de cada uno. Al habilitar este método y proporcionarle una lista y un tiempo determinado, el hilo detectara los canales que pertenezcan a esta lista y esperara el tiempo facilitado por el usuario.
run()
Este es un método de la clase “Thread”. Una vez que se lance el hilo se ejecutará lo que está dentro de este método. En nuestro caso un bucle que recorre infinitamente una y otra vez toda la lista de canales, provocando el salto de canal.
Una vez que tenemos creado nuestro “bicho” es hora de comprobar que todo funciona correctamente. Para ello, ponemos la interfaz en modo monitor. En los ejemplos estoy utilizando una distribución de Kali Linux un tanto peculiar. Esta distribución modificada, entre otras cosas, permite poner la interfaz Wi-Fi que viene por defecto con la Raspberry Pi 3 en modo monitor.
Hablaros sobre todo esto escapa del objetivo principal de este artículo. Para los interesados aquí os dejo ciertas referencias al proyecto NexMon y la URL donde podéis descargaros las imágenes de Kali Linux modificada. Para poner la tarjeta de la Raspberry Pi en modo monitor tan solo tenemos que utilizar este comando: monstart Para parar el modo monitor, bastaría con: monstop
Como veis, todo muy sencillo, pero ¡ojo!, si se utilizan varias tarjetas inalámbricas, hay que cerciorarse bien cuál es la interfaz que está en modo monitor. Se puede hacer con iwconfig o iw dev
Una vez que se tiene la interfaz en modo monitor se puede comprobar que todo funciona correctamente utilizando un sniffer. Existen varias posibilidades, yo me he decantado por Wireshark por venir ya preinstalado, por ser un viejo conocido (aka Ethereal) y por la interfaz gráfica, para que todo sea más visual en las capturas de pantalla.
Para realizar el sniffing con Wireshark antes se debe de indicar la interfaz por la cual se quiere capturar tráfico. Es decir, la interfaz que esté en modo monitor. Si todo es correcto, irán apareciendo los paquetes capturados en Wireshark.
Probando salto_canal.py.
Existen varias formas de lanzar este módulo. La primera forma es simplemente ejecutándolo directamente con python saltocanal.py. Recordad que si utilizáis este método deberéis de crear en el “main” algo como esto:
sc = SaltoCanal(“wlan1”)
sc.start()
raw_input('Presiona enter para finalizar...')
El raw_input es fundamental, de lo conterario el programa y el hilo finalizaran y no se podrá testear. Pero si quieres también puedes probarlo ejecutándolo a través de la consola de Python. Para ello se lanza la consola de Python mediante un comando python y desde allí de importa el módulo. (Para ello se aconseja lanzar la consola de python en el mismo directorio que salto_canal.py). Y se prueban los métodos. Como se aprecia en las siguientes capturas, todo parece funcionar correctamente.
Figura 19: Preobando el módulo de Salto de Canal en Python en una Raspberry Pi 3
Conclusiones:
Como hemos visto, crear un script que realice el salto de canal no es complejo. Lo fundamental es conocer los problemas que pueden aparecer y buscarle soluciones óptimas. Esto solo es posible analizando y estudiando el funcionamiento de las cosas. Gracias al Open Software existen multitud de herramientas de código abierto que pueden ayudarnos en este proceso.
A la hora de auditar una red WLAN puede que las herramientas más conocidas no nos sirvan. Bien por ser algo muy concreto y especifico o porque necesitamos automatizar el proceso. Crear nuestras propias herramientas nos facilitará muchísimo las cosas, además de permitirnos tener un mayor control de lo que estamos haciendo.
Crear herramientas modulares y abstractas nos facilitarán la reutilización de las mismas en casi cualquier escenario. Incluso pueden darnos nuevas ideas. Una vez solucionado el problema del salto de canal, ya se puede empezar a jugar con: python + scapy + dot11 y dejar volar nuestra imaginación. ¡¡happy hacking!!.
Si tenéis cualquier inquietud no dudéis en poneros en contacto conmigo.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
