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.
Desde que lanzamos la característica de Latch Cloud TOTP hemos ido sacando algunos tutoriales y vídeo tutoriales para configurar las protecciones de Verificación en Dos Pasos con TOTP utilizando Latch. En el post de hoy os recojo todos los que hemos publicado hasta ahora en el blog de ElevenPaths, en El lado del mal o en Seguridad Apple.
Figura 1: Vídeo tutoriales de configuración de Latch Cloud TOTP
Por supuesto, si tienes dudas y quieres saber cómo se utiliza Latch, o configurarlo en algún sitio ya sea la protección de Latch o de Latch Cloud TOTP, en la Comunidad de ElevenPaths - donde somos ya casi 800 personas - puedes consultar cualquier duda. En los enlaces debajo de los vídeos están los artículos - si los hay - con el paso a paso de configuración.
Para la última parte de esta serie podemos hacer exactamente el mismo ataque que hemos visto en el caso anterior pero ahora contra una cuenta de Windows Live. Para ello podríamos utilizar la misma App que creamos inicialmente o crear otra distinta, y podríamos usar el mismo correo electrónico con ingeniería social o distinto, pero deberemos cambiar la SCOPE_LIST del correo de petición de permisos para adecuarlos a los disponibles en Windows Live, que son distintos a los que existen en Office 365.
Figura 30: Atacando cuentas de Windows Live
Una vez que la víctima decidiera aceptar dar permisos a la app "besar al sappo" con un clic en YES, nuestra plataforma recibiría un AccessToken que le permitiría invocar la API de Windows Live para acceder a todos los recursos concedidos. Como se puede ver, en la implementación existente a día de hoy en Windows Live no se permite - aún - acceder al correo electrónico, aunque sí que existen los SCOPES definidos para ello. Actualmente, están en un proceso de migración que todavía no han concluido y en el que pronto dejarán disponible el acceso para todos los buzones.
Figura 31: Un AccessToken válido para una cuenta de Windows Live en Sappo
Desde nuestra plataforma es posible, sin embargo, hacer uso de otras APIs, como acceder a los contactos o al servicio de almacenamiento de ficheros OneDrive. Como parte de la PoC hemos implementado el acceso a OneDrive de forma gráfica, así que basta con hacer clic en el botón de OneDrive y acceder a la estructura de documentos contenida.
Figura 32: Accediendo a los documentos de las carpetas de OneDrive
Allí se pueden descargar todos los ficheros, navegar por las carpetas para ir buscando documentación e, incluso, lanzar consultas de búsquedas de palabras dentro de documentos, lo que ayudaría a encontrar la información de forma mucho más dirigida.
Figura 33: Con la API de OneDrive en Windows Live se pueden buscar docs
Al igual que en el caso de Microsoft Office365, en Windows Live es posible ver los permisos concedidos a las apps. En este caso, además es posible ver en detalle todos los permisos que se han concedido. Hay que ir a la zona de Aplicaciones y Servicios y allí estará la app.
Figura 34: Lista de Apps con permisos concedidos
Y si hacemos clic en detalles podremos ver la lista detallada de todos los permisos que se han concedido a esta app.
Figura 35: Lista de permisos concedidos a esta app
Dependiendo de cuál sea el IDP las funciones que se podrían realizar con este tipo de Apps maliciosas cambiará, pero al final el concepto es siempre el mismo. Conseguir un AccessToken para una serie de SCOPES e implementar el acceso.
Ask the Experts
Como hemos venido contando a lo largo de la serie, al final el gran problema es que hemos estado entrenando a los usuarios a detectar un tipo de ataque de phishing muy concreto en el que se solicitan las credenciales a través de una página web alojada en un servidor hackeado o falso en el que no se identifica de forma correcta el dominio del sitio, pero todas estas recomendaciones fallan cuando hablamos de un ataque de Spear App.
Figura 36: Pregunta a los expertos }:)
Cuando el usuario tiene que dar clic en YES - besar al sappo - lo hace en el sitio web original de Microsoft. Está en el dominio Microsoft.com, está bajo una conexión HTTPs, con un Certificado Digital de Validación Extendida - verde - que es correcto y pertenece a Microsoft, y además nunca se está solicitando ningún usuario ni contraseña.
Figura 37: La URL está dentro de Microsoft.com siempre
Además de todo eso, el filtro AntiPhishing implementado en el navegador tampoco puede detectar nada ya que la URL en la que se está es la correcta de Microsoft, y no va a bloquearla. Hay que entrenar a los usuarios para detectar este tipo de ataques con Spear Apps, además de entrenarlos para detectar el Spear Phishing.
Soluciones: Awarenes & Cloud Analytics
Como posibles contramedidas a estas soluciones se presentan varias alternativas. Por supuesto, reforzar las tecnologías AntiSpam en los sistemas de correo electrónico debería ser parte de la estrategia, pero al basarnos en servicios de Cloud Pública como Office365 no hay demasiado que hacer en ese aspecto. Lo que sí que se puede hacer es una monitorización activa de las situaciones anómalas por medio de un análisis de los logs de los proveedores de Cloud, tal y como hacemos en nuestros servicios de Security Monitoring.
Figura 38: Security Monitoring de Eleven Paths basado integrado con LogTrust
En Microsoft Office 365 es posible acceder a los logs de actividad de todas las cuentas de un dominio corporativo para proceder a su análisis. Un Sistema de Detección de Intrusiones en Cloud que analice estos logs para detectar patrones anómalos o comportamientos no habituales podría detectar la aparición de una nueva app asociada a un buzón de correo.
Figura 39: Esquema de funcionamiento de Elastica de Blue Coat
Tecnologías como LogTrust que permite analizar todos los logs y crear reglas de uso o soluciones como Elastica de BlueCoat pueden dar soporte a este tipo de trabajos a realizar por los equipos de seguridad de una empresa.
Soluciones: Cifrado de Nube Pública
Por último, otra opción posible para evitar el robo de datos por medio de apps maliciosas podría ser el uso de soluciones de cifrado de datos de nube pública. En este caso, una solución como Vaultive que cifra Office 365 haría que, si una app consigue permisos para acceder a los correos mediante un AccessToken, esta app no pueda acceder a los datos descifrados de la cuenta si no lo hace vía el Gateway corporativo que realiza el cifrado y descifrado de los datos.
Figura 40: Cifrado de Office 365 con Gateway de Vaultive
En esta conferencia tienes un ejemplo de cómo funciona Vaultive en Office 365, que estuvieron en nuestro Security Innovation Day mostrando la integración que han hecho con Latch.
Figura 41: Cifrado de Office 365 con Vaultive
Si la app consiguiera el AccessToken, pero intentara acceder desde fuera de la red de la empresa - sin pasar por el gateway que cifra y descifra la nube pública - entonces obtendrías todos los datos de los mensajes de correo electrónico cifrados, tal y como se ve en la siguiente imagen.
Figura 42: El correo al que se accede está cifrado.
Una aplicación maliciosa podría seguir destrozando los correos o accediendo a la lista de remitentes, pero nunca podría leer los correos electrónicos del buzón, ya que están todos cifrados.
Conclusiones
Estas técnicas no son nuevas, y en el mundo del cibercrimen se han utilizado puntualmente en muchos escenarios de ataque. En el pasado ya se habló por aquí de ataques de SPAM Phishing para conseguir Tokens OAuth y es una de las recomendaciones de seguridad de Hotmail y Gmail que debes revisar para saber si te están espiando ahora, pero es importante que los responsables de identidades en las organizaciones sean totalmente conscientes de los peligros de estos ataques que son mucho mayores que los típicos ataques de Spear Phishing - ya de por sí muy peligrosos en las organizaciones -.
Llegados al punto anterior, en el que el usuario tiene que elegir entre conceder o denegar los permisos, es cuando termina la última medida de seguridad. Si el usuario decide concederlos, a partir de ese momento - y hasta que le sean revocados los permisos o caduquen sin ningún proceso de renegociación el AccessToken - la app podrá acceder a todos los recursos indicados en la lista de SCOPES.
Figura 21: Atacando cuentas de MS Office 365
Cuando el usuario hace clic en YES, en el end-point marcado en Redirect-URI se recibirá el AuthCode, que le permitirá a la aplicación solicitar el AccessToken. Esto se hace de esta forma porque en la petición del AccessToken debe indicarse el Application ID y el Secret para demostrar que se es el dueño de la app que quiere los permisos. La petición que se debe realizar para solicitar el AccessToken es como la que sigue a continuación:
POST common/oauth2/token HTTP/1.1 Host: https://login.microsoftonline.com Content-Type: application/x-www-form-urlencoded grant_type=[authorization_code]&code=[authCode] &client_id=[client_id]&client_secret=[secret]
&redirect_uri=[redirect_uri]
Como se puede ver, se solicita que se entregue lo que sería el AccessToken en Redirect_URI, y si el AuthCode entregado es el correcto, lo que devolverá el servidor del IDP, en este caso Microsoft, será un token de acceso.
JWT (JSON Web Token)
En el caso de Microsoft el token llega en formato JWT que no es más que una cadena URL Encoded en BASE64 con una estructura de tres partes: Cabecera, Payload y Firma. En la siguiente captura se puede ver un token recuperado en formato JWT.
Figura 22: JWT completo con las tres partes
Si decodificamos la cadena en BASE64, podremos ver que en el payload está la información completa de toda la sesión de acceso. En ella aparece la información de la app, la lista de permisos y los datos de la cuenta que ha concedido los permisos.
Figura 23: Información decodificada del payload
Este token, en bruto, tendrá que ser enviado en cada petición de acceso a los recursos de la cuenta en el IDP siempre que se haga una llamada a la API de Office365 o Windows Live. Las peticiones habrán de ser hechas siguiendo el formato que aparece a continuación:
GET https://login.microsoftonline.com/common/oauth2/authorize HTTP/1.1 Host: login.microsoftonline.com Authorization: Bearer [Access_Token]
Usando la API de Office365 para acceder a los recursos
Todo este proceso está automatizado en nuestra plataforma, así que cuando el usuario acepta - besa al sappo - lo que aparecerá en la lista de tokens serán todos aquellos válidos que pueden utilizarse para acceder a los datos de la cuenta.
Figura 24: AccessToken válido en Sappo para acceder a una cuenta Office365
En el caso de Office365, el acceso es completo a los correos electrónicos, así que podemos listar todos los mensajes en la bandeja de entrada o en cualquiera de las carpetas de la cuenta. Para que sea más sencillo lo hemos integrado en un interfaz de usuario que permite navegar por el buzón.
Figura 35: Acciones implementadas con ese AccessToken en Office365
Entre las opciones, está también la de borrar el mensaje de correo y, lo que es más peligroso, la de enviar mensajes desde la cuenta.
Figura 26: Envío de correos usando la API de Office365 y el AccessToken
Estas tareas se podrán realizar mientras que el acceso a la aplicación en Office365 no sea revocado. Para ello, el usuario debería irse a la parte de Configuración de Office 365, y en la sección de Permisos de Aplicación, eliminar el acceso a sus datos de cualquier app no deseada.
Figura 28: Lista de todos los correos. Se pueden visualizar completos y con adjuntos.
Una cosa curiosa es que las nuevas apps con permisos concedidos tardan un rato en aparecer y, cuando aparecen, no tienen por qué permitir acceder a la información detallada de la app. Lo más normal es pedir información de los permisos de la app y no poder acceder a ellos en Office365 si la app es maliciosa como las que creamos aquí.
Figura 29: Aplicación con permisos en el perfil del usuario de Office365
El funcionamiento es análogo, pero no exactamente igual, en Windows Live, así que en la siguiente parte veremos un caso usando otra implementación de Microsoft.
Entendiendo cómo funciona el sistema descrito en la primera parte de este artículo, ya es posible trazar cómo sería un ataque de este tipo. El esquema que se debe seguir consistiría en los siguientes puntos.
1) Construir una aplicación Sappo para el IDP a atacar 2) Construir una URL con la solicitud del SCOPE (los permisos) adecuado 3) Conseguir el AuthCode cuando el usuario "bese" el "Sappo" 4) Con el AuthCode solicitar el AccessToken 5) Con el AccessToken acceder a todos los servicios vía API
Figura 11: Creando la aplicación Sappo
Construcción de la aplicación Sappo
Como en este ejemplo vamos a hacer el ataque contra cuentas de Office365 y Windows Live, necesitamos crear una aplicación Sappo en la plataforma Microsoft que nos ayude a extraer los datos de las cuentas que confíen en ella. Para ello, con cualquier cuenta de Outlook debemos ir a la dirección apps.dev.microsoft.com y crear una nueva aplicación. Allí recibiremos un Application ID y un Secret, además de que deberemos especificar un servidor con un end-point donde vamos a recibir el AuthCode y el AccessToken. Este servidor deberá estar en nuestra infraestructura y deberemos poner un programa que escuche las llamadas.
Figura 12: Creación de una aplicación en Microsoft
Para controlar la aplicación Sappo, en nuestra infraestructura "Sappo" registramos los datos de la app que acabamos de crear. Esto nos permitirá después poder hacer uso de la API de Office365 y/o Windows Live a través del AccessToken concedido a la app por parte del usuario directamente desde nuestra plataforma.
Figura 13: Registro de la app en Sappo
Una vez que ya tenemos la app creada, ya se pueden crear las solicitudes de permisos, para ello, será necesario que el usuario haga clic en YES por lo que la ingeniería social cobra mucha fuerza. En el ejemplo anterior la app la he llamado Sappo, para dejar claro que es a esta app a quién el usuario debe "besar", pero para conseguir mayor impacto en Ingeniería Social se deben buscar nombres más suculentos.
Figura 14: Una App llamada MS AntiSpam PRO O365
Para nuestra presentación, elegimos crear una app que simulara ser un AntiSpam Pro gratis, lo que no llamaría mucho la atención cuando se piden permisos para leer y escribir el correo electrónico. Pos supuesto, el domino del endpoint y el logotipo serán fundamentales para acabar de dar el efecto adecuado en cada caso.
Construcción de la URL de petición de SCOPES
Para conseguir los permisos adecuados, el usuario debe navegar al servidor de Microsoft con una URL que debe llevar el siguiente formato:
GET https://login.microsoftonline.com/common/oauth2/authorize/common/oauth2/authorize?scope=[scope_list]& response_type=[code]&client_id=[client_id]&redirect_uri=[redirect_uri]
Como se puede ver, es necesario identificar qué app es la que solicita los permisos, en este caso Client_id, después hay que especificar la lista de permisos que se quieren obtener en Scope_List y por último que lo que se espera obtener es un AuthCode que deberá ser entregado en Redirect_URI.
Figura 15: Algunos SCOPES de Windows Live
La lista de permisos que hay en Windows Live es grande, y aunque en algunos de ellos se especifica que es posible leer y escribir el correo electrónico vía API, lo cierto es que en muchas cuentas no está permitido aún. Eso sí, se pueden acceder, por ejemplo, a los documentos de OneDrive como veremos en una de las demos, o a la lista de contactos.
Figura 16: Más SCOPES de Windows Live. Acceso a OneDrive y OneNote
En el caso de Office365 sí que están disponibles las APIs para acceder al correo electrónico y, por tanto, leer, enviar correos electrónicos o borrar mensajes de las diferentes carpetas del buzón de la víctima.
Figura 17: SCOPES en Office365
Una vez que se envía genera la URL, lo suyo es hacérsela llegar a la víctima mediante un correo electrónico que le engañe. En nuestro caso hemos elegido un correo de Microsoft que personaliza el mensaje y lo envía como si fuera un AntiSpam Pro. Esta personalización la hacemos directamente desde la herramienta Sappo, en la que solo debemos elegir una nueva víctima a la que vamos a enviar una app Sappo.
Figura 18: Enviando el ataque de Spear APP
El correo que se envía en este ataque está hecho como si fuera un mensaje auténtico, así que si el usuario no está especialmente alerta contra estos ataques se encontrará con la diatriba de si debe o no aprobar los permisos a esta "magnifica" app que hará que tenga menos spam en su bandeja de entrada.
Figura 19: Correo electrónico que invita a instalar Microsoft AntiSpam Pro en tu Office365
Cuando la víctima recibe el correo electrónico y hace clic en el enlace, acabará en una pantalla en la que se solicita su aprobación.
Figura 20: Pantalla de aceptación de permisos para la app "El beso del Sappo"
Como se puede ver, no es una web de phishing. No pide usuarios y contraseñas. Está bajo el dominio oficial de Microsoft, con HTTPs y un certificado de color verde precioso. Por supuesto, el filtro antiphishing del navegador no ha saltado y yo tengo un 2FA configurado ¿Qué puede ir mal?
Durante los últimos años hemos visto una gran cantidad de ataques a organizaciones que han terminado con el robo de información y la exposición pública de la compañía. Compromisos de seguridad famosos que han pasado a formar parte del ideario de nuestra profesión para constatar la necesidad de invertir en más medidas de seguridad y conseguir sistemas más resistentes a los ciberataques. Aún cuando en origen es totalmente correcta esta aproximación, la ejecución de dicha inversión sigue siendo el verdadero problema de fondo, ya que mientras algunos responsables de seguridad invierten grandes cantidades de dinero en nuevas tecnologías, muchos de los "BASICS" permanecen si ser resueltos totalmente.
Figura 1: Estructura del ataque SAPPO
Si revisamos los orígenes de muchos de los ataques más famosos de nuestros últimos años, veremos que en la gran mayoría muchos de los ataques comenzaron por un sencillo ataque de Spear Phishing con el que el atacante consiguió acceso a una identidad interna de la organización que no tenía configurada más medida de seguridad que un usuario y contraseña, sin contar con un segundo factor de autenticación o un segundo factor de autorización (2FA&2FA).
Como vamos a ver en este artículo, esto aún puede ser mucho más complejo de proteger aún si nos centramos en los ataques que tienen como objetivo el robo del acceso a las cuentas de correo electrónico sin necesidad de robar el usuario y la contraseña, es decir, el robo de tokens OAuth que permitan a un atacante saltarse hasta el 2FA ya que por diseño el acceso vía API usando OAuth está fuera de estas protecciones. Esto es lo que vamos a atacar con SAPPO y vamos a explicar en este artículo cómo funciona.
Robo de Cuentas en IDPs
En este artículo, los IDP (Identity Providers) que hemos seleccionado han sido Office 365 y Windows Live, pero el trabajo es análogo para otros IDP como Twitter, Facebook, Google, etcétera, como veremos en trabajos posteriores. El objetivo de las técnicas de robo de tokens es conseguir acceso a los recursos vía API consiguiendo que el usuario, en lugar de entregar un conjunto de credenciales válidas, entregue solo un AuthCode OAuth que permita el acceso a sus datos.
Si pensamos en las formas en las que puede estar protegida una cuenta Office365 contra un ataque nos podemos encontrar con diferentes escenarios.
- Solo 1FA: En este caso la cuenta Office 365 está protegida únicamente por usuario y contraseña, con un único primer factor de autenticación. El atacante puede robar las credenciales vía ataques de Spear Phishing.
- 2FA y Applicaction Passwords: En este caso la cuenta está protegida por un 2FA y solo aquellos clientes con un Applicaton Password estarán exentos de pasar por el 2FA. El atacante debería robar un application password del lugar donde esté almacenada o tener acceso a 2FA.
- 2FA sin acceso a red o 2FA: Si la cuenta es remota, y no hay acceso ni a la red para hacer un ataque de man in the middle ni al 2FA parece el entorno más complicado.
En todos los casos, si centramos los esfuerzos en el robo de tokens OAuth, todos los escenarios serían igual de sencillos ya que ninguna de las medidas de protección que se usan en unos y otros aplican al escenario de ataque que vamos a explicar.
Spear Phishing: Ataques y contramedidas
Los ataques de Phishing se basan en engañar al usuario para conseguir que introduzca las credenciales dentro de una web falsa. Estas webs están alojadas en dominios fraudulentos que simulan ser el entorno conocido por la víctima, así si se deseara robar una cuenta de Office365 se simularía el login de Office 365. Si se deseara robar un Apple ID, se simularía la web de Apple ID. Así de sencillo.
Figura 3: Un sitio web de Phishing robando datos de Apple ID
Para conseguir atraer víctimas a estos sitios, se pueden hacer dos tipos de ataques. El masivo, conocido como SPAM Phishing, que no va personalizado y se envía a una gran cantidad de destinatario esperando tener éxito basado en probabilidades o el dirigido a una víctima concreta, llamado Spear Phishing.
En este último caso, el correo electrónico está personalizado con detalles que hagan pensar a la víctima en la veracidad del mensaje. Es en este último tipo de mensajes donde los atacantes ponen sus esfuerzos cuando estamos en un escenario de APT contra una organización.
Figura 4: Un correo de Spear Phishing personalizado para una víctima concreta
Para evitar los ataques de Phishing, SPAM Phishing & Spear Phishing se utilizan diferentes medidas de seguridad. Estas son variadas, y se aplican a diferentes niveles de la organización:
- Awareness: Consiste en educar al usuario a reconocer uno de estos ataques de Phishing, SPAM Phishing y Spear Phishing. Para ello se les explica que no deben dar sus datos a sitios web que les envían por correo electrónico, que deben fijarse en el dominio de los servidores a los que se conectan, etcétera. Por desgracia, ni son totalmente correctas estas recomendaciones en todos los casos, ni las organizaciones luego fomentan su cumplimiento, ya que el uso masivo y descuidado que se hace de los mensajes de correo electrónico en las empresas va en contra de ellas.
Es común ver a agencias contratadas por equipos de marketing contratados para eventos, consultoras de RRHH o asesores varios que envíen correos electrónicos a los empleados de una organización solicitando una acción o registro en una web. Es decir, mientras que por un lado hacemos "awareness" para reconocer los ataques de phishing, por otro lado se entrena a los empleados para caer en el phishing.
- Tecnología AntiPhishing: Tanto a nivel de correo electrónico, como a nivel de navegador, se integran medidas para detectar correos electrónicos de SPAM Phishing como sitios de Phishing. Herramientas como los filtros AntiPhishing de Google Safe Browsing o el Microsoft Smart Screen vienen integrados para detectar webs que estén haciendo Phishing. Sin embargo, cuando hablamos de ataques dirigidos tipo Spear Phishing, la cosa es mucho más complicada de detectar, y en casi todas las ocasiones pasa por debajo del radar de estas tecnologías.
- Segundo Factor de Autenticación: El último bastión para evitar el robo de las cuentas es proteger las identidades digitales. Para ello, lo ideal sería proteger una cuenta con tres factores, siendo uno algo que se conozca (password), otro algo que se tenga (teléfono o token físico) y otro tercero algo que se sea (biometría). Algunas organizaciones utilizan smartcards protegidas por biometría o certificados digitales almacenados en tokens USB que se abren con biometría y passwords. La elección dependerá de cada sistema. En el caso de Office 365/Windows Live se puede poner un 2FA para proteger las cuentas.
Por desgracia, ninguna de estas tres medidas va a ser útil para proteger a los usuarios contra ataques destinados a robarte los tokens OAuth, tal y como vamos a ver.
OAuth en pocas palabras
OAuth es un protocolo de autorización implementado como OAuth2 en la mayoría de los IDPs de Internet. Se basa en un sistema de autorización en el acceso a los recursos por parte del usuario dueño de la identidad, o lo que es lo mismo, se basa en el que el usuario de YES a permitir que una aplicación acceda a sus datos. Por resumir el proceso, existen tres fases:
Figura 5: Esquema de funcionamiento de OAuth
1.- Solicitud de Acceso
En esta primera parte, una aplicación registrada en el IDP, es decir, en el caso de que queramos acceder a los datos de Office365 de usuarios una aplicación registrada como de Office365, genera una URL con la lista de permisos que quiere que un usuario le de. Para ello se genera una URL que lleva una lista de SCOPES (ámbitos de acceso) que será donde tendrá concedido el permiso una vez el usuario lo autorice.
Figura 6: SPAM Phishing de falsa cuenta de Spotify lleva a un servidor hackeado
Figura 7: El servidor hackeado hace un redirect a una URL para solicitar permisos de acceso
2.- Aprobación de Acceso
Cuando el usuario hace clic o es redirigido a la URL de solicitud de acceso, se le mostrará una pantalla en la web del IDP (Microsoft, Google, etc...) en la que se le informará de los accesos que se le están solicitando y en la que deberá decir YES o NO. Esa es la última barrera antes de conceder a la aplicación solicitante todos los datos que está pidiendo.
Figura 8: El usuario no ha iniciado la sesión pero la lista de SCOPES está en la URL
Cuando el usuario no ha iniciado sesión e los servicios del IDP, entonces la web que aparecerá será similar a la del login, tal y como se ve en la figura. Sin embargo, en la URL se puede ver como hay una lista de permisos que son los que la URL del punto 1 ha generado. Por el contrario, si el usuario ya ha iniciado sesión previamente, se irá directamente a la parte de aprobación o no de los permisos de acceso, en una web como la que se ve a continuación.
Figura 9: Falsa app de Spotify solicitando acceso a la cuenta en Windows Live
Si el usuario hace clic en YES, entonces el servidor del IDP generará un AuthCode en esta fase que le permitirá a la aplicación solicitar ya el token de acceso a los recursos.
3.- Consecución del Acceso
Si el usuario concedió e AuthCode en la parte anterior, ahora es cuestión de la aplicación consumidora solicitar el AccessToken. Para ello deberá usar su ApplicationID, su Secret, su AuthCode y solicitar que el AccessToken le sea enviado a un EndPoint. Será ahí donde el IDP le hará llegar vía API el token válido que da acceso a los recursos solicitados en la lista de SCOPES. La aplicación, quedará registrada en la lista de apps con permisos concedidos. En la siguiente imagen se ve una app maliciosa aprobada en una cuenta de Windows Live.
Figura 10: App maliciosa aprobado su acceso vía OAuth2 en Windows Live
A partir de ese momento, ya se podrá acceder vía API a cada uno de los recursos del IDP que hayan sido aprobados, como veremos en las siguientes partes de este artículo.
En la ya más que cercana Gira Up To Secure 2012 voy a estar hablando de Windows 8, donde uno de los topics más de moda es la integración con Windows Live, hasta tal punto, que se podría autenticar un usuario en local en Windows 8 con los servidores de WindowsLive.
Para ello, el administrador del sistema, cuando da de alta una cuenta dentro del equipo puede elegir la opción de autenticarse con un Windows Live ID. Esta integración está pensada para los futuros tablets o dispositivos móviles con Microsoft Windows 8, donde se puedan, de igual forma que hace Apple con iCloud, acercar los servicios de Windows Live a la plataforma escritorio. Así, un usuario podría guardar directamente en su SkyDrive, o enviar por correo con su cuenta de Hotmail, compartir estados en Windows Live Messenger y demás cosas que gustan tanto a los más sociales.
Sin embargo, cuando esta características fue anunciada, rápidamente se levantó la polémica. Ayer, ya con la gira en ciernes, he estado haciendo alguna prueba para ver cómo funciona bien y aquí va.
Cuando te creas una cuenta con Windows Live ID en tu Windows 8 - de momento la Developer Preview Edition - sólo hay que indicar la cuenta de correo electrónico asociada al Windows Live ID y listo. Nada más.
Figura 1: Dar de alta un usuario con WIndows Live ID en Windows 8
Una vez creada la cuenta se puede seleccionar en la lista de usuarios para iniciar sesión y, poniendo la contraseña de Windows Live ID acceder al equipo local. Automáticamente se carga la foto de perfil y se configuran detalles en Windows 8 provenientes desde Windows Live. Eso sí, al mismo tiempo en la cuenta de Windows Live se recibe un e-mail con información de este hecho, y hasta un SMS informativo si se tiene asociado el número de teléfono.
La pregunta es... ¿cacheará la contraseña? La respuesta es SÍ.
Cuando se inicia sesión con una cuenta Windows Live, esta contraseña se almacena en el equipo, por lo que basta con desconectar el cable, intentar conectarse con una contraseña erronea y Windows 8 lo deja bien claro: "No hay conexión, conéctate con la última password con la que iniciaste sesión".
Eso deja varios frentes de seguridad abiertos, el primero en el equipo local, pues si alguien averigua una contraseña antigua solo necesitaría desconectar el equipo de la red y usarla para autenticarse en la máquina local.
La segunda en la cuenta del usuario, ya que alguien podría hacerse con la caché de almacenamiento de contraseñas y crackear la password por medio de algún ataque de fuerza fruta en local, algo impensable en la web de Microsoft Widnows Live hoy en día, donde las cuentas son robadas por phishing, RATs o recuperación de passwords con preguntas.
La última curiosidad es que al darse de alta un usuario en Windows 8 como cuenta de Windows Live, este automaticamente hace una solicitud de convertirse en un equipo de confianza de Windows Live, lo que le permite, si se aprueba esta concesión, en alguien capaz de cambiar la contraseña sin conocer la password anterior.
Figura 2: equipo de confianza en Windows Live. Proceso de alta manual
¿Se puede eliminar esta conexión entre Windows 8 y la cuenta de Windows Live ID?
Pues sí, en cualquier momento, desde Windows Live se puede revocar el equipo de confianza una vez se desee cortar el nexo entre ambos.
Figura 3: Mail que se recibe cuando se crea un usuario en Windows 8 autenticado por Windows Live ID. En él se encuentran los links de confirmación como equipo de confianza y el de revocación de confianza.
Además, se pueden borrar las credenciales en el Windows 8 eliminando la cuenta del usuario o eliminar simplemente la información de Windows Live. Para ello, basta con ir a Windows Credential Manager de Windows 8, y en la parte de Credenciales de Windows utilizar las opciones de Remove para quitar la información de la cuenta.
Figura 4: Visualización de datos de cuenta Windows Live en Windows Credential Manager
Como se puede ver, hay dos credenciales de Windows Live ID, una es la de la sesión activa, por lo que tiene asociado un token, y la otra es la contraseña y la cuenta con la que Windows 8 va a hacer login en los servidores de Windows Live. Así que, si la paranoia es tu lema, ya sabes donde borrarlas.
Este tipo de soluciones de usabilidad y movilidad a través de la nube pueden ser un problema cuando se pierden o son robados los dispositivos, así que evita hacer uso de estas cosas si no has acompañado esto con una política de seguridad asociada de acceso local, como borrado seguro remoto, cifrado de disco completo, bloqueo de sesiones y una política de contraseñas, para todas las cuentas, robusta.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
