Recientemente identificamos una vulnerabilidad en una interfaz de programación de aplicaciones (API) perteneciente a Abib, un Operador Móvil Virtual (OMV). La falla permite consultar información de usuarios sin necesidad de autenticarse.
Por razones evidentes, no publicaremos aquí la dirección exacta ni instrucciones que permitan reproducir la vulnerabilidad.
El problema corresponde a lo que en ciberseguridad conocemos como IDOR (Insecure Direct Object Reference). Explicado sin tecnicismos: un sistema permite solicitar información utilizando un identificador —en este caso, un número telefónico—, pero no comprueba adecuadamente si quien realiza la consulta tiene autorización para acceder a esos datos.
En nuestras pruebas encontramos una ruta de la API accesible públicamente que permite proporcionar un número perteneciente al operador. Cuando esa línea ha realizado, o aparentemente intentado realizar, el proceso de vinculación con una CURP, el servidor devuelve información relacionada con la persona.
No fue necesario iniciar sesión.
No fue necesario proporcionar una contraseña.
El servidor simplemente respondía.
¿De cuántas personas estamos hablando?
De acuerdo con la información que pudimos analizar, Abib tendría aproximadamente 429 mil líneas telefónicas asignadas, aunque alrededor de 31 mil estarían activas.
Dentro de este universo logramos identificar 13,717 registros correspondientes a personas que realizaron o intentaron realizar el proceso de vinculación de su línea con una CURP.
La cifra es importante, pero el verdadero problema no está solamente en cuántos registros pueden consultarse.
Está en lo que demuestra.
Desde que comenzó la discusión sobre la vinculación obligatoria de líneas telefónicas hemos advertido que asociar un número celular con la identidad de una persona transforma ese número en un dato mucho más sensible.
Antes podíamos discutirlo como un riesgo hipotético. Casos como éste permiten observar cómo puede materializarse.
El problema no necesariamente es la base central
Cuando hablamos de seguridad de estos sistemas solemos imaginar una enorme base de datos gubernamental que algún atacante intentará vulnerar.
Pero el riesgo puede aparecer mucho antes.
Cada operador necesita sistemas para registrar usuarios, consultar información, validar procesos y atender solicitudes. Esos sistemas utilizan servidores, bases de datos, aplicaciones y APIs. Basta que uno de esos componentes esté mal configurado para abrir una puerta que nunca debió existir.
Y esto cambia considerablemente la discusión.
La pregunta ya no puede limitarse a “¿la plataforma oficial es segura?”.
También tenemos que preguntar quién almacena los datos, qué proveedores tienen acceso, qué APIs los consultan, cómo se autentican esas consultas, cuánto tiempo se conserva la información y qué controles existen para detectar accesos masivos o anómalos.
La seguridad de todo el sistema termina dependiendo también de su eslabón más débil.
Una vulnerabilidad sencilla, consecuencias importantes
Lo preocupante de una vulnerabilidad IDOR es que técnicamente puede parecer algo trivial.
No requiere necesariamente romper cifrados, instalar malware o comprometer servidores. El problema está en la lógica de autorización de la aplicación: el sistema entrega información que nunca debió entregar a esa persona.
Por eso las APIs expuestas públicamente deben diseñarse bajo una premisa básica: conocer un identificador no significa estar autorizado para consultar lo que existe detrás de él.
Un número telefónico no debería funcionar como llave para acceder a información personal.
Mucho menos cuando ese número ha sido relacionado con información de identidad.
Esto apenas comienza
La intención de señalar esta vulnerabilidad no es demostrar que todos los sistemas de vinculación de líneas sean inseguros ni afirmar que inevitablemente ocurrirá una filtración masiva.
Sería irresponsable hacerlo.
Pero también sería irresponsable ignorar una evidencia concreta cuando aparece.
Durante meses la discusión pública se ha concentrado en si los ciudadanos deben entregar sus datos para conservar una línea telefónica. Se ha hablado mucho menos de lo que ocurre después con esa información.
¿Quién la protege?
¿Quién audita las implementaciones de los operadores?
¿Existen estándares mínimos de seguridad?
¿Se realizan pruebas antes de poner estos sistemas en producción?
¿Y qué sucede cuando un investigador encuentra una vulnerabilidad como ésta?
Porque obligar a millones de personas a vincular su identidad con un número telefónico también genera una responsabilidad: proteger correctamente esa relación durante todo su ciclo de vida.
El ciudadano ya cumplió entregando sus datos.
Ahora corresponde demostrar que quienes los reciben realmente están preparados para protegerlos.