API key leaks

web hacking

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

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:

  • Verifica los permisos (lectura, escritura, admin, etc)

  • Verifica el contexto: web pública? app interna? backend?, etc.

  • controla lo que haces y asi no romperas nada.

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

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

#!/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.

PreviousPrompt injections / ingeniería de promptsNextWeb Cache Deception

Last updated