En Synack realmente disfrutamos de grandes vulnerabilidades, ya sea en la web, el móvil, el host o incluso en dispositivos y sistemas completamente extravagantes (¿piratear a alguien por satélite?). Pero siempre mantenemos confidenciales los grandes hallazgos que nosotros y la TER hemos hecho para nuestros clientes. Así que si bien esto no será una publicación sobre un gran vuln en un cliente de Synack, cubre el tipo exacto de cosas que vemos semanalmente o a veces diariamente: Una vulnerabilidad en un sistema con millones de usuarios que conduce a un compromiso completo de la seguridad del sistema.

Recientemente encontré una vulnerabilidad en Microsoft Live.com sistema de autenticación, que, si tiene una cuenta con cualquier servicio de Microsoft, probablemente le habría afectado. Esta publicación describe todos los detalles de la vulnerabilidad ahora que Microsoft ha solucionado el problema.

Introducción

La comprensión de la persona promedio de la seguridad informática siempre ha sido bastante limitada. En el pasado, si alguien se enteraba de que estabas involucrado en la seguridad informática, la pregunta estándar sería «¿puedes hackear mi Hotmail?», o más a menudo, «¿puedes hackear el Hotmail de mi amigo?». Supongo que en su día la gente todavía usaba Yahoo mail y Microsoft aún no había adquirido Hotmail, ¡pero eso es un poco demasiado atrás! Inevitablemente, sugeriría que la persona solo adivine las preguntas de restablecimiento de contraseña de la persona, o instalaría Sub7. En realidad, hackear Hotmail estaba destinado a ser demasiado difícil, por no mencionar que era totalmente ilegal.

El mundo de la seguridad de la información ha cambiado mucho en los últimos dos años, y a diferencia de años anteriores, Microsoft ahora alienta completamente a los investigadores de seguridad a intentar «hackear Hotmail». Por supuesto, Hotmail se ha convertido en Outlook.com, y en estos días todo el mundo quiere saber si puedes hackear su Facebook, pero eso no viene al caso.

El programa de recompensas de Microsoft Online Services se actualizó recientemente para incluir «Cuenta de Microsoft» como objetivo, que es básicamente los sistemas de inicio de sesión alojados en cada uno de estos dominios:
– login.windows.net
– login.microsoftonline.com
– login.live.com

En la lista anterior, login.live.com es el sistema de autenticación por el que pasará si está intentando autenticarse Outlook.com y un gran número de otros servicios de Microsoft. Decidí examinarlo primero para ver si podía descubrir algún problema. Como era de esperar, las diversas API utilizadas para procesar un inicio de sesión parecían estar bien reforzadas. En muchos lugares existían capas adicionales de protección; por ejemplo, en algunos lugares las contraseñas se cifran con una clave pública antes de la transmisión, a pesar de que todas las comunicaciones se realizan a través de HTTPS.

Después de probar durante unas horas, descubrí algunos problemas menores que informé, pero nada realmente notable. Al probar aplicaciones web, a menudo encuentro que el flujo de trabajo más común también es el más seguro, por lo que me dediqué a examinar otras formas en que un usuario podría autenticarse en el live.com sistema. Hace casi un año había encontrado varias vulnerabilidades de OAuth en Yammer, que también era un objetivo de recompensas de Microsoft Online Services, así que ahí es donde busqué a continuación live.com. ¡Aquí es donde comienzan los hallazgos interesantes!

Fondo de vulnerabilidad

Antes de entrar directamente en la vulnerabilidad descubierta, es necesario un resumen rápido del sistema de seguridad equivocado conocido como OAuth:

Wikipedia me dice que «OAuth proporciona a las aplicaciones cliente un’ acceso delegado seguro ‘a los recursos del servidor en nombre del propietario de un recurso». Wikipedia también tiene algunos comentarios mordaces sobre su evolución y seguridad, que vale la pena leer para reírse. Siendo realistas, todo lo que hace OAuth es permitir que un usuario conceda acceso a parte o a la totalidad del acceso de su cuenta a un tercero. Hice un dibujo de MS Paint para ilustrar esto porque no pude encontrar uno genial en Wikipedia.

Como se puede ver en la imagen anterior, tiene un Servidor al que el Usuario autorizó para dar acceso a su cuenta a una Aplicación Cliente. El mecanismo que maneja esto detrás de escena se puede construir de varias maneras diferentes, que se definen en el RFC de OAuth. Una forma de construirlo es mediante un flujo de autenticación «implícito», que implica que el servidor de autenticación proporcione una clave de acceso directamente al cliente. Otra forma popular es usar un procedimiento de «código de autorización», donde el servidor de autenticación emite un código de autorización, que el sistema cliente toma, y luego intercambia por una clave de acceso utilizando su valor secreto de cliente. Microsoft tiene una buena descripción de su uso de cómo han implementado estos mecanismos para live.com aquí:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

El gráfico que hicieron para el flujo de «código de autorización» se ve así:

Una imagen como esa es genial para entender el proceso, pero para mí, como probador de bolígrafos, también muestra muchas oportunidades y lugares para que las cosas salgan mal. ¡Así que con eso como fondo, a lo que se descubrió!

¿Qué Podría Salir Mal?

Como se indica en la sección anterior, hay muchos lugares en los que algo podría salir mal. Uno de los pasos fundamentales en el procedimiento de autenticación OAuth es que un usuario elija otorgar acceso a una aplicación. Esto generalmente se logra a través de un indicador como este:

Por lo general, un usuario solo necesitará aceptar este mensaje una vez, pero hasta que lo acepte, esa aplicación no tendrá acceso a su cuenta (¡si el usuario promedio permitirá o no que la Aplicación Malvada de Wes obtenga acceso es quizás una pregunta diferente!).

Pensando como atacante, definitivamente sería genial si pudiéramos aceptar la solicitud en nombre del usuario. Desafortunadamente para mí, el encabezado «X-Frame-Options» se configuró en «deny» (la configuración de x-frame-options también estaba fuera del alcance de esta recompensa). Así que mientras el clickjacking está fuera, decidí comprender mejor cómo funcionaba la solicitud en sí. Si un usuario hace clic en «Sí», la siguiente solicitud se envía al servidor (además de algunos encabezados aburridos):

Si bien la ruta de URL anterior incluye algunos tokens generados, las pruebas mostraron que no eran necesarios para que la solicitud tuviera éxito. Una PUBLICACIÓN en la siguiente URL funcionaría igual de bien:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26 scope % 3dwl.basic%26response_type%3dcode%26redirect_uri%3dhttp:// exfiltrated.com& client_id = 000000004C15E107& rd = exfiltrado.com& scope = wl.básica

La cookie enviada con la solicitud necesaria para contener un token de sesión válido en «IPT». Este valor de cookie se rellena con https:/ / login.live.com / oauth20_authorize.srf antes de que se muestre la página que solicita permiso al usuario. Esto sucede independientemente de si un usuario finalmente hace clic en «Sí» o no, aunque está configurado por algún código Javascript, por lo que si atacamos este proceso, tendríamos que forzar al usuario a cargar esa página en algún momento.

Si estás siguiendo, espero que ahora estés preguntando: «OK, ¿qué pasa con la solicitud POST en sí y ese valor canario?». Había examinado todos los demás parámetros y flujos de comunicaciones primero, ya que ver un valor etiquetado como «canary» que se envía con una solicitud POSTERIOR casi con certeza significa que se está utilizando como un token para evitar ataques CSRF. El objetivo de las pruebas de seguridad, sin embargo, es verificar que las suposiciones son correctas. Así que modifiqué la solicitud POST, y cambié el valor canario a «hacks_go_here». En lugar de redirigir a un error 500, el servidor envió una respuesta positiva.

CSRF a PoC

Dado que el token CSRF era lo último que había intentado manipular, sabía con certeza que esto debería hacer una vulnerabilidad CSRF válida. Al igual que con casi todos los ataques de CSRF, el único requisito previo era que la víctima hubiera iniciado sesión y tuviera un token de sesión válido en su cookie. A diferencia de muchas otras vulnerabilidades web, el impacto de una vulnerabilidad CSRF depende completamente de la función de API afectada. Este CSRF me permite omitir el paso de interacción del usuario del sistema de autenticación OAuth, pero un PoC vale más que mil palabras, por lo que el siguiente paso fue crear un código para demostrar adecuadamente el impacto de esta vulnerabilidad.

En el flujo normal de autenticación OAuth, después de que el usuario conceda acceso, el servidor debe devolver un código de acceso al usuario. El usuario lo pasa a la aplicación cliente, que puede usar los permisos concedidos. A live.com la aplicación cliente puede solicitar una amplia gama de permisos posibles. Consideré simplemente deshacerse de los contactos del usuario o algo así, pero ¿por qué sacrificarse por el objetivo de hackear Hotmail ahora? Los permisos que mi PoC necesitaba entonces eran:

wl.offline_access + wl.imap

Offline no era tan necesario, pero lo incluí para demostrar que se concedería.

Con los permisos necesarios elegidos, hay 4 pasos para obtener acceso a la cuenta de correo electrónico de un usuario:

1) Necesitamos hacer una solicitud de autorización para nuestra aplicación cliente utilizando los permisos anteriores. El servidor le pedirá al usuario que acepte o rechace.
2) Cuando un usuario acepta nuestra solicitud de esos permisos, el servidor agregará un parámetro «#access_token=<token>» a la redirección que le indiquemos que tome.
3) Dado que nuestros scripts del lado del servidor necesitarán acceso a ese valor, necesitamos hacer una página simple para tomar el token del campo URL del navegador y pasarlo a nuestro servidor.
4) Finalmente necesitamos algunos scripts del lado del servidor para tomar ese token y usarlo para iniciar sesión en IMAP. Microsoft tiene un proceso un tanto complicado para usar el token OAuth para iniciar sesión directamente a través de IMAP. Existen algunas bibliotecas de muestra para esto, y todo el proceso se describe en esta página:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

Ese flujo de trabajo funcionaría bien suponiendo que el usuario elija darnos permiso. Ahora solo necesito modificar el flujo de trabajo para incluir el CSRF. Como se señaló anteriormente, la live.com el servidor de autenticación estará esperando un token de sesión en la cookie IPT. Podemos asegurarnos de que se rellene enviando primero al usuario a una página validhttps://login.live.com/oauth20_authorize.srf. Inmediatamente después, podemos ejecutar la solicitud CSRF que hará uso del valor de cookie recién rellenado. Esto ahora puede reemplazar el paso 1 y forzar al servidor a saltar inmediatamente al paso 2.

Demo e Impacto

Microsoft ha solucionado este problema, pero aquí hay un video rápido que lo muestra en acción.

Como se puede ver en el video, todo lo que realmente es necesario es hacer que la víctima visite su página web maliciosa. La demostración no fue diseñada para ser engañosa y ejecutarse en el fondo de un sitio web, o como parte de un banner publicitario malicioso, pero ciertamente podría haberse hecho de esa manera.

Usar esto como un ataque dirigido definitivamente tiene un alto impacto, pero también es el tipo perfecto de vulnerabilidad para convertirse en un gusano. Con IMAP y acceso a la libreta de contactos, un gusano podría enviar fácilmente un correo electrónico a todos los contactos de un usuario (o al menos a los que usan Hotmail, Outlook.com, etc.), con algo atractivo, estilo de virus «ILOVEYOU», y se propaga a cada usuario que hace clic en el enlace.

Pensamientos finales y Línea de tiempo

La búsqueda de esta vulnerabilidad y la realización de un PoC de trabajo implicaron una buena cantidad de esfuerzo excavando a través de los diversos live.com API. Sin embargo, mirando hacia atrás, esto realmente es solo una vulnerabilidad CSRF clásica. Lo único sorprendente es que se encuentra en un sistema de autenticación crítico que, en última instancia, se puede usar para hacerse cargo de la cuenta de cualquier usuario.

Como probador externo, no tengo idea de cuánto tiempo puede haber existido esta vulnerabilidad, o si alguien alguna vez intentó explotarla. Al mismo tiempo, son hallazgos como este los que definitivamente muestran el valor de permitir que los evaluadores externos envíen vulnerabilidades a su empresa antes de que los atacantes las aprovechen contra usted. Microsoft está muy por delante de la mayoría de las empresas en lo que respecta a la seguridad, y aún así sigue siendo susceptible a problemas como este. La experiencia de Synack ha sido que las vulnerabilidades se descubren incluso en sistemas aparentemente bien protegidos cuando un gran grupo de investigadores externos prueba ese sistema. Esa es esencialmente la premisa en la que opera Synack, y es por eso que cada vez más empresas ofrecen sus propios programas de recompensas (¡yo, por supuesto, recomendaría el programa de Synack en lugar de ejecutar el suyo propio!).

Como se puede ver en la línea de tiempo a continuación, Microsoft fue receptivo para obtener una solución para este problema, lo cual fue genial ver.

Cronología:
23 de agosto de 2015: Vulnerabilidad descubierta
25 de agosto de 2015: Vulnerabilidad reportada a Microsoft
31 de agosto de 2015: Problemas de Microsoft número de caso de vulnerabilidad
15 de septiembre de 2015: Microsoft releases fix for issue, issues bounty 24,000 bounty (promo de recompensas dobles)