Hackeamos GitHub durante un mes: esto es lo que encontramos

Tras una larga pausa, volvemos con un nuevo write-up. Aunque normalmente no participamos en programas de bug bounty debido a otros compromisos, aceptamos el reto de hackear GitHub durante un mes y estamos encantados de compartir nuestros hallazgos. Todo empezó cuando Shivam Singh (Mr. Rajput Hacker) se puso en contacto conmigo en noviembre y me animó a probar el bug bounty. Decidimos centrarnos en npmjs.com, una filial de GitHub. A pesar de que GitHub es una gran empresa y de que el programa de bug bounty era público en HackerOne, consideramos que merecía la pena intentarlo.

Centrarse en la lógica de negocio

Mr. Rajput Hacker y yo decidimos centrarnos exclusivamente en los fallos de lógica de negocio de la aplicación. Antes de empezar la búsqueda, nos aseguramos de comprender la aplicación por completo. Esto implicó un uso mínimo de Burp Suite y poner el foco en entender la funcionalidad y los procesos fundamentales de la aplicación. Nuestro objetivo era encontrar cualquier debilidad en la lógica de negocio que pudiera explotarse. Al limitar nuestro conjunto de herramientas y centrarnos en comprender la aplicación, buscábamos descubrir vulnerabilidades únicas o pasadas por alto. Como npmjs.com era una aplicación relativamente pequeña, nuestra comprensión y nuestras notas nos llevaron menos de dos horas.

Vulnerabilidades descubiertas

N.º	Título del informe H1	Objetivo	Fecha de reporte (DD/MM/AA)	Gravedad	Recompensa
1	Reclamar el nombre de usuario de una cuenta eliminada antes de 90 días puede provocar varios problemas	https://github.com/	11/12/22	Informativa	NA
2	Las sesiones de la cuenta siguen activas y vinculadas al nombre de usuario anterior tras cambiar el nombre de usuario	https://education.github.com/	11/12/22	Baja	$2000
3	Engañar a los miembros de una organización víctima mediante una vulnerabilidad de confusión de nombres en la función de invitación de miembros de la organización	https://npmjs.com/	07/12/22	Media	Duplicado
4	La víctima puede reclamar el nombre de usuario de una cuenta eliminada – conduce a una apropiación de cuenta al controlar la sesión de la cuenta eliminada	https://npmjs.com/	02/12/22	Media	$4000
5	Eliminar la cuenta de cualquier persona en NPMJS abusando de una mala configuración del sistema de soporte	https://npmjs/com/	11/12/22	Baja	Duplicado ($200)
6	Elusión de la verificación de inicio de sesión en NPMJS.com	https://npmjs.com/	16/11/22	Media	$4000
	Recompensa total				$10000

Vulnerabilidades reportadas al GitHub Security Program

Aunque mencionamos que en total  se reportaron 9 vulnerabilidades, hoy escribimos aquí sobre 3 de ellas, que se indican a continuación:

1. Elusión de la verificación de inicio de sesión en npmjs.com
2. Pre-Account Takeover en npmjs.com
3. Problema de control de acceso en education.github.com

Elusión de la verificación de inicio de sesión en NPMJS

Descripción  –

Al revisar la parte de autenticación de npmjs.com y funcionalidades habituales como la actualización de la dirección de correo electrónico y del perfil, detectamos un comportamiento extraño de la aplicación que nos llamó la atención: el formato del enlace de verificación de correo, del enlace de restablecimiento de contraseña & del enlace enviado para actualizar la dirección de correo . 

El enlace tenía para todas las funcionalidades el formato https://npmjs.com/verify/{some_random_token_here} – ya fuera restablecimiento de contraseña, enlace de verificación de correo o cualquier otro enlace del sitio . A continuación observamos que, cada vez que inicias sesión en la aplicación, esta envía un código de verificación a la dirección de correo registrada, que hay que introducir como parte de la verificación de inicio de sesión (una especie de código 2FA/MFA por correo) para acceder correctamente a la cuenta .  Entonces intentamos eludir esta funcionalidad y lo conseguimos – como habíamos recorrido por completo la aplicación en las últimas 2 horas, conocíamos cada funcionalidad, pudimos relacionarlas y encontrar la elusión; lee los siguientes pasos para reproducirlo y ver cómo lo hicimos .

Durante nuestro examen del proceso de autenticación y de las funcionalidades habituales de npmjs.com, como la actualización de direcciones de correo y perfiles, descubrimos un comportamiento peculiar en el formato de los enlaces de verificación de correo, los enlaces de restablecimiento de contraseña y los enlaces enviados para actualizar direcciones de correo. Estos enlaces tenían el formato https://npmjs.com/verify/{random_token} y se usaban para todas las funcionalidades, incluidos el restablecimiento de contraseña, la verificación de correo y otras.

También observamos que, cada vez que un usuario iniciaba sesión en la aplicación, se enviaba un código de verificación a la dirección de correo registrada. Este código de verificación era necesario para completar el proceso de inicio de sesión, actuando como una forma de autenticación de dos factores. La segunda cosa que notamos: al actualizar una dirección de correo en npmjs, el cambio se producía sin requerir confirmación de contraseña. Se enviaba un correo tanto a la dirección antigua como a la nueva. El correo enviado a la dirección antigua informaba al destinatario de que, si el cambio no lo había hecho él, podía hacer clic en un enlace (https://npmjs.com/verify/{some_random_token_here}) para revertir el cambio y volver a establecer su dirección antigua como la actual. El correo enviado a la dirección nueva contenía un enlace para verificar el nuevo correo y vincularlo a la cuenta que se acababa de actualizar.

Nos encontramos con un problema sorprendente al intentar iniciar sesión en una cuenta después de actualizar la dirección de correo en la página de perfil. A pesar de no haber confirmado ni hecho clic en ningún enlace ni del correo antiguo ni del nuevo, el sistema mostraba un mensaje indicando que se había enviado un código de verificación a la nueva dirección sin verificar. Esto parecía sugerir que no podríamos iniciar sesión.  Sin embargo, al examinarlo más de cerca, descubrimos un correo enviado a nuestra dirección antigua, pidiéndonos revertir el cambio para evitar el bloqueo de la cuenta. Al hacer clic en el enlace proporcionado (https://npmjs.com/verify/{random_token}) para revertir el correo, fuimos redirigidos a la página de inicio de sesión. Para nuestra sorpresa, cuando introdujimos nuestras credenciales, el sistema no pidió el código de verificación y en su lugar nos permitió iniciar sesión y revertir el cambio de correo.

Sin embargo, tras investigar más a fondo, logramos eludir con éxito esta funcionalidad. Nuestra profunda comprensión de la aplicación, obtenida al dedicar dos horas a familiarizarnos con sus funciones, nos permitió relacionar distintas funcionalidades y encontrar la elusión. Los pasos para reproducir la elusión se muestran a continuación.

Pasos para reproducirlo –

1. Registrarse con [email protected] (nombre de usuario attacker1)
2. Iniciar sesión en attacker1 con el usuario y la contraseña (ya que el inicio de sesión de npmjs funciona solo con nombre de usuario y contraseña)
3. Ir a Account > Update Email > [email protected]
4. Revisa la bandeja de entrada de [email protected], verás un correo de npmjs.com

5.Abrir el enlace https://www.npmjs.com/verify/{some_random_token_here} Redirigirá al inicio de sesión > Intenta iniciar sesión con el nombre de usuario & la contraseña de la víctima
6.Serás redirigido a la página 404 & ¡habrás iniciado sesión en la cuenta sin código de verificación! (Aunque la página te muestre un mensaje que te dice que no has iniciado sesión con el usuario correcto)

POC –

https://youtube.com/watch?v=ox6np-b3nyI%3Ffeature%3Doembed

Impacto –

Un atacante puede explotar una vulnerabilidad en npmjs para eludir el proceso de verificación de inicio de sesión, que está pensado para proteger frente a ataques de recolección y filtración de credenciales. Esto permite en la práctica que el atacante obtenga acceso no autorizado a la cuenta sin pasar por los controles de seguridad previstos. Esta vulnerabilidad es, en esencia, una elusión del proceso de verificación de inicio de sesión, que sirve como medida temporal hasta que se activa la autenticación de dos factores.

Nuestra conclusión –

En conclusión, aunque disfrutamos descubriendo una vulnerabilidad en GitHub, nos decepcionó la recompensa recibida. A pesar de cumplir los criterios de una vulnerabilidad crítica enumerados en la página de política de Hackerone de GitHub – incluida la elusión del proceso de inicio de sesión, el acceso a datos sensibles de usuario y el acceso a datos de otro usuario -, se nos clasificó como media y no recibimos ninguna justificación clara por parte de GitHub. A pesar de intentar dialogar con el equipo de GitHub a través de la mediación H1, nuestros esfuerzos fueron en vano. Creemos que esta situación plantea dudas sobre la equidad del sistema de recompensas de GitHub y sobre el cumplimiento de sus propias políticas.

Criterios de vulnerabilidad crítica mencionados en la página de política de Hackerone de GitHub

• ejecución arbitraria de código/comandos en un servidor de nuestra red de producción
• consultas SQL arbitrarias en una base de datos de producción
• elusión del proceso de inicio de sesión, ya sea la contraseña o la 2FA
• acceso a datos sensibles de usuario de producción o acceso a sistemas internos de producción
• acceso a los datos de otro usuario en el servicio GitHub Actions

CAPTURA DE PANTALLA DE LA POLÍTICA DE GITHUB

Solicitud de comentarios al equipo de GitHub:

Si algún miembro del equipo de GitHub tiene alguna justificación para la clasificación de la vulnerabilidad, agradeceríamos una respuesta en el informe o que se pusiera en contacto con nosotros en nuestros perfiles de H1 @th3pr0xyb0y y @mrrajputhacker2

Pre-Account Takeover en npmjs.com 

Descripción  –

Tras revisar a fondo la aplicación, decidimos centrarnos en encontrar fallos lógicos. Durante nuestra observación, notamos que el proceso de autenticación solo usaba un nombre de usuario para iniciar sesión y que la dirección de correo podía actualizarse fácilmente sin verificación de contraseña. Esto nos llevó a pensar que el nombre de usuario era un aspecto crítico del backend de npmjs.com.

Probamos la funcionalidad de eliminación de cuenta y exploramos los siguientes escenarios:

1. ¿Podíamos seguir accediendo a la sesión de la cuenta si estaba abierta en un navegador distinto?
   Comprobamos que eliminar la cuenta desde un navegador cierra de inmediato la sesión del usuario en todas las demás sesiones.
2. ¿Podíamos registrarnos usando el mismo nombre de usuario de una cuenta eliminada recientemente?
   Nuestras pruebas mostraron que no era posible registrarse con un nombre de usuario existente o eliminado previamente.
3. ¿Había alguna forma de cambiar el nombre de usuario o reclamar uno nuevo/eliminado? Descubrimos una opción para reclamar o cambiar un nombre de usuario en la aplicación – creando una organización en la cuenta de npmjs. Esto nos permitía elegir un nuevo nombre de usuario para la organización o convertir nuestra cuenta en una organización, cambiando así en la práctica nuestro nombre de usuario. Sin embargo, ni siquiera esta opción permitía cambiar a un nombre de usuario eliminado previamente.

A pesar de llegar a callejones sin salida en los tres escenarios, estábamos decididos a encontrar una solución y logramos eludir el sistema con éxito gracias a nuestra insistencia. Documentamos los pasos en nuestro informe para demostrar cómo pudimos crear una apropiación previa de cuenta.

Nuevas observaciones en nuestra investigación –

Ya sabíamos que podíamos solicitar la eliminación de nuestra cuenta enviando un ticket de soporte. Por lo tanto, probamos este método y eliminamos nuestra cuenta. Tras recibir el correo de confirmación, descubrimos que, aunque la cuenta estaba eliminada, seguíamos con la sesión iniciada y nuestro nombre de usuario aparecía en la esquina superior derecha, pero no podíamos realizar ninguna acción.

Intentamos reclamar de nuevo el nombre de usuario eliminado registrándonos en un navegador distinto, pero no fue posible. Sin embargo, como habíamos encontrado una forma de cambiar nuestro nombre de usuario, intentamos reclamarlo de nuevo en otro navegador. Para nuestra sorpresa, lo conseguimos, y en cuanto reclamamos el nombre de usuario, la sesión se transfirió a nuestra sesión anterior, en la que solo veíamos una página de error 404. De este modo, pudimos apropiarnos de la cuenta de una persona que intentaba cambiar su nombre de usuario por el de una cuenta eliminada, porque teníamos las cookies y la sesión se nos transfirió.

Si la explicación resulta confusa, consulta los pasos para reproducirlo y la prueba de concepto para entender mejor esta vulnerabilidad.

Pasos para reproducirlo –

1. Regístrate como atacante con un nombre de usuario común (por ejemplo, commonusername123) usando el navegador Google Chrome.
2. Solicita la eliminación de la cuenta al soporte.
3. Una vez que el soporte haya eliminado la cuenta, actualiza el navegador en el que la cuenta tenía la sesión iniciada. Verás que todas las páginas excepto la de perfil muestran tu nombre de usuario (el enlace de la página sería https://npmjs.com/~username).
4. Intenta visitar https://www.npmjs.com/settings/commonusername123/profile. Verás una página 404.
5. Regístrate como víctima con un nombre de usuario distinto (por ejemplo, victimusername123) usando el navegador Firefox.
6. Convierte la cuenta de la víctima en una organización. Esto hará que el nombre de usuario de la organización sea victimusername123 y te pedirá elegir un nuevo nombre de usuario. Elige commonusername123 como nuevo nombre de usuario para la cuenta.
7. Actualiza la página de la sesión del atacante https://npmjs.com/~username usando el navegador Google Chrome.
8. Intenta visitar https://www.npmjs.com/settings/commonusername123/profile. Ahora verás el correo de la víctima (por ejemplo, [email protected]) y tendrás acceso a la cuenta de la víctima y a la organización que creó.

POC –

https://youtube.com/watch?v=5039T3y8yFw%3Ffeature%3Doembed

Impacto –

Un actor malicioso puede crear varias cuentas con nombres de usuario comunes en npmjs.com, eliminarlas enviando un ticket de soporte y conservar las cookies. Como resultado, tiene la posibilidad de apropiarse de una cuenta si otra persona reclama esos nombres de usuario.

Nuestra conclusión – 

En conclusión, aunque estábamos entusiasmados por descubrir una vulnerabilidad en GitHub, nos decepcionó la recompensa recibida. Se trataba de una apropiación de cuenta compleja pero posible, que podría haber afectado a una gran organización. Para aclarar el impacto, todavía teníamos una cuenta con cookies almacenadas y sesiones activas que llevaban en marcha más de tres meses, ya que la sesión de una cuenta eliminada nunca caduca en npmjs. Sin embargo, GitHub consideró esta vulnerabilidad como “media” y solo nos concedió una recompensa de $4000 en total.

Problema de control de acceso en education.github.com

Descripción  –

Tras quedar insatisfechos con la respuesta de GitHub a nuestras vulnerabilidades anteriores reportadas en npmjs y con la recompensa, decidimos centrarnos en otros subdominios de GitHub. Descubrimos que education.github.com utilizaba el inicio de sesión único (SSO) de GitHub para su proceso de acceso. Inspirados por los fallos que encontramos en npmjs, experimentamos con un enfoque similar usando nombres de usuario de cuentas eliminadas.

Para nuestra sorpresa, descubrimos que eliminar una cuenta de GitHub no hacía que la sesión caducara en education.github.com, y cada página mostraba un error 404, incluso estando aún con la sesión iniciada. En otro navegador, intentamos crear una nueva cuenta de GitHub con el mismo nombre de usuario eliminado, pero, según la política de GitHub, los nombres de usuario no se pueden reclamar durante 90 días después de eliminarlos .

Sin embargo, a pesar de estos callejones sin salida, pudimos eludir el problema y obtener el control de acceso . 

Elusión del control de acceso –

Observamos que, aunque cambiamos un nombre de usuario en GitHub y actualizamos nuestra sesión de education.github.com, el nombre de usuario seguía siendo el mismo – no cambiaba, a pesar de que lo habíamos modificado en nuestro perfil de GitHub. Esto ocurre porque el token de sesión está vinculado al nombre de usuario y el SSO solo lo actualiza cuando volvemos a iniciar sesión a través de GitHub. Así que rápidamente reclamamos la cuenta de GitHub eliminada y luego el antiguo nombre de usuario, que todavía estaba asociado en https://education.github.com  con esa cuenta, usando una nueva cuenta de GitHub en un navegador distinto, e iniciamos sesión en https://education.github.com en un nuevo navegador.  Entonces observamos que ambas cuentas tenían el mismo nombre de usuario pero un correo diferente asociado y eran completamente funcionales; así que, si enviábamos cualquier formulario educativo o activábamos alguna función, podía provocar daños en la integridad de los datos en ambos lados, por lo que lo reportamos como un problema y se aceptó como un problema válido .

Notamos que, incluso después de cambiar nuestro nombre de usuario de GitHub, la sesión en education.github.com permanecía sin cambios. Esto se debía a que el token de sesión estaba ligado al nombre de usuario y el SSO solo lo actualizaba al iniciar sesión a través de GitHub. Para explotarlo, reclamamos rápidamente una cuenta de GitHub eliminada y luego el antiguo nombre de usuario, que todavía estaba asociado a la cuenta de education.github.com. Después iniciamos sesión en education.github.com usando un navegador distinto con una nueva cuenta de GitHub, y comprobamos que ambas cuentas tenían ahora el mismo nombre de usuario pero direcciones de correo diferentes y eran plenamente funcionales.

Esto significaba que, si enviábamos un formulario educativo o activábamos alguna función, podía provocar daños en la integridad de los datos en ambos lados. Reportamos esto de inmediato como un problema y se aceptó como una vulnerabilidad válida.

Pasos para reproducirlo – 

1. Inicia sesión en tu cuenta de GitHub
2. Visita https://education.github.com/schools
3. Cambia el nombre de usuario de tu cuenta de GitHub
4. Actualiza la página o vuelve a visitar https://education.github.com/schools y comprueba el nombre de usuario en el icono de perfil de la derecha
5. Verás que el antiguo nombre de usuario sigue activo en education.github.com
6. Como el antiguo nombre de usuario es reclamable, parece que es posible una apropiación de cuenta en education.github.com reclamándolo.
7. Si no tienes un correo universitario, no puedes verificar si las acciones realizadas en la sesión antigua afectarán a una nueva cuenta registrada con el antiguo nombre de usuario.
8. Inicia sesión en education.github.com en una nueva ventana de Chrome con una cuenta recién creada que tenga el mismo nombre de usuario que la sesión antigua.
9. Verás que ahora tienes dos sesiones activas con el mismo nombre de usuario.

Impacto –

El impacto de este problema debería ser evaluado por el equipo de GitHub. Tiene el potencial de comprometer información sensible de nuevos usuarios, como su centro educativo o su dirección de correo y su información de identificación personal (PII), si se registran con el nombre de usuario para el que existe una sesión activa. Esto podría dar lugar a una apropiación de cuenta y a la filtración de PII.

Nuestra conclusión – 

Nos alegró descubrir esta vulnerabilidad en GitHub, aunque fuera similar a la que encontramos en npmjs. Esta vez no pudimos evaluar el impacto completo del problema. Aun así, quedamos satisfechos con la recompensa concedida.

¿Aprendiste algo con nosotros?

Ayúdanos compartiendo este artículo con tus amigos, tu familia y tus colegas, y siguiéndonos en nuestras redes sociales. También puedes suscribirte a nuestra lista de correo para recibir más write-ups informativos sobre nuestros hallazgos. Muestra tu apoyo tuiteando sobre este artículo y compartiéndolo con la comunidad tanto como sea posible.

Echa un vistazo a nuestro nuevo producto, Blind XSS Hunter, diseñado para apoyar a la comunidad, solo en https://bxsshunter.com.

¡Prepárate para un emocionante lanzamiento de CyberXplore! Hemos trabajado sin descanso durante los últimos dos años para perfeccionar un producto que estamos deseando compartir contigo. Sé de los primeros en probarlo manteniéndote en contacto con nosotros o siguiéndonos en nuestro camino. Y para todas las novedades, ¡no olvides suscribirte a nuestro boletín! ¡Este es un lanzamiento que no querrás perderte!