Eliminar una clave filtrada de tu repositorio no te protege

En resumen: si se te filtra un secreto, cámbialo inmediatamente. Borrar un archivo, reescribir el historial de commits de Git o eliminar tu repositorio no te protegerá. Los atacantes buscan habitualmente secretos en Internet, así que da por hecho que ya tienen una copia. Utiliza Betterleaks o Aikido detección de secretos para encontrar secretos filtrados en tus repositorios, y Aikido Device Protection para encontrarlos en los equipos de los desarrolladores.

En mayo, los desarrolladores de LiteLLM subieron por error una clave administrativa a un repositorio público de GitHub. Meses más tarde, los atacantes utilizaron esa credencial para comprometer su infraestructura.

El análisis a posteriori de LiteLLM recoge la cronología de las medidas que tomaron para solucionar la fuga. Una frase del informe me llamó especialmente la atención:

«Aproximadamente tres horas después, una confirmación posterior eliminó el archivo [que filtró el secreto] y se señaló que era necesario revocar las claves, pero la confirmación original permaneció en el historial público del repositorio hasta el 22 de octubre».

LiteLLM detectó la filtración en menos de tres horas. Su primera medida correctiva fue esta solicitud de incorporación de cambios (Pull Request), que simplemente eliminaba el archivo. Meses más tarde, el 22 de octubre, reescribieron el historial de Git para eliminar las confirmaciones que habían filtrado la credencial.

Esas dos medidas, aunque habituales, reflejan ideas erróneas generalizadas entre los desarrolladores sobre la filtración de información confidencial en el historial de Git. Ninguna de las medidas que tomó LiteLLM impide realmente que cualquiera pueda ver los datos filtrados. De hecho, el commit en el que se filtró la credencial sigue siendo visible a día de hoy (¡no te preocupes, ya la han cambiado!).

La única forma de solucionar por completo el problema de una credencial filtrada es cambiarla. Una vez que se ha hecho pública, deja de ser un secreto y ya nunca volverá a serlo.

Ideas erróneas comunes sobre la filtración de secretos en Git

Los experimentos que se muestran a continuación ponen a prueba, cada uno de ellos, una «solución» habitual para los secretos filtrados en los repositorios de Git:

• Elimina el archivo
• Reescribir el historial de Git
• Eliminar el repositorio

Ninguna de estas medidas te protege por completo de que los atacantes descubran y utilicen un secreto que se te haya escapado. Aunque solo haya estado a la vista del público durante unos minutos.

Idea errónea n.º 1: Borrar el archivo

LiteLLM adoptó este enfoque nada más descubrir la fuga de información, y probablemente sea la reacción más habitual. El desarrollador detectó un error en su código, por lo que lo «corregió» eliminando el archivo problemático en una nueva confirmación. Como veremos más adelante, los escáneres de información confidencial analizan el historial de Git y examinan los archivos eliminados.

1. Crea un nuevo repositorio Git local. Realiza un commit de un archivo README. A continuación, realiza un commit de un archivo que contenga un secreto.

mkdir tmp_repo
cd tmp_repo
git init
echo "# README" > README.md
git add README.md
git commit -m "commit inicial"
# clave falsa filtrada
echo "secret_token=ZQ5Cl16U8kmc4uOxS581xDWr" > archivo.txt
git add archivo.txt
git commit -m "revelación del secreto en file.txt"

2. Elimina ese archivo. Vuelve a confirmar los cambios.

rm archivo.txt
git add .
git commit -m "Se ha eliminado el dato confidencial expuesto en el archivo file.txt"

3. Realiza un análisis con Betterleaks. Verás que detecta un secreto en el historial de Git. (Instrucciones para configurar Betterleaks en la página de GitHub.)

betterleaks en Git.

Idea errónea n.º 2: Reescribir el historial de Git

Lo siguiente que suele hacer uno es «borrar» la filtración del historial de Git. LiteLLM lo intentó el 22 de octubre realizando un «force push» de un historial reescrito que excluía las confirmaciones relevantes. A primera vista, parece que funciona, ya que no se puede acceder a esas confirmaciones desde ninguna rama. Por desgracia, GitHub sigue mostrando las confirmaciones «eliminadas» a cualquiera que tenga su hash SHA-1.

1. Anota el hash SHA-1 de la confirmación en la que revelaste el secreto.

git log --format=%H --grep="revelación de un secreto en el archivo file.txt" -1

Nota: Los hash SHA-1 tienen 40 caracteres, lo cual es demasiado largo para adivinarlo. Sin embargo, GitHub permite a los usuarios introducir una versión abreviada en su interfaz de usuario, que se convierte en los 40 caracteres completos. La versión abreviada puede tener tan solo 4 caracteres (0-9a-f), lo que hace que estos hash sean más fáciles de descubrir.

2. Sube el repositorio local de arriba a GitHub. (Crea el repositorio en la página web de GitHub si el primer comando no funciona.)

git remote add origin https://github.com/<github-username>/tmp_repo.git
git branch -M main
git push -u origin main

3. Restablece el puntero de Git al primer commit. Realiza un push forzado a GitHub.

git reset HEAD~2 --hard
git push --force

Nota: Hay diferentes formas de reescribir el historial de confirmaciones. Se trata de una demostración sencilla, por lo que lo único que hacemos es restablecer nuestro repositorio a la primera confirmación inicial y, a continuación, realizar un «force push».

4. Elimina tu repositorio local.

cd ..
# rm -r tmp_repo # comprueba bien el nombre del directorio antes de ejecutar esto

5. Clona el mando a distancia.

git clone https://github.com/<user>/tmp_repo.git
cd tmp_repo

6. Revisa el historial de Git en la versión clonada. Solo aparecerá una confirmación.

git log

7. Recupera tu commit «eliminado» directamente de GitHub. Visualiza el archivo «eliminado».

git fetch origin <sha1_hash_from_step_1>
git checkout <sha1_hash_from_step_1>
cat file.txt

Si accedes a la confirmación «eliminada» desde el navegador, verás un mensaje en la parte superior que dice «Esta confirmación no pertenece a ninguna rama de este repositorio…», pero aun así podemos verla.

https://github.com/<user>/tmp_repo/commit/<sha1_hash_from_step_1>

Idea errónea n.º 3: Eliminar el repositorio

Como último recurso, los desarrolladores suelen borrar todo el repositorio. Por desgracia, esto tampoco es suficiente. En primer lugar, no tienes ninguna visibilidad sobre quién ha clonado tu repositorio. En segundo lugar, si alguien ha creado una bifurcación de tu repositorio, GitHub conservará una copia de tu «commit» eliminado de forma indefinida.

1. Pide a un amigo que haga un fork del repositorio que hemos creado anteriormente.
2. Elimina tu repositorio.
3. Visita la confirmación eliminada (mediante el hash) en la versión bifurcada de tu amigo.

https://github.com/<friend>/tmp_repo/commit/<sha1_hash_from_step_1>

La confirmación que contiene tus datos filtrados permanecerá indefinidamente en GitHub hasta que se elimine la última bifurcación.

¿Y si nadie lo hubiera visto?

Si esos experimentos no han sido suficientes para convencerte de que debes rotar una credencial que está expuesta públicamente, mira cómo nuestro compañero Mackenzie filtró una clave en directo durante una conferencia y comprueba después cuántos actores la escanearon en tan solo unos minutos. Los investigadores, las plataformas SaaS y en la nube, y los actores maliciosos buscan constantemente información confidencial. Da por hecho que, en el momento en que se hace pública, alguien ya la ha visto.

Cambia la posición de las llaves expuestas

Borrar un archivo, reescribir el historial o eliminar un repositorio hacen que un secreto filtrado siga siendo accesible. La única medida que protege totalmente tu cuenta es la rotación de credenciales:

• revocar el que se ha filtrado
• emitir uno nuevo
• actualizar en todos los lugares donde se utilizaba la versión anterior

Aunque la rotación de credenciales evita un uso indebido en el futuro, no soluciona el uso indebido que ya se ha producido, y una clave filtrada puede permanecer activa durante meses antes de que alguien la descubra. La clave de LiteLLM estuvo activa durante más de cuatro meses antes de que un atacante la utilizara para obtener un token de GitHub y publicar una versión maliciosa.

Una vez que hayas girado la llave, comprueba si hay indicios de que la llave antigua ya se haya utilizado:

• Los registros de uso y acceso propios de la clave o el token
• Commits recientes en la rama principal y en cualquier rama protegida
• Cambios en la configuración de CI y del flujo de trabajo, y ejecuciones recientes del proceso de integración

Si no puedes descartar que se trate de un uso indebido, trátalo como un incidente.

Cómo ayuda el aikido

Aikido te ayuda a comprobar si se han filtrado secretos. Los clientes disponen de un servicio de gestión de filtraciones ( detección de secretos ) integrado en la plataforma Aikido, y cualquiera puede utilizar Betterleaks, el motor gratuito de código abierto que lo hace posible.

Aikido detección de secretos o y protección de dispositivos

Conecta tus repositorios de GitHub, GitLab, Bitbucket o Azure DevOps, ya sean públicos o privados, y Aikido detección de secretos los analizará en busca de claves API, contraseñas, tokens y otras credenciales expuestas. Por defecto, analiza el código actual, pero puedes activar comprobaciones completas del historial de Git para detectar secretos que se hayan añadido y posteriormente eliminado, como el archivo borrado del error número 1.

El motor Betterleaks combina patrones de credenciales conocidos con técnicas para detectar secretos genéricos. En el caso de los tipos de credenciales compatibles, la función «Live Secret Detection» comprueba si un secreto filtrado sigue activo y ajusta la gravedad del problema en consecuencia. La función «Secrets AutoTriage» utiliza el contexto para distinguir las credenciales reales de los valores de ejemplo o de prueba.

Aikido también detecta los secretos en fases más tempranas del desarrollo. Las extensiones IDE y un hook de pre-commit avisan a los desarrolladores antes de que un secreto llegue a una confirmación. En CI/CD, Aikido puede bloquear una compilación o una solicitud de incorporación de cambios (PR) que contenga uno.

Aikido Device Protection añade una capa de protección en los equipos de los desarrolladores. Su agente analiza los archivos locales del dispositivo, como el historial del shell, en busca de secretos codificados de forma fija. El contenido de los archivos permanece en el dispositivo. Cuando el agente encuentra un secreto, Aikido recibe el tipo de secreto y unos pocos caracteres del valor, suficientes para reconocer el hallazgo.

Betterleaks

Cualquiera puede ejecutar Betterleaks por su cuenta. Aikido patrocina el proyecto, y es gratuito bajo la licencia MIT. El autor original de Gitleaks lo creó como un sustituto directo de Gitleaks.

Recordatorio: Sea cual sea la herramienta que detecte una filtración de un secreto, renuévalo. Aikido señala las credenciales activas y recomienda renovarlas; revoca y sustituye la credencial con el servicio que la emitió. Si eliminas el secreto de tu última confirmación, este seguirá apareciendo en el historial de Git, tal y como muestran los experimentos anteriores.