GitHub tiene más de 543.000 credenciales expuestas desde hace años: algunas siguen funcionando desde 2009
Elígenos como tu fuente preferida en Google.
Acaban de encontrar más de medio millón de credenciales que siguen funcionando pese a llevar años publicadas en repositorios públicos de GitHub. Algunas llevan expuestas desde 2009.
Para aquellos que no lo conozcan, GitHub es el espacio donde millones de desarrolladores suben código todos los días. El problema es que, de vez en cuando, entre todo ese código también acaba apareciendo algo que nunca debería ser público, como una contraseña, una clave de API o unas credenciales para entrar en una app.
Esto es algo que sucede con relativa frecuencia, teniendo en cuenta los millones de usuarios que usan cada día esta herramienta. El problema viene cuando esa clave se queda publicada y nadie la cambia. Porque aunque borres después el archivo, la credencial puede seguir funcionando igual.
Eso es lo que ha encontrado Truffle Security después de analizar 224 millones de repositorios y más de 58.000 millones de archivos. Los investigadores encontraron 543.699 credenciales diferentes que seguían siendo válidas cuando las comprobaron en julio.
Rizando el rizo, algunas llevaban muchísimo tiempo expuestas. La mitad de las credenciales analizadas estuvieron accesibles de forma totalmente pública durante al menos 784 días, es decir, más de dos años. Además, el 10% de las que seguían funcionando tenían más de 6,3 años y la más antigua se remontaba a 2009.
¿Cómo puede seguir funcionando una contraseña publicada hace años?
La respuesta es simple: no se ha cambiado. Aunque GitHub descubra que hay una credencial circulando, no puede decidir que esta deje de estar operativa. Al final, quien debe avisar es el servicio al que corresponde y, en última instancia, el usuario debe cambiarla.
Eso sí, matizar que, aunque una credencial siga activa, no significa que alguien la haya robado o utilizado. El estudio no puede realmente saber cuántas de esas claves han acabado en manos de ciberdelincuentes. Solo han querido avisar de que seguían siendo válidas cuando las probaron.
Por otro lado, GitHub lleva años intentando que las credenciales no lleguen a publicarse por accidente. Una de sus herramientas es Push Protection.
Cuando intentas subir código, GitHub lo analiza y busca patrones que puedan corresponder a contraseñas, tokens o claves de acceso. Si encuentra algo dudoso, puede bloquear la publicación antes de que llegue al repositorio.
El problema es que este sistema no reconoce todos los tipos de credenciales. Según Truffle Security, el 51,8% de las credenciales que seguían funcionando pertenecían a categorías que la protección predeterminada de GitHub no bloquea, como algunas cadenas de conexión a bases de datos o claves de Google API.
Además, de las 543.699 credenciales que seguían funcionando, 199.843 se habían publicado después de que Push Protection estuviera activado por defecto, según la investigación. Son alrededor del 36,8% del total.
Eso sí, los investigadores reconocen que esta herramienta de protección de la paltaforma funciona a la perfección. Según sus datos, la cantidad de credenciales expuestas dentro de esas categorías cayó un 53% después de que la protección se activara por defecto.
Sin embargo, no todas las claves se pueden reconocer de la misma forma. Algunas tienen formatos que el sistema no identifica y otras pueden aparecer de maneras que hacen más difícil detectarlas. Resumiendo, GitHub ha puesto una barrera bastante útil, pero no es una barrera que lo cubra todo.
¿Qué sucede si descubres una clave tuya en GitHub?
Parece evidente, pero lo que tienes que hacer es cambiarla. Recuerda que borrar el archivo del repositorio no basta. Si la contraseña o el token ya ha sido publicado, no puedes estar 100% seguro de que nadie la tenga.
Después, no estaría de más que echases un vistazo para ver dónde más aparece dentro del repositorio, porque puede seguir en el historial de Git aunque hayas eliminado el archivo.
También deberías revisar los accesos que ha tenido el servicio en cuestión por si alguien ha utilizado esa credencial. Y, cuando el servicio lo permita, activaría la caducidad automática de las claves para que no puedan quedarse funcionando durante años.
