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

lunes, agosto 26, 2024

WhatsApp: Passkeys para hacer más cómodo el proceso de Login y reducir los SMS-OTP

Una de las características que ha introducido WhatsApp para mejorar su proceso de autenticación es la del uso de las Passkeys. No es que WhatsApp haya cambiado su forma de iniciar sesión ten tu cuenta, con el famoso SMS que se usa como canal OTP de desafío a tu número móvil, sino que se ha añadido, una vez instalado en un dispositivo, poder autenticarse mediante un sistema de clave privada / clave pública como alternativa al SMS.

Figura 1: WhatsApp: Passkeys para hacer más cómodo
el proceso de Login y reducir los SMS-OTP

Es decir, la idea es reducir el número de SMS-OTP que se envían - y que han sido tradicionalmente el punto de ataque para robar cuentas de WhatsApp -, permitiendo que el usuario pueda utilizar las Passkeys - si las tiene -, como forma cómoda y segura de autenticarse.

Figura 2: Passkeys en WhatsApp

Como podéis ver en la imagen superior del Help Center de WhatsApp, las claves se pueden utilizar opcionalmente, si se tienen, lo que hará mucho más cómodo el proceso de autenticación, ya que será como autenticarse como con cualquier otra credencial de los gestores de contraseñas que tienen Android e iPhone, por lo que se puede utilizar FaceID o la Biometría de la huella dactilar.


Nuevo libro de Luis Márquez en 0xWord.

Es decir, para el usuario será más cómodo porque no hay que esperar que llegue el SMS OTP, no tendrá que leerlo y escribirlo, y no se producirá una transmisión del código para que pueda ser capturado por un posible atacante.  Pero si no lo tiene, no pasa nada, el usuario puede autenticarse como siempre.

Figura 4: Creación de Passkeys

Crear la Passkey es tan sencillo como podéis ver en estas capturas. Se entra en Account -> Passkeys, le damos al botón de Continuar y la Passkey es creada. Y tendremos una solución temporal de autenticación utilizando claves criptografías.
Una vez que pasa esto, sólo hay que almacenarla en el gestor de credenciales de tu dispositivo, lo que hace WhatsApp de manera automática. En mi caso, que tengo un iPhone, me autentico con FaceID y se queda guardada en el Password Manager de Apple.

Figura 6: Creación, almacenamiento y borrado de las Passkeys

Como se ve en la imagen anterior, se puede eliminar la Passkey, y si existe esa Passkey, se puede utilizar para iniciar sesión en cualquier dispositivo sin utilizar el SMS-OTP tradicional. 

Conclusión

Este proceso implica dos cosas a tener en cuenta que quiero recalcar para que sea fácil entender este sistema de autenticación:

1.- No sustituye el SMS-OTP como forma permanente de autenticación: Es una alternativa que puede ser utilizada, pero si has perdido las Passkeys porque has perdido el dispositivo, con recuperar la SIM puedes volver a iniciar sesión. 

2.- Si alguien tiene las Passkeys podría iniciar sesión: Así que debes, como ves en la figura 5, eliminar las Passkeys antes de cambiarte de Android a iPhone, o de cambiar de Password Manager, porque si alguien pudiera acceder a ellas, tendría acceso a tu sesión.

3.- Más info para verificar un robo de cuenta: He querido añadir este punto porque al final, si alguien te clona la SIM o consigue tu OTP, y tú tienes también el SMS-OTP haciendo un login en paralelo, pero además tienes las Passkey, puede ser que Meta use las Passkeys como elemento para determinar que estás sufriendo un ataque, así que no viene mal tenerlas. 

Por último, recalcar que, a día de hoy, el proceso de login sólo se hace cuando hay cambio de dispositivo, o un cambio drástico en el sistema operativo, por lo que ya a día de hoy hay un proceso de autenticación para mantener la seguridad de la cuenta mediante claves de dispositivo que también se guardan en el Password Manager, así que digamos que esto es una evolución que permite utilizar estas Passkeys más allá del uso actual.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


martes, septiembre 21, 2021

Social Worms & Frauds: WannaSAPP & WannaGRAM

El viernes pasado impartí mi conferencia en la HBSCON a la que me había comprometido, y aproveché para hablar de algo que habíamos construido en el equipo de Ideas Locas tiempo atrás, para demostrar el funcionamiento de los gusanos que se despliegan por WhatsApp o Telegram robando cuentas y datos de los usuarios. 

Figura 1: Social Worms & Frauds: WannaSAPP & WannaGRAM

La idea de estos gusanos es muy sencilla. Se trata de infectar un terminal inicial, al que llamaremos "Paciente Zero", una vez que consiguen esa cuenta de WhatsApp y Telegram, acceden a toda la lista de contactos - con las que tienen mucha o poca, pero al menos, cercanía -. Una vez que tenemos los números de teléfono de los contactos, la idea es robarles la cuenta a ellos para seguir expandiendo el gusano.

Figura 2: Esquema de robo de cuentas de WhatsApp/Telegram

Para ello, con un proceso en backend, por cada contacto de la lista que acaba de ser robada al Paciente Zero se intenta iniciar sesión en Telegram o WhatsApp, lo que provoca que le llegue un mensaje SMS de confirmación con un OTP para autorizar el login. El gusano, para conseguir ese Token OTP lo que hace es, usando el WhatsApp o Telegram del Paciente Zero enviarle un mensaje de ingeniería social vía WhatsApp o Telegram diciendo algo como:

- "Por error te he enviado un SMS con un número de lo-que-sea. ¿Me lo mandas?"

¿Cuántos contactos de la lista de contactos del paciente zero enviarán el Token OTP al WhatsApp o Telegram del Paciente Zero controlado por el gusano? Pues los que sean, pero en cuanto se pueda acceder a una nueva cuenta de WhatsApp o Telegram, el gusano repite el proceso de manera recursiva. 

Figura 3: WannaGram y WannaSapp

Para demostrar este proceso, y explicar una forma de conseguir el primer Paciente Zero, creamos en el equipo de Ideas Locas dos guanos de WhatsApp y Telegram llamados WannaSAPP y WannaGRAM, unas extensiones maliciosas de Mozilla Firefox para tomar control de navegadores en equipos compartidos. Estas extensiones hacen que, en el momento en que se inicie sesión en WhatsApp Web o Telegram Web, el gusano tenga su Paciente Zero y comience a vivir.


En la conferencia que podéis ver en el vídeo de arriba, podréis ver que la parte de "gusanizar" el ataque, es decir, de pasar del Paciente Zero al Paciente Uno la hacemos a mano, ya que no queríamos que se nos escapase por ahí un ataque con un gusano que cobrara vida propia, así que solo explico el paso de pasar de Paciente Zero a Paciente Uno, pero... os hacéis una idea.

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

Por supuesto, no queríamos fomentar tampoco ningún ataque, y solo explicar cómo se han estado produciendo de verdad estos ataques, así que WannaGram y WannaSapp no está públicos. Creemos que es suficiente con que se vea su funcionamiento para entender lo que queríamos explicar, y lo mejor, es que estés informado de cómo protegerte de los peligros en Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


domingo, enero 31, 2021

Servicios Digitales Financieros: Una mirada a la seguridad de los Mobile Financial Services.

Nos encontramos ante un nuevo paradigma o nicho de mercado, donde los tradicionales servicios financieros, están migrando hacia servicios dependientes cien por ciento de las comunicaciones. Las autoridades y grandes holdings financieros están empujando fuertemente a la sociedad y empresas a hacer uso de ellos, pues les conviene en todo sentido.

Figura 1: Servicios Digitales Financieros: Una mirada a la
seguridad de los Mobile Financial Services.

El crecimiento de estos DFS, del inglés “Digital Financial Services”, es vertiginoso y por tanto necesitamos construir esto sobre sistemas seguros para dar confianza a los usuarios, protección a los bancos y medios de pago, y estabilidad al nuevo mercado.

El mundo Fintech

Cuando se utiliza el término “Fintech” se hace de una manera amplia abarcando al uso de aplicaciones digitales, servicios, software y tecnología por parte de empresas y startups centradas en la innovación en el mundo de la banca y las entidades financieras, y pueden ir desde servicios de pagos, como Bizum o Twyp, hasta sistemas de crédito al consumo como Movistar Money.

Esta disrupción ha hecho que la industria de los servicios financieros, especialmente la industria bancaria, se esté convirtiendo cada vez más en un negocio de tecnología. Más que nunca, la competitividad de varios productos centrados en las finanzas se diferencia por las soluciones tecnológicas que los habilitan.


En los mercados emergentes, donde más carencia de ciudadanos bancarizados existían, los teléfonos inteligentes se han convertido en el medio principal por el cual las personas acceden a Internet y utilizan diferentes servicios financieros.

Debido a este crecimiento, se ha comenzado a trabajar en dar forma al futuro de los servicios financieros en la economía digital. Según las actas de la Cuarta Cumbre de Políticas y Conocimiento entre América Latina y el Caribe y China , el crecimiento exponencial de la digitalización y la conectividad a Internet es la columna vertebral de la Cuarta Revolución Industrial, que ha afectado a todos los sectores, incluidos los servicios financieros.

La economía digital ha impactado profundamente el sector de servicios financieros en China al permitir nuevos modelos de negocios de banca e inversión basados en Internet con un menor costo de operación que han ampliado significativamente el alcance entre los consumidores, como es por ejemplo el uso de pagos con la plataforma de mensajería de WeChat.

Los Servicios Financieros Digitales

Los DFS incluyen una amplia gama de servicios a los que se accede y se prestan a través de canales digitales, incluidos pagos, crédito, ahorros, remesas y seguros. Y como hemos visto, en ellos el concepto DFS incluye servicios financieros móviles basados en los smartphones – pero también los Feature Phones que son el principal medio usado en algunos países de Africa e Índia -, llamados Mobile Financial Services (MFS), como elementos fundamentales del mundo Fintech. Dentro de los MFS, que utilizan el teléfono móvil para acceder a servicios financieros y ejecutar transacciones financieras, se encuentran los denominados:

- M-Money: es un servicio móvil que facilita las transferencias electrónicas y otros servicios transaccionales y no transaccionales que utilizan redes móviles. Es decir, centrados en la transferencia de dinero entre cuentas bancarias. Existen algunos como Instant Money, que permiten enviar dinero a cualquier teléfono móvil (SmartPhone o Feature Phone), con solo enviar un SMS.


- M-payments: es el servicio concreto de pagos por móvil, como por ejemplo Mobile Pay, WePay de WeChat, Twyp de Bankinter con el que puedes pagar en comercios y gasolineras - por ejemplo -, o el popular Bizum

- M-Banking: es el uso de un teléfono móvil para acceder a servicios bancarios y ejecutar transacciones financieras, donde empresas como BBVA o Banco Sabadell han hecho auténticos esfuerzos por construir una banca móvil puntera. A menudo se utiliza este termino, lógicamente, para referirse solo a clientes con cuentas bancarias.

En los servicios Fintech, hay tres tipos de compañías que están realizando estos negocios, como son los servicios virtuales construidos sobre los servicios de la banca, que funcionan de forma similar a los operados móviles virtuales de las redes de comunicaciones, pero en el entorno bancario, y que son conocidos como MVNO como es el caso de Twyp y Bizum que se basan en entidades bancarias y clientes bancarizados asociando números de cuenta bancaria o tarjetas de crédito, los que han construido algunas empresas del mundo de las telecomunicaciones aprovechando que tienen suscripciones mensuales con sus clientes y, por tanto, tienen historial crediticio solvente y domiciliación de pagos actualizada, lo que les permite crear nuevos DFS, y que son llamados MNO por ser precisamente basados en eso, en un Mobile Network Operator.

A estos, hay que unir servicios independientes creados por nuevas empresas que se meten en el mundo de los DFS, como es el caso de WePay de WeChat o WhatsApp Payments que se basan en pagos y wallets gestionados por su red de servicios de chat, por ejemplo. Por supuesto, nos vamos a encontrar situaciones mixtas, porque hay bancos que se convertirán también en MVNO de sus propios servicios, como es el caso de SberBank o, alianzas entre varios bancos como es el caso de Bizum, conformada por la unión de 27 bancos españoles.

Riesgos de seguridad en los DFS

Por supuesto, donde hay dinero, hay gente buscando la oportunidad de robarlo, así que hay que evaluar bien los riesgos de seguridad y qué debemos hacer para mejorar su seguridad. En concreto, hay que mejorar algunos aspectos de la confirmación de las operaciones con los códigos de firma de operación basados en Segundos Factores de Autenticación utilizando códigos OTP (One-Time Password).

Teniendo en cuenta que los usuarios de estas plataformas pueden sufrir en cualquier momento un robo de las credenciales de acceso, los servicios DFS cuentan con ese Segundo Factor de Autenticación que se envía por un canal paralelo, ya sea una aplicación instalada en el móvil, un SMS recibido en el terminal móvil, un token criptográfico externo o una llamada de teléfono. Y es aquí donde los atacantes focalizan sus esfuerzos.

En un informe reciente de ITU, ENISA y todos los organismos financieros relevantes, donde se analiza el posible fraude en los sistemas DFS, se ven que las superficies de ataque de estos códigos de confirmación de operaciones pueden ser las siguientes :

- SS7 (principalmente por medio de captura de mensajes SMS y USSD – ambos son mensajes SS7): En estos casos el atacante tiene que conseguir acceso a la red SS7 - porque es un empleado interno malicioso de la empresa de telecomunicaciones o vulnerando servidores de esta red -,  que aunque no es algo al alcance de todos los atacantes, sí que existen esos escenarios donde es posible acceder al medio físico o la red para generar el tráfico malicioso. Sería necesario acceder al tráfico de la operadora de comunicaciones, y por tanto las empresas de telecomunicaciones que tienen los servicios FinTech en su negocio, han tomado medidas de fortificación de estas redes SS7, aunque no todas.

- Conexiones móviles (2G/3G/4G/5G): Desde hace tiempo, los ataques a las conexiones entre los terminales móviles y las antenas de comunicación han sido un punto de riesgo. Los ataques RTL-SDR para romper el tráfico GSM, o las vulnerabilidades que se han ido descubriendo en 2G/3G/4G han hecho que se pudieran capturar – si se está cerca de la víctima -, los mensajes SMS
Estos ataques a las conexiones móviles se explican en el libro de Hacking de Comunicaciones Móviles (2G/3G/4G) se explica muy bien, y en este artículo de 2014 de Pedro Cabrera se puede ver un ejemplo. Los nuevos estándares 5G han tenido en cuenta la protección y el cifrado estas conexiones para dificultar la posibilidad de crackear este tráfico y acceder al contenido del SMS en texto plano.


- Clonado de SIM: Otra de las técnicas utilizadas por los atacantes consiste en tener el control de la tarjeta SIM de la víctima, para lo que se utilizan diferentes técnicas, como son el clonado de las tarjetas SIM, que se basa en vulnerabilidades criptografícas o debilidades en la cadena de seguridad de los proveedores de SIM – empresas de telecomunicaciones – a la hora de dar una copia de una tarjeta a una persona. 

- SIM Swapping: En este caso, con el objeto de tener el control de la SIM que pertenece al número de teléfono de la víctima, el atacante pide la portabilidad de un número de teléfono de una operadora a otra sin haber validado correctamente la identidad del que solicita la portabilidad. 

- Robo de 2FA en Apps TOTPs y SMS por Troyanos bancarios: Otra forma habitual de robar estos segundos factores de autenticación ha sido por medio de apps maliciosas, o troyanos instalados en el terminal. Solicitando acceso de lectura a los mensajes SMS en sistemas Android ha sido muy común, o directamente troyanizando el terminal llevándose las semillas de las apps TOTP

- Robo de Tokens en buzones de voz: Por último, como opción de accesibilidad, muchas plataformas permiten utilizar llamadas de voz para entregar los códigos de los Segundos Factores de Autenticación, lo que permite a algunos atacantes, aprovechar momentos en que el usuario tiene el terminal apagado – por ejemplo, en horario nocturno – y solicitar la entrega de los 2FA por voz. Esto lleva a que acabe el código en el buzón de voz grabado. Si no se ha fortificado el acceso al buzón de voz cambiando la contraseña por defecto – muy común en algunas operadoras de comunicaciones – entonces el atacante puede acceder al 2FA accediendo al mensaje del buzón de voz.

Como se puede ver, para fortificar el sistema de verificación de los DFS, es necesario hacer mejoras de seguridad a varios niveles. Desde la gestión de la seguridad en los terminales móviles, hasta en los protocolos de las redes de comunicaciones, y por supuesto en las apps de los propios MFS. Y por supuesto, en el Primer Factor de Autenticación, las credenciales de acceso al sistema.

Según encuestas realizadas por el grupo de trabajo ITU y la Agencia de la Unión Europea para la Seguridad de las Redes y la Información (ENISA), menos del 30% de las empresas de telecomunicaciones de la Unión Europea (UE) y menos del 0,5% de las empresas de telecomunicaciones de los países en desarrollo habían implementado algunas medidas de mitigación para los riesgos de SMS, los protocolos inseguros de las SIM o los buzones de voz. Hay que tener presente que, un fallo criptográfico en la SIM Card obliga al cambio y distribución de millones de nuevas tarjetas, lo que no hace fácil una operativa automática y de costes eficiente.

La encuesta, y el informe es del año 2017, y es verdad que las empresas de telecomunicaciones han evolucionado sus sistemas, e incluso implantado soluciones RCS, pero la existencia del enorme mercado aún de Feature Phones,  la no apuesta por RCS de iOS que apuesta por su iMessages, y la base enorme de apps que aún utilizan SMS, hace que haya que seguir poniendo medidas de seguridad al sistema SMS, que seguirá un tiempo en esta industria.

El uso del SMS en texto claro

El sistema de mensajes SMS, que se pueden enviar tanto por las redes de conmutación de paquetes, como encapsulados en la red de datos, y que se utiliza como Segundo Factor de Autenticación en muchos de los MFS, no va cifrado. Así, como se ha dicho anteriormente, si alguien accede al tráfico de las tramas SS7 que aún se utilizan en la red de conmutación de circuitos y paquetes, podrá visualizar el contenido del mensaje, en este caso el código OTP de una operación Paypal. Como se ha dicho antes, para acceder y manipular las tramas SS7 es necesario estar dentro de la red SS7 o vulnerar la seguridad de un servidor de la red - como ha hecho el mundo del cibercrimen en ocasiones pasadas - pero si lo puede hacer podrá acceder al contenido del mensaje. 

Figura 6: Captura de un SMS de Paypal en un paquete SS7 desde la red telco

En la imagen anterior vemos la parte correspondiente a la pila TCP/IP, debajo de ella la parte de SS7 y en este caso concreto, un mensaje SS7 cuyo “Operation Code” es: “forwardSM” y se corresponde con un factor de doble autenticación enviado por PayPal. El detalle que deseo que observéis (independientemente de las debilidades y ataques de la red SS7), es que estáis observando todo el contenido en texto plano, como hemos dicho, algo que no se puede cambiar porque SMS no va cifrado, así que hay que fortificar la capa de red, sí o sí. Si analizamos únicamente el campo “TP-User-Data” en otras capturas de tráfico, vemos que estos mensajes SS7 en texto plano, son empleados por un sinnúmero de aplicaciones y empresas:

Figura 7: Mensajes SMS capturados desde la red SS7.

En el caso de los SMS, la protección es que para acceder a ellos hay que tener acceso al tráfico de red, así que si alguien desde el otro lado del mundo intenta acceder a estos mensajes no podrá, ya que solo se envían en una ruta de encaminamiento hacia donde se encuentra el número destinatario en la red, por eso los ataques se deben de hacer desde posiciones muy estratégicas, salvo que, como se ha dicho antes, alguien pueda vulnerar la red SS7 y colarse dentro de ella. 

Es decir, que si alguien consigue acceder a la red SS7, o conseguir una conexión GSM insegura entre la antena y el destinatario del SMS con un ataque RTL-SDR, podrán conseguir ver el Segundo Factor de Autenticación. Es verdad que para que les sea útil deben tener antes el Primer Factor de Autenticación del MFS.

En el caso de apps para gestión de tokens de verificación enviados desde el servidor, como es el caso de Latch y sus OTPs (que aunque sean TOTP no hay que confundir con los Latch Cloud TOTP que se generan en el dispositivo), o Authy, los datos se cifran usando la red datos, como podemos ver en el ejemplo en la imagen siguiente.

Figura 8: Captura cifrada de un paquete de Authy

En la imagen anterior, podemos ver el triple handshake TCP, una vez finalizado ya pasa al nivel aplicación con el protocolo SSLv2 empleando el algoritmo SHA2, en la ventana inferior de Wireshark, se ve perfectamente que el contenido es “ilegible”.

Aún así, el uso de las apps en el dispositivo para la generación de códigos TOTP o la recepción de tokens TOTP desde el servidor, siguen teniendo sus riesgos. Las apps maliciosas en el dispositivo pueden acceder a las semillas TOTP en apps con permisos inseguros, el uso de plataformas de canales de mensajería tipo WhatsApp o Telegram siguen relegando su seguridad en el SMS (que utilizan para verificar el inicio de sesión de las cuentas), y, lo aún más preocupante, los atacantes han descubierto que cuando se hace un ataque de phishing a una víctima, lo mejor es pedirle primero el usuario y la contraseña y después el 2FA, con lo que en esos entornos no les importa si el TOTP se ha enviado por un canal sin cifrar, cifrado o se ha generado en el dispositivo. Engañan al usuario para que se lo entregue.

Reflexión final

Por supuesto, el esfuerzo en seguridad el mundo de los DFS y los MFS implica hacer ejercicios conjuntos a nivel de redes de comunicación,  continuar el proceso de fortificación de las redes de conmutación de paquetes con mensajes SS7, proteger al máximo los puntos de defensa del tráfico por el que circulan los SMS, ya que mientras no haya un standard como SMS que funcione asociado a un dispositivo en iOS, Android y Feature Phones seguirá con nosotros, por supuesto, se pueden utilizar otros canales alternativos como apps, sistemas de mensajería OTT como WhatsApp, Telegram, RCS o iMessage para los 2FA, y también debemos fortificar las apps, añadir mecanismos de detección del fraude y concienciación de los usuarios con la protección de su Primer Factor de Autenticación, ya que si el atacante no consigue éste, nunca le servirá el 2FA para nada.


Como guía de mejores prácticas, se presenta a continuación exactamente lo que recomienda realizar DFS/ITU-T en su documento: “Security Aspects of Digital Financial Services (DFS)” Este documento presenta 21 recomendaciones que invito a que las leáis pues son la base de las medidas de seguridad en estas redes.

Autor: Alejandro Corletti

domingo, octubre 01, 2017

Un OTP con "No Repudio" biométrico basado en voz usando Latch

Hace ya un tiempo, en ElevenPaths estuvimos evaluando meter en Latch una capacidad que al final decidimos dejar fuera del roadmap del producto principal. Se trata de la implementación de una protección del Token OTP (One-Time Password) que se entrega vía Latch para garantizar el No Repudio.

Figura 1: Un OTP con "No Repudio" biométrico basado en voz usando Latch

La idea es bastante sencilla. Cuando una aplicación envía vía Latch un código OTP como forma de firmar un transacción - en lugar de utilizar por ejemplo un SMS -, como se hace en la implementación de algunos bancos, existe la posibilidad de que una persona, que no sea la que es dueña del terminal, acceda a ese valor. Eso lo hemos visto en muchos casos en los que alguien puede acceder al contenido de un SMS utilizando las opciones de previsualización, como en el "truco de bar para robar cuentas de Gmail".
Para evitar esto empezamos a pensar en cómo sería utilizar un Tercer Factor de Autenticación para garantizar el No Repudio. Es decir, para garantizar que el el Token OTP había sido visto solo por el autentico dueño del terminal, y para eso comenzamos a trabajar en un esquema basado en biometría de voz.

Figura 3: Esquema de funcionamiento de OTP basado en biometría de voz

La idea es bastante sencilla. Se trata de enviar un desafío que debe ser leído por la persona que quiere acceder al Token OTP. Si su firma biométrica de voz coincide con la que se tiene almacenada, entonces se le entrega el valor OTP que debe utilizar para firmar la transacción que sea. Es decir, una forma de garantizar el No Repudio de una determinada operación.


Esta semana os publicaremos en el blog de ElevenPaths el vídeo de la implementación que hicimos que, como os digo, se quedó fuera del producto principal de Latch. Mientras tanto, tenéis el paper que escribimos con dicho trabajo en el SlideShare de ElevenPaths, y lo tenéis publicado aquí.

Saludos Malignos!

miércoles, mayo 03, 2017

WhatsApp y la paradoja de la SIM como Verificación en 1 paso

En WhatsApp, no hace demasiado tiempo, se incluyó la posibilidad de configurar Verificación en dos pasos utilizando un PIN. Es decir, al sistema de autenticación basado en mensajes OTP enviados por SMS  o por mensaje de voz, se añadió la posibilidad de utilizar una contraseña para poder iniciar sesión como segundo paso de la autenticación en dos pasos para proteger tu cuenta de WhatsApp contra el robo de la misma y desalentar a los que desean espiar WhatsApp. Pero este método de proteger la cuenta es algo bastante poco común en los servicios de Internet.

Figura 1: WhatsApp y la paradoja de la SIM como Verificación en 1 paso

Como ya sabéis, en la mayoría de los servicios de Internet se utiliza un usuario y una contraseña. Dentro de la visión de una identidad, esto tiene un factor de universalidad y de usabilidad muy alto, pero de robustez y cumplimiento legal en entornos críticos, muy bajo. Los usuarios y contraseñas se roban con facilidad en los lugares en los que se introducen, pero pueden ser utilizados desde cualquier sitio y todo el mundo entiende cómo funcionan.

Figura 2: Configuración de Verificaicón en dos pasos
en las opciones de cuenta de WhatsApp

En el caso de WhatsApp, el primer factor de autenticación es tu tarjeta SIM a la que se envía un token OTP cada vez que inicias la sesión en un nuevo dispositivo, o hay un cambio en el terminal que hace que cambie su huella. Utilizar la SIM es más robusto, porque a pesar de que existen ataques a la SIM, no es tan sencillo de robar como un usuario y una contraseña. Se necesita hacer un ataque mucho más elaborado y mucho menos silencioso, ya que el dueño del terminal detecta que su cuenta de WhatsApp ha sido usurpada. 

Por otro lado, es menos usable, ya que no puedes tener abiertas las sesiones en todos los dispositivos que quieras, y siempre deben ser aprobados por el terminal donde tienes la SIM. Incluso si utilizas WhatsApp Web o WhatsApp para Windows o WhatsApp para macOS, estos necesitan que estén aprobadas las sesiones por la sesión principal, y que además esté encendido el terminal, ya que es este el que envía el tráfico cifrado del dispositivo al cliente de WhatsApp Web, para macOS o para Windows.

Figura 3: Activar la Verificación en dos pasos en WhtasApp

Es decir, utilizar la SIM es más robusto pero al mismo tiempo un poco menos usable y un poco menos universal que utilizar solo usuario y contraseña - una cuenta, una SIM -. Ahora, con la aplicación de la Verificación en dos pasos utilizando PIN y un correo electrónico de recuperación, la cosa es aún más segura todavía y puede que mejor.

¿SIM como primero, como segundo o como recuperación de passwords?

Si tu utilizas un usuario y una contraseña como primer factor de autenticación y la SIM del número para recibir el SMS en caso de que la contraseña se ha olvidado o perdido, entonces tu SIM es como si fuera tu primer factor de autenticación, tal y como os expliqué en el artículo "Cuando los SMS son realmente los first factor of authentication". No es un caso comparable a tener una verificación en dos pasos, pero tiene su importancia en la paradoja que os vengo a contar.

Figura 4: Configurar un PIN como Verificación en dos pasos

Si tu utilizas el usuario y la contraseña como primer factor de autenticación, y la SIM como segundo factor de autenticación - que no es lo mismo que solo utilizarlo para restablecer la password - entonces puede darse el caso de que te roben el usuario y la password, y se busquen mañas para robar el SMS (o el token TOTP si no llega por SMS) a posteriori. De hecho, muchas víctimas reciben el OTP porque les han robado la password y no saben por qué lo han recibido, y siguen utilizando la misma contraseña hasta que con algún ataque de ingeniería social consiguen que la víctima les de el OTP, o preparan un ataque de SIM Swapping, o incluso un APT utilizando SDR-RTL en la ubicación física de la víctima para robarle el token OTP que le llegue. Cualquiera de los ataques dirigidos a la SIM de los que ya os hablé.

Figura 5: Configurar correo electrónico para recuperar el PIN

Alguien podría pensar que esto es al revés en WhatsApp con este sistema, es decir, si el atacante tiene que robar primero la autenticación basada en la SIM y luego el PIN de la password, la víctima se daría cuenta de que la cuenta ya no le funciona por culpa de la SIM y podría alertarse. Pero los atacantes no van a caer en este error básico sabiendo cómo funciona WhatsApp ahora con la Verificación en dos pasos

Figura 6: Solicitud de PIN para activar una cuenta de WhatsApp
protegida co Verificación en dos pasos

Si un atacante tuviera que robar una cuenta de WhatsApp ya no debe preocuparse de robar solo la cuenta vía robo de SIM. Debería previamente robar el PIN que se utiliza como segundo factor de autenticación o la cuenta de correo electrónico con la que se recupera el PIN. Si no lo hiciera, entonces la víctima se daría cuenta muy rápidamente y el atacante sería detectado. 

La paradoja de la  SIM

Sin embargo, si la víctima tiene una cuenta de WhatsApp que tiene una Verificación en dos pasos, que está protegida por un PIN, y este PIN se puede recuperar por medio de una cuenta de correo electrónico que utiliza como forma de recuperar la contraseña la SIM, entonces, la Verificación en dos pasos de WhatsApp acabaría de convertirse en Verificación en 1 paso. Bonita paradoja.

Figura 7: Restablecimiento de contraseña de cuenta de Gmail usando SMS

Este error puede sucederte, si no te has fijado en los detalles de la seguridad de tus cuentas. Y puedes caer en él solo porque la cuenta de WhatsApp y la de correo configuran la seguridad de forma inversa. Una pide el número de teléfono para autenticarse junto con un OTP más un PIN que se recupera por correo electrónico. La otra pide un usuario de e-mail más una password que se recupera por SMS. Así que, como conclusión de esta diatriba, deberías llevarte los siguientes puntos para asegurarte de no haber caído en esta paradoja.
1.- Configura la Verificación en dos pasos de WhatsApp sí o sí. 
2.- Configura como cuenta de correo electrónico una con verificación en dos pasos
3.- Configura una cuenta de correo electrónico que no utilice la misma SIM para restablecer la contraseña bajo ningún concepto. 
4.- O al menos, que la cuenta de correo electrónico que uses no sea conocida.
Saludos Malignos!

lunes, octubre 31, 2016

Latch Cloud TOTP versus Google Authenticator

Cuando hablamos de un Segundo Factor de Autenticación, los tokens TOTP (Time One-Time Password) son unos de los más populares. Servicios tan populares como Google, Microsoft, Dropbox o Facebook tienen la posibilidad de configurar una protección extra de la cuenta añadiendo una verificación del código TOTP que el usuario tiene configurado. Hoy os quiero hablar de Latch Cloud TOTP que es otra de las novedades de las que hablamos en el pasado Security Innovation Day 2016 y de cuáles son los detalles y el pensamiento que nos ha llevado a crearlo. Que nadie piense que esto es un "combate" ni nada parecido a ver qué solución es mejor, sino solo una explicación de cuáles son los detalles que de Google Authenticator que nos hicieron crear Latch Cloud TOTP.

Figura 1: Latch Cloud TOTP vs. Google Authenticator

La idea del TOTP es tan sencilla como que un algoritmo, con la misma semilla de parametrización, genera en el lado del servidor y en el lado del cliente un código dependiente del tiempo. Es decir, en el lado del servidor y en el lado del cliente, cada cierto tiempo, se genera el mismo número - el mismo token -. Cuando un usuario va a realizar un proceso de login, primero debe proveer correctamente el usuario y la contraseña, y después de que se verifique que esta es correcta, se debe proporcionar el valor TOTP correcto.

Figura 2: Demo de Latch Cloud TOTP en Dropbox con Latch para iPhone y Lath para Apple Watch

La herramienta más popular para gestionar los tokens TOTP es Google Authenticator, y es válida para usar en servicios como Google, Microsoft, Dropbox o Facebook. Basta con configurar esta protección en tu cuenta y utilizar Google Authenticator para capturar el código QR que transmite la semilla al algoritmo TOTP que generará el código TOTP constantemente.

TOTP en Google Authenticator

Durante mucho tiempo hemos estado jugando con los códigos TOTP de Google Authenticator, y hemos estado haciendo muchas pruebas que paso a contaros, porque creo que son relevantes para entender por qué decidimos hacer un Cloud TOTP en Latch.
1) No garantiza un único dispositivo: Cuando estás configurando un código TOTP en el cliente de Google Authenticator u otro similar, realmente al servidor no se le avisa de en cuantas apps se ha capturado la semilla. Es decir, podrías generar en la misma app de Google Authenticator 4 entradas con la misma semilla y al mismo tiempo copiar en cuatro dispositivos con Google Authenticator la misma semilla, y al mismo tiempo en otras apps. 
2) La semilla se podía robar del backup: Antiguamente, cuando se hacía un backup del sistema operativo, de este se podían sacar los ficheros de las semillas y conseguir regenerar el algoritmo correcto para tener los TOTP en cualquier otro dispositivo. Esto tenía un lado positivo y un lado negativo. 
El lado positivo es que podrías migrar de tu iPhone 6 a tu iPhone 6S todo un backup, y las entradas de Google Authenticator seguían intactas, lo que era una ventaja si se te había perdido el terminal o te lo habían robado, por lo que si tenías el backup podrías recuperar tu Google Authenticator con todas las entradas. 
Figura 3: Robar semillas TOTP de bakup de iOS
El lado negativo es que alguien podría extraer del backup tus ficheros de Google Authenticator y recrear en una app controlada por él tus valores y tener los TOTPs de todas tus cuentas. Además, para que este ataque fuera un poco más sencillo, se unen dos debilidades que pueden aprovecharse que os describo en los puntos 3 y 4.
3) En Google Authenticator se indica el usuario: En cualquiera de las entradas de los TOTP se puede leer con claridad la cuenta de correo a la que está asociada esa entrada TOTP, lo que pone bastante fácil saber a quién hay que robarle la contraseña. De hecho, lo más fácil era hacerse con el backup de Google Authenticator, ver cuáles eran las semillas de los algoritmos TOTP que se habían robado, y hacerles un ataque de phishing a esos para robarles el último factor que hacía falta - la password -.
Figura 4: En cualquier Google Authenticator se ven los tokens TOTP y los usuarios
4) En Google no implementan correctamente las alertas TOTP: Como ya he dicho en otras ocasiones, si te roban la password en Google y entran en tu cuenta, saltaría la verificación del token TOTP, pero no queda ninguna alerta de seguridad en el log si no se intenta poner ningún token, por lo que al atacante no se le detecta a la primera. En el caso de Microsoft, esto se implementa mejor.
Figura 5: En el log de Google no queda que se ha puesto correctamente la password
y no se ha introducido ningún token TOTP durante la verificación en dos pasos.
5) Ahora no migra de un terminal a otro: Para fortificar las semillas, en Google Authenticator ahora, estas se cifran en el keychain con una clave del dispositivo, por lo que es posible recuperar las semillas si y solo si es en el mismo dispositivo. Esto es un problema serio si has perdido el terminal, porque entonces solo te salvarán las Recovery Keys que se obtienen cuando se configura la protección TOTP o si tienes también puesto el número de teléfono, por el SMS (lo que vuelve a convertir el SMS en el primer factor de autenticación). Dependiendo del servicio, se podrían utilizar otros mecanismos como en el caso de Google que se permiten las llaves, los click-OK o los códigos impresos, pero no es lo habitual para todos los servicios protegidos con servicios TOTP, ni además son muy populares en su uso.
6) No protección local de Google Authenticator: En Google Authenticator, si alguien tiene acceso al terminal y abre la app, puede ver los valores de los tokens y a qué cuentas pertenecen porque no hay forma de ponerle una password a nivel de aplicación, tal y como se ve en la Figura 4.
Cloud TOTP en Latch

Sabiendo cómo funciona bien Google Authenticator, decidimos hacer una implementación que funcionara de manera distinta usando Latch a la que hemos llamado Cloud TOTP, que tiene las siguientes características:
1) Asociada a tu cuenta Latch: Cuando se pone un token TOTP en Google Authenticator, este se almacena en uno o varios dispositivos y - ahora - no puede salir de ahí, pero al servidor no se le garantiza ni que se haya puesto en un terminal concreto ni que se haya puesto solo en uno. En este caso, cambiamos el paradigma y lo ponemos en una cuenta de Latch que puede ser abierta en cualquier dispositivo móvil siempre que tengas tu cuenta de Latch (no asociada a tu cuenta protegida con el token TOTP)
2) Sin identificar nombre de cuenta asociada: Aunque en la primera versión utilizamos el mismo funcionamiento de Google Authenticator y mostrabamos la cuenta de usuario, hemos decidido que se pueda renombrar durante el proceso de configuración y después, para que en lugar de poner micuenta@google.com pueda poner algo genérico como "Mi cuenta de Google" o "Mi cuenta de Dropbox", con lo que se disasocia en Latch Cloud TOTP el valor del token del valor de la cuenta y del valor de la contraseña.
Figura 6: El token no se muestra hasta que no se solicita. Queda en el log

3) Con log de acceso al código:
Hemos decidido que en Latch Cloud TOTP, el valor del token no se muestre nada más que durante un instante. Para eso el token TOTP de cualquier semilla estará oculto y se deberá solicitar su muestra. Esto implica que se generará una entrada en el log de Latch que el usuario podrá consultar en el futuro para saber si desde esa app, en un momento concreto, se mostró o no se mostró el código TOTP. No evita las malas implementaciones del servidor, pero sí que permite guardar información que podría ser útil en un posible análisis de logs cruzado con los datos del servidor.
4) Protección de acceso local a Latch: Además de que el código TOTP de una cuenta no se muestra por defecto y debe solicitarse manualemente, dejando un rastro en el log, la app de Latch tiene dos protecciones: Una primera la autenticación contra el servidor, y una segunda la autenticación a nivel de app (integrada con Touch ID en iPhone e iOS). Esto hace que, aunque se tenga el terminal desbloqueado en un descuido, no se pueda acceder a ella sin poner la password o pasar una autenticación biométrica vía Touch ID.
Figura 7: La app de Latch se protege en local con autenticación y por Touch ID en iOS

Con esta aproximación de Latch Cloud TOTP lo que hemos buscado es cubrir un hueco en el uso de tokens TOTP. Dotamos al sistema de una mayor flexibilidad al permitir que los tokens se puedan recuperar desde cualquier dispositivo, y añadimos mayores opciones de seguridad en aspectos como el acceso local vía descuido, la asociación de token TOTP a nombre de cuenta o el control de los tokens TOTP que se entregan, ya que no es un proceso continuo sino discreto bajo demanda que deja rastro en el log.

Figura 8: Cloud TOTP y Latches en la misma app de seguridad

Ahora está disponible en la nueva versión de Latch para Android, y en breve estará disponible en la nueva versión de Latch para iOS. Poco a poco os iré contando por aquí como sacarle provecho a todas las características de este Cloud TOTP en diferentes servicios y entornos. Y lo mejor es que puedes tener en una sola app tanto tus tokens TOTP como tus cuentas protegidas por Latch.

Saludos Malignos!

lunes, abril 25, 2016

PayPal: Di adiós a tu dinero si te confundes con el e-mail

Tras publicar este jueves los fallos de privacidad y seguridad de Uber, en el que explicaba en un artículo que no se verifica la dirección de correo electrónico antes de crear una cuenta de Uber o de enviar información personal del uso de la cuenta, muchos se pusieron en contacto conmigo para contarme otro buen montón de servicios que no verifican la cuenta de correo electrónico antes de comenzar a usar el servicio o enviarte notificaciones con información confidencial. De todos ellos, el que más me sorprendió fue PayPal, un servicio que se promociona como muy seguro, y que cae en un fallo de seguridad tan simple y peligroso para el dueño de la cuenta como este.

Figura 1: PayPal. Di adiós a tu dinero si te confundes con el e-mail

Para comprobarlo le pedí a mi compañero Pablo que creara una cuenta en un minuto para ver si funcionaba de esa forma. decidimos crear una cuenta de PayPal asociada a una dirección de correo electrónico con una dirección que no tenemos y ver si podíamos utilizar esa cuenta de PayPal. Para ello, primero comprobamos que XXXX.rodriguez86@gmail.com es una cuenta que existe en Gmail. Como se puede ver en la siguiente imagen el servicio nos solicita la contraseña, por lo que podemos concluir que la cuenta existe.

Figura 2: Buscamos una cuenta que exista para la demo

Ahora vamos a PayPal y comprobamos los tipos de cuenta que existen a la hora de hacer una nueva. Elegimos la cuenta personal, que es rápida y gratuita. Una vez seleccionada el tipo de cuenta se nos solicitarán una serie de datos. Los datos que nos solicitan para crear una cuenta de PayPal y comenzar a usarla son: País, dirección de e-mail y la contraseña.

Figura 3: Tipos de cuenta en PayPal

Al contrario de lo que pasa con el e-mail, con la contraseña nos pide que la introduzcamos dos veces, para que no nos confundamos, es decir, por precaución para evitar el fallo. Sin embargo, y como se verá más delante, en el caso del e-mail es importante no equivocarse, ya que podríamos acabar creando una cuenta para otro usuario de nuestro proveedor de correo electrónico.

Figura 4: Se verifica la password, pero no la dirección de e-mail

Completamos el resto del registro con los datos más personales del usuario. Si nos fijamos, el número de teléfono móvil puede ser inventado también, no hay tampoco una comprobación de este número para poder comenzar a usar la cuenta. Es decir, no es necesario verificar ninguna información para comenzar a usar la cuenta de PayPal. Pero si te equivocas en el e-mail, la has liado gorda.

Figura 5: Completando la creación de la cuenta.
El número de teléfono no se verifica tampoco.

Una vez nos registramos en PayPal, podríamos esperar a tener que verificar el correo electrónico, pero si nos vamos al sitio web de PayPal podremos iniciar sesión sin ningún problema. Estamos utilizando el e-mail de un usuario de Gmail que no somos nosotros y lo tenemos vinculado a nuestra cuenta de PayPal, por lo que si el verdadero dueño, cuya dirección de e-mail es XXX.rodriguez86@gmail.com (que existe) puede robarnos la cuenta, ¿Cómo? Fácil, pidiendo recuperar la contraseña a través del correo electrónico.

Figura 6: Se puede iniciar sesión. La cuenta está funcionando.

Como se ve en la imagen siguiente podemos recuperar la contraseña a través de esa cuenta de correo electrónico.

Figura 7: Recuperación de cuenta por medio de correo electrónico

Al no haberse hecho una verificación del correo electrónico, el propietario real del correo podría quitarnos la cuenta simplemente restaurando la contraseña con el enlace que recibirá en su e-mail.

¿Y si hubiera puesto el número teléfono correcto?

Pues tu gozo en un pozo. En las opciones de recuperación de cuenta ves que hay una opción que dice "No me acuerdo de la dirección de e-mail" pero no, no sirve para que te manden un código OTP por SMS y solo te comprueban tres direcciones de correo electrónico que te puedan sonar.

Figura 8: Direcciones de e-mail para recuperar una dirección de e-mail

Y si has pesado que en la última opción de recuperación tal vez podrías recuperar la cuenta por medio de un SMS OTP, pues tampoco, PayPal vuelve a solicitar tres direcciones de correo electrónico para ver si alguna de ellas que ya tienes es la que asociaste a tu cuenta de PayPal. Así que, si te equivocas en el correo electrónico, comienzas a usar la cuenta, metes dinero en ella, puede que te quedes sin él, porque el dueño del correo electrónico de verdad podrá recuperar la cuenta y gastarse tu dinero.

Figura 9: Más direcciones de e-mail para recuperar contraseña o dirección de e-mail

Este fallo de no verificar la dirección de correo electrónico no se comete solo cuando se hace el registro de una cuenta, sino cuando se configura para recibir notificaciones. Cualquier sistema que envíe notificaciones con información confidencial - como sistemas bancarios, o aplicaciones con información personales - primero debería verificar que el dueño del correo es el usuario que es el dueño de la cuenta, y así evitar problemas de estos tipos.

Saludos Malignos!

Entrada destacada

+300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial

Hace un mes comencé a recuperar en un post mi interés en los últimos años, donde he publicado muchos artículos en este blog , y he dejado mu...

Entradas populares