Balizas v16: Los árboles que no dejan ver el bosque

Mucho se ha hablado (y se está hablando) sobre las Balizas v16 con geolocalización para señalizar averías en tiempo real de la DGT, las cuales son obligatorias a partir del 1 de enero de 2026 por el Real Decreto 1030/2022 que modifica el 159/2021. El eje principal de la discusión está focalizado en el “ataque a la privacidad” que se presupone por parte de este tipo de dispositivos al realizar el envío de datos de geolocalización cuando se activan. 

Figura 1: Balizas v16 - Los árboles que no dejan ver el bosque

Sin embargo, en este nuevo sistema de alerta de la DGT, ¿es cierta tal preocupación o nos la hemos auto-generado para evitar ver lo que hay más allá? Vamos a desarrollarlo un poco.

Figura 2: Real Decreto 1030/2022

Las Balizas v16 son dispositivos IoT que disponen de una SIM para comunicarse con los servidores de sus respectivos fabricantes con el objetivo de que éstos puedan agregar y preparar la información antes de derivarla a los servidores de la DGT.

Como dispositivos IoT que son, su producción escalable y asequible deriva en deficiencias de seguridad al no incorporar distintos módulos hardware que proporcionan capacidades avanzadas de cómputo, almacenamiento seguro, u otras características relevantes.  En este sentido, existe ya algún algún que otro análisis pormenorizado de estas deficiencias como el realizado por Luis Miranda disponible en su propio Github.

Figura 3: Vulnerabilidades en Balizas V16 Conectadas

Ahora bien, como explico en el Capítulo VI de Arquitecturas en el Internet de las Cosas de mi libro Arquitectura de Seguridad y Patrones de Diseño Seguro, si queremos suplir dichas deficiencias de seguridad, las balizas v16 deben contar con capacidades de cómputo suficientes para utilizar protocolos de seguridad robustos, almacenamiento seguro anti manipulación para custodiar las credenciales de identificación del dispositivo así como los certificados para las comunicaciones seguras, capacidades de gestión de auto registro en el sistema tras su encendido y gestión de ciclo de vida de todas sus credenciales custodiadas, entre otros. 

Figura 4: "Arquitectura de Seguridad y Patrones de Diseño"

El nuevo libro de 0xWord escrito por Elías Grande.

La incorporación de todas estas características en los dispositivos IoT producirían un aumento sustancial del precio de compra de las Balizas v16 (así como el consumo de batería que necesitaría una baliza para soportar todo lo descrito anteriormente). Teniendo esto en mente y que si no fueran asequibles por parte de los ciudadanos sería complejo que un Real Decreto nos obligase a comprarlas, ¿tanto riesgo para la privacidad implica su uso?

Análisis

Partiendo de la base de que no soy jurista y evitando interpretaciones artificiosas de la norma, si leemos el Reglamento General de Protección de Datos (RGPD) se indica objetivamente que la geolocalización se considera un Dato Personal si ésta permite identificar directa o indirectamente a una persona física.

En base a esta premisa, si analizamos la Baliza v16, la tarjeta SIM está asociada sólo al dispositivo IoT y no existe relación contractual del ciudadano con la SIM (como sí ocurre entre el ciudadano y la SIM de la teleoperadora que le proporciona voz y datos en su terminal móvil). Esto independiza completamente la identidad del individuo de la Baliza v16 que utiliza.

Es más, el único momento en el que se podría intentar ligar uno a uno la baliza con el ciudadano podría ser en el momento de compra siempre que ésta se realice con tarjeta y sólo sea una unidad (en este caso se podría intentar ligar el número de la tarjeta con el número de serie / IMEI, aunque habiendo datos de tarjeta ya nos metemos en otro jardín con PCI DSS aún mayor y por tanto podemos descartar dicha vinculación).

Al no existir entonces esa vinculación baliza-ciudadano sino que los datos de geolocalización están asociados SÓLO a la baliza activa (dispositivo IoT sin identidad de persona física), no aplicaría un análisis de riesgos de privacidad LINDDUN ya que la única forma de conocer la identidad del sujeto que activa la baliza es estar presente en la misma geolocalización en la que dicha baliza está activa.

Mapa Balizas v16  

En base a esto, y a que en muchas ocasiones en las grandes superficies de venta hay Balizas v16 activas como reclamo visual para su compra, ¿qué persigue el poder disponer de un mapa de España con las balizas activas en cada momento?

Figura 5: Mapa de Balizas en España

Presuponiendo el buen hacer de la DGT, se puede entender que el objetivo principal de disponer de toda esta información de averías en tiempo real es la de, en un futuro tras el análisis estadístico de los datos, actualizar los puntos negros en carretera para, por ejemplo, modificar la señalización o incorporar nuevos radares (fijos, móviles, de tramo, etcétera).

Figura 6: Información de baliza

Esta presuposición se apoya en que la baliza de por sí no es un sistema de emergencia ya que no está conectada al 112 ni tiene capacidad de determinar si se necesita una ambulancia, bomberos o policía, o si sólo se requiere una grúa. 

Teniendo en cuenta todo lo descrito anteriormente y sabiendo que hay múltiples fabricantes homologados, la arquitectura simplificada de todo este sistema sería algo así:

Figura 7: Arquitectura con fabricantes homologados

A partir de esta visión holística y presuponiendo el caso de uso de fines estadísticos para actualizar los puntos negros de la seguridad vial española, el eje de la privacidad motivo de muchas discusiones sobre las Balizas v16 debería cambiar a un eje más propio de ciberseguridad.

Desde dicho punto de vista de ciberseguridad, si analizamos el sistema planteado en su conjunto basándonos en el modelo de amenazas STRIDE, vemos que de inicio, los ejes de integridad y no repudio parecen no haberse tenido en cuenta, pudiendo derivar en graves riesgos para todo el sistema.

Figura 8: Modelo STRIDE

Una posible amenaza podría ser meter dentro de una caja de zapatos varias Balizas v16 legítimas de distintos fabricantes encendidas: la caja para evitar los destellos de luz y lo de que sean de distintos fabricantes para que no se pueda bloquear fabricantes concretos por uso indebido (algo así como un DDoS con balizas).

Con este simple planteamiento teórico a priori se podrían generar accidentes/averías falsas con balizas homologadas, lo cual comprometería la integridad de los datos del sistema en su conjunto al introducir datos corruptos y, con capacidad de repudio por parte del portador de la caja al no existir una vinculación 1:1 entre ciudadano y balizas.

Este modelo de amenaza teórica se materializó en 2020 por un artista alemán que “paseó” 99 móviles en un carrito para que Google Maps creyera que existían atascos de tráfico, lo cual apoya la hipótesis de un posible riesgo estructural en el sistema de alertas de Balizas v16 de ser factible un ataque similar a este.

Eso sí, si cuando se enciende tu Baliza v16 tu eres el único que va en el coche, y tienes encendido tu móvil, alguien que tenga la localización de tu móvil podría asociarlo con esa baliza y pasar a estar asociada con ese móvil en el futuro. Así que el problema sigue siendo: ¿qué apps o empresas tiene la localización de tu móvil? Asociar tu Baliza v16 a tu perfil les dará... más información, sobre que probablemente fuiste tú el que activó la Baliza v16.

  
Conclusiones

Como punto final del análisis se puede concluir que, el riesgo de uso de las Balizas v16 no se focaliza tanto en un ataque a la privacidad del ciudadano sino en el uso malintencionado que se puede hacer de ellas en perjuicio del sistema en su conjunto. 

Dicho uso malintencionado puede provocar que el sistema en sí, el cual se diseñó por el bien de la ciudadanía enfocado en la seguridad vial, recopile datos incorrectos que perviertan el posterior análisis en detrimento de la seguridad vial de todos los españoles y de las posibles futuras mejoras.

Saludos,

Autor: Elías Grande (Contactar con Elías Grande)  

 Contactar con Elías Grande

La "shittización" en contra de hacer las cosas simples

Hace años, más de una docena, usaba a mis queridos héroes de "The Big Bang Theory" para explicar cómo de difícil lo habíamos hecho los que trabajamos en ciberseguridad para que las personas normales se pudieran conectar de forma segura a una red WiFi y a Internet. En el artículo de "Mea Culpa, Penny" explicaba todas las cosas que un usuario debía saber para configurar una VPN que se tunelizara a través de proxys, firewalls de redes,... ¿La quiere L2TP, SSTP o PPTP? 

Figura 1: La "shittización" en contra de hacer las cosas simples

Si eso se lo tengo que decir a mi madre, mejor la tengo que decir que no se conecte. Pero esta complejidad constante de la tecnología se ha ido extendiendo a la guerra comercial por el usuario, lo que hace que cada vez el número de opciones, los diseños de los interfaces, y el salto conceptual intelectual que el diseñador de un UX espera de un usuario, es cada vez mayor. 

En los foros tecnológicos se dice que un UX se ha "shitted" o "enmierdado" cuando la cantidad de opciones para el usuario, la anarquía de la distribución, la diversidad de los controles que debe tocar, y la cantidad de cosas que el usuario "debe suponer" para poder manejarlo, es enorme, y genera frustración en los usuarios. Esto, que parece evidente, es muy complicado de hacer. Hacer las cosas simples require de mucho trabajo, y para ello hay que primar al usuario o consumidor, por encima de las necesidades de negocio.

Cambiar de terminal iPhone

Os cuento esto por dos casos que he sufrido esta semana, que han sido bastante significativos. El primero de ellos con la migración de mi iPhone. Este es un proceso que he realizado ene veces ya, porque todos los años voy migrando mi iPhone. Esto implica migrar las apps, las fotos, los datos, etcétera... Todo esto bien, pero pero cuando llegamos a las partes de seguridad, la cosa se complica un poco. En mi caso, el iPhone era americano, además, como tengo en el mismo la conexión personal y la profesional, tenía una SIM y una eSIM, de dos países diferentes, además de que tenía que pasar de SIM a eSIM obligatoriamente.

El proceso, por supuesto, no funcionó correctamente, y acabé teniendo que ir a tienda, borrando las eSIM creadas virtualmente a partir de la SIM, y teniendo que comprar nuevas eSIM para el terminal americano. Eso hizo que perdiera los contactos de la SIM, y los contactos de la SIM perdidos generaron que se borraran también de la agenda, y por ende de WhatsApp y por ende usuarios dejaron de ver mi foto y me escribieron "¿Me has bloqueado?" No, estoy migrando un iPhone, no worries. Algunos se habrán enfadado y me habrán borrado a mí, así que me ha hecho perder amigos.

Como tengo Multi-SIM para dos países distintos, voy cambiando qué SIM activo o desactivo, pero claro, en la nueva versión de iPhone asocia a cada contacto una SIM por defecto, y cuando no está conectada esa SIM te sale una alerta que dice: "¿Quieres cambiar la asociación por defecto de la SIM a este contacto para poder llamar?" Y un sinfín de lindezas más, como por ejemplo que los contactos de iOS ahora tienen el botón de contactos, donde sale la lista y solo se puede hacer scroll y pulsar a la derecha en unas letras muy, muy, muy chiquititas... que no sé quién ha diseñado.

Figura 2: Esta me ha encantado. El número que el banco ha pasado a Apple es erróneo y después de llamar al Contact Center de ese número y esperar 20 minutos me dicen: "El número que te da iPhone no es de tu banco, somos otro banco". Genial.

Con la SIM ha sido una fiesta, pero luego hubo que migrar las Wallets, las apps bancarias, los 2FA, las autenticaciones de las herramientas de mensajería, etcétera, etcétera, y para cada una el proceso con la entidad es distinto. Instala app, inicia sesión con las credenciales, por el 2FA, te falta la passkey, recupera password, envía SMS, es de otro país y no llega, desactiva SIM, activa la otra, etcétera. Muy divertido y entretenida la gincana de migrar un terminal iPhone.

La autenticación doble con la identidad simple

La más divertida ha sido una app de un servicio - permitidme que no diga la empresa porque tengo amigos en ella y quiero arreglarlo antes -, donde al ir a hacer Login me ha dado la opción de usuario y contraseña, y en paralelo la opción de "Login con Google". Como no recordaba la contraseña - llevaba la app instalada mucho tiempo con autenticación automática con FaceID - le he dicho que autentique con Google. Y... surprise, me he encontrado con que usé la cuenta de Google sí, pero no con autenticación delegada, sino que lo hice con una contraseña, así que estamos en el caso de misma dirección de e-mail con doble autenticación, con usuario y contraseña o con IdP delegado usando OAuth.

Esto es un problema de arquitectura que los responsables de identidad y seguridad deben resolver, y si no lo hacen bien, genera escenarios de ataque como os comenté en el artículo del año 2022 : "Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree". Dependiendo de cómo lo resuelvan, se pueden dar unos casos u otros. En mi caso, ha sido un DoS en toda regla que aún no he podido resolver y que voy a resolver llamando a mis colegas en esa empresa. 

El proceso ha sido muy divertido. Me enfrento al login y doy a "Login with Google". Comienza el proceso de autenticación delegada, y el sistema descubre que mi cuenta ya está creada pero con autenticación con contraseña. Salta el sistema de protección y unión de los dos procesos de autenticación para la misma identidad y me pide la contraseña que tiene la cuenta. Correcto. No la recuerdo, así que voy al proceso de recuperación de contraseña. Me manda el enlace de recuperación al correo de la cuenta de Google. Ojo que me lo envía a la dirección de correo con la que acabo de hacer login con Google, luego... ¿para qué? Si acabo de hacer login con Google, tengo acceso al Gmail del login de la cuenta, así que es un paso innecesario que no añade ninguna seguridad, pero para el sistema serán dos procesos independientes, y es el usuario el que se tiene que adaptar a la arquitectura y no al revés.

Da igual, sonrío, hago clic para cambiar la contraseña de la cuenta, pongo una y me dice... "No se puede cambiar la contraseña a esta cuenta". ¿Por qué? Pues porque en vez de mantener los dos autenticadores - con Google y por Usuario/Password, ha fusionado a un sólo autenticador, pero hasta que no introduzca la contraseña anterior - que no me deja cambiar - no puedo iniciar sesión. Conclusión "Deadlock" de libro por un mal diseño de seguridad. 

Después de dos días migrando cosas, aún me quedan un par de tarjetas bancarias que por motivos "corner case" aún no he conseguido migrar, y una cuenta de servicios de la empresa que por geo-location tampoco me permite procesar, pero más o menos lo tengo todo. Pero mientras pasaba por este proceso, me imaginaba a mi madre, y a muchas, muchas, muchas personas que tienen que pasar por aquí recordando que yo entiendo qué me están pidiendo, qué me está pasando, cuál es la situación en la que estoy en todo momento, pero que para ellas puede ser un dolor increíble.

La nueva "Simple" Televisión

Esta parte, que ha sido una de ellas, no ha sido la única experiencia que he tenido estas últimas 72 horas con esto, ya que además he querido cambiarle una televisión a mi madre para quitarle el descodificador y que solo tuviera un mando - de la SmartTV - y que no se confundiera. Al final, su problema consiste en que enciende la Televisión y el Descodificador y que si todo va bien, no hay problema, coge el mando del desco y cambia los canales y ve la tele - que es lo único que ella quiere -. Pero... si usa el mando de la SmartTV para subir o bajar canal, la SmartTV cambia el Source y se va a modo TV quitando el HDMI 1 de su fuente, y adios televisión. Y mi mamá, de 74 años, piensa que "ya se me ha ido la televisión".

Pues bien, le dije, ¨te voy a cambiar la televisión que está vieja, y te voy a poner la tele en una app y quitamos un mando del medio". Precioso decir, imposible para ella. Al final, encender la televisión y me pide una cuenta de la empresa de SmartTV que tengo que crear con un QRCode - imaginaos a una persona de 74 años ante eso -, después me pide que instale una app en el terminal, así que hay que usar las cuentas de Apple para ponerla en el iPhone, la instalas, te autenticas en la app con un correo y una password, te manda un SMS como 2FA, luego sigues un Wizzard de permisos para la app, y si quieres las noticias de la compañía de la televisión, las ofertas, los datos que le quieres dar de la app, y luego te pide el código que ves en la pantalla de la televisión de 14 dígitos, para darla de alta en tu app.

Y todo eso, en la primera pantalla de configuración de la SmartTV. 

Después de más de 20 pasos y una hora de configuración, con las ofertas de Amazon Prime gratis un mes, la de Apple TV, de quitar las apps de SmartThings para IoT, las autenticaciones en las diferentes apps, el inferfaz usa controles de usuario de tabs arriba, con líneas de vídeos y apps en un scroll infinito para abajo, y paneles que se expanden en los laterales. Así que me pongo con mi madre a enseñarle, y después de decirle 

"no, esa película no la puedes ver porque es de una promoción de un mes gratis de Apple TV y te lleva a esa app. Dale para atrás. Vaya, no sale. Pues dale al inicio. Ahora vete a la sección apps. Sí, tienes que bajar. Con las flechas. Ahora. Dale al ok. ¿El ok? Ah, espera, en este mando es distinto, el ok, es ese cuadrado con una flecha que sale de él. Sí, ahí. Ahora dale a la app. Sí, no te sale el canal que tenías antes, porque se personaliza con tus datos de navegación, así que hasta que no lo veas varias veces no te lo va a poner en su sitio, así que tienes que entrar en la guía. Es ese icono con unas rayas arriba a la izquierda. Sube con las flechas. Ahora entra, y sale la guía, ahora baja hasta que encuentres el canal. Sí, sigue bajando que hay cientos de canales. Ahora dale al ok. Sí esa es la ficha del canal. Dale al ok. No, que le has dado a la flecha y te has movido. Vuelve atrás. No, te has ido a la guía otra vez, era que movieras la flecha a la izquierda. No pasa nada vuelve a bajar. Sí, sé que son muchos... "

Pues bueno, le he quitado al nueva SmartTV, y le hemos puesto el sistema del desco (con una sola televisión) y al mando de la televisión anterior, para que no lo toque, Mi Survivor ha decidido ponerle celo a todos los botones menos al de encender y apagar, para que sepa que ese mando solo es para encender la televisión y nunca lo cambie de Source. Y no son pocos los que hacen eso.

Figura 3: Mandos "simples"

El MacBook Pro no arranca

Ya la última de las aventuras con la "shittización" de la tecnología, ha sido con mi MacBook Pro, que ha decidido no arrancar esta mañana - por eso estoy escribiendo el post tan tarde -. No tiene botón de hard-reset, la batería está cargando, pero no arranca. La última vez que me pasó eso, tuve que esperar dos días a que descargara toda la batería, y empezar de nuevo a cargarlo, y entonces funcionó, pero no tengo ni idea de qué le ha pasado. Tengo copia de seguridad de todo, así que no hay problema, pero tengo la seguridad de que si lo llevo a la tienda Apple me van a decir:

"Está roto, no se puede recuperar nada, compre otro". 

UPDATED: 20 horas después, se ha descargado y ha arrancado el MacBook Pro... otra vez como nuevo. Sin comprar ningún otro.

En resumen, menos mal que estoy al día de la tecnología y entiendo cómo funciona, entiendo qué está mal hecho en los sistemas, y al menos sé qué debo hacer para avanzar desde una situación a otra para conseguir arreglar el segundo paso, pero hablando de esto hace unos meses con un viejo colega de armas, sentados cómodamente, enumerábamos la cantidad de productos que eran fáciles, guays, sencillos y que se han "Shitted".

Unos meses después, os estoy escribiendo este artículo, porque cada vez vamos más rápido sacando tecnología, cada vez tiene menos QA, cada vez los UX son más "shitted" por permisos, seguridad, necesidades de negocio, etc... y hacen que las funciones core (como en el ejemplo de "ver la tele") estén cada vez más lejos de los usuarios. Recordad que os conté el lío que tuve con el bug de UX en WhatsApp solo por el tamaño de letra...

¿Tienes alguna experiencia similar? Déjamela en comentarios que me encantará leerla...

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo crear una aplicación y protegerse de ciberestafas con el API de SIM Swap

Si eres lector de este blog, seguramente ya habrás leído en más de una ocasión sobre Open Gateway y las enormes posibilidades que ofrece a los desarrolladores. Hoy quiero mostrar cómo crear una aplicación sencilla en Python para comprobar el estado de SIM Swap utilizando las APIs de Open Gateway y aprovechando el Sandbox de Telefónica para hacer pruebas sin riesgo.

Figura 1: Cómo crear una aplicación y protegerse

de ciberestafas con el API de  SIM Swap

¿Qué es SIM Swap?

Vamos a comenzar con una explicación de por qué esto es importante. SIM Swap es un evento de red que ayuda a detectar un tipo de ciberestafa en el que un atacante obtiene un duplicado de la tarjeta SIM de una víctima, mediante un engaño o una portabilidad entre empresas de telecomunicaciones fraudulenta, lo que le permite acceder a su línea de teléfono y recibir tanto llamadas de teléfono como mensajes SMS, lo que le da acceso a los códigos OTP de autenticación de segundo factor (2FA), o incluso realizar llamadas en nombre del usuario. 

Figura 2: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Esto facilita el acceso no autorizado a cuentas bancarias, redes sociales u otros servicios sensibles que utilizan el SMS o la llamada como validación de 2FA, además de poder suplantar a la víctima en llamadas de teléfono fraudulentas. 

Figura 3: API de SIM Swap en Telefónica

Con la API de SIM Swap de Open Gateway, podemos verificar si el número de teléfono de un usuario ha sido asociado recientemente a una nueva tarjeta SIM, lo que permite prevenir fraudes de manera más efectiva.

Sandbox de Telefónica Open Gateway

Antes de acceder a los datos reales, es fundamental probar la aplicación en un entorno seguro. Aquí es donde entra en juego el modo mock del Sandbox de Telefónica Open Gateway, un entorno de pruebas que simula el comportamiento real de la API sin comprometer datos de usuarios. Antes de empezar a programar, hay que dirigirse al sandbox para crear la aplicación. Aquí encontraremos las APIs disponibles con las que podemos trabajar, estando actualmente Device Location Verification, Device Status, Number Verification y SIM Swap.

Figura 4: APIs disponibles en el Sandbox de Telefónica Open Gateway

Para la demo, se va a hacer uso de la API de SIM Swap. Tras seleccionar esta API y darle al botón de crear aplicación, se encuentra un formulario para rellenar información sobre esta. Desde aquí se puede seleccionar el modo de trabajo (producción o mock), indicar el nombre que se le quiere asignar a la aplicación, la URL de redirección (si es necesario) y una pequeña descripción.

Figura 5: Formulario de creación de aplicación

El siguiente paso es para aceptar los términos y condiciones de uso.

Figura 6: Confirmación de los términos y condiciones

En el último paso se muestra un resumen con toda la información anterior y el botón para confirmar y terminar con creación de la aplicación.

Figura 7: Resumen de la aplicación y confirmación

Ahora, en el apartado de “Mis aplicaciones”, se puede ver la nueva aplicación creada, aunque podría estar pendiente de validación. 

Figura 8: Información de la aplicación creada

Desde aquí se puede conocer el identificador de la aplicación, así como el secreto que será necesario para autenticarse al realizar llamadas a la API.

Ejemplo de aplicación SIM Swap en Python

Para comenzar a crear la aplicación en Python se tienen dos opciones:

• Revisar la API e implementar todas las llamadas para conseguir la autorización y las llamadas a la API de SIM Swap usando alguna librería como puede ser requests.

• Hacer uso del SDK que está preparado para trabajar con el sandbox.

Esta última opción es el que se opta por utilizar en este ejemplo para agilizar la creación de la aplicación. Su instalación se puede hacer con pip, indicando el paquete opengateway-sandbox-sdk:

pip install opengateway-sandbox-sdk

Ahora, se crea un nuevo script de Python  y vamos a definir una función que, dado un número de teléfono, cree una instancia de Simswap con los datos de nuestra aplicación (Client ID y Client Secret que se encuentran en la información de nuestra aplicación creada en el sandbox), así como el número de teléfono (en formato E.164) que se desea consultar. 

Se ejecuta la función retrieve_date() para obtener la fecha del último cambio de emparejamiento MSISDN <-> IMSI, o lo que es lo mismo, la última vez que el número de teléfono (MSISDN) fue vinculado a una nueva tarjeta SIM (IMSI).

Figura 9: Función para obtener última fecha de cambio de SIM

Este sería el código más básico para poder hacer uso de SIM Swap a través del SDK. Vamos a ampliar un poco el código para poner validación del número de teléfono y que se pueda pasar un número de teléfono o un fichero con un listado de número a través de parámetros al iniciar el script. Creamos una nueva función que, pasado un número de teléfono, compruebe a través de una expresión regular que cumple con el formato E.164. 

<->

Figura 10: Función para validar que un

número está en formato internacional

<->
La expresión regular que aparece en re.compile(r"^\+[1-9]\d{9,14}$") está diseñada para validar números de teléfono en formato internacional. Veamos en que consiste cada parte:

• <->^: Marca el inicio de la cadena, asegurando que no haya caracteres antes del número.

• <->\+: Busca el símbolo "+" al principio del número, que es obligatorio en los formatos internacionales.

• <->[1-9]: Busca un dígito entre 1 y 9, lo que impide que el código de país comience con 0 (en números internacionales, los códigos de país nunca empiezan por cero).

• <->\d{9,14}: Busca entre 9 y 14 dígitos después del código de país, representando el número de teléfono.
• <->\d significa cualquier dígito (0-9).
• <->{9,14} especifica que debe haber un mínimo de 9 dígitos y un máximo de 14 después del código de país.

• <->$: Marca el final de la cadena, asegurando que no haya caracteres adicionales después del número.

En resumen, esta expresión regular valida un número de teléfono internacional que:

• <->Empieza con un símbolo +.
• <->Tiene un código de país que comienza con un dígito entre 1 y 9.
• <->El número de teléfono contiene entre 9 y 14 dígitos después del código de país.

Algunos ejemplo válidos para esto serían: “+34600123456” (España) o “+14155552671” (EE. UU.). Y un par de ejemplos de números no válidos podrían ser: “+0123456789” (el código de país no puede empezar con 0) o “34600123456” (falta el símbolo +).

Figura 11: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

<->Por último, realizamos la creación de una función principal. La función main() se encarga de gestionar los argumentos de la línea de comandos para que el usuario pueda verificar el estado de SIM Swap de uno o varios números de teléfono. Utiliza la librería argparse, que facilita la creación de interfaces de línea de comandos en Python. A través de esta función, el usuario puede proporcionar un número de teléfono individual utilizando la opción -p/--phone, o bien un archivo que contenga varios números de teléfono, uno por línea, con la opción -f/--file.

La función emplea un grupo de argumentos mutuamente excluyentes, lo que significa que el usuario debe elegir entre una de estas dos opciones, pero no ambas al mismo tiempo. Esto simplifica el manejo de los datos y asegura que la herramienta sea flexible pero a la vez fácil de usar. 

Figura 12: Función principal del programa

<->
Cuando se pasa un número de teléfono, este se valida usando la función phone_validator(), y, si todo va bien, se procesa con la función sim_swap(). Si se utiliza un archivo, la función intenta leer los números de teléfono línea por línea, y si encuentra algún error (como que el archivo no exista o no se pueda leer), gestiona las excepciones e informa al usuario. Esta estructura permite que la herramienta sea robusta y manejable, garantizando una buena experiencia de usuario con el manejo de errores y validaciones necesarias para evitar problemas.

Para finalizar se debería realizar la llamada a la función main(), algo que se puede integrar dentro del condicional if __name__ == “__main__": típico de Python. Sólo una cosa más, ¿recuerdas que en la llamada a SIM Swap había que indicar el Client ID y Client Secret? En el código mostrado anteriormente, estos valores aparecían en la función sim_swap() en las constantes CLIENT_ID y CLIENT_SECRET. 

<->

<->

Figura 13: Recuperando las credenciales desde el entorno

<->

<->Como se trata de valores que contienen información sensible, como buena práctica de programación, se recomienda leerlos del entorno. Para ello se puede hacer uso de la librería python-dotenv y almacenar las credenciales en un archivo .env que contiene las variables del entorno. 

<-> A continuación comparto un vídeo de ejemplo del uso de la API de SIM Swap donde puede apreciarse el código tanto haciendo uso directo de la API, como del SDK.

Figura 14: SIM Swap API vs SDK

Las APIs de Telefónica Open Gateway son una puerta abierta para que los desarrolladores puedan explorar nuevas formas de enriquecer sus aplicaciones con capacidades avanzadas, como el ejemplo visto con la detección de SIM Swap. El acceso a estos servicios no solo refuerza la seguridad de las aplicaciones, sino que también te permite crear experiencias más confiables para los usuarios.

Figura 15: APIs Open Gateway estandarizadas

Con el sandbox, tienes a tu disposición un entorno seguro para experimentar, probar e integrar estas funcionalidades en tiempo récord, sin necesidad de comprometer datos reales.  Si buscas llevar tus proyectos al siguiente nivel, esta es tu oportunidad, y puedes comenzar hoy mismo a experimentar con las APIs de Telefónica Open Gateway, explorar todo su potencial y transformar tus ideas en soluciones reales que impacten de forma positiva a miles de usuarios.

<->

<->Developer Hub

<->

Para que empecéis a experimentar, es necesario que os unáis al Developer Hub de Telefónica Open Gateway. La inscripción a este programa no tiene ningún coste, por lo que podréis disfrutar del Sandbox de forma gratuita. En la sección Technical Toolbox del área privada, una vez que os hayáis registrado y logado, encontraréis el acceso y, una vez dentro, lo primero que veréis es nuestro catálogo completo de APIs disponibles en el entorno de pruebas. 

Figura 16: Darte de alta en el Telefónica Open Gateway Developer Hub

Seleccionad aquella con la que queráis trabajar, añadid la información general de vuestra aplicación y elegid el modo que deseéis, ya sea de producción o mock, para empezar con vuestros desarrollos. Probad vuestros desarrollos con estas APIs para llevarlos al siguiente nivel de seguridad antifraude con OpenGateway.

Figura 17: Suscríbete a la newsletter de Telefónica Open Gateway

Y si quieres mantenerte informado con novedades en la iniciativa como más webinars sobre nuestras soluciones, lanzamientos comerciales o nuevas APIs disponibles, suscríbete a nuestra newsletter de Open Gateway.

Saludos y

Happy Coding!

Autor: Álvaro Núñez-Romero, investigador en el equipo de Ideas Locas. Autor del libro "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun" y del VBOOK de "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun"

Contactar con Álvaro Núñez-Romero

Cómo evitar que te roben las cuentas [y el dinero] de tu empresa con Geo-Fencing

El proyecto OpenGateway tiene APIs  que están siendo las más utilizada en casos de uso, especialmente para luchar contra el Fraude, y son Device Location Verification, SIM Swap, Device Status y Number Verify. Unas APIs de OpenGateway que permiten saber si un terminal móvil se encuentra en una determinada ubicación sí o no, si está en roaming, y qué número se encuentra en una determinada conexión de Internet móvil, además de si el número ha sido portado recientemente.

Figura 1: Cómo evitar que te roben las cuentas [y el dinero]

 de tu empresa con Geo-Fencing

Y como esto se hace desde la red, su información es oro puro para evitar el robo de cuentas, el robo de dinero mediante transferencias bancarias fraudulentas, o aplicar soluciones de Geo-Fencing.

APIS de Open Gateway para luchar contra el Fraude

El funcionamiento de Device Location Verification es bastante sencillo. Puedes preguntar por una tarjeta SIM en una determinada ubicación con un radio que permite gestionar el grado de protección de la privacidad que se quiere dar a una determinada persona. La gracia de esa información es que viene desde la red, y por tanto no se puede utilizar ningún Fake GPS para engañar al dispositivo y pretender estar en una ubicación en la que no está. Y con sólo eso, se pueden evitar muchos problemas de robo de cuentas y de transferencias fraudulentas haciendo Geo-Fencing.

Figura 2: API de Device Location Verification en Telefónica

En el caso de Number Verification, lo que sabemos es qué número de teléfono está detrás de una determinada conexión móvil, sabiendo si una determinada app está autenticada por la red con un número de teléfono móvil. 

Figura 3: API Number Verification en Telefónica

También tenemos SIM Swap, que permite saber si una determinada SIM ha cambiado de operadora por un proceso de portabilidad en las últimas horas, que es una práctica habitual de robo de tarjetas SIM.

Figura 5: API de SIM Swap en Telefónica

La última de ellas, Device Status, te permite saber si un terminal está en Roaming (fuera de su país) o no, así que preguntando a la red se puede saber si la persona está en su ubicación habitual o no.

Figura 6: API de Device Status en Telefónica

Haciendo un uso de esta información, es fácil saber si una cuenta ha sido robada o no, si una persona está haciendo las transferencias desde su ubicación habitual o autorizada, y dificultar en cualquier caso cualquier robo de cuenta.

Protección contra el robo de cuentas

Detectar que una cuenta ha podido ser robada, o evitar que lo sea, puede ser tan fácil como comprobar si la cuenta está iniciando sesión en la ubicación en la que normalmente inicia sesión desde el número de móvil del que normalmente lo hace. Y si no es así, bloquear el acceso, subir el nivel de riesgo, o bloquear determinadas opciones como el cambio de contraseña, el cambio de correo electrónico de recuperación, etcétera. 

Figura 7: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Solo con eso, ya se podrían evitar muchos problemas al no permitir que se modifiquen las opciones de seguridad importantes, como se está empezando a realizar ahora en las cuentas de AppleID o GoogleID para evitar que se robe una contraseña y se cambie todo el perfil de seguridad de una identidad. 

Protección contra transferencias fraudulentas

Esto es algo que están incorporando entidades bancarias, y es tan sencillo como que en el perfil de transferencia autorizada deba cumplir que:

• La tarjeta SIM del 2FA no ha sufrido SIM SWAP recientemente.
• La tarjeta SIM está en la ubicación autorizada (oficinas de la empresa)
• La app móvil del banco que autoriza el 2FA está conectada a la red móvil por el número de la SIM autorizada.

Number Verification no funciona en conexiones WiFi, y en ese caso habría que hacer una verificación de la SIM con un OTP vía SMS o usando Mobile Connect con SIM+PIN para ponerlo más difícil.

Device Location Verification y reducir la superficie de exposición con Geo-Fencing

En cualquier caso, poder preguntar a la red si una SIM está en una ubicación autorizada, como un país, una ciudad, o una zona en un radio concreto de una ubicación GPS y que no pueda ser falseada en el dispositivo reduce masivamente el fraude que viene desde cibercriminales remotos, ya que la transferencia está acotada a unas verificaciones de SIMs, de autenticaciones de red y de ubicaciones concretas.

Figura 8: Device_Location_Verification con un radio de 10Km en Madrid

En este ejemplo se ve como una SIM la tenemos acotada en Madrid. Reducimos el radio y acotamos la zona en la que la preguntamos, y de los cuatro posibles centros, la SIM se encuentra sólo en el que está pintado de verde.

Figura 9: Device_Location_Verification con un radio de 5Km.

Está en el círculo verde superior deecho.

Si seguimos reduciendo el radio - en este ejemplo lo hemos llevado a un círculo de 2Km -, vemos en qué zona de la ciudad está la SIM. Si la ubicación autorizada esta dentro de ese círculo, la app está conectada con el número de la SIM y no ha habido portabilidad recientemente, entonces se autoriza la transferencia, el login, o el cambio de opciones de seguridad, si no no.

Figura 10: Device_Location_Verification con un radio de 2Km.

Para hacer Geo-Fencing en una ubicación concreta.

Como podéis ver, aunque podrían existir esquemas de ataque más complejos, estas APIs ayudan a poner mucho más difícil cualquier intento de fraude remoto de cibercriminales, y por ello están siendo tan utilizadas por entidades bancarias hoy en día.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

WhatsApp y la desactivación de cuentas con un mensaje de e-mail

Hace un par de días publiqué en el blog el artículo de "WhatsApp: Cómo un atacante puede bloquear tu cuenta sin que la puedas desbloquear" escrito por Luis Márquez Carpintero y Ernesto Canales Pereña en el que se "weaponizan" dos características de seguridad de WhatsApp, para convertirlo en un ataque para la personas.

Figura 1: WhatsApp y la desactivación de cuentas con un mensaje de e-mail

Esto no es la primera que sucede, y es algo bastante más habitual de lo que las personas se pueden imaginar. En este tipo de escenarios, una medida de seguridad mal diseñada acaba convirtiéndose en un problema - en este caso de disponibilidad del servicio - para un usuario. Si quieres ver muchos ejemplos de esto, di una conferencia el año pasado sobre justo este tema que se llamaba "Weaponizing Features", donde explicaba muchos ejemplos de estas mismas características.

Figura 2: Conferencia de Weaponizing Features

En el caso concreto del bloqueo de la cuenta de WhatsApp, lo que hacen los investigadores es explotar o "weaponizar" de dos medidas de seguridad. Por un lado la de medida de seguridad que evita los ataques de fuerza bruta o adivinación de los códigos de activación de enviados por SMS, con una protección temporal para hacer inviable prácticamente en tiempo útil un ataque de esas características, y una segunda medida de protección - y esta es la más curiosa - por la que un usuario (cualquier) puede desactivar cualquier cuenta de WhatsApp, sea la suya o no, con un simple mensaje de correo electrónico.

Figura 3: Luis Márquez Carpintero, uno de los investigadores de este bug.

La explicación de cómo funciona este correo electrónico para desactivar una cuenta está en la web de WhtasApp, y existe para proteger la privacidad de un terminal ante robos o pérdidas de dirección de e-mail. Basta con que se envíe un mensaje de e-mail al la dirección de WhatsApp, y listo, la cuenta se desactiva.

La explicación de esta medida es fácil. Un usuario sufre el robo de su teléfono desbloqueado, y lo que debe hacer automáticamente es llamar para bloquear la SIM, urgentemente, y evitar así que se reciban llamadas o códigos de verificación por SMS, y luego pedir un cierre de sesión siguiendo el mecanismo antes explicado.

Figura 4: Cómo enviar el e-mail de desactivación de cuenta en WhatsApp

Lo que hace endiabladamente sutil y peligroso es esa regla de "usabilidad", por la que desde cualquier dirección de e-mail se pueda bloquear cualquier sesión en cualquier número de teléfono registrado en WhatsApp. Es verdad que, una dirección de e-mail solo puede usare una vez y para un solo número de teléfono, lo cual es un acierto como forma de mitigar un poco el ataque descrito en el artículo de hace dos días, con lo que una persona que quiera estar cerrando sesiones de WhatsApp debe estar creando mensajes de correo electrónico nuevos cada vez.

Figura 5: Sesión de WhatsApp cerrada por un e-mail

Por supuesto, esta medida es también fácilmente saltable para un atacante con hacer un poco de spoofing de e-mail, suplantando en cada petición una dirección de correo diferente, lo que la hace un poco inútil. Y es algo curioso, pues de nuevo, el correo electrónico - ese caos maravilloso que digo yo - se ha convertido no en un sistema de comunicación sino en algo más, que como ya explicaba en el artículo de "El e-mail ha muerto. ¡Larga vida al e-mail!", le hemos ido dando atribuciones más allá de la de ser un buzón de comunicación.

Llegados a este punto, lo que pasaba por mi cabeza durante el día de ayer, era... ¿cómo puede WhatsApp mitigar este ataque de una manera más racional? Pues usando características extras de protección a la cuenta y mitigación de weaponización.

Por ejemplo, si el usuario tiene un 2FA de WhatsApp asociado a un e-mail, que solo pueda ser desactivada la cuenta de esa dirección de e-mail. Esto dificultaría al atacante la explotación porque tendría que conocer y adivinar cuál es la dirección de e-mail configurada como 2FA. Cuando se configura ese 2FA ya se asocia, implícitamente, la seguridad de la cuenta a la seguridad del e-mail, y además es una solución bastante curiosa, porque realmente no es demasiado práctica si el e-mail está protegido por un 2FA basado en SMS, como os expliqué en el artículo de "WhatsApp y la paradoja de la SIM como Verificación en 1 paso", pero al menos sirve para eso, para asociar un e-mail a un cuenta de WhatsApp, que en este caso puede tener mucho sentido.

Figura 6: Configurar correo electrónico para recuperar el PIN
del 2FA en WhatsApp

Luego, se pueden buscar otras soluciones de mitigación, como por ejemplo hacer un desafío al e-mail para garantizar que no es un correo electrónico suplantado. Para ello, el proceso de desactivación debería ser en dos pasos. Paso uno, se pide la desactivación de la cuenta. WhatsApp genera un OTP y se lo devuelve por e-mail a la dirección de correo electrónico que pide la petición de desactivación. El solicitante de la desactivación envía la confirmación de la desativación con el OTP, para así garantizar que ese correo existe y no está suplantado. Esto reduciría la facilidad de "weaponización" de este ataque.

Y por supuesto, buscar otras soluciones por las que la re-activación no se pueda ver bloqueada por un esquema similar, dando al usuario alguna otra forma de reactivar la cuenta y evitar el bloqueo de los códigos de verificación de forma tan sencilla y automatizable. 

En cualquier caso, este es un ejemplo de una medida de seguridad que se convierte en un problema para la vida del usuario, no solo para su usabilidad, sino también para la disponibilidad, por lo que debe servirnos como ejemplo y muestra del cuidado que debemos tener en cada implementación de una nueva medida de seguridad, que nuestro objetivo es hacerle la vida más segura y fácil, y no nada de lo contrario.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso) (Consigue 100 Tempos gratis con ESET)

Chema Alonso en MyPublicInbox