Apple arregla el AirPod "Spy" añadiendo alertas de seguridad y permitiendo Find My por Internet

Cuando me compré los AirPods de Apple había algo que no tenía sentido. Cualquiera podía parearse unos AirPods sin que el dueño lo supiera, y encima si los AirPods no estaban en el alcance de una conexión BlueTooth no te aparecían en Find My, con lo que se había quedado a medias el diseño de seguridad de estos dispositivos.

Figura 1: Apple arregla el AirPod "Spy" añadiendo alertas de 

seguridad y permitiendo Find My por Internet

Primero, alguien podía controlarte en la proximidad, y segundo, si los perdías no podías recuperarlos porque en la distancia no te decía quién los había pareado. Por supuesto, yo que soy un amante del Hacking iOS tanto de iPhone como de iPad, me puse a jugar con ellos a ver qué salía.

Figura 2: Libro de Hacking iOS:iPhone & iPad (2ª Edición) en 0xWord de
Chema Alonso, Ioseba Palop, Pablo González y Alejandro Ramos entre otros.

Escribí primero un artículo titulado "AirPods Pro: Unas pruebas en casa de Safety & Security" donde hablé de las cosas que se podían hacer con ellos y las que no. Y luego escribí el artículo de este blog llamado AirPodSpy, donde hablaba de los problemas de privacidad de esta forma de funcionar, que podéis ver aquí.

Figura 3: Peticiones de mejora a Apple para evitar el AirPodSpy

Y es de agradecer que, a pesar de que algunos decían que eso no era un problema de seguridad y privacidad, Apple decidiera arreglar estas dos características que podrían llevar a una persona a que le robaran sus AirPods al mismo tiempo que perdía algo de privacidad al poder ser controlado en distancia de Bluetooth,

Figura 4: Alerta de que te están viendo ahora.

Hoy en día Apple avisa cuando una persona, que no es el dueño, se ha pareado un dispositivo, para que sea consciente de que alguien puede saber dónde estás en todo momento, lo que ayuda a desincentivar el robo de dispositivos AirPods Pro, ya que se puede saber quién los tiene. Y por otro lado, ayuda a que una persona sepa que alguien se ha pareado los dispositivos AirPods Pro y que puede estar siendo vigilado, lo que resuelve los dos problemas de los que hablé en el artículo original.

Figura 5: Alerta de que usar estos AirPods informa de

 tu ubicación a otro AppleID

Al final, este tipo de decisiones de usabilidad, donde se intenta evitar dar demasiadas alertas a los usuarios, pueden llevar a problemas, como sucedió con el caso de DirtyTooth, donde después de demostrar cuál era el riesgo, Apple decidió poner la alerta de sincronización de contactos, tal y como sugerimos.

Figura 6: Apple pide confirmación para permitir a
un perfil BlueTooth acceder a los contactos

En cualquier caso, muy contentos de que Apple haya mejorado la seguridad de los dispositivos que utilizamos todos los días, porque al final, lo importante es eso. Tecnología que nos haga la vida más cómoda y feliz sin meternos en problemas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

RFC 9116: Llegó el estándar de Security.TXT, la evolución de aquel Hackers.TXT

Era el año 2011 cuando yo pedía que las webs tuvieran un fichero Hackers.TXT para que los investigadores supieran cómo y de qué manera tenían que reportar las vulnerabilidades de las webs de las empresas sin meterse en ningún lío, y hacerlo además de forma responsable. Que pudieran saber si hay un Bug Bounty, si hay canales especiales, si hay que utilizar determinadas claves de cifrado, etcétera.

Figura 1: RFC 9116: Llegó el estándar de Security.TXT,

la evolución de aquel Hackers.TXT

Aquella petición que yo hice generó un hilo de debate en muchos sitios, como en Stack Overflow [hackers.txt], donde la gente preguntaba por cuál era la definición de ese fichero, si existía algún formato en concreto, o alguna ubicación en detalle donde buscarlo en una web.

Figura 2: Petición de definición de hackers.txt

En 2013 ese movimiento creció, y más gente pidió que se estandarizase, al mismo tiempo que crecía el interés por la profesión de capturar Bug Bounties, es decir, ser un Cazador de Recompensas en busca de bugs que sean pagados.

Figura 3: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

Pero no fue hasta el año 2017 que apareció la idea de Security.TXT como una evolución para estandarizar ese fichero para hablar con los Security Researchers directamente desde la web. Para ello se creó en el IETF un grupo de trabajo para ver cómo dar formato a esta idea. 

Figura 4: Draft para Security.TXT

El resultado de ese trabajo ha sido el RFC9116, que como bien indica es un Formato de fichero para ayudar en la revelación de vulnerabilidades, que a partir de ahora podrá ser utilizado por todos los equipos de seguridad como parte de su política de seguridad en la web. Que podrá ser leído de forma automática por las herramientas de pentesting, y que ayudará en su trabajo a los Security Researchers.

Figura 5: RFC 9116

El formato es bastante sencillo, en modo TXT, y con una forma de localizarlo bastante sencilla. En lugar de estar en la raíz, va a estar situado en .well-known/security.txt, por lo que es ahí donde deberán mirar tus herramientas ahora mismo.

Figura 6: Ubicación oficial de security.txt

Además, se podrá indicar la forma de contactar con los equipos de seguridad, tanto con direcciones de correo, números de teléfono o con webs de información extendida que puedan llevar a otros canales, con protocolos de comunicación, etcétera.

Figura 7: Información de contacto para reportar bugs

Y si hay métodos de comunicación cifrada, para proteger la información que pueda estar enviado el Security Researcher, también se podrán publicar o indicar dónde se encuentran disponibles, en caso de que estén en servidores DNS, por ejemplo.

Figura 8: Ejemplos de comunicación de claves de cifrado

Por supuesto, si se quiere dar reconocimiento a los Security Researchers, también se puede utilizar para tener un Hall of Fame. A mí siempre me alegró cuando Microsoft, Google, WhatsApp o Apple nos reconocían el reporte de los bugs, incluso sin que hubiera una recompensa, así que es una buena idea que esté estandarizado también esa parte.

Figura 9: Configuración del Hall of Fame

El formato de fichero quedaría por tanto, más o menos, como este ejemplo que tenéis aquí, donde se han configurado algunos de los parámetros que se pueden incluir de una manera normalizada. No son obligatorio ninguno, así que es simplemente para que si tu empresa tiene una política de cómo relacionarse con Security Researchers, Hackers y Bug Bountiers, la puedas comunicar.

Figura 10: Ejemplo de un fichero de Security.txt "compliance"

Así que, al final, aquella idea loca de Hackers.TXT se ha llevado a un final a término. Han sido muchos años, pero si gracias a este fichero los hackers saben si una web tiene un Bug Bounty, o es "Hacker Friendly" o por el contrario es peligroso jugar con ella, se habrá conseguido arreglar posibles problemas a los Security Researchers, así que, happy++.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cervantes: Una nueva herramienta para hacer tus pentests más fáciles

Desde que la tecnología ha ido inundando nuestras vidas, la ciberseguridad se ha vuelto algo esencial para proteger nuestra privacidad y nuestros datos. Para ello la Seguridad Ofensiva o el Pentesting se ha vuelto una de las piezas principales en los últimos años y cada toma más presencia como requerimiento en muchos estándares o normativas de seguridad de cualquier organización.

Figura 1: Cervantes: Una nueva herramienta para hacer tus pentests más fáciles

Al final un Ethical Hacking no es más que un ataque “autorizado y controlado” sobre uno o varios sistemas informáticos de una empresa. Este proceso es realizado para identificar vulnerabilidades, así́ como los puntos fuertes, lo que permite completar una evaluación de riesgos, y existen prácticas para su realización, procedimentadas y faseadas, que los profesionales de esta disciplina conocen perfectamente.

Figura 2: Libro de Ethical Hacking 2ª Edición  de 0xWord
escrito por Pablo González Pérez

Por supuesto, la organización de la información de un pentesting, el proceso de generación de informes y la colaboración dentro de un de estos proyectos, es una de la partes fundamentales y críticas para la consecución con éxito de este. Al final todo esto nos lleva a un reporte que es donde se representará nuestro trabajo, todo lo que hemos realizado durante semanas y es el lugar donde daremos toda la información descubierta, así como las recomendaciones de seguridad a nuestro cliente.

Figura 3: GitHub de Cervantes

Para organizar y representar de forma clara, concisa y sencilla toda esta información nos es necesaria la ayuda de alguna herramienta, que nos ayudará a ahorrar tiempo de trabajo durante el pentest, en la redacción y elaboración del informe. Y para ello se hemos trabajado en el siguiente proyecto llamado Cervantes, que nos permitirá compartir, organizar toda la información que se vaya recolectando, y haga la vida y el trabajo del pentester más fácil.

Figura 4: Página principal de Cervantes

   

Cervantes destaca por ser una herramienta potente, extensible y de fácil mantenimiento. Esta escrita en el lenguaje de programación C# y sobre la última versión de .NET Core 6 por lo que puede funcionar sobre cualquiera de los sistemas Microsoft Windows, GNU/Linux o MacOS. Cervantes es un proyecto OpenSource por lo que cualquier usuario de la comunidad puede colaborar y ampliar las posibilidades de ésta.

Figura 5: Generación Informe Cervantes

Nos ofrece muchas características como un sistema multi-idioma donde actualmente nos podemos encontrar los idiomas español e inglés, además de permitirnos generar informes en dichos idiomas en un solo clic.

Figura 6: Dashboard de un proyecto en Cervantes

Nos permite una gestión de proyectos completa, así como una colaboración en equipo, trabajar en vulnerabilidades de forma conjunta, asignar tareas a distintos miembros del proyecto, etcétera.

Figura 7: Kanban de proyecto en Cervantes

Haciendo énfasis en la parte de seguridad nos ofrece doble factor de autenticación, donde puedes proteger tu cuenta con Latch Cloud TOTP y muchas más características incluidas y que aún están por llegar, mantente al tanto para ir descubriéndolas.

Figura 8: Configuración de 2FA con TOTP en Cervantes

Actualmente el proyecto se encuentra en desarrollo, pero tenéis disponible en GitHub una versión Alpha tanto en formato Docker como en instalación de forma local. Os dejo con el vídeo para instalarlo de forma rápida y fácil desde Docker.

Figura 9: Instalación de Cervantes desde Docker

Han sido unos meses entretenidos de ir haciendo poco a poco la herramienta, desarrollando los distintos módulos que forman parte de esta, de intentar encontrar una interfaz agradable. Todavía queda camino y mucho trabajo por delante, ya que acaba de empezar el proyecto por así decirlo. Pronto espero tener novedades y mejoras como la capacidad de poder importar reportes de otras herramientas como Nmap, Nessus, (¿FOCA?), etcétera. Generación de reportes en múltiples formatos y mucho más. Pronto habrá más noticias.

Saludos,

Autor: Ruben Mesquida Gomila

Contactar cn Ruben Mesquida

BlockChain & SmartContracts: Ataque de phishing a tx.origin y robo de criptomonedas

Ya hemos hablado en el blog de algunas vulnerabilidades que afectan a los SmartContracts. Es un tema de actualidad y es un tema importante que debemos manejar en el mundo Web3. La seguridad es un proceso transversal a cualquier paradigma de la llamada transformación digital y el mundo Web3 no escapa de ello. Que una vulnerabilidad en un contrato afecta a miles de usuarios y pueda secuestrar o robar sus fondos es algo crítico.  Desde el mundo IT, el de toda la vida, vemos esto como un riesgo que debe ser gestionado. Por esta razón, la base de todo modelo de defensa es el conocimiento y la concienciación. 

Figura 1: BlockChain & SmartContracts: Ataque de phishing

a tx.origin y robo de criptomonedas

En este caso, no solo los desarrolladores de SmartContracts deben disponer de conocimientos para codificar de forma segura, sino que también deben ser los usuarios de los contratos los que entiendan los riesgos básicos. El artículo de hoy va, precisamente, de esto. ¿Cómo puede afectar el pshising a un SmartContract? Expondré algún ejemplo que debemos entender y valorar antes de ponernos a interactuar con este entorno. Ya hemos hablado en el blog sobre vulnerabilidades como la de Reentrancy que puede afectar a la pérdida o robo de fondos de un contrato y a un escenario de bloqueo de criptomonedas de un contrato o denegación de servicio de un contrato. Hoy vamos a explicar un caso de phishing basado en una mala práctica del uso del elemento tx.origin.

Figura 2: Libro dedicado a "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo

En este artículo se puede ver el riesgo de usar tx.origin para validar la propiedad de un contrato. ¿Qué es tx.origin? En Solidity se utiliza como variable global la cual devuelve la dirección pública de una cuenta. En este caso la dirección que envió la transacción. Debemos tener claro que si utilizamos tx.origin para validar o chequear a los usuarios, dichos contratos serán vulnerables a ataques de phishing. Hay que saber que tx.origin es una variable global en Solidity que devuelve la dirección de la cuenta que envió la transacción. Los contratos que utilizan tx.origin para autorizar a los usuarios son vulnerables a los ataques de phishing.

Escenario y ejemplo de vulnerabilidad

Para entender el concepto, vamos a suponer el siguiente escenario:

• Contrato A, el cual es vulnerable.
• Contrato B, el cual es un contrato preparado por un atacante.
• Usuario A, el cual será una víctima.
• Usuario B, el atacante.

El contrato A tiene una función para transferir fondos. Recordemos que el contrato A es el contrato vulnerable. La función permite mover ETH de un contrato a una dirección. El requisito para llevar a cabo esta operación de mover fondos es que tx.origin sea igual al owner del contrato.

¿Qué diferencia hay entre tx.origin y msg.sender? tx.origin es la variable que contiene el emisor de la transacción, es decir, la dirección que ha originado todas las posibles llamadas disparadas a través de los contratos (teniendo en cuenta que un contrato puede llamar a otro, y ese otro a otro…). La variable msg.sender almacena la dirección origen de la llamada actual, por lo que la diferencia es clara, la primera almacena el origen de todo y la segunda el origen de la llamada que se está ejecutando.

Figura 3: Escenario del ataque de phishing a tx.origen

Ahora que tenemos claro que es el tx.origin, supongamos que el usuario B (atacante) envía un phishing al usuario A. El usuario A confía en el phishing y ejecuta una llamada contra el contrato B a través del método ‘attack’. El método ‘attack’ va a provocar que se haga una llamada contra el contrato A en el método ‘Transfer’. El usuario A es el que invoca contratoB.attack por lo que llamada de contratoB.attack a contratoA.Transfer seguirá teniendo como tx.origin al usuario A.

Figura 4: Envio del phishing al usuario A

Si analizamos el requisito del método contratoA.Transfer es que tx.origin sea igual a owner del contrato, por lo que, en este caso, quedará validado con este engaño al usuario A. En la siguiente imagen, se va a mostrar el flujo completo y cómo se activan la pila de llamadas. De todos modos, vamos a hacer un pequeño resumen de la ejecución:

• El phishing enviado del usuario B al usuario A hace que éste ejecute la primera acción: El usuario A invoca a contratoB.attack. En este punto msg.sender y tx.origin tiene como valor la dirección del usuario A.

• El contratoB.attack es ejecutado, por lo que éste ejecuta una llamada al contratoA al método ‘Transfer’. En este caso, cuando se ejecuta contratoA.Transfer, msg.sender vale la dirección del contratoB, pero tx.origin sigue valiendo la dirección del usuario A. Aquí está la vulnerabilidad.

Figura 5: Resumen completo de llamadas con el robo de fondos

Al final, la transferencia se valida, ya que el requisito es que tx.origin sea igual al owner del contrato A. En el engaño, en el contrato B, seguramente, se configura para que los valores de transferencia sean para un wallet del usuario B y se produce el robo de fondos.

¿Cómo podemos evitar esto?

La primera práctica es no usar tx.origin, ya que no nos permite verificar realmente quién está detrás de la llamada que invoca. Es mejor utilizar msg.sender para verificar, aunque existen casos dónde podemos tener problemas. Quizá la mejor solución es la firma de mensajes para verificar, antes de realizar la transacción que somos conscientes que vamos a realizar una transacción. Es importante estudiar los patrones de codificación segura en Solidity, ya que podremos evitar cometer errores graves. Además, realizar auditorías de seguridad y utilizar herramientas DAST y SAST en los entornos de desarrollo parecen algo fundamental. 

 

Figura 6: Pablo González "SmartContrats: Funcionamiento y Vulnerabilidades

En el siguiente enlace se puede ver un listado de patrones que proporcionan utilidad en cuanto a la mejora de la seguridad en el desarrollo de SmartContracts, y en el vídeo anterior una charla mía sobre vulnerabilidades en SmartContracts. El objetivo de estos artículos es concienciar a las personas y que aprendan a evitar estas vulnerabilidades. Seguiremos mostrando más vulnerabilidades en el mundo de los SmartContracts y seguiremos aprendiendo más sobre este interesante mundo de la Web3. Más artículos sobre este mundo Web3:

• Blockchain & SmartContracts: Una serie para aprender
• BlockChain & SmartContrats: Primer SmartContract con Solidity
• Blockchain & SmartContracts: Cómo probar y desplegar un SmartContract en Ethereum
• WWW, Web 1.0, Web 2.0, Web 3.0, Web3 y ¿Web 4.0?
• Metaverso, multiverso y las tierras digitales en que vivimos en forma de avatar
• Los Fan Tokens vs. las Criptomonedas y los NFTs: Level 101
• Tokenomics: Las criptomonedas y las "Proof-of-work": Level 101
• Los NFTs y el registro mundial de los dueños de activos digitales en el Metaverso
• BitCoin: Blockchain y su investigación
• BlockChain & SmartContrats: El Internet descentralizado y el almacenamiento off-chain en IPFS
• Reentrancy Attack: Cómo te roban criptomonedas por un bug en tu SmartContract
• BlockChain & SmartContract: Bugs que pueden dejar tu SmartContrat "fuera de juego"
• Blockchain & SmartContracts: Patrones y buenas prácticas de seguridad
• Blockchain & SmartContracts: Herramientas de Auditoría de Seguridad de SmartContracts

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

Contactar con Pablo González

Fluence y MyPublicInbox sellan una alianza para sumar sus fuerzas

La agencia de líderes de opinión y Marketing Digital Corporativo Fluence Leaders y la plataforma de comunicación e impacto de perfiles públicos en Internet MyPublicInbox han cerrado un acuerdo de colaboración a través del cual pretenden aunar esfuerzos para dar un gran paso adelante.

Figura 1: Fluence y MyPublicInbox sellan una alianza para sumar sus fuerzas

Beatriz Cerrolaza, CEO de MyPublicInbox comenta habla sobre la colaboración: 

‘Desde la primera reunión con Jorge Branger, CMO de Fluence, nos dimos cuenta de que teníamos muchas cosas en común y las posibles sinergias brotaban conforme avanzaba la conversación. Las dos compañías nos enfocamos en potenciar el impacto de las empresas y perfiles públicos en Internet y será fantástico amplificar nuestros servicios colaborando juntos.’ 

Como parte del acuerdo, Fluence aportará su trabajo como agencia de marketing digital a la plataforma MyPublicInbox para potenciar las oportunidades profesionales de los perfiles públicos en su crecimiento en Internet. Además, Fluence tendrá a MyPublicInbox como plataforma tecnología para potenciar el trabajo de los influencers que representan con todas las herramientas y servicios que tienen a su disposición los Perfiles Públicos en MyPublicInbox.

Jacobo Carmona, CEO de Fluence también valora muy positivamente esta alianza:

 ‘Tenemos la misma filosofía y nuestra forma de hacer se complementa perfectamente con la de MPI. Hoy en día es imprescindible tener presencia Digital y mucho más si eres un perfil de éxito o una compañía. En MyPublicInbox y Fluence creemos firmemente en que esa presencia digital puede optimizarse y enfocarse para que sea una ayuda y fuente de negocio en lugar de una obligación tediosa.’

Amanda Montiel, COO de Fluence considera esta alianza ‘clave para el desarrollo y la expansión de ambas empresas tanto a nivel nacional como internacional. Hoy en día tener una marca personal bien posicionada, visible y sobre todo accesible a través de la plataforma MyPublicInbox es un must’.

Figura 2: De izquierda a derecha, Jacobo Carmona, Beatriz Cerrolaza,

 Jorge Branger y Amanda Montiel de MyPublicInbox y Fluence Leaders.

Ambas empresas ya trabajan en nuevas estrategias y acciones que les permitan dar un mayor alcance a su colaboración y a sus usuarios.

Saludos,

Autor: Leire, la facilitadora en MyPublicInbox

 Contactar con Leire, la Facilitadora en MyPublicInbox

Próximos eventos para estos días: Ciberestafas, URJC, KickStart de Ciberseguridad y #SouthSummit22

Esta semana, y la que viene, tengo algunas citas en las que voy a participar, por si quieres pasarte por ellas. De algunas ya os he contando hace poco, pero os completo las que quedan y las nuevas de las que aún no os he comentado. Aquí os las dejo.

Figura 1: Próximos eventos para estos días: Ciberestafas,

URJC, KickStart de Ciberseguridad y #SouthSummit22

La primera será la Presentación del libro de Ciberestafas: La historia de nunca acabar" de Juan Carlos Galindo, que publicamos en 0xWord, como ya os conté en este artículo con todos los detalles del libro. En la presentación estaremos el propio Juan Carlos Galindo, el juego Eloy Velasco, Alfonso Cebrián - director general de CEDEU -, Carmen Mª García, presidenta de la Fundación Woman's Week, Salvador Molina - presidente de MAD FinTech -, Javier Rodrigo que presentará el acto,  y yo para hablar de este mundo. Será el jueves 27 a las 19:00 horas en Madrid, habrá posibilidad de comprar el libro allí, y podrás llevártelo firmado y dedicado.

Figura 2: Apúntate a la sesión Jueves 27 a las 19:00 en Madrid

La segunda de las charlas será el día 31 de Mayo, en el III Congreso Anual de la URJC, donde yo participaré con una charla a las 09:45 para hablar de tecnología y ciberseguridad. Así que espero que si te apetece pasarte por mi querido Móstoles, te apuntes a venir.

Figura 3: Congreso Anual de la URJC

La siguiente cita será el Kickstart Profesional de Ciberseguridad que tendrá lugar ya el día 1 de Junio, y que será una sesión de todo el día, con la realización de las pruebas de Singularity Hackers por la mañana, y de la charla conmigo por la tarde. Tienes los detalles de esta jornada en el artículo que os dejé publicado en el blog, y puedes apuntarte en la web del Campus Internacional de Ciberseguridad.

Figura 4: 1 de Junio "kickstart profesional en ciberseguridad"

Y después de esto, participaré en el South Summit del día 8 al 10 de Junio , donde daré una charla llamada "Trick or Token" sobre Web3, y participaré en un debate, y alguna cosa más haré por allí, que ya que paso, seguro que me hacen trabajar bien.

Figura 5: SouthSummit22

Lo siguiente ya será mi participación en la UAD360 que será los días 10 y 11, donde yo participaré el segundo día, pero...  ya os contaré más de eso en otro artículo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Telefónica Kernel: El compromiso con una visión y la patente internacional WO 2018/024933 A1

En el año 2016, cuando comencé mi trabajo de Chief Data Officer, tenía una misión impuesta con una visión. La misión de hacer de Telefónica una compañía Data-Centric que rompiera los silos de la visión "application centric" de tiempos pasados, y que permitiera construir el futuro de las tecnologías digitales sobre ella. La llamada como Codename: 4º Plataforma. Y no era nada fácil de aterrizar aquella idea en un entorno multinacional como el nuestro.

Figura 1: Telefónica Kernel: El compromiso con una visión y

la patente internacional WO 2018/024933 A1

Hoy en día han pasado ya varios años de trabajar, de hacer que aquel CodeName: 4ª Plataforma se convirtiera en Telefónica Kernel, donde integramos hoy en día todos los datos, productos y servicios digitales. Pero aún recuerdo aquellos días de debate, de plasmar una estrategia táctica para ir dando pasos y conseguir el objetivo. 

Figura 2: El mapa de la 4ª Plataforma para ser Data-Centric

Tuvimos charlas, dibujos, debates, e incluso, plasmamos todo el proceso en un patente que se registró para Telefónica, con la visión de José María Álvarez-Pallete, y el aterrizaje que hicimos en el equipo para ello, que hizo que aparezcamos en la patente internacional W0 2018/024833 A1 mi compañero Antonio Guzmán y yo.

Figura 3: Patente W02018024833A1 de Codename 4ª Plataforma

Al final, es un trabajo de Telefónica, pero lo que más me llama la atención, hoy, con la perspectiva de los años, es como de claro que teníamos que construir esa plataforma internamente en Telefónica, cómo debías controlar el Asistente Digital - que finalmente sería AURA -, como la privacidad era clave e importante para nosotros, con la llegada del GDPR, las demandas de Transparencia y Control de Consentimientos de uso de Datos.

Figura 4: Documento PDF de la patente de la 4ª Plataforma

Hoy en día, la locura esa de que los datos y el tiempo que dedicas a una plataforma deben tener un valor, y que sonaba a locura, ha sido reemplazado por el Tokenomics y las criptomonedas proof-of-work  minteadas para los usuarios como forma de pagar su tiempo, sus datos, y su aporte de valor a una plataforma, y que nosotros plasmamos en la primera versión de Movistar Tokens, y que seguimos evolucionando.

Figura 5: Sección Generar Tokens en Mi Movistar

Me llama la atención como una visión de transformación de una compañía se llevó tan decididamente, y creo que fue esa decisión la que hizo posible que, con todas las dificultades que conlleva un cambio tan grande, pudiera avanzar y crecer hasta convertirse en nuestro Telefónica Kernel. Una maravilla ser testigo de excepción.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El "leak" del Login en tu Banca Online con tu D.N.I. (NIF) o con tu C.I.F.

Ya he hablado muchas veces de lo que llamamos El "leak" del login, o lo que es lo mismo, cómo saber que una persona tiene una cuenta en un servicio a base de aprovechar los intentos de intentar hacer las tres acciones que se pueden hacer con datos públicos de una persona, es decir, Iniciar Sesión, Crear una cuenta o Recuperar una contraseña, y analizar los mensajes de error.

Figura 1: El "leak" del Login en tu Banca Online con tu D.N.I. (NIF) o con tu C.I.F.

Para iniciar sesión en un servicio, para recuperar la contraseña, y para crear una cuenta, nos van a solicitar datos que normalmente son públicos, como son la dirección de correo electrónico, el usuario, o el número de teléfono. Datos, que en una tarjeta de visita pueden aparecer con mucha facilidad. Con estos datos se puede intentar iniciar sesión en un servicio, se puede intentar recuperar una contraseña, o se puede intentar crear una cuenta. 

Figura 2: Se informa al que introduce el e-mail de si la cuenta existe o no

Si el sitio web en el que estamos probando, tanto al intentar iniciar sesión, al recuperar una contraseña o al intentar crear una cuenta, da un mensaje distinto cuando la dirección de correo electrónico o el número de teléfono existe previamente en el servicio, que cuando no existe, entonces podremos saber con facilidad si esa persona tiene una cuenta en esa plataforma, lo que es un leak de privacidad, como hemos visto en ejemplos varios:

• El leak del login en Instagram
• El leak del login en redes sociales de contactos íntimos de adultos
• El leak del login en Grindr

Con todos estos "leaks", es posible capturar el correo electrónico y/o el número de teléfono de una tarjeta de visita y sacar un mapa de los servicios en los que una persona tiene una cuenta, lo que da mucha información de su vida en la red. Con esta premisa, creamos el servicio de Dirty Business Card en nuestro equipo de Ideas Locas.

Figura 3: Demo de Dirty Business Card

Sin embargo, una de las cosas que también se puede extraer información de las entidades bancarias en las que una persona tiene cuenta, no solo por el número de teléfono (como vimos en el caso de Bizum) o la dirección de correo electrónico, lo que facilitaría los ataques de phishing bancario, enviando el correo de phishing del banco correcto a la persona correcta, sino que también se puede hacer por el número de DNI de una persona.

Figura 4: Libro DNI-e: Tecnología y usos

en 0xWord de Rames Sarwat

En algunos bancos, para saber si tienes cuenta o no con ellos, y poder activarte la Banca Online, te solicitan el número de DNI, y si tienen el "leak del login", entonces darán un mensaje diferente cuando ese DNI esté en sus sistemas a cuando no esté en sus sistemas, como en este ejemplo que podéis ver aquí, que para poder ver si tienes cuenta se solicita primero el número de DNI.

Figura 5: Activar el acceso a la Banca Online en un banco

Después, si la cuenta no existe, da un mensaje de error en el que invita a hacerse cliente de la entidad bancaria en concreto, como podéis ver en la imagen siguiente.

Figura 6: Ese DNI o tiene Banca Online

Mientras que si tienes una cuenta bancaria asociada a ese número de DNI (o CIF o NIF dependiendo del número que soliciten), entonces saldrá un proceso distinto para comenzar la recuperación de la contraseña.

Figura 7: Ese DNI tiene Banca Online en este Banco -> Leak

Por desgracia, en nuestro país, localizar el número de DNI, teniendo los dos apellidos y el nombre de una persona, no es demasiado complejo encontrar su número de DNI, ya que en el Boletín Oficial del Estado, en entidades públicas, listados de oposiciones, listados de notas, etcétera, se han publicado y se publican por transparencia, lo que no siempre es lo mejor por privacidad y seguridad.

Figura 8: Un poco de Hacking con Buscadores en Google o Bing y con

Nombre y Apellidos de una tarjeta de visita no es difícil dar con el DNI.

Además, como hemos visto en artículos anteriores, muchos sitios web solicitan con demasiada frecuencia el DNI y hay que tomar precauciones para evitar enviar copias del DNI con todos los datos que den demasiada información, e incluso se pueden enviar los documentos con marcas ocultas de Shaadow para saber en el futuro si ha habido un fallo de seguridad en la gestión de tu documentación.

Figura 9: Libro de "Cómo protegerse de los peligros en Internet"
de José Carlos Gallego en  0xWord

Así que, si encuentras un "leak del login" en una entidad bancaria, lo suyo es que se lo reportes para que hagan menos "Verbose" el proceso y no sea fácil conocer si una persona ( o una organización ) tiene cuenta en esa entidad o no, ya que se lo ponemos más fácil a los malos, que con mucha información, y un poco de ingeniería social son capaces de hacer estragos en las personas menos informadas, como la banda que desarticuló la Policía. Y nos ayuda a todos a estar más protegidos contra los peligros en Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)