El error de GitHub hizo que los usuarios iniciaran sesión en otras cuentas de usuario

Anoche, GitHub cerró automáticamente la sesión de muchos usuarios al invalidar sus sesiones de GitHub.com para proteger las cuentas de los usuarios de una vulnerabilidad de seguridad potencialmente grave.

A principios de este mes, GitHub había recibido un informe de comportamiento anormal de una parte externa.

El comportamiento anómalo resultó de una vulnerabilidad de condición de carrera poco común en la que la sesión de inicio de sesión de un usuario de GitHub se dirigió incorrectamente al navegador web de otro usuario que inició sesión, lo que le proporcionó a este último una cookie de sesión autenticada y acceso a la cuenta del usuario anterior.

GitHub desconecta automáticamente a los usuarios debido a un error

A partir de ayer, GitHub cerró la sesión de todos los usuarios que iniciaron sesión antes del 8 de marzo, a las 12:03 UTC.

Este paso se logró casi una semana después de que la compañía recibió un primer informe de comportamiento sospechoso en GitHub.com de una parte externa.

"El 2 de marzo, GitHub recibió un informe de comportamiento anormal externo para la sesión de usuario autenticado de GitHub.com".

"Al recibir el informe, GitHub Security and Engineering inmediatamente comenzó a investigar para comprender la causa raíz, el impacto y la prevalencia de este problema en GitHub.com", dijo la compañía en un anuncio de seguridad.

El viernes 5 de marzo, los equipos de GitHub solucionaron el problema de seguridad y continuaron con el análisis durante el fin de semana.

Además, invalidar todas las sesiones de anoche fue el último paso para corregir el error.

La vulnerabilidad, según GitHub, podría explotarse en circunstancias extremadamente raras cuando se produzca una condición de carrera durante el proceso de manejo de solicitudes de backend.

En este caso, la cookie de sesión de un usuario de GitHub conectado se enviaría al navegador de otro usuario, dándole a este último acceso a la cuenta del usuario anterior.

"Es importante tener en cuenta que este problema no fue el resultado de contraseñas de cuentas comprometidas, claves SSH o tokens de acceso personal (PAT) y no hay evidencia que sugiera que esto sea el resultado de otros sistemas GitHub comprometidos".

"En cambio, este problema se debió al manejo inadecuado, raro y aislado, de sesiones autenticadas".

"Además, este problema no puede ser provocado o dirigido intencionalmente por un atacante", Él dice Mike Hanley, director de seguridad de GitHub.

Menos del 0,001% de las sesiones afectadas

La compañía afirma que el error subyacente estuvo presente en GitHub.com durante un período acumulativo de menos de dos semanas en ciertos momentos entre el 8 de febrero y el 5 de marzo de 2021.

Después de que se identificó y resolvió la causa inicial el 5 de marzo, la compañía lanzó un segundo parche el 8 de marzo para fortalecer aún más la seguridad del sitio web.

Esto es lo que provocó que GitHub invalidara todas las sesiones de inicio de sesión que estaban activas antes del mediodía del 8 de marzo.

No hay evidencia de que otros recursos o productos de GitHub.com, como GitHub Enterprise Server, se hayan visto afectados por este error.

"Creemos que este error de dirección de sesión se produjo en menos de 0,001% de sesiones autenticadas en GitHub.com. "

"Para la población de cuentas muy pequeña que sabemos que se ve afectada por este problema, nos hemos comunicado para obtener más información y orientación", continúa Hanley en el anuncio.

Si bien aún tenemos que confirmar el alcance total del impacto de este error, las sesiones autenticadas estimadas en 0.001% podrían significar más de decenas de miles de cuentas, considerando que GitHub obtiene más de 32 millones visitantes activos (autenticados o no) en un mes.

Además, la compañía aún no ha comentado si alguno de los repositorios o el código fuente del proyecto ha sido alterado debido a esta vulnerabilidad.

Las vulnerabilidades de autenticación como estas, si son explotadas por adversarios, pueden allanar el camino para ataques encubiertos en la cadena de suministro de software.

BleepingComputer se comunicó con GitHub para obtener comentarios antes de la publicación y estamos esperando su respuesta.