El SDK de Facebook JS es ampliamente utilizado por los desarrolladores por varias razones, como iniciar sesión en el sitio web usando Facebook o para insertar complementos Compartir o Me gusta, lo que dejó a miles de sitios web vulnerables a varios ataques, como la apropiación de cuentas. Los sitios webs que lo incluían (muchos) eran potencialmente vulnerables. Un fallo en la expresión regular, permitía utilizar cualquier subdominio acabado en facebook.com como "testfacebook.com". El investigador de seguridad Youssef Sammouda ha reportado el fallo y ha sido recompensado con 10.000$. 

• La expresión regular incorrecta utilizada en el SDK de Javascript de Facebook permitía robar cuentas en sitios web de terceros que lo incluían

Este error podría permitir a un atacante apuntar a sitios web que incluyan SDK de Javascript de Facebook. El atacante engañaría a un determinado usuario del sitio web para que visitara su sitio web, lo que explotaría un error en la implementación utilizada en el SDK para permitir la comunicación de origen cruzado entre el sitio web que incluía el SDK y el sitio web principal de Facebook. 

Detalles técnicos

El SDK de Facebook JS podría implementarse en un sitio web por varias razones, como iniciar sesión con Facebook, compartir, incrustar. Además, el mismo SDK podría usarse para comunicarse con el sitio web de Facebook para autenticar y servir contenido para aplicaciones Canvas / Tab a las que se accedería a través de apps.facebook.com o pestañas de página. Esto se hace al incluir el SDK en una página de su sitio web que tendría el contenido de la aplicación de lienzo, luego agregaría el enlace de la página en la configuración de la aplicación de lienzo de Facebook. Si visita apps.facebook.com/APP_ID/, debería encontrar que la página seleccionada se publicaría en un iframe y que el sitio web de Facebook se comunicaría con su sitio web y viceversa mediante el método postMessage y EventListeners para mensajes de ventana de origen cruzado.

La clave principal para la comunicación segura entre orígenes es verificar siempre el origen y el destino de un determinado mensaje. Facebook no pudo hacer eso en el SDK que está incluido en un sitio web de terceros porque estaba usando una expresión regular incorrecta para verificar el origen de cierto mensaje de origen cruzado recibido:

Este es un fragmento del código responsable de la comunicación entre orígenes en el SDK:

__d("sdk.XD", ["JSSDKXDConfig", "Log", "QueryString", "Queue", "UrlMap", "guid", "isFacebookURI", "resolveWindow", "sdk.Event", "sdk.feature", "sdk.RPC", "sdk.Runtime", "sdk.Scribe", "sdk.URI"], (function(a, b, c, d, e, f) {
var g = new(b("Queue"))(),
h = "parent",
i = null,
j = /^https:\/\/.*facebook.com$/;
...

window.addEventListener("message", function(a) {
var c = a.data,
d = a.origin || "native";
if (!/^(https?:\/\/|native$)/.test(d)) {
b("Log").debug("Received message from invalid origin type: %s", d);
return
}
if (!j.test(d)) return;
if (typeof c === "string") r(c, d);
else {
if (a.source == parent && a.data.xdArbiterRegisterAck && j.test(d)) {
typeof a.data.xdArbiterRegisterAck === "string" && a.data.xdArbiterRegisterAck !== "" && p(a.data.xdArbiterRegisterAck);
g.isStarted() || g.start(function(a) {
if (a == null) {
b("Log").warn("Discarding null message from %s to %s", m, d);
return
}
var c = parent;
typeof a === "object" && typeof a.relation === "string" && (c = b("resolveWindow")(a.relation));
((c = c) != null ? c : parent).postMessage({
xdArbiterHandleMessage: !0,
message: a,
origin: m
}, d)
});
return
}
b("Log").warn("Received message of type %s from %s, expected a string. %s", typeof c, m, ES("JSON", "stringify", !1, c));
return
}
});

Si examinamos el código, encontramos que hay un Eventlistener para mensajes de origen cruzado dentro del SDK. Una vez que se recibe un mensaje, verificaría si el origen comienza con https (o nativo), y si verifica la expresión regular "/^https:\/\/.*facebook\.com$/"

Como puede notar, la expresión regular estaba destinada a facebook.com y sus subdominios, sin embargo, falta un punto de escape antes de facebook.com (el correcto sería /^https:\/\/.*\.facebook\.com$/) .

Esto permite que un dominio como testpocfacebook.com pase la verificación de origen realizada aquí.

El mensaje enviado por testpocfacebook.com sería {“xdArbiterRegisterAck”: ”canvas”} y el SDK devolvería un mensaje con formato json FB_RPC a la ventana principal. El mensaje incluiría "fallback_redirect_uri", que es el valor de window.location.href.

Aquí viene la explotación de este error. Como se explicó anteriormente, el SDK incluye código para todas las funcionalidades posibles, un sitio web podría usar el SDK para usar solo la funcionalidad para compartir, sin embargo, el código para la funcionalidad del lienzo aún estaría incluido, lo que significa que el sitio web tendría un EventListener para mensajes de origen cruzado que ahora aceptaría mensajes del sitio web propiedad del atacante aprovechando el error. Como puede observar en el código anterior, la fuente del mensaje está marcada y debe ser la ventana principal, lo que significa que para que esto funcione, la página de destino también debe permitirse el iframed.

Para concluir, si podemos encontrar una página en un sitio web que incluye el SDK de Javascript de Facebook y se puede incluir en un marco flotante, podemos filtrar el archivo window.location.href de esa página.

¿Cómo abusar de esto?

Esto podría usarse para filtrar información después de las redirecciones en el sitio web de destino. Por ejemplo, si hacemos iframe https://example.com/me página que redirigiría a https://example.com/profile/PROFILE_ID, el / profile / page puede ser iframed, enviamos el mensaje después de la redirección y recibiría el ID de perfil de usuario conectado.

El mismo ataque podría aplicarse a los puntos finales de devolución de llamada de oauth u otros mecanismos de autorización que incluyen el SDK de Facebook. Dado que muchos sitios web incluyen el SDK de Facebook JS en cada página (de la misma manera que se incluye la etiqueta de Google Analytics), esto permitiría la toma de control de cuentas o el robo de tokens confidenciales. Esto funcionaría de la misma manera que en el ejemplo anterior, asumimos que el sitio web usa Google o Facebook para la autenticación, haríamos un iframe https://accounts.google.com/o/oauth2/auth o https: //www.facebook. com / dialog / oauth con parámetros que incluyen el sitio web de destino Google o los detalles de la aplicación de Facebook (redirect_uri y app_id), si la víctima ya ha iniciado sesión en sus cuentas de Facebook o Google, estas direcciones URL redirigirán a los puntos finales de devolución de llamada en el sitio web, si los puntos finales de devolución de llamada pudieran ser iframed, entonces enviaríamos el mensaje de origen cruzado y recibiríamos el access_token o el código (ya que estamos recibiendo window.location.href actual dentro del iframe)

Este ataque podría lanzarse fácilmente contra sitios web que alojan aplicaciones de lienzo o pestañas de página. La página que se usa en la aplicación de lienzo se puede incluir en un iframe para permitir que se incluya en un iframe dentro de apps.facebook.com, y también la misma página, la mayoría de las veces, se usaría como un punto final de devolución de llamada oauth de Facebook.

Insertaríamos un iframe dentro de https://testpocfacebook.com/ con el siguiente src 

https://www.facebook.com/dialog/oauth?client_id=APP&redirect_uri=REDIRECT_URI&response_type=token

 Si el usuario autorizó esta aplicación antes, esto redirigiría directamente a REDIRECT_URI, que tendría incrustado el script SDK de Facebook. En ese punto, la ventana principal enviaría el mensaje de origen cruzado y recibiría el access_token incrustado dentro de fallback_redirect_uri.

El sitio web del atacante podría tener 100 iframes con cada iframe apuntando a un sitio web diferente que aloja una aplicación de lienzo, lo que aumentaría la posibilidad de tener un visitante que haya utilizado una de estas aplicaciones antes y finalmente recibiríamos un access_token con los permisos seleccionados en el alcance de la aplicación.

• https://www.facebook.com/whitehat/thanks

Demostración rápida

Esta PoC se utilizó en el informe enviado a Facebook (ya que no pude incluir PoC para sitios web de terceros). Aunque esto no funcionó ya que el punto final de devolución de llamada de www.instagram.com no permitía ser iframed (X-Frame-Options: deny header estaba configurado), sin embargo, el punto final incluía el SDK de Facebook JS. Si se encontró una omisión para el problema de iframing, esto podría haber llevado a una toma de control completa de la cuenta de Facebook, ya que la aplicación de Facebook de Instagram.com es una aplicación de primera parte y los access_tokens generados tendrían acceso a https://graph.facebook.com/ punto final graphql.

Si un usuario de Facebook que ha iniciado sesión visita el sitio web del atacante, se solicitará https://www.facebook.com/dialog/oauth en el iframe, se realizará una redirección a https://www.instagram.com/accounts/ signup / con un access_token en la parte del fragmento hash de la URL. El punto final / cuentas / registro / incluye el SDK de Facebook (aunque no se puede incluir en un marco flotante, por el bien del ejemplo asumiremos que sí). Se enviaría un mensaje de origen cruzado a la ventana del iframe y recibiríamos un mensaje con el token de acceso del usuario de Facebook incluido. Entonces podemos tomar el control de la cuenta: ’).

Facebook pagó una recompensa de $25k por errores por XSS encadenado basado en DOM en Noviembre al mismo investigador

El investigador de seguridad obtuvo una recompensa por errores de $ 25,000 después de descubrir una vulnerabilidad de scripting entre sitios (XSS) basada en DOM en Facebook.

Un usuario que haya iniciado sesión sería víctima de un ataque que explotara la falla crítica en la página de redireccionamiento de pagos de Facebook al visitar un sitio web controlado por un atacante y luego hacer clic en él.

Esto desencadenaría la apertura de una nueva pestaña o ventana emergente que contiene una carga útil maliciosa, que luego exfiltra un access_token de primera parte, entregando al atacante el control de su cuenta.

Sammouda descubrió que podía enviar mensajes de origen cruzado desde facebook.com a través de postMessage a la ventana de apertura.

Al encadenar esta falla a un script que construyó y envió de manera insegura un formulario basado en datos recibidos en mensajes a través de un Eventlistener, Sammouda logró XSS y una generosa recompensa financiera.

El investigador diseñó el exploit durante una competencia de hacking en BountyCon2020, un evento de búsqueda de errores realizado recientemente por Facebook y Google.

Historia de origen

Sammouda dedujo que postMessage estaba destinado al uso exclusivo de los empleados de Facebook porque el dominio interno .intern.facebook.com se estableció como targetOrigin.

Sin embargo, apuntar al extremo vulnerable con .alpha.facebook.com devolvió este dominio como targetOrigin.

Esto llevó a Sammouda a buscar páginas que contengan un Eventlistener que solo aceptara subdominios de facebook.com en el origen del mensaje, "una gran pista de que los datos recibidos en el mensaje se usarían para hacer algo serio".

Al acceder a las aplicaciones de lienzo, Sammouda notó que el dominio apps.facebook.com cargaba 'https://www.facebook.com/platform/page_proxy/?version=X' dentro de un iframe y luego le enviaba mensajes a través de postMessage (un hallazgo que anteriormente surgió un error grave en el marco OAuth de Facebook).

“La página page_proxy contenía código que enviaba un mensaje con frameName a través de postMessage a cualquier origen… y configuraba un Eventlistener” que allanó el camino para XSS, como se explica con más detalle en la publicación del blog.

Explotación explicada

Al hacer clic en el dominio del atacante, la víctima se redirige a http://our.alpha.facebook.com/platform/page_proxy, que abre our.alpha.facebook.com/payments/redirect.php en una nueva pestaña, con el javascript que envía "Un mensaje posterior a la ventana de apertura, que ahora es http://our.alpha.facebook.com en lugar de" el dominio del atacante, Sammouda dijo a The Daily Swig.

“Elegir [el] dominio our.alpha.facebook.com nos ayudaría a completar la segunda etapa del ataque, ya que postMessage en our.alpha.facebook.com/platform/page_proxy/ solo enviaría mensajes a http: // our. alpha.facebook.com ".

El script dentro del dominio page_proxy “también solo aceptaría mensajes de dominios * .facebook.com como origen y para eso el ataque es exitoso. Si aceptaba cualquier origen, usar http://our.alpha.facebook.com/platform/page_proxy/ no será necesario ya que podemos usar nuestro propio sitio web para enviar mensajes usando postMessage ".

El investigador agregó: “Técnicamente hablando, creo que este error no es difícil de explotar. Sin embargo, lo difícil fue encontrar la segunda parte ”

La falla se descubrió el 10 de octubre, el segundo y último día de BountyCon2020.

Facebook emitió una solución el 28 de octubre después de eliminar postMessage de las redirecciones de pago y configurar appTabUrl para que se verifique cuando comience con https [/^https:/.test(a.data.params.appTabUrl)].

El gran pago de Sammouda eclipsa los 20.000 dólares que ganó el investigador Vinoth Kumar en mayo por descubrir una vulnerabilidad XSS basada en DOM en el botón "Iniciar sesión con Facebook" y los 5.000 dólares otorgados a Enguerran Gillier por encontrar el mismo tipo de defecto en Gmail en 2018.

Bug Bounty Facebook 2019-2020

Uno de los aspectos más destacados fue el hallazgo de Youssef Sammouda, quien también se ubicó en el primer lugar de nuestra clasificación de líderes de sombrero blanco este año. Su pago por recompensa equivalente a USD$ 65,000 superó el pago por recompensa más alto realizado el año pasado.

Youssef descubrió un error al realizar una consulta web en una terminal utilizada para la gestión de derechos de autor. Debido a una respuesta de error mal configurada, una consulta web podría haber devuelto fragmentos de datos no deseados desde la terminal de derechos de autor. Implementamos una solución para este problema pocas horas después de que Youssef nos lo informara. Tras implementar la solución inicial, creamos una revisión de seguimiento exhaustiva utilizando una combinación de detección automática y la revisión del código manual. Como resultado, solucionamos un marco más amplio en la forma en que se manejaban los errores para evitar que otras terminales pudieran devolver datos similares. Como siempre lo hacemos, entregamos al investigador su recompensa en función del máximo impacto posible del error informado, y no en función del problema inicial que nos informó.

Fuentes:

https://ysamm.com/?p=510