# API key leaks

> Las claves API y los tokens son **métodos de autenticación que se utilizan comúnmente para gestionar permisos y acceso a servicios públicos y privados.** La filtración de estos datos confidenciales puede provocar accesos no autorizados, comprometer la seguridad y posibles filtraciones de datos.

*Claves API: Identificadores únicos que se utilizan para autenticar las solicitudes asociadas a tu proyecto o aplicación.*

*Tokens: Tokens de seguridad (como los tokens OAuth) que otorgan acceso a recursos protegidos.*

***

## Enumeración y Explotación

**`trufflesecurity`** será solo un ejemplo de una "víctima".

Usaremos la herramienta de truffleHog: <https://github.com/trufflesecurity/truffleHog>

* *Leak de API key en el código fuente*: algunos desarrolladores pueden sin querer dejar API keys o tokens directamente en el código fuente.

```
# Ejemplo
api_key = "23fg4443334r3"
```

* *disclosure en repositorios públicos*: Poner accidentalmente datos sensibles a un control publico accesible de sistemas como github

```
# ejemplos

# escanear una organizacion de github
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=trufflesecurity

# escanear un repositorio de github, sus problemas y pull requests
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys --issue-comments --pr-comments
```

* *Harcoding en imagenes de Docker*: Api keys y credenciales podrían estar harcodeadas en Docker images hosteadas en Dockerhub o registros privados

```
# escanear una imagen de docker por secretos verificados
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest docker --image trufflesecurity/secrets
```

* *Logs e Informacion de Debug*: las keys y los tokens podrían ser representadas durante procesos de debugging y logs
* *Archivos de configuración*: Keys y tokens que estan incluidos accidentalmente en archivos de configuración accesibles como:\
  \- archivos .env\
  \- archivos .aws\
  \- config.json\
  \- settings.py\
  \- credential files

> es recomendable buscar en el código fuente esta información si lo tenemos a mano, podemos revisar el github de la web por ejemplo.

#### **Herramientas**

* **Keyfinder es una extensión de Chrome que nos permite buscar en el DOM por cualquier link de script incrustado, que podría contener Keys por una API especifica**

[https://github.com/momenbasel/KeyFinder.git](https://web.archive.org/web/20191012175520/https://github.com/momenbasel/KeyFinder.git)

ahora para la finalizar la instalación ve a:

```
	chrome://extensions
	Ahi activa el "Developer mode"
	agarra y dropea ahi el folder de keyfinder
```

ahora puedes visitar el sitio web del objetivo e ir visitando paginas, la extensión ira automáticamente capturando api keys publicas y ocultas. La extensión te permite agregar tus propios filtros o palabras clave.

**Ahora vamos a verificar nuestras llaves API**

este texto sirve como una **guía para identificar a qué servicio pertenece una API key** y cómo verificar si es válida. Está orientado a investigadores de seguridad (como los que participan en programas de bug bounty)

***

#### Que se puede hacer realmente con api keys?

* Con una clave de AWS puedes listar buckets, lanzar instancias EC2, etc.
* Con una clave de SendGrid puedes mandar emails desde el dominio de la empresa - phishing.
* Con una API key de Mapbox mal configurada, alguien puede usar el servicio y hacer que pagues miles en facturación

> y mucho mas, depende de cada clave y servicio, pero no siempre será como eso, toma en cuenta estos errores:

* Encontrar una API key es crítico, incorrecto: muchas son de solo lectura o tienen permisos limitados
* si la clave es valida, se puede explotar, incorrecto: puede estar ligada a una IP, dominio o limitarse a un endpoint sin riesgo

Siempre que encuentres una clave:

* &#x20;Verifica los permisos (lectura, escritura, admin, etc)
* Verifica el contexto: web pública? app interna? backend?, etc.
* &#x20;controla lo que haces y asi no romperas nada.

#### &#x20;Cómo identificar el contexto:

* **Dónde fue encontrada la clave?**
  * En el frontend (JS minificado): probablemente pública, limitada.
  * En un `.env` privado: probablemente backend o clave sensible.
  * En logs: puede estar usada en producción o staging.
* **Está ligada a una IP, dominio o app?**
  * Algunas claves están **restringidas por IP** (Google Cloud, Firebase).
  * Otras, por **referer** (Mapbox, Algolia).

Prueba mandando peticiones desde un entorno distinto (tu máquina o Burp) y comprueba:

`{ "message": "invalid referer" }`

**Es una clave "test" o "live"?**

* Stripe: `sk_test_` o `sk_live_`
* Algolia: claves de test a veces solo permiten una búsqueda sencilla
* Firebase: claves públicas suelen tener reglas de seguridad activadas

#### &#x20;Que mas deberias revisar:

* Revisa la documentación oficial del servicio, te dirá qué endpoints puedes probar, y cómo ver el scope o permisos.
* **Usa Burp Suite o Postman** para experimentar rápidamente con headers personalizados.
* **En bug bounty**, busca endpoints de la web objetivo que usen esa API key, para ver cómo la usan ellos.

### script de prueba&#x20;

`#!/bin/bash TOKEN="$1" echo "[+] Probando validez..." curl -s -H "Authorization: token $TOKEN" https://api.github.com/user | jq . echo "[+] Probando acceso a repos..." curl -s -H "Authorization: token $TOKEN" https://api.github.com/user/repos | jq .`

Es funcional, aunque podrías expandirlo un poco con mas servicios o detección automática del tipo de token.
