Mostrando entradas con la etiqueta spoofing. Mostrar todas las entradas
Mostrando entradas con la etiqueta spoofing. Mostrar todas las entradas

jueves, abril 02, 2026

Cómo lograr el Check de Verified en LinkedIn con una Identidad Pública que no coincide con la Identidad Legal

Durante los últimos años, las redes sociales han ido incorporando sistemas de verificación con el objetivo de reforzar la confianza entre los usuarios. Estos sistemas consisten en un mecanismo mediante el cual la plataforma confirma que la persona o entidad que gestiona una cuenta es realmente quien dice ser. La recompensa visible para el usuario es una insignia, un pequeño icono —el conocido check— que, para muchos, simboliza autenticidad y fiabilidad.

Figura 1: Cómo lograr el Check de Verified en LinkedIn con una
Identidad Pública que no coincide con la Identidad Legal

En el caso de LinkedIn, esta insignia de verificación pretende indicar que un perfil pertenece a una persona real y que la información presentada coincide con su identidad profesional, pero hay que entender que no tiene por qué ser la información legal. A través de estos distintivos, la plataforma busca generar un entorno más seguro, donde los usuarios puedan interactuar con confianza, evitando suplantaciones y facilitando la creación de redes profesionales legítimas. Además, el sistema permite verificar no solo la identidad, sino también documentación, garantizando que determinada información que aparece en el currículo de la persona es correcto.

Sin embargo, esta lógica presenta un matiz a conocer. La verificación no siempre vincula de manera técnica y directa la identidad visible del perfil con la identidad que se ha validado internamente. Algo que hay que entender si te dedicas a la investigación de identidades en Internet. Es decir, un usuario podría mostrarse como verificado gracias al check, pero no existir una correspondencia completa entre los datos de la persona que aparece en el perfil y aquella que ha pasado el proceso de validación. 

La insignia ofrece cierta seguridad y confianza, pero no asegura la correspondencia absoluta entre la identidad verificada y la visible, por lo que debes conocer su funcionamiento correctamente para entender sus límites. En LinkedIn, un perfil verificado transmite una idea muy concreta, detrás de ese nombre hay una identidad confirmada, pero podría darse el caso que no fuera exactamente la visible, que es lo que la mayoría de usuarios interpreta sin pensarlo demasiado. 

 o que vas a ver a continuación no muestra una intrusión, ni una toma de cuenta, ni una vulnerabilidad técnica clásica. Muestra algo distinto, un flujo de verificación para reforzar la autenticidad del perfil, pero que deja que la identidad visible de una cuenta sea distinta de la identidad legal acreditada. Esto, si lo conoces, no tiene por qué ser malo. Muchas personas tienen nombres públicos que no son los que están en sus identidades legales, como Moxie Marlinkspike o Chema Alonso, pero aún así se puede verificar que son ellos. Moxie Marlinsspike protagonizo en un evento una anécdota que se hizo famosa cuando le pedían un ID con su nombre en un evento, y el dijo simplemente: "Google me", para que la persona que le registraba supiera que él era Moxie Marlinspike, - una identidad creada por él mismo - incluso si su identidad legal era otra.

Dicho de otra forma, el sistema comprueba que hay una persona real detrás - que ha hecho el proceso de Know Your Custormer -, pero el usuario final puede seguir sin saber quién es realmente esa persona . Cuando una insignia de verificación deja de responder a la pregunta “quién está detrás” y pasa a responder sólo a “hay alguien detrás”, el modelo de confianza debe ser otro. Es cierto que, si hay algún problema, la plataforma que ha verificado a esa cuenta, sabe quién está detrás de ella. Es decir, la identidad legal del que controla esa cuenta.

Lo curioso es que, de acuerdo con el flujo operativo descrito, ante una discrepancia, LinkedIn propone una salvaguarda consistente en mostrar el nombre oficial como complemento público en el perfil. Incluso llega a mostrar una vista previa en la que el alias, la insignia de verificación y el nombre legal aparecen conjuntamente, reforzando la transparencia y autenticidad del perfil. 

Sin embargo, esto no parece la mejor idea para perfiles que tienen una identidad pública bien reconocida que prefieren conservar la privacidad de su identidad legal. Como vamos a ver en esta demostración, aunque la intención declarada por LinkedIn en la ayuda es mostrar la identidad legal, el resultado operativo final, y el resultado finalmente visible demuestra que se puede ocultar la identidad legal, divergente con la identidad pública.


La prueba de concepto que sigue documenta precisamente eso. Cómo un perfil con un nombre divergente puede atravesar el proceso de verificación documental y biométrica, llegar hasta la fase en la que LinkedIn reconoce la discrepancia - y aunque promete transparencia -, terminar finalmente con la insignia añadida sin que se muestre tu identidad legal. Aunque hay discrepancia, la identidad legal no queda visible como complemento en el perfil. No se trata de una hipótesis. Se trata de una secuencia reproducida, documentada y observable. Vamos al grano.

1. Preparación de la cuenta y estado inicial

Qué se quiere demostrar con esta prueba de concepto:
  • Se parte de una cuenta con un nombre de perfil divergente respecto del nombre del documento.
  • El proceso de verificación documental y biométrica se completa correctamente.
  • LinkedIn detecta la discrepancia y ofrece una salvaguarda de transparencia.
  • La vista previa muestra que el nombre oficial aparecería entre paréntesis.
  • El resultado final observado es un perfil verificado con alias y sin nombre complementario visible.
La cuenta utilizada en la prueba muestra un nombre de perfil divergente, "El lado del mal", y en ese momento todavía no dispone de ninguna verificación añadida. 

Figura 4: Estado inicial de la cuenta: nombre de perfil divergente
y ausencia de verificación previa. 

Este punto es importante porque fija el estado previo. El alias visible, cuenta operativa y cero insignias activas.

2. Verificación documental y biométrica

El flujo de Persona valida la identidad de la persona real detrás de la cuenta. El material gráfico permite ver que el proceso pasa por el escaneo físico del documento, la comprobación biométrica y la validación final de identidad. 

Figura 5: Secuencia resumida del proceso de "Know Your Customer".
Escaneo del documento, verificación biométrica y validación positiva de identidad.

Para evitar exponer datos innecesarios, en esta versión se han omitido capturas donde aparecen campos documentales completos.

3. LinkedIn detecta la discrepancia y propone una salvaguarda

Una vez verificada la identidad real, LinkedIn no añade todavía la insignia. En ese punto aparece un mensaje explícito: el nombre del ID no coincide con el nombre del perfil y, como alternativa para poder verificar la identidad, se ofrece mostrar el nombre del documento oficial como complementario en el perfil.

Figura 6: Aviso de discrepancia de nombre y activación
de la salvaguarda propuesta por LinkedIn.

4. La propia plataforma enseña el resultado esperado

La siguiente pantalla es decisiva porque ya no es una interpretación del investigador. Es la propia plataforma la que muestra una vista previa de cómo debería quedar el perfil si se acepta la opción propuesta: alias visible, insignia de verificación y nombre oficial entre paréntesis como complemento público.

Figura 7: Vista previa del comportamiento esperado. El nombre oficial
aparece como complemento visible junto al alias.

5. Resultado final observado

Tras completar el flujo, la verificación queda añadida al perfil. No obstante, el resultado visible no coincide con la vista previa anterior, el perfil termina mostrando la insignia de verificación sobre el alias, pero sin el nombre oficial complementario que LinkedIn había presentado como mecanismo de transparencia.

Figura 8: Comparativa directa entre el resultado que LinkedIn
promete y el resultado finalmente observado en el perfil.

6. Interpretación técnica de la evidencia mostrada

La imagen documenta el estado final de la prueba de concepto y concentra, en una sola vista, el núcleo del fallo de lógica observado en el flujo de verificación de LinkedIn. Desde el punto de vista técnico, lo que se aprecia es la coexistencia de tres elementos que no deberían convivir de esta forma si la salvaguarda de transparencia se aplicara correctamente, según la ayuda de la plataforma.
  • Un nombre de perfil arbitrario o alias visible
  • Una insignia de verificación de identidad activa
  • La ausencia del nombre legal complementario que el propio flujo promete mostrar cuando detecta discrepancia entre identidad acreditada e identidad mostrada.
Figura 9: Resultado obtenido BYPASS Business Logic Error
 / Broken Identity Binding

Esto permite inferir que el proceso de validación documental y biométrica ha finalizado con éxito - se ha hecho el KYC,  el backend ha marcado la cuenta como verificada y tiene la documentación almacenada, pero que la capa de representación pública del perfil no está materializando de forma efectiva el mecanismo de unión entre identidad legal e identidad pública, que es algo que debes tener en cuenta.

Dicho de manera más precisa, la plataforma resuelve correctamente la pregunta “existe una persona real detrás de esta cuenta y sabemos quién es”, pero “la identidad pública que se muestra al resto de usuarios no tiene por qué ser la identidad legal que ha sido acreditada”.

Lo que se muestra no es una simple anomalía visual o un problema cosmético. Lo que refleja es una posible desincronización entre el estado de verificación concedido y la política de exposición del atributo de identidad complementaria descrito en la ayuda de Linkedin. En otras palabras, el sistema concede el distintivo sin hacer cumplir de manera consistente la condición de transparencia que él mismo presenta como alternativa cuando existe un desajuste de nombres, pero que por otro lado permite a las identidades públicas mantener la privacidad de sus identidades legales.

A nivel de lógica de negocio, esto encaja con un escenario de Broken Identity Binding, la identidad  legal validada existe, pero no queda correctamente enlazada con la identidad pública consumida por terceros. El resultado práctico es que el usuario que observa el perfil recibe una señal de autenticidad fuerte, pero que si carece del contexto mínimo necesario para interpretar correctamente qué ha sido verificado y bajo qué identidad, podría llevarle a confusión o error. 

7. Implicación de seguridad y abuso potencial de esta evidencia

En un sistema de verificación bien ligado, la insignia debería actuar como un atributo de confianza contextualizado. Es decir, no solo debería indicar que el proceso de validación ha sido superado, también debería permitir interpretar correctamente qué identidad ha quedado acreditada frente al resto de usuarios. Cuando esa unión falla, el distintivo conserva su fuerza visual, pero pierde precisión semántica. Es decir, podría parecer que la identidad legal es la que se ve públicamente es la misma - porque no aparece entre paréntesis otro nombre), sin ser así.

Eso abre la puerta a varios escenarios a tener en cuenta. Lógicamente, hay que pensar en la suplantación creíble con validación, ya que un actor podría construir un perfil con un alias, una identidad visual cuidada o incluso una identidad coincidente con la de un tercero, completar la verificación con su propia documentación legítima y terminar mostrando públicamente una cuenta que transmite autenticidad sin revelar el contexto real de la verificación. Para el observador externo, la insignia refuerza la apariencia, para el atacante, reduce el riesgo de ser detectado y aumenta credibilidad. Para limitar la suplantación de personas conocidas, por supuesto, Linkedin tiene los mecanismos de denuncia de suplantaciones, y por eso las empresas monitorizan las identidades de sus ejecutivos en la red para detectar estos posibles casos.

Hay que añadir que, además, en caso de que esta identidad fuera parte de un delito que se investigara, la plataforma podría entregar la documentación que usó la persona en el proceso de KYC, pero para engaños individuales a personas a través de redes sociales, podría dar a la identidad un halo de ser lo que se ve, cuando realmente es otra persona.

En este caso, el objetivo ya no es parecer una persona concreta, sino parecer una entidad fiable. Nombres como “Security Team”, “Compliance Department” o cualquier otra formulación institucional adquieren más potencia cuando van acompañados de una verificación activa. El problema no es solo el alias, también que el distintivo puede ser interpretado por la víctima como una validación indirecta del rol, del contexto o de la autoridad del emisor. Para ello hay que entender que las verificaciones pueden verificar también la documentación, pero puede ser que alguien verifique su identidad con este proceso, pero no verifique sus aptitudes, por lo que podría ser mintiendo en sus títulos y acreditaciones.

Cuando una plataforma proyecta una señal fuerte de autenticidad, terceros pueden usarla como referencia adicional en procesos de evaluación, contacto profesional, validación de antecedentes o interpretación pericial informal. Hay que entender bien los límites de la verificación, y si la identidad visible no queda unida con transparencia a la identidad legal acreditada - lo que podría ser una opción de privacidad - ,  y los que consumen estos límites no lo conocen, la plataforma introduce sin quererlo ruido precisamente en el punto donde debería reducirlo.

En otras palabras, el problema no está en que LinkedIn permita usar identidades públicas o alias. El problema aparece cuando el distintivo de verificación sigue actuando como una señal fuerte de identidad legal - tal y como dice en su ayuda - sin que el usuario pueda interpretarlo correctamente. Es decir, si la Verificación permite el uso de Identidades Públicas con privacidad de Identidades Legales, no debería decir que si hay discrepancia entre ellas mostrará las dos en la Verificación y luego que se pueda evitar eso.

Saludos,


martes, marzo 10, 2026

Fear of the Dark: Detección de Suplantación de Identidad y DeepFakes usando Verificación de Identidad en MyPubicInbox

Continuando la serie de Fear of the Dark, como parte de la presentación de RootedCON, sincronizamos la publicación de un servicio para Perfiles Públicos que llevaba tiempo con ganas de tener. Como os he contado muchas veces, me he topado con la experiencia de la suplantación de mi identidad muchas veces, y por eso quería tener una forma de solucionar esto, mediante una Verificación de Identidad explícita, en este caso, usando MyPublicInbox.
La idea es muy sencilla. Supongamos que tú estás por ahí en las redes, y supuestamente te has topado conmigo, con Chema Alonso en un foro, en un canal de chat, o alguien que has encontrado te ha dicho que yo es mi amigo y que yo hago trabajos de hacking, que invierto en nosequé, o que yo estoy detrás de algo, y entonces un día tienes un chat o una vídeo conferencia "conmigo"... 

Ya te digo yo que seguramente sea un Suplantación de Identidad y puede que estén usando una DeepFake, así que, sencillo. te vas a mi perfil en MyPublicInbox, y solicitas una Verificación de Identidad, que de momento es un servicio gratuito para todos los usuarios de MyPublicInbox.
Desde ahí puedes enviar una evidencia, mediante una captura de pantalla, junto con una descripción de dónde supuestamente estás teniendo una reunión virtual conmigo, un chat, o una conversación. Si estás teniendo esa supuesta reunión conmigo, puedes "decirme" que quieres Verificar Mi Identidad sin ningún problema, que yo pasaré este proceso contigo.
Esto generará una Petición de Verificación de Identidad que me entrará en Mi buzón de MyPublicInbox para que pueda revisarla, con toda la información que me has enviado. Solo tengo que ir a la sección de Verificación de Identidad y tendré en la zona de Verificar Identidad la petición.
Y ahora, pues con pulsar en Revisar tendré acceso a los detalles que me hayas proporcionado, con la captura de la imagen por delante, así que puedo ver si es una conversación mía de verdad o no. En este caso, para la demostración he subido una fotografía mía, pero lo suyo es subir la captura de una vídeo conferencia o del chat, o de lo que sea que se supone que soy yo.
Y como yo soy yo, y sé si yo estoy haciendo ese chat, esa vídeo conferencia, esa reunión virtual o tengo esa cuenta en ese supuesto foro, pues daré a Rechazar o Verificar, con lo que generará un PDF con los datos del proceso de la Verificación o la No Verificación.
El documento son unas páginas donde se detallan los datos de la petición, los datos de las fechas, y que ha pasado por los servidores de MyPublicInbox, que el usuario concreto que recibió la petición la revisó y dijo que sí, que era él, o que no, que no era él.
La única Verificación de Identidad que utilizamos ahora mismo es la del dueño de la cuenta, que sabe si él está o no está teniendo esa reunión o no. Es como si me llamara un amigo y me dijera: 

"Oye Chema, ¿eres tú el que está ahora en el foto de XXXX diciendo esas cosas?" 

Y yo le confirmará que sí o que no. Lo que me ayudará a mí a saber dónde me están suplantando la identidad y a él a protegerse contra una estafa.
Para configurar esto este servicio en MyPublicInbox, si eres un Perfil Público, puedes activarlo en el menú de tu cuenta de MyPublicInbox en la sección de Verificación de Identidad - Configurar Verificación. En el siguiente vídeo tienes una demostración de proceso completo.
Al final, a pesar de que sea un servicio dependiente de una identidad en Internet - la de MyPublicInbox - ya obliga a los ciberestafadores a primero tener que robar la cuenta de MyPublicInbox, y luego a hacer la DeepFake o la suplantación, por lo que es una protección más antes de enviar dinero, o hacer cualquier tontería. 
Y por supuesto, desde MyPublicInbox monitorizamos el uso de este servicio para detectar situaciones de fraude, que además de mucha víctima, también hay mucha ciberestafa, por lo que la monitorización constante es clave siempre.
¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


martes, febrero 03, 2026

Quantum GPS: Navegación con GPS cuánticos para evitar ataques de Jamming & Spoofing

Todos damos por hecho el punto azul en el mapa de nuestro móvil. Desde pedir un taxi hasta guiar un misil, la civilización en nuestro tiempo ha delegado el sentido de la orientación en una constelación de satélites que orbitan a 20.000 kilómetros de altura: el GPS. Pero, ¿y si te dijera que el talón de Aquiles de los ejércitos modernos es precisamente esa dependencia? Este escenario es el que analiza en profundidad el artículo del MIT Technology Review titulado ”Navegación cuántica para evitar los ataques al GPS militar”, una lectura que os recomiendo encarecidamente para entender el contexto geopolítico actual.

El texto pone de manifiesto una realidad alarmante: en septiembre de 2025, un avión militar español en ruta hacia Lituania sufrió un ataque mediante transmisiones de radio diseñadas para bloquear su sistema de navegación. Aunque el incidente no terminó en tragedia, la preocupación es mayúscula. 

No se trata de un hecho aislado, sino de un ejemplo más en una lista de miles de afectaciones registradas desde la invasión de Ucrania en 2022, parte de una amplia campaña de interferencias electrónicas (principalmente rusas). Técnicas muy conocidas de un mundo en ciberguerra.


La vulnerabilidad reside en la física básica: las señales GPS, tras viajar miles de kilómetros desde el espacio, llegan a la Tierra con una potencia extremadamente baja, similar a un susurro. 

El problema: Navegar a ciegas

Esto las hace presas fáciles del Jamming (bloqueo por ruido) o, lo que es peor, del GPS Spoofing (falsificación). En este último caso, un barco podría creer que navega en aguas internacionales cuando, en realidad, ha sido desviado sutilmente hacia territorio enemigo. Cuando falla el GPS, los vehículos militares recurren a ”sistemas inerciales”, y a las clásicas brújulas y acelerómetros. Sin embargo, estos sistemas tienen un enemigo mortal: la deriva.


Como ya analizamos en el artículo sobre Sensores Cuánticos (Quantum Sensors), los sensores clásicos sufren ”ruido” térmico e imperfecciones mecánicas. Un error de cálculo minúsculo al inicio se convierte en una desviación de kilómetros tras una hora de vuelo. Es el equivalente a intentar caminar en línea recta con los ojos vendados: inevitablemente, acabarás torciéndote.

Figura 5: Esquema de los problemas y su solución con la navegación cuántica

La solución no es lanzar más satélites, sino dejar de mirar hacia arriba y empezar a mirar hacia abajo (o hacia dentro). Aquí es donde la física cuántica viene al rescate para crear lo que podríamos llamar la ”Brújula Inhackeable”.

Solución 1: El mapa imborrable de la Tierra

Imaginad que cada metro cuadrado del planeta tuviera una huella dactilar única. De hecho, la tiene: la corteza terrestre emite anomalías magnéticas sutiles que forman un mapa fijo e inalterable. Para leer este mapa no nos sirve una brújula convencional; necesitamos una sensibilidad extrema. Aquí entran en juego los diamantes cuánticos. Los científicos crean un defecto intencionado en la estructura del diamante, reemplazando átomos de carbono por nitrógeno y dejando un hueco conocido como ”vacante”. 
El funcionamiento detallado de estas brújulas cuánticas de diamante ya lo tratamos en el blog en el artículo ”Quantum Sensors: Cuandolo invisible se hace visible”, por lo que os invito a releerlo si queréis profundizar en este tema. Con esta tecnología, el avión ya no necesita preguntar al satélite ”¿dónde estoy?”. Simplemente ”mira” hacia abajo, lee la huella magnética de la Tierra y la compara con un mapa almacenado a bordo. No hay señal que bloquear, porque la Tierra no se puede apagar.

Solución 2: Rastreo del movimiento de forma precisa

Se trata de una aproximación conceptualmente muy sencilla, recuerda al típico problema de matemáticas que nos ponían en el instituto con los trenes. Si conocemos nuestra posición inicial, velocidad, dirección y tiempo transcurrido, deberíamos ser capaces de calcular nuestra posición actual con exactitud matemática.

Este concepto, denominado formalmente navegación inercial, ha sido difícil de perfeccionar en la práctica. ¿El motivo? No teníamos sensores lo suficientemente estables. Cualquier incertidumbre, por pequeña que sea, se acumula exponencialmente. Los mejores dispositivos inerciales clásicos pueden desviarse hasta 20 km tras 100 horas de viaje. Sería como tener un reloj que se atrasa un minuto al mes; al cabo de un año, viviríamos en un huso horario de casi un cuarto de hora distinto al del resto del planeta.

Esta desincronización es inadmisible para la aviación. Aquí regresa la cuántica. Tal y comovimos al hablar de interferometría, podemos usar átomos fríos para realizar medidas con muchísima más precisión y libres de ruido. Recordad el ejemplo de los ”dos senderistas” cuánticos que recorren caminos distintos para medir diferencias sutiles. Esto es lo que precisamente ha hecho la empresa Inflection y que lo han probado ya en un avión adaptado en un centro de ensayos militar británico.


Además, para lograr una precisión en el tiempo absoluta, el sistema se apoya en un reloj óptico que, textualmente, ”pierde un segundo cada 2 millones de años”. Ya hemos hablado de la fascinante precisión de los relojes atómicos en el artículo de "Un Reloj Atómico Óptico del MIT con Optimización Cuántica para medir el Tiempo del Futuro", pero el hito de esta compañía es haber conseguido que funcionen en un entorno tan hostil y vibrante como el interior de un avión en vuelo.

Solución 3: Corrección mediante software

Existe una tercera y última vía, empleada por empresas como Q-CTRL. Su enfoque consiste en utilizar sensores cuánticos que, aunque pueden ser ”ruidosos” por sí mismos, se vuelven extremadamente robustos gracias a algoritmos de Machine Learning.

Figura 9: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Para que esto funcione, el sistema debe entrenarse en condiciones reales. Q-CTRL equipó una avioneta Cessna y tomó datos durante un año entero. Este banco de información es vital para enseñar a la Inteligencia Artificial a separar la señal útil del ruido ambiental (vibraciones del motor, turbulencias, etcétera). 

El resultado es impresionante, logrando precisiones hasta 94 veces superiores a las de un sistema inercial convencional.

Conclusión

La tecnología que se describen en los papers académicos ya se está probando en el mundo real para evitar ataques al GPS militar. Estamos pasando de una navegación ”conectada” (dependiente de satélites vulnerables) a una navegación autónoma y pasiva. Los sensores cuánticos no emiten señales, no se pueden hackear y no necesitan mirar al cielo. 

En el futuro, perder la cobertura no significará perderse. Simplemente, dejaremos de depender de las estrellas artificiales para confiar en la certeza inmutable de los átomos. Si te gustan estos temas de Quantum Security, puedes participar, comentar y aprender en el Foro de Quantum Security al que puedes conectarte con tu cuenta de MyPublicInbox. Primero inicia sesión con tu cuenta de MyPublicInbox, y luego visita este enlace para poder entrar en el foro.

Además, aquí te dejo todos los artículos que he publicado en este blog sobre estos temas por si quieres leer con calma todo. 
Espero que estos temas te estimulen a ir haciendo cada día más cosas con las tecnologías alrededor del mundo cuántico, porque cada día vamos a ver nuevos avances al respecto. 

jueves, agosto 26, 2021

On-the-fly: Una nueva herramienta para auditar redes TI, IoT & ICS

En el equipo de Ideas Locas tenemos algunas sorpresas para estas semanas. Una de ellas es la publicación de una nueva herramienta denominada on-the-fly, la cual ya está disponible en su Github. Pronto anunciaremos algo más sobre un par de herramientas y algunos sitios donde se podrán ver y donde realmente se darán a conocer. 

Figura 1: On-the-fly. Una nueva herramienta para auditar redes TI, IoT & ICS

Hoy queremos hablar del trabajo que ha sido sacar esta herramienta. La idea es proporciona una herramienta modular que permita al usuario ir configurando módulos que permitan realizar ataques de redes tanto en el mundo TI, IoT o ICS.
Algo que se debe tener claro es que la utilización de diferentes tecnologías entre estos dispositivos que nos rodean hace que la seguridad sea heterogénea. Cuando se afronta un Ethical Hacking en cualquier entorno, uno de los factores importantes es la red. La red conecta el mundo del Internet de las cosas, el mundo de los sistemas de control industrial y el mundo de las tecnologías de la información.

Figura 3: Libro de Ethical Hacking 2ª Edición

La irrupción del paradigma IoT, la conectividad del mundo OT / ICS y el crecimiento exponencial del mundo TI hacen que el pentester requiera conocer todos estos espacios para poder trabajar acorde a lo necesario. Una herramienta que centraliza diferentes técnicas de evaluación de vulnerabilidades o debilidades en una red es un concepto interesante. Dándole el concepto de modular se consigue lograr varias cosas:

1. Que cualquier usuario de la comunidad (hay que recordar que la herramienta es Open Source) puede colaborar y ampliar las posibilidades de ésta, gracias a la implementación de un módulo. 
 
2. Disponer de diferentes técnicas modernas para llevar a cabo este tipo de evaluación y que fácilmente sea ampliable. 
 
3. Lectura y entendimiento sencilla para poder implementar módulos y compartirlos con la comunidad.

Según podemos encontrar en el artículo de presentación de la herramienta: 

“La herramienta ‘on-the-fly’ es un framework que proporciona funcionalidades para llevar a cabo tareas de pentesting en redes de datos en entornos IoT, ICS y TI. La herramienta permite ejecutar diferentes acciones de forma simultánea y de forma modular, simplificando el encadenamiento de acciones y otorgando la posibilidad de realizar diferentes ataques simultáneos.”


‘on-the-fly’ tiene una arquitectura modular y dispone de más de 40 módulos con funcionalidades para el pentesting en entornos IoT, ICS & TI. Esto es algo interesante, ya que cualquier usuario podría ampliar la base de conocimiento de la herramienta. La arquitectura de la herramienta es la siguiente:

Figura 5: Arquitectura de "on the fly"

A continuación se enumeran los tipos de módulos principales:

Figura 6: Módulos de 'on-the-fly'

- Discovery: En este tipo de módulos se pueden encontrar funcionalidades para descubrir diferentes tipos de servicios y máquinas. Se utilizan diferentes protocolos: Modbus para descubrimiento ICS, TCP para descubrimiento de servicios y máquinas, MDNS y SSDP, etcétera.

- Manipulation: Este tipo de módulos permiten manipular ‘al vuelo’ (on-the-fly) el tráfico que pasa a través de la máquina. Son módulos especializados en cambiar valores que pueden observarse y manipularse. Permiten obtener ventaja, por ejemplo, manipulando las consultas a una base de datos y consiguiendo acceso.
 
- Server: Este tipo de módulos proporcionan al pentester la posibilidad de levanar un servicio o servidor y disponer de un servicio fake sobre SSDP, MQTT o DNS, por ejemplo.

- Spoof: Este tipo de módulo permite llevar a cabo ataques de spoofing entre diferentes máquinas. Por ejemplo, se puede hacer los clásicos ARP Spoofing, DNS Spoofing o NTP Spoofing, pero también ataques de spoofing en COAP y MQTT (IoT) y en Modbus (ICS).

- Pivot: Este tipo de módulo permite utilizar ‘on-the-fly’ como herramienta para pivotar en un pentest. Permite utilizar SOCKS4 y un port-forwarding sobre TCP para redirigir el tráfico. Una funcionalidad necesaria para el pentester.

- Sniffer: Este tipo de módulo permite llevar a cabo un ‘sniffing’ de paquetes. Hay módulos que vienen preparados para ‘sniffar’ tráfico concreto, y otros módulos permiten configurar qué se quiere sniffar, cómo y dónde almacenarlo.

- Examples: Este tipo de módulo muestra ejemplos de implementación de un módulo. Esto sirve para que un usuario pueda crear de manera sencilla su propio módulo con la funcionalidad que quiera.

Los comandos disponibles en la herramienta ‘on-the-fly’ son los siguientes que puedes ver en la siguiente captura. De ellos, el comando jobs muestra los módulos que generan ‘hilos’ y están en ejecución. Desde este comando podemos ‘terminar’ un módulo cuando se quiera. ‘on-the-fly’ tiene un sistema de gestión de hilos interno para poder ejecutar en background cualquier trabajo y poder finalizarlo cuando el usuario lo requiera.

Figura 7: Comandos de 'on-the-fly'

Esta funcionalidad es la que permite poder cargar diferentes módulos para un ataque de red y poder juntar funcionalidades a través del uso de hilos. La gestión se lleva a cabo a través del comando Jobs.

Figura 8: Descripción de los comandos de 'on-the-fly'

Próximamente hablaremos de cómo hacer un módulo en on-the-fly o ver algunas de las funcionalidades interesantes que podemos encontrar. Es un proyecto en fabricación y que ha visto la luz recientemente. Todos los comentarios de mejora serán bienvenidos. Hay mucho más detalle en su repositorio de Github. Para finalizar, os dejamos con los siguientes vídeos donde se puede ver un ataque de SSDP fake, engañando a los dispositivos de la red tal como se puede ver en el artículo sobre EvilSSDP.
 

Figura 9: Ataque SSDP Fake

Por otro lado, os dejamos un ejemplo de spoofing en Modbus.

Figura 10: Demo de Spoofing de Modbus con 'on-the-fly'

Han sido meses de ir haciendo poco a poco la herramienta, pensar los módulos e ir añadiendo funcionalidades. Todavía queda camino, ya que el proyecto puede acabar con un gran número de implementaciones. Gracias a todos los miembros del equipo que han ido participando en el proyecto. Casi todos hemos pasado por la herramienta para aportar nuestro granito de arena. Pronto más noticias :)

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

jueves, abril 15, 2021

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.
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.
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.

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares