Outlook.com .... "¡Tíralo todo por el water!" ( y sé molón)

Ayer estaba borrando correos antiguos porque me estaba quedando sin espacio. Y me di cuenta de un pequeño detalle, con respecto a Outlook.com / Hotmail / Live.com , que me llamó la atención, y es la forma en que gestiona el vaciado de los "Elementos Eliminados" en Outlook.Live.com, que es el equivalente a la "Papelera" de Gmail. Y os lo voy a contar.

Figura 1: Outlook.com .... "¡Tíralo todo por el water!" ( y sé molón)

Veréis, borrando para hacer espacio, eliminé muchos correos antiguos (todos incriminatorios, por supuesto) de una cuenta que tengo en Outlook.com (que es la misma interfaz para Hotmail.com), y cuando fui a los "Elementos Eliminados" para "tirarlos por el water definitivamente", me encontré que de eso nada, durante 30 días se pueden recuperar de los "Elementos Eliminados".

Figura 2: Más de 2.600 correos que no puedo "tirar por el water" en Outlook.com

Esto, es algo que en Gmail funciona como uno espera, vas a la "Papelera", tienes 194 correos eliminados, y le das a "Vaciar la Papelera"....

Figura 3: Tengo 194 correos en la papelea que se eliminarán automáticamente en 30 pero...

que puedo "tirar por el water" ahora mismo.

... y los correos desaparecen para siempre. No se pueden recuperar, y tampoco te dice ni cuantos correos se han eliminado, que es lo que uno espera cuando quiere "tirar todo por el water". Así que, a ver si en pro del control de la privacidad del usuario ponen algo así.

Figura 4: Papelera vaciada correctamente. Ni rastro de ellos.

Como forma de mitigar (en teoría) la limitación de borrar los mensajes automáticamente, te puedes meter en las opciones de "Configuración -> Administración de Mensajes", y marcar la opción de "Vaciar la carpeta Elementos eliminados al cerrar la sesión". No los elimina del todo, porque se pueden recuperar, pero al menos "no se ven". Qué cosa más absurda, ¿no?

Figura 5: Vaciar la carpeta de Elementos eliminados al salir

Me llama poderosamente que un caso de uso tan claro y común de control de la privacidad como querer borrar todo "ipso-facto" no esté disponible, así que a ver si consigo convencer a mis amigos de Microsoft a que lo revisen, y si pueden, que lo pongan en el evolución de producto }:). 

Y si hay alguna opción oculta, por favor... que alguien me lo explique.

Actualización:

Un amigo de Microsoft, especialista en SharePoint, me ha dicho que, efectivamente, es un problema de UX, porque el enlace de la carpeta de "Elementos Eliminados" pone "Recuperar Elementos Eliminados de Esta Carpeta", y debería decir "Recuperar y Borrar Permanentemente Elementos Eliminados de Esta Carpeta".

Figura 6: La carpeta Deletions con opción de Vaciar Carpeta

Y es que, una vez que haces clic en ese enlace, aparece una "Papelera" de segundo nivel que se llama "Deletions", y ahí sí se activa la opción de "Vaciar Papelera". Vamos, que es una decisión de UX que complica mucho al usuario descubrir cómo gestionar su privacidad. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

DMARC: Domain-based Message Authentication, Reporting & Conformance

Cuando se recibe un correo electrónico que no viene firmado digitalmente, siempre es complicado para el destinatario saber si es auténtico o no. Si todos los mensajes llegaran firmados con PGP o S/MIME y las herramientas que utilizamos habitualmente fueran sencillas a la hora de utilizar estas tecnologías no habría que buscar otras alternativas. Por desgracia esto no es así y se han buscado soluciones como SPF (Sender Policy Framework) / SenderID o DKIM (DomainKeys Identified Mail) para paliar esta solución. Pero la situación es aún un poco confusa ya que las configuraciones que hacen muchos dominios de ellos no son correctas y las limitaciones que tienen las tecnologías SPF/SenderID o DKIM hacen que los proveedores de correo electrónico no se atrevan a confiar ciegamente en ellos.

Figura 1: DMARC - Domain-based Message Authentication, Reporting & Conformance

Esta situación ha llevado a que grandes proveedores como Gmail han llegado a obviar completamente SPF o que la firma DKIM de un mensaje de correo electrónico no genere ninguna alerta positiva de verificación en Hotmail, a diferencia de lo que ocurre, por ejemplo, en Gmail con las cuentas de Ebay o Paypal.

Figura 2: Icono de llave en mensajes de Ebay firmados con DKIM

Viendo este ecosistema hacía falta una solución de análisis de los mensajes de correo electrónico que verifique todos los patrones para poder determinar si un mensaje es correcto o no, evaluando las firmas SPF/SenderID y DKIM y tomando una decisión en función de las configuraciones globales. Nosotros en Informática64, tiempo atrás, creamos un plugin para el navegador que hacía estas verificaciones y lo llamamos el Proyecto Apolo. Con él, analizando SPF y la configuración del dominio que lo enviaba, mostrábamos un icono al lado de cada mensaje de correo electrónico en Gmail.

Figura 3: El plugin del Proyecto Apolo mostraba información con las validaciones SPF

En aquel proyecto nosotros no analizábamos DKIM y basábamos todo nuestro trabajo en las configuraciones de SPF y SenderID. Con esta misma idea, hace ya unos años se comenzó a trabajar en un estándar que siguiera las mismas ideas que nuestro proyecto Apolo, pero usando ahora SPF/SenderID y DKIM en la lógica de la validación. Este estándar se llama DMARC: "Domain-Based Message Authentication, Reporting & Conformance" y tiene, además de la validación, la posibilidad de establecer un sistema de reporte para enviar información de los correos que están incumpliendo las políticas y una forma de forzar que las políticas se cumplan en todos los posibles subdominios de una organización.

DMARC: Domain-based Authentication, Reporting & Conformance

El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 4: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -.

En el caso de Hotmail u Outlook.com, los mensajes de algunas grandes compañías que han implantado DMARC y cumplen DKIM y SPF correctamente, reciben un escudo verde en el cliente web, similar a la llave que pone Gmail a los mensajes de Ebay o Paypal que vienen firmados por DKIM. En el caso de DMARC, las verificaciones son SPF y DKIM, por lo que son mucho más estrictas. 

Figura 5: mensajes en Outlook.com de Apple

En la imagen podéis ver cuatro mensajes de correo electrónico provenientes de Apple.com. Los cuatro pasan la política SPF y los cuatro vienen firmados correctamente por DKIM, pero Hotmail/Outlook.com ha puesto el escudo verde solo en uno de ellos porque es lo que han decidido hacer por acuerdo, no porque unos tengan más medidas de seguridad que otros. 

Verificando un política DMARC

Vamos a ver con el cuarto mensaje cómo se comprueban todas las comprobaciones con DMARC para que al final Outlook.com ponga el escudo verde al mensaje de correo. Si miramos el código fuente del mensaje, podemos ver que el dominio del remitente es id.apple.com. Este es el dominio que se ha elegido para verificar los mensajes de correo electrónico que lleguen y ponerle el escudo verde. Todos los mensajes que lleguen de ese dominio serán validados por DMARC a ver si son merecedores del escudo verde o no.

a) Paso 1: Verificación SPF

Primero tenemos que comprobar el registro SPF en el servidor DNS para ver qué direcciones IP son las autorizadas por id.apple.com para enviar mensajes de correo electrónico con su dominio. Como se puede ver la lista está compuesta por 6 segmentos de direcciones IP. Además, la política que se ha elegido para el protocolo de Sender Policy Framework - ya que es un registro spfv1 - es de softfail.  

Figura 6: Configuración SPF de id.apple.com

Si miramos el código fuente del mensaje de correo electrónico podemos observar que ha sido entregado desde un servidor con la dirección 17.151.1.33, que pertenece a uno de los rangos marcados en el registro SPF. 

Figura 7: Verificación de SPF en el correo electrónico recibido 

Por tanto, como se marca en el código fuente del mensaje, aparece como que el correo electrónico ha pasado correctamente la validación SPF.

b) Paso 2: Verificación DKIM

Si miramos el código fuente de mensaje enviado desde id.apple.com, podemos ver cómo viene firmado digitalmente por el servidor que envía el mensaje usando una clave llamada id2048 que el servidor de correo entrante debe poder obtener en el servidor DNS de id.apple.com. 

Figura 8: Firma DKIM del mensaje de id.apple.com

Si nos conectamos al servidor DNS de id.apple.com y buscamos el registro que debe contener la clave, es decir, id2048._domainkeys.apple.com, podemos ver cuál es el valor de la parte pública de esta clave.  

Figura 9: Clave pública id2048 en el DNS de id.apple.com

Además, la política DKIM para Apple.com está configurada con un softfail (o=~) también. En este caso, aún la mantiene en modo test (t=y). 

Figura 10: política DKIM de Apple.com

Para este correo en concreto no hay ningún problema porque el servidor de correo electrónico entrante, es decir, Outlook.com, se ha conectado al servidor DNS, ha recogido la clave pública de id2048 y ha verificado que el mensaje de correo electrónico está correctamente firmado.

c) Paso 3: Política DMARC

Llegados a este punto, debemos revisar la política DMARC de id.apple.com. Esta se encuentra en el registro DNS llamado _dmarc.id.apple.com y tiene una configuración bastante sencilla en la que indica cuáles son las direcciones de correo electrónico a las que se debe enviar información de los correos que no cumplan las políticas SPF y DKIM anteriores. 

Figura 11: Configuración del registro DMARC de id.apple.com

La configuración del registro DMARC en el servidor DNS se hace con un registro TXT en el que hay que configurar una serie de valores. En primer lugar la versión, que a día de hoy es DMARC1, luego las direcciones de e-mail en las que se quiere reportar aquellos mensajes que incumplan las políticas para hacer un análisis forense y en las que se van a enviar los reportes agregados con estadísticas.

Figura 12: Valores de configuración de registro DMARC

Luego, se configuran valores como la política a aplicar, que en el caso de id.apple.com es la de rechazar cualquier correo electrónico que no cumpla con la política SPF y la política DKIM. 

Políticas para subdominos y alineamiento con DKIM & SPF

Una de las cosas interesantes del protocolo DMARC es que tiene en cuenta los ataques que realizan los suplantadores de identidad inventando subdominios con sp. En este caso, muchos servidores de correo electrónico no verifican que los registros SPF de los dominios padres prohiben el envío de mensajes desde una determinada dirección IP y buscan ser entregados al buzón de la víctima como si el subdominio no tuviera configurado el registro SPF. Además, tiene configuraciones para que la política que se aplique sea la configurada en DKIM o SPF, con los valores de alineamiento (adkim & aspf).

DMARC es un paso más para intentar evitar la suplantación de direcciones de remitente en mensajes de correo electrónico que, si es posible, merece la pena que configures en tu organización.

Saludos Malignos!

La astronauta del gobierno que me estafa por Linkedin

Dentro de las tareas rutinarias que tengo metidas en mi vida desde hace años está la de publicar por Linkedin los enlaces a los artículos. Cuando entro a publicar, siempre suelo revisar las peticiones de contacto y leer los mensajes que me han llegado por esa red de contactos. Ayer me envió un mensaje un perfil de una mujer que se presenta como parte del gobierno de los Estados Unidos de America, con su biografía y fotografías a juego. Sin embargo, es un perfil falso que se utiliza para hacer una estafa típica del 419 o del Nigeriano, pero usando la imagen y el medio de Linkedin.

Figura 1: La astronauta del gobierno que me estafa por Linkedin

Como se puede ver, han creado un perfil completo de una personalidad popular. En este caso se trata de la Teniente Coronel Susan Helms, una personalidad muy conocida debido a su carrera como astronauta, al haber sido seleccionada por la NASA en los años 90 para trabajar en la Estación Internacional Espacial, así que hay muchas referencias a ella por todo Internet. Todo un ejemplo.

Figura 2: CV en Linkedin creado con la imagen de la Teniente Coronel Susan Helms

Yo recibí una invitación suya y, como tengo varios contactos de personas del ejercito de los Estados Unidos entre mis relaciones, no le di más importancia. Además, tras haber estado dando recientemente una charla en las oficinas de la Organización de Estados Americanos en Washington D.C., pensé que sería una de las asistentes a dicho evento. Todo parecía normal hasta que he recibido el mensaje vía Linkedin siguiente. Como se puede ver tiene muy mala pinta. Mal escrito, referenciando a una cuenta de correo electrónico de Hotmail, etcétera... Huele a estafa del Nigeriano por todas partes.

Figura 3: Mensaje enviado vía Linkedin

Fijándome ya en el perfil de Linkedin se puede ver que tiene muy pocos contactos, algo extraño para un Teniente Coronel de los Estados Unidos que va pidiendo contactos por la red. Además, entre ella y yo no hay ningún contacto en común, así que vino de forma aleatoria hasta mi buzón, probablemente porque hayan hecho una búsqueda por contactos de correo electrónico que hayan ido consiguiendo. Por último, al final, la Teniente Coronel en Linkedin parece que se ha asentado en Madrid a vivir. Algo posible, pero improbable.

Figura 4: Informe de relaciones entre mi perfil y el falso perfil de Susan

Para terminar de cerciorarme busqué la imagen del perfil usando Google Images y di con la referencia completa de la autentica persona y con referencias a las estafas 419 hechas con esta misma imagen a través de cuentas de correo electrónico, al old-style de las estafas nigerianas.

Figura 5: Referencias a estafas 419 hechas con este perfil

Al final, lo único que han hecho ha sido pasarse a Linkedin para dar mucha más profesionalidad a la estafa. El que contacten a través de de Linkedin, con un CV por delante, con fotos, extracto de vida profesional, etcétera, es mucho más efectivo que una cuenta de correo electrónico de Gmail o Hotmail, así que hay que subir las alertas cuando eso pase.

Reflexión final

Aunque sea Linkedin, sacarse una perfil falso como se hace en Facebook es igual de sencillo. Como nota importante, dentro de los servicios de Vigilancia Digital hay que tener controladas las cuentas de tu organización en Linkedin, ya que puede ser que haya gente que esté impersonando a tus empleados o directivos o que alguien esté dando información de seguridad - me viene a la mente el caso del servidor LifeRay de Apple y el ingeniero del proyecto - o incluso mintiendo. Por si acaso, sube las alertas por si se empiezan a ponerse de moda las estafas 419 por este medio.

Saludos Malignos!

Cómo elegir un "mal desarrollador" para publicar tu app

Tras ya más de un año jugando con nuestra plataforma de investigación en el mundo de las apps Tacyt, hemos realizado muchos informes de seguridad a empresas sobre las amenazas en el mundo de las apps de Android. Una de las cosas que hacemos es generar una documento con las debilidades que vemos a sus apps publicadas, donde como os podéis imaginar la lista de cosas que nos hemos ido encontrando es larga.

Figura 1: Cómo elegir un "mal desarrollador" para publicar tu app

Desde apps con frameworks con bugs conocidos, hasta conexiones de login sin ningún tipo de cifrado, pasando por los típicos leaks de información de infraestructura interna o los accesos a servidores de backend desprotegidos. Son muchas las vulnerabilidades y debilidades que pueden tener las apps si no ha se ha tenido un mimo en su construcción y publicación. Ya sabéis que hackers y developers viven un amor imposible, así que toma nota de qué es una mala elección en tu app.

Mala elección en la cuenta del desarrollador

Hoy quería comentaros unos detalles sobre la cuenta de publicación de a las apps en Google Play. En este apartado quería recalcar que al final, la cuenta que tiene acceso a la plataforma es la autentica dueña de las apps, y es por tanto importante que se tenga muy controlada, en todo momento, esa identidad. Al acceso de esa cuenta se debe poner un segundo factor de autenticación, para que ningún atacante que se haga con la contraseña pueda utilizarla en ningún momento, algo que es evidente, pero además hay que elegir la identidad correctamente para la cuenta de Developer:

- Cuentas gratuitas para instituciones: La verdad es que una de las cosas que llama más la atención es encontrarnos como cuenta de developer para un banco, una empresa multinacional o una gran organización, que el desarrollador es una cuenta de Gmail, Hotmail o iCloud. En todo momento, una persona con algo de cuidado tiende a sospechar de este tipo de apps cuando se buscan apps oficiales, lo que hace que se pierda confianza y por tanto baje el número de apps descargadas. Si tienes una de esas, pon un 2FA y ten cuidado no te la estén espiando.

Figura 2: Apps con la palabra Bank en el Título de la app y cuenta de desarrollador de Gmail

- Cuentas de desarrolladores personales: Otra de las cosas curiosas es que, cuando encuentras una cuenta de correo electrónico para el desarrollador que no es genérica, y parece que es personal, como por ejemplo lucas.martin@miorg.lol también suceden problemas, que hay que tener presentes: 

Figura 3: John King era el desarrollador de esta app del South Bank

- La cuenta ya no existe: Si la app tiene un poco de tiempo, basta con enviarle un mensaje de correo electrónico para ver si esa cuenta sigue existiendo o no. Si no existe, tenemos un problema a corto, pero es que además puede que el empleado ya trabaje para otra empresa. 

- La cuenta no se puede tocar: Esa cuenta pertenece a una persona, y en muchos casos va a ser totalmente imposible meterle mano sin el permiso de esa persona. Re-crear la cuenta o cambiar la password para poder acceder a sus mensajes puede suponer un problema legal para la organización. 

- La cuenta tiene perfiles de redes sociales: La imagen es más divertida si la cuenta del desarrollador es una cuenta personal que tiene asociados perfiles en redes sociales,  como Facebook, Twitter, etcétera, lo que puede ser muy útil para saber más del desarrollador y la imagen de la empresa. Acabas de crear un portavoz de la organización sin pensarlo. 

Figura 4: Cuenta de Gmail personal para una app del Everest Bank

- Objetivo claro de APT: Por supuesto, si hay una organización enemiga que quiere hacerte un APT, acabas de apuntar con dedo a la persona clave a la que hay que atacar, así que más vale que le hayas puesto un buen entrenamiento de seguridad para evitar problemas.

- Cuentas de desarrolladores de empresas terceras: Esta es otra de las cosas que nosotros miramos. Muchas de las apps están subcontratadas, por lo que es fácil saber qué empresa es la encargada del desarrollo con este tipo de cuentas. Esto puede generar:

- Salir en listas no deseables: Esto puede dar situaciones cómicas, donde el desarrollador hace apps de muy diverso ámbito y la empresa puede aparecer listada en lugares poco deseables en el futuro. Una empresa que es capaz de cuidar sus referencias en proveedores al extremo, pierde el control total al utilizarse una cuenta que delata su procedencia. 

Figura 5: Todas las apps creadas por la misma empresa. Todas son cuasi-iguales

- Riesgo de seguridad asumido: Además, se acaba de asumir en el plan de riesgos la seguridad las políticas de seguridad y los fallos que tenga esa empresa, así como se ha extendido la superficie de exposición de la compañía.

Lo ideal es que se controle totalmente esa cuenta de developer y se tenga protegida dentro de la compañía para evitar cualquier problema de imagen y/o seguridad asociada a la app. Es algo fácil de controlar y que no requiere grandes esfuerzos - solo organizativos -, así que revisa cuáles son los desarrolladores de tus apps y toma medidas. 

Saludos Malignos!

Gmail & Hotmail: Cómo saber si ahora mismo te están espiando

Hace algo de tiempo os hablé de cómo había visto unas campañas de robo de cuentas de Gmail y Hotmail por medio de tokens de acceso OAuth a la cuenta. Ahora, unas semanas después me he topado con el caso de una persona a la que habían conseguido engañar para robarle los tokens. Ese acceso además, lo utilizaron para leer durante mucho tiempo su correo electrónico y preparar un ataque a su vida personal y robarle dinero del banco. El esquema que usaron los cibercriminales fue el mismo que os conté el año pasado en el artículo "Dos casos reales de robo de dinero", en concreto el caso de la transferencia bancaria desde el correo electrónico.

Figura 1: Gmail & Hotmail: Cómo saber si ahora mismo te están espiando

Todo lo que se había utilizado en el esquema era información que estaba en los mensajes de correos electrónicos Enviados y Recibidos. Datos de cuentas, documentos, información personal para demostrar conocimiento y familiaridad con la persona del banco e incluso secciones de texto copiadas de correos electrónicos para repetir mismos términos y formalismos. Cuando tuve que analizar este caso, y viendo que la cuenta en un Hotmail, rápidamente pensé en el truco de los tokens OAuth de acceso al buzón, y ahí estaba la app fraudulenta que había conseguido acceso al buzón.

Figura 2: Una cuenta monitorizada durante meses por una app fraudulenta

Como podéis ver, la cuenta estaba monitorizada desde el mes de Abril, pero habían estado esperando el mejor momento para poder trazar el plan de ataque, que se llevó a principios de Junio. Se tomaron todo el tiempo del mundo porque prácticamente nadie vigila los tokens OAuth que ha concedido. Por supuesto, el truco se completa simulando que es una conexión con una cuenta Google, algo que la víctima no tiene.

Puntos de revisión de tu cuenta de Hotmail y Gmail

Visto esto, os quiero dejar unas recomendaciones de seguridad que os recomiendo que hagáis ahora mismo en Gmail y Hotmail para descubrir si os están espiando el correo electrónico ahora mismo. Si es así, tomad las medidas de protección que os dejo después:

Revisión de Tokens OAuth: Como ya os expliqué en el otro artículo, debéis ir a las siguientes URLs y quitar acceso a todas las apps a las que hayáis concedido un token de acceso a vuestro buzón y no lo sepáis.

Figura 3: Apps conectadas a tu cuenta de Google

- Apps conectadas a tu cuenta de Hotmail
- Apps conectadas a tu cuenta de Gmail

Revisar cuentas a las que se reenvía el correo: A veces cuando se tiene acceso a tu cuenta, alguien deja una cuenta de reenvío para seguir viendo tus mensajes de correos electrónicos aunque le quiten acceso: 

Figura 4: Opciones de reenvío de correo electrónico en Hotamil

- Cuentas a las que se envía tu correo de Hotmail
- Cuentas a las que se envía tu correo de Gmail

Poner un sistema de verificación en dos pasos: Tanto en Hotmail como en Gmail es imposible utilizar Latch - salvo como un hack para Gmail - pero sí que es posible en ambos utilizar Google Authenticator, así que tanto si tenías a alguien leyendo tu correo electrónico con alguno de los dos trucos anteriores como si no, puede que alguien te haya robado tu contraseña y esté entrando a tu buzón, así que:

Figura 5: Google Authenticator para entrar en Gmail

- Cambia la password ahora mismo
- Configurar Verificación en dos pasos en Hotmail
- Configurar Verificación en dos pasos en Gmail

Es una pena cuando alguien tiene acceso a tu correo electrónico, ya que una vez que se han llevado todos tus datos se los han llevado para siempre y deberás pasar mucho tiempo cambiando la información que puedas, avisando a personas con las que trabajas y estando vigilante a lo que pueda pasar con tu vida digital en el futuro. Si esto te sucede, mira la posiblidad de contratar un seguro contra el robo de identidad.

Saludos Malignos!

Spam con Phishing para robarte Tokens OAuth de tus cuentas de Microsoft o Google

Últimamente me he topado con muchos casos de personas que han sufrido un espionaje y robo de sus cuentaas de Google y Microsoft Live con un truco bastante sencillo y bien pensado. Se trata de conseguir unos Tokens OAuth que autoricen al atacante a acceder a las partes de la cuenta que le interesen. Con el Token OAuth con los permisos correctos, una atacante podría acceder a todos los datos de la cuenta, además de realizar múltiples acciones con la cuenta, como enviar correos electrónicos, leer tus mensajes, descargarse tu lista de contactos, etcétera.

Figura 1: Spam con Phishing para robarte tokens OAuth de tus cuentas Microsoft o Google

Para entenderlo, digamos que las cuentas de Microsoft, Google, Facebook o Twitter, tienen una serie de datos en ellas, además de una serie de funciones. Cuando se quiere autorizar a un tercero, por ejemplo una aplicación que configure el calendario de eventos - por poner algún caso de manipulación de cuenta -, o a un lector de noticias RSS para que lea tu dirección de correo electrónico, se debe pedir permiso al usuario. Para ello, el usuario debe aprobar que se genere un token OAuth que permitirá a cualquier app identificarse e interactuar con la cuenta con los permisos que se le hayan concedido. 

Figura 2: Esquema de flujo de funcionamiento de OAuth 2.0

Estas implementaciones de OAuth 2.0 en Microsoft se conocen como Live Connect, y en cada uno de los proveedores de identidad tiene un nombre similar, como Facebook Connect, o Mobile Connect cuando hablamos de la identidad de los números de teléfono.

Un spam con phishing para lograr el token OAuth

Para conseguir este token con permisos autenticados hay que conseguir que la víctima acepte conceder dichos permisos, así que como siempre, el recurso más fácil es el de hacer una campaña de phishing con un buen gancho. En los últimos días he visto campañas de falsos premios de Netflix, Media Mark y Spotify, que te permitían acceder a servicios gratis.

Figura 3: Correo de spam con un phishing de Spotify que lleva un enlace a una web

El enlace del "call-to-action" que lleva cada uno de estos mensajes lleva a un servidor web hackeado de alguna empresa, pero que, cada vez que se hace clic, fuerza un redirect, tal y como se puede ver en la siguiente imagen.

Figura 4: El redirect para la generación del token OAuth

El sitio al que lleva es al panel de aprobación de Tokens OAuth con permisos de acceso a la cuenta del proveedor de la identidad que se quiere robar.

Figura 5: Login para generar un token OAuth que de acceso a tu cuenta de Microsoft

En el caso de Microsoft, como es este ejemplo, llegaremos a la página de login de Live, donde se solicitará el usuario, la contraseña, y el segundo factor si fuera necesario, para poder aprobar la generación del token.

Los permisos del token OAuth

Por supuesto, el sitio es un sitio original de Microsoft por lo que para muchos usuarios puede parecer normal, pero si nos fijamos en la URL del redirect, podemos ver que estamos concediendo los permisos de: wl.signing, wl.basic, wl.emails, wl.emails_contacts. Si revisamos los permisos en la documentación de Microsoft podemos ver que esto significa lo siguiente:

Figura 6: Permisos de acceso a tu cuenta Microsoft con Live Connect

Al final, le estamos permitiendo que esa app maliciosa que ha sido creada para esta campaña, sea capaz de acceder a todos los datos de las cuentas a los que permiten los permisos que se conceden a ese token y que como veis son muchos.

Figura 7: Lista de permisos de acceso extendidos de Live Connect

Una vez que se consigan esos accesos, es fácil para la aplicación maliciosa conseguir expandiéndose como un gusano enviando nuevos correos electrónicos al resto de los contactos de la víctima para conseguir más tokens y más objetivos.

Revisar los Tokens de acceso a tu cuenta condecidos

Tanto en Microsoft, como en Google, como en Facebook, puedes revisar que apps han sido autorizadas con un Token OAuth y con qué permisos, por lo que lo suyo es que lo revises periódicamente. En el caso de Microsoft puedes ir al siguiente enlace y ver qué apps tienes conectadas, si ves algo raro, quítale el acceso.

Figura 8: Aplicaciones conectadas con una cuenta Microsoft

Lo mismo en Google, en el siguiente enlace de tu cuenta puedes ver qué apps tienes conectadas y revocarle el acceso si lo consideras oportuno.

Figura 9: Aplicaciones conectadas a una cuenta Google

Una vez más, ten mucho cuidado con los enlaces que te llegan en correos electrónicos de conocidos o amigos, pero sobre todo evita autenticarte y aprobar accesos a tus cuentas si no sabes a qué lo estás haciendo. Como recomendaciones finales, revisa periodicamente las propiedades de seguridad de tu cuenta y pon segundos factores de autenticación en todas tus identidades.

Saludos Malignos!

Cómo te pueden robar tu Gmail con un ataque RTL-SDR

Esta semana me tocó dar una charla en un evento llamado 5Talks en el que me pidieron algún tema de seguridad en móviles. Para la ocasión yo llevé una charla que se llamó "Tu iPhone es tan (in)seguro como tu Windows" en la que recogía algunas de las formas en las que puede atacar un iPhone a pesar de su cifrado robusto. Todas ellas están en el libro de Hacking iOS {iPhone & iPad} y muchas de ellas han salido ya por este blog.

Figura 1: Cómo te pueden robar tu identidad con un ataque RTL-SDR

Entre todas las técnicas para atacar a un usuario con un smartphone, hay una que es curiosamente extremadamente peligrosa. Se trata de robar una identidad por medio de un ataque RTL-SDR de la forma más sencilla, haciendo algo similar a Robar una cuenta de Hotmail o Gmail usando Siri. Os cuento la idea.

He olvidado tu contraseña de Gmail o Hotmail

Si no has tenido precaución de poner un segundo factor de autenticación con Google Authenticator o con cualquier otro sistema para proteger identidades digitales, entonces tu cuenta está protegida solo por la contraseña, o por contraseña más OTP enviado por SMS.

Figura 2: Solicitar la recuperación de contraseña vía código SMS

Esto permite a cualquier atacante intentar quitarte la cuenta cambiando la contraseña de tu identidad siguiendo el formulario de "He olvidado mi contraseña". Entre los métodos que se pueden solicitar está el de envío de un código temporal de recuperación de cuenta, que se puede enviar vía SMS para que te llegue a teléfono móvil.

Figura 3: Visualización del código de recuperación con la pantalla bloqueada

Si tienes la previsualización de mensajes en el terminal y el atacante tiene alguna posibilidad de acceso físico, se podría ver el código en la ventana bloqueada y robar la cuenta, pero si no... se puede hacer uso de un ataque RTL-SDR. 

Capturar el mensaje SMS con RTL-SDR

El ataque RTL-SDR se basa en sintonizar una antena de comunicaciones en la banda GSM para capturar el tráfico que por ella circula y después descifrarlo con las rainbow tables que se publicaron para ello. Si el dueño de la identidad que se quiere robar tiene el teléfono encendido y está en la misma zona geográfica, solo sería necesario pedir el envío del código de recuperación de contraseña vía SMS y capturarlo tal y como se explica en este artículo.

Figura 4: Adaptando la señal para capturar canal GSM

A partir de este momento se podría cambiar la contraseña. Una vez cambiada la contraseña, si la persona tuviera puesto un OTP (One-Time Password) basado en SMS, entonces sería necesario seguir capturando los SMS hasta conseguir el OTP y acceder a la cuenta. Y fin.

Figura 5: SMS capturado con WireShark usando RTL-SDR

Este ataque NO se puede hacer en todas las estaciones base ni en todas las operadoras, ya que algunas están desplegando ya nuevos protocolos de cifrado A5/3, pero en las antiguas estaciones base sí, es conveniente poner sistemas Time-Based OTP, Latch o similares para evitar estos ataques. Si quieres saber más de estos ataques, te recomiendo el libro de Hacking de Comunicaciones Móviles.

Saludos Malignos!

Cuentas robadas y bloqueos en Yahoo!, Gmail y Hotmail

Gestionar la seguridad de cualquier servicio online que sea ofrecido por Internet sin poner un ojo en los rincones de la red donde se encuentran las guaridas de los ladrones de identidad es imposible. Es por eso que para todas las empresas que precien la seguridad de sus sistemas su CPD hace tiempo que se convirtió en un Mundo Sin Fin. Con estas cosas en mente fui a probar a ver cuánto tardan las cuentas identidades robadas de los servicios de Hotmail, Yahoo! y/o Gmail en ser bloqueadas o qué medidas de seguridad tenían después de ser expuestas en algún rincón de Internet, y la verdad es que ha sido un resultado curioso que os cuento por aquí.

Buscamos un dump fresco

Para hacer la prueba me dediqué a buscar en Pastebin algunos ficheros con dumps de passwords que no llevaran mucho tiempo publicados. La idea es tan sencilla como filtrar los resultados por fecha y hacer las búsquedas adecuadas para que aparecieran los dumps. Alguno con varios miles de claves, otros con solo algunos cientos, pero en todos ellos con cuentas de Microsoft, Yahoo! y/o Hotmail, que es lo que quería probar y que seguramente habrían sido robadas por medio de algún malware in the browser.

Figura 1: Dump con 3708 cuentas con 24 horas de antigüedad

Pruebas con los sistemas de protección "autenticación adaptativa"

En el caso de Gmail lo cierto es que si las cuentas tenían más de 24 horas no parecían funcionar ninguna de ellas, pero en algún caso llegué al segundo factor de verificación. Este segundo filtro de seguridad salta debido a que la huella digital de la conexión de esa cuenta no le encajaba a Gmail, y por tanto - con buen criterio - se asumía que había posibilidad de que no fuera una conexión legítima.

Figura 2: Segundo factor para una cuenta robada de Gmail.

La huella digital de la conexión se genera para conocer el patrón de conexión habitual de un cliente, como su región geográfica, su navegador, y la configuración del entorno de completo, algunas veces con técnicas de fingerprinting del navegador exhaustivo. Con estos datos, si se nota un cambio radical lo que debe hacerse es bloquear la conexión con un segundo desafío.

En el caso de Microsoft Hotmail las cuentas tampoco parecían bloqueadas, pero si protegidas por alguna capa extra debido al "número" de conexiones simultáneas desde diferentes zonas geográficas, y de nuevo aparecía un desafió de segundo factor.

Figura 3: Cuenta con protección, pero la password parece funcionar

En el caso de Yahoo! de nuevo apareció un comportamiento similar. Primero un captcha doloroso que obliga a afinar tu humanidad para reconocer los números y las letras, y luego una verificación extra cuando la contraseña era correcta para poder continuar.

Figura 4: Segundo factor en Yahoo! para una cuenta robada. Contraseña funciona.

En todos los casos el haber realizado las pruebas desde la red TOR sumado a la huella digital de las conexiones parece que genera alertas extras de seguridad, lo que tiene más que todo el sentido del mundo. Es por eso que yo me "quejé" de que el comportamiento de algunos bancos en su banca online no detectarán un cambio de conexión en la huella digital tan brutal como conectarse a la cuenta por medio de la red TOR cuando antes nunca se había realizado.

Para terminar, también probé alguna cuenta de Facebook, pero al salir por un nodo en la red TOR situado en alguna dirección IP de algún país remoto, acabé topándome con una barrera idiomática. 

Figura 5: Cuenta de Facebook ...¿?

Lo cierto es que con las cuentas de Facebook, a veces puedes saber mucho sobre la víctima, ya que con las búsquedas en el propio Facebook es fácil saber a quién le han robado la cuenta en cada momento.

Rompiendo la barrera geográfica

Por supuesto, también hay dumps con la dirección IP de la víctima, lo que ayuda a que sea más fácil saltarse la validación de "ubicación extraña" si controlas algún equipo cerca de esa ubicación geográfica.

Figura 6: Dump con usuarios, passwords y direcciones IP

Dicho esto, os recomiendo a todos que pongáis un second factor authentication tipo Google Authenticator a tu cuenta Gmail, una verificación en 2 pasos para Apple o asociar un número de teléfono para poner un OTP en Hotmail, o poner un Latch en los servicios que ya puedas... just in case.

Saludos Malignos!