GitHub corrige un error que hace que los usuarios inicien sesión en otras cuentas

0
518

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 contra una vulnerabilidad de seguridad potencialmente grave.

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

El comportamiento anómalo se debió a 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 desvió al navegador web de otro usuario que inició sesión, lo que le dio a este último una cookie de sesión autenticada y acceso a la cuenta del usuario anterior.

GitHub cierra la sesión de los usuarios automáticamente 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 tomó casi una semana después de que la compañía recibió un informe inicial de comportamiento sospechoso en GitHub.com, de una parte externa.

“El 2 de marzo, GitHub recibió un informe externo de comportamiento anómalo para su sesión de usuario de GitHub.com autenticada”.

Al recibir el informe, Seguridad e Ingeniería de GitHub inmediatamente comenzaron a investigar para comprender la causa raíz, el impacto y la prevalencia de este problema en GitHub.com“, se lee en un anuncio de seguridad de la compañía.

El viernes 5 de marzo, los equipos de GitHub solucionaron la falla 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 ocurriera una condición de carrera durante el proceso de manejo de solicitudes de backend.

En tal caso, la cookie de sesión de un usuario de GitHub que haya iniciado sesión 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 fue el resultado de un compromiso de cualquier otro sistema GitHub”.

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

“Además, este problema no puede ser provocado o dirigido intencionalmente por un usuario malintencionado”, 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 solucionó la causa inicial el 5 de marzo, la compañía emitió 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 activas antes del mediodía del 8 de marzo.

No hay evidencia de que otros activos o productos de GitHub.com, como GitHub Enterprise Server, hayan sido afectados como resultado de este error.

“Creemos que el enrutamiento de esta sesión se produjo en menos del 0,001% de las sesiones autenticadas en GitHub.com”.

“Para la pequeña población de cuentas que sabemos que se verán afectadas por este problema, nos hemos comunicado con información y orientación adicionales”, continúa Hanley en el anuncio.

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

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

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

BleepingComputer se acercó a GitHub para hacer comentarios antes de publicar y estamos esperando su respuesta.