En marzo de 2020 comenzó la pandemia, así que tuve mucho tiempo libre. Debían administrarse con prudencia y decidí obtener la certificación OSWE. Después de aprobar el examen el 8 de agosto, me tomé un par de semanas de descanso y luego, a mediados de septiembre, me dije: “¿Sabes qué? Mi nombre no apareció en el Salón de la Fama de Facebook en 2020, aunque sí ocurre allí anualmente. ¡Es hora de solucionar este problema! ”.
Nunca encontré una vulnerabilidad en uno de los subdominios de Facebook, así que estudié los artículos y encontré una publicación sobre el subdominio de Facebook que me llamó la atención. Esta es una gran publicación, recomiendo leerla: [El error de conversión de HTML a PDF conduce a RCE en el servidor de Facebook] .
Después de leer esta publicación, me di cuenta de que se pueden encontrar muchas vulnerabilidades en una aplicación web tan grande.
Mi objetivo principal era
https://legal.tapprd.thefacebook.com
implementar RCE (ejecución remota de código) o algo similar.
Ejecuté herramientas de fuzzing para averiguar todos los puntos finales de esta aplicación web, tomé una siesta de dos horas y miré una película. Luego volví a mi computadora y encontré buenos resultados.
403:
/tapprd/
/tapprd/content/
/tapprd/services/
/tapprd/Content/
/tapprd/api/
/tapprd/Services/
/tapprd/temp/
/tapprd/logs/
/tapprd/logs/portal/
/tapprd/logs/api/
/tapprd/certificates/
/tapprd/logs/auth/
/tapprd/logs/Portal/
/tapprd/API/
/tapprd/webroot/
/tapprd/logs/API/
/tapprd/certificates/sso/
/tapprd/callback/
/tapprd/logs/callback/
/tapprd/Webroot/
/tapprd/certificates/dkim/
/tapprd/SERVICES/
Creo que este resultado es suficiente para confirmar mi teoría sobre la enormidad de esta aplicación. Luego comencé a leer archivos de Javascript, para comprender cómo funciona el sitio web, qué métodos usa, etc.
Vi una manera de evitar la redirección al inicio de sesión SSO
https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login
y después de analizar la página de inicio de sesión encontré este punto final:
/tapprd/auth/identity/user/forgotpassword
Después Fuzzing por el punto final del usuario, identifiqué otro punto final
/savepassword
esperando una solicitud POST. Después de examinar los archivos Javascript, descubrí cómo funciona la página, que el token generado y el token xsrf son necesarios, etc. Al principio pensé que valía la pena intentarlo para verificar, puede cambiarlos manualmente con la ayuda
burp suite
, pero obtuvo un error falla de la operación .
Pensé que podría ser la dirección de correo electrónico incorrecta o algo similar. Intentemos recoger el correo electrónico del administrador. Comencé a anotar direcciones de correo electrónico arbitrarias, a hacer una lista de palabras y luego a usar eructos para probar lo que sucedía.
Cuando regresé un par de horas después, vi los mismos errores, más otro resultado. Fue un redireccionamiento 302 a la página de inicio de sesión. ¡Maldita sea, funcionó!
Permítanme explicar lo que sucedió aquí: envié solicitudes aleatorias con un token CSRF usando un cracker y direcciones de correo electrónico aleatorias con una nueva contraseña de punto final
/savepassword
, y uno de los resultados fue una redirección 302.
Redirigir
Ahora podía ir a la página de inicio de sesión, ingresar mi correo electrónico y una nueva contraseña: BOOM, el inicio de sesión en la aplicación fue exitoso y tuve acceso al panel de administración.
Leí el informe de un hacker que encontró un RCE anterior implementado con PDF, la empresa le dio una recompensa de solo $ 1000. Así que decidí: ok, necesitas dar una buena impresión y escribir el exploit perfecto para conseguir un alto impacto.
Rápidamente escribí un script Python simple para aprovechar esta vulnerabilidad: ingresas una dirección de correo electrónico y una nueva contraseña, y el script cambia la contraseña.
El impacto fue tan grande aquí porque los empleados de Facebook iniciaron sesión con sus cuentas de trabajo. Es decir, usaron sus propios tokens de acceso a la cuenta de Facebook, y es probable que si otro atacante quisiera usar este exploit, le daría acceso a las cuentas de algunos empleados de Facebook,
luego informé la vulnerabilidad y se revisó mi informe. .
Recibí un premio de $ 7,500 el 2 de octubre
Me gustó mucho el exploit para esta vulnerabilidad, y decidí que no era suficiente, ¡el script es demasiado débil! Vale la pena seguir profundizando.
Entonces encontré dos vulnerabilidades más, que discutiré en la segunda parte del artículo.
La segunda parte
En la primera parte, descubrí la posibilidad de secuestrar una cuenta con una API insegura, lo que me permitía cambiar la contraseña de cualquier cuenta de administrador sin la intervención del usuario, por lo que el departamento de seguridad de Facebook me pagó 7.500 dólares . En la segunda parte, descubrí una forma de secuestrar una cuenta mediante la manipulación de cookies. Combinándolo con la SSRF interna , recibí una recompensa de $ xxxxx . Sí, una suma de cinco cifras ... Bueno, comencemos.
Antes de la publicación, el artículo fue revisado por varias partes y tuve que obtener un permiso por escrito, por lo que algunos de los nombres y la información podrían cambiarse a pedido de Facebook y sus socios.
Cuando descubrí la vulnerabilidad de la primera parte del artículo, Facebook la solucionó al día siguiente de recibir el informe. Luego comencé a estudiar historia
burp suite
para comprender cómo funciona todo.
Como puede ver en la captura de pantalla (número 1 sobre fondo azul), ASPXAUTH se utiliza como cookie . ¡Idealmente!
¿Ves a lo que me refiero? ASPXAUTH tiene un 80% de posibilidades de ser vulnerable, pero esto requiere la siguiente información:
validationKey
(): , .decryptionMethod
(): ( «AES»).decryptionIV
(): ( — , ).decryptionKey
(): , .
Puede leer más sobre esto aquí: MachineKey Class .
No tengo información sobre ninguno de los puntos, entonces, ¿por qué asumí que hay una vulnerabilidad aquí?
En realidad, no lo sé, pero la mayoría de las aplicaciones ASPXAUTH en cookies encriptadas con claves de encriptación usualmente solo usan el tiempo de expiración de correo electrónico o usuario y cookie. He utilizado este método muchas veces en los programas de recompensas de otros sitios web y funcionó.
Necesitaba encontrar una manera de sortear este sistema, al menos no un intento de tortura. Fui a Google y busqué otros sitios web que usan la misma aplicación. Se suponía que debía tener suerte y encontrar un sitio web con la misma aplicación y las mismas claves de cifrado, y simplemente elegir el nombre de usuario de administrador correcto.
Encontré otro sitio web usando la misma aplicación, el registro estaba activo, así que inicié sesión con el nombre de usuario de administrador de Facebook, intercepté la solicitud, tomé ASPXAUTH y lo reemplacé con un ASPXAUTH de Facebook caducado . ¿Adivina qué pasó?
Ya me perdí este panel, pero finalmente volví a él. Ahora, hablemos un poco sobre la supervisión de ASP.net que la mayoría de los desarrolladores deberían tener en cuenta al crear aplicaciones para mantenerlas seguras:
- ASPXAUTH debe almacenarse en la base de datos y la aplicación debe validar su corrección.
- Como comprobación adicional, ASPXAUTH a veces debería contener más que solo el nombre de usuario.
- Cada sitio debe tener claves de cifrado y descifrado únicas (las claves predeterminadas deben cambiarse).
Conclusión 1 : podría iniciar sesión en cualquier cuenta de administrador, conociendo solo su nombre de usuario; Considero que la complejidad de esta vulnerabilidad es muy baja y su impacto alto . Si solo informo de esta vulnerabilidad, recibiré solo $ 7500 , como en la primera parte, pero quería más.
En el panel, noté algo curioso, es decir, la opción para crear formularios y otra opción: disparador de API. Sospeché algo, lo más probable es que exista la posibilidad de una SSRF (Falsificación de solicitud del lado del servidor) ilimitada. Por lo tanto, escribí una carta al departamento de seguridad de Facebook, diciendo que hay casi el cien por ciento de la vulnerabilidad SSRF crítica en la aplicación, pidiendo permiso para probarla. La respuesta me vino:
En ese momento, todavía estaba discutiendo el informe de la primera parte (secuestro de cuenta) con ellos, porque les informé de estas vulnerabilidades una semana después de la primera. Como puede ver, el departamento de seguridad de Facebook siguió creyendo que yo estaba reclamando otra omisión de autenticación y SSRF, incluso después de explicar las vulnerabilidades con evidencia. A juzgar por esto, me dieron permiso para probar la SSRF.
Después de un tiempo, escribí un pequeño guión y lo subí a su editor. El script me permitió enviar cualquier solicitud con cualquier dato (GET, POST, PUT, PATCH, HEAD, OPTIONS) a cualquier URL, tanto interna como externa.
Desde el backend del script, pude cambiar el método de solicitud y los datos enviados, etc.
En esta etapa, podría expandir esta vulnerabilidad a RCE, tal vez a LFI (inclusión de archivos locales, agregar archivos locales), si voy un poco más allá ( no estoy completamente seguro de esto, luego le pedí permiso a Facebook para realizar ingeniería inversa la solicitud, pero se negaron y dijeron que no creían que pudiera ampliar el ataque ).
Luego intenté atacar Facebook con un script canario. ¿Adivina qué pasó de nuevo?
Recibí mi token canario. ¿Que sigue? Necesito escribir un nuevo informe con todos los detalles, incluidos los scripts y PoC (prueba de concepto), como me dijeron anteriormente.
Conclusión 2: Al escribir un script para enviar solicitudes arbitrarias, pude obtener la SSRF interna y proporcionar acceso a la red interna de Facebook. Considero que la dificultad de este ataque es baja y el impacto crítico .
Impact SSRF:
SSRF- Facebook, , -, . SSRF .
SSRF-, , , , , .
Puede encontrar más información sobre las vulnerabilidades de SSRF en el artículo portswigger .
Conclusión final: encadené ambas vulnerabilidades hasta el punto en que tuve acceso a la intranet de Facebook ( SSRF ), usando la toma de control de la cuenta para acceder a mi script cargado dentro de la aplicación, enviando las solicitudes arbitrarias que quería.
Hablemos de lo que puedo lograr con la cadena de vulnerabilidad que descubrí:
- Puedo acceder a la cuenta de cualquier empleado de Facebook en el panel del Departamento Legal.
- No es necesario explicar qué información importante puede obtener un atacante después de iniciar sesión.
- Podría usar SSRF para acceder a la intranet de Facebook (intern.our.facebook.com).
- Creo que con un poco más de esfuerzo, podría expandir esta vulnerabilidad y usarla para escanear la red / servidores internos.
Todos sabemos cuán crítica es la SSRF , especialmente si no tiene una frecuencia limitada. Puedo cambiar fácilmente el tipo de contenido y los métodos de solicitud. Según las guías de pago de Facebook , esta vulnerabilidad debería ser recompensada con $ 40,000 en un bono de $ 5,000 si puedo cambiar el tipo de contenido de la solicitud y el método de solicitud.
Después de una larga espera, recibí este mensaje de Facebook:
Recibió un premio de $ 40,000 de Facebook más un bono de $ 2,000 (por encima de los $ 7,000 esperados ).
Les hice una pregunta sobre por qué no recibí el Bono de Control Total ( $ 5,000 ) y recibí esta respuesta:
En total, con la primera vulnerabilidad, ascendió a 54.800 dólares .
Informé de esta vulnerabilidad unos días después de la primera parte del informe de vulnerabilidades.
Cronología de informes:
- Miércoles 9 de septiembre de 2020 - Se envió el informe de vulnerabilidad.
- Lunes 26 de octubre de 2020 : Facebook me ha pedido que abra un nuevo informe. ~ Medidas correctivas tomadas.
- Lunes 26 de octubre de 2020: informe revisado.
- Jueves 25 de febrero de 2021: problema resuelto y recompensa pagada. Aproximadamente seis meses, sí .
- Viernes 5 de marzo de 2021: se paga un bono de $ 5,300.
Quiero dar algunos consejos valiosos a los cazadores de insectos. Cuando vea ASPXAUTH, intente obtener cookies de otro sitio web utilizando la misma aplicación y pruebe el mismo método que el mío:
- Cree nuevas cookies ASPXAUTH desde otro sitio web.
- Verifique si las cookies funcionarán en el sitio web bajo investigación.
Me gustó el proceso, pero esperar seis meses y cerrar informes por razones irracionales fue molesto. Estoy agradecido, pero tuve que trabajar duro y esta no es la única SSRF que he encontrado. De hecho, encontré más curiosos, pero Facebook cerró los informes como "informativos" porque la empresa firmó un acuerdo con el proveedor que llegó a las pocas semanas de revisar los informes. En definitiva, este no es mi problema, por lo que esta experiencia no es agradable.
Al final, quiero disculparme si algo no quedó claro. Me llevó algún tiempo publicar la segunda parte; como se mencionó anteriormente, estaba esperando el permiso por escrito y la revisión del informe. Por tanto, se han eliminado o censurado muchos aspectos para preservar la confidencialidad de terceros.