7 formas de exponer contraseñas, API keys y secretos sin darte cuenta
Estimados amigos de Inseguros !!!
Cuando hablamos de una fuga de información, mucha gente imagina una operación de hacking tremendamente sofisticada.
Un 0-day. Un exploit desconocido. Un atacante utilizando técnicas avanzadísimas para atravesar media docena de controles de seguridad.
Y luego resulta que la contraseña estaba en GitHub.
En texto plano.
Desde hacía ocho meses.
Muchas exposiciones de información sensible no empiezan con un ataque espectacular. Empiezan con algo bastante menos cinematográfico: un error durante el desarrollo, una mala configuración o una credencial que alguien no debería haber publicado.
Un archivo .env subido al repositorio, una API key escrita directamente en el código, un token que aparece en un log de CI/CD o una captura de pantalla donde se ve más de lo que debería.
Y esto es especialmente interesante desde el punto de vista del hacking ético y el pentesting, porque una parte importante del trabajo de reconocimiento consiste precisamente en localizar información que una organización ha expuesto sin darse cuenta.
Vamos a ver algunas de las formas más habituales de exponer contraseñas, tokens, API keys y otros secretos.
¿Qué consideramos un secreto en ciberseguridad?
Antes de continuar conviene aclarar qué entendemos por secreto.
No hablamos únicamente de una contraseña.
Dentro de una aplicación o infraestructura podemos encontrar información sensible como:
- Contraseñas de bases de datos.
- API keys.
- Tokens de acceso.
- Tokens OAuth.
- Credenciales de servicios cloud.
- Claves privadas.
- Connection strings.
- Credenciales de cuentas de servicio.
- Webhooks privados.
- Tokens de CI/CD.
- Secretos JWT.
- URLs internas con credenciales.
- Información de acceso a infraestructura.
El problema aparece cuando alguno de estos datos termina en un lugar donde no debería estar.
Y muchas veces no hace falta comprometer ningún servidor para encontrarlo.
Puede estar en un repositorio público.
En un fichero olvidado.
En un log.
En una captura de pantalla.
O indexado por un buscador.
1. Archivos .env publicados en GitHub
Este es uno de los clásicos.
Los archivos .env se utilizan habitualmente para almacenar variables de entorno necesarias para una aplicación.
Por ejemplo:
DB_USER=admin
DB_PASSWORD=MiPasswordSuperSegura
API_KEY=xxxxxxxxxxxxxxxx
JWT_SECRET=xxxxxxxxxxxxxxxx
El problema no es utilizar variables de entorno.
El problema es terminar subiendo el fichero que contiene los valores reales a GitHub, GitLab, Bitbucket o cualquier otro repositorio accesible.
Y sí.
Pasa.
Un desarrollador crea el archivo para probar algo localmente.
Hace un git add.
Hace commit.
Push.
Y ya tenemos las credenciales dentro del historial del repositorio.
Añadir posteriormente el fichero a .gitignore ayuda a evitar futuros commits, pero no elimina mágicamente el secreto del historial de Git.
Si una credencial real ha llegado a un repositorio que no debía contenerla, hay que asumir que puede haber sido comprometida y actuar en consecuencia.
2. API keys escritas directamente en el código
Otro clásico:
const API_KEY = "xxxxxxxxxxxxxxxxxxxxxxxx";
Es rápido.
Funciona.
Y es una idea horrible.
Las credenciales escritas directamente dentro del código fuente pueden terminar en:
- Repositorios públicos.
- Repositorios internos con demasiados usuarios.
- Copias de seguridad.
- Paquetes distribuidos.
- Imágenes Docker.
- Aplicaciones móviles.
- Artefactos de compilación.
- Forks del proyecto.
Además, existen herramientas automáticas capaces de revisar enormes cantidades de código buscando patrones que se parecen a claves, tokens y credenciales.
Por tanto, pensar:
«Nadie va a mirar este repositorio»
no es precisamente una estrategia de seguridad.
De hecho, aprender a buscar información expuesta forma parte del reconocimiento y del OSINT utilizado en hacking ético profesional.
Antes de intentar explotar una máquina, muchas veces merece la pena comprobar qué ha publicado ya la propia organización.
3. Secretos expuestos en logs de CI/CD
Los pipelines CI/CD automatizan compilaciones, pruebas y despliegues.
Y para hacer todo eso suelen necesitar permisos.
Muchos permisos.
Un pipeline puede necesitar acceso a:
- Repositorios.
- Registros de contenedores.
- Azure.
- AWS.
- Kubernetes.
- Bases de datos.
- Servidores.
- Servicios externos.
Eso significa que en algún punto estamos manejando credenciales, tokens o identidades.
El problema llega cuando durante una compilación alguien hace algo parecido a:
echo $API_TOKEN
o cuando una aplicación muestra accidentalmente las variables de entorno durante una ejecución de diagnóstico.
El secreto puede terminar almacenado dentro del log del pipeline.
Y entonces aparece una pregunta importante:
¿Quién puede leer esos logs?
Porque proteger el secreto original y después imprimirlo en una consola accesible por medio departamento no ayuda demasiado.
Este tipo de problemas son un buen ejemplo de por qué una auditoría de ciberseguridad no debería limitarse a ejecutar un escáner de vulnerabilidades. También hay que revisar procesos, permisos, configuraciones, exposición y evidencias.
4. Logs de depuración que muestran tokens o contraseñas
Durante el desarrollo es completamente normal añadir trazas para entender qué está ocurriendo.
Algo como:
console.log(token);
console.log(user);
console.log(response);
El problema empieza cuando aquello que servía para depurar acaba llegando a producción.
Imagina que imprimimos la respuesta completa de un proceso de autenticación.
Dentro puede aparecer:
- Un access token.
- Un refresh token.
- Un identificador de sesión.
- Información del usuario.
- Cabeceras HTTP.
- Datos personales.
Ahora ese dato sensible ya no existe únicamente dentro de la aplicación.
También está en el sistema de logging.
Quizás además se replica a un SIEM.
Quizás se exporta a otro servicio.
Quizás permanece almacenado durante un año.
Una línea de debug aparentemente inocente puede multiplicar los lugares donde termina almacenado un secreto.
Por eso la monitorización también necesita criterio. Herramientas como Wazuh permiten centralizar eventos, crear reglas y detectar actividad, pero primero debemos decidir correctamente qué datos enviamos a nuestros sistemas de monitorización. Si quieres trabajar esta parte, tienes disponible el curso práctico de Wazuh, reglas y detección.
5. Ficheros de configuración con credenciales reales
Otro lugar habitual donde aparecen secretos son los ficheros de configuración.
Por ejemplo:
config.jsonsettings.ymlapplication.propertiesweb.configappsettings.json- Scripts PowerShell.
- Playbooks.
- Plantillas de infraestructura.
El problema no es el formato del fichero.
El problema es utilizar credenciales reales donde deberían existir referencias a un sistema seguro de gestión de secretos.
Algo especialmente peligroso es utilizar una contraseña temporal durante una prueba y olvidarse posteriormente de sustituirla.
Temporal.
La palabra favorita de la informática.
Hay servidores temporales con diez años.
Y contraseñas temporales que duran más que algunos empleados.
6. Buckets y almacenamiento cloud configurados como públicos
No todos los secretos se filtran a través del código.
También tenemos la nube.
Un almacenamiento cloud mal configurado puede exponer archivos que deberían ser privados.
Por ejemplo:
- Backups.
- Documentos internos.
- Logs.
- Exportaciones de bases de datos.
- Archivos de configuración.
- Imágenes.
- Datos de clientes.
El problema normalmente no es que AWS S3, Azure Storage o el proveedor correspondiente «publique archivos» por su cuenta.
El problema está en la configuración de permisos.
Cloud no elimina los problemas clásicos de seguridad.
Les añade una API.
Por eso, cuando trabajamos seguridad en Azure o cualquier otra nube, no basta con aprender a crear recursos. Hay que comprender identidades, permisos, exposición, configuraciones y cómo puede aprovecharlos un atacante.
Si trabajas con este tipo de entornos, en SeguridadSi puedes consultar la formación específica de ciberseguridad en Azure, Microsoft y cloud dentro del catálogo de la academia.
7. Capturas de pantalla que muestran demasiado
Esta me gusta especialmente porque parece una tontería.
Hasta que deja de serlo.
Alguien publica en LinkedIn, Twitter, un foro, Discord o un grupo de Telegram una captura para enseñar:
«Mirad lo que estoy montando».
Y de regalo incluye:
- Una API key.
- Una URL interna.
- Un nombre de servidor.
- Una dirección IP.
- Un nombre de usuario.
- Un tenant.
- Un correo corporativo.
- Una ruta interna.
- Una cookie.
- Un token.
El atacante ni siquiera ha tenido que conectarse a la infraestructura.
Le hemos enviado la información en JPEG.
Esto es especialmente importante cuando hablamos de OSINT y reconocimiento.
La información aparentemente insignificante puede ser útil cuando se combina con otras fuentes.
Un dominio por aquí.
Un usuario por allá.
Una tecnología en una oferta de empleo.
Una URL interna en una captura.
Un repositorio antiguo.
Y poco a poco obtenemos un mapa bastante interesante de la organización.
En el curso gratuito de hacking ético y ciberseguridad tienes una introducción a OSINT, hacking web, redes y entornos Microsoft si todavía estás empezando en estas materias.
GitHub y los secretos: borrar el archivo no siempre soluciona el problema
Este punto merece una sección propia.
Imagina que subimos una API key a GitHub.
Nos damos cuenta cinco minutos después.
Borramos la línea.
Commit.
Push.
Problema solucionado.
No necesariamente.
Git mantiene un historial de cambios.
Eso significa que una credencial eliminada de la versión actual puede continuar existiendo en commits anteriores.
Y si el repositorio ha sido público debemos trabajar con la hipótesis de que alguien podría haber obtenido ese secreto.
Por eso la respuesta correcta ante una credencial expuesta no suele ser únicamente:
«Ya la he borrado».
La pregunta importante es:
«¿Sigue siendo válida?»
¿Qué hacer si has publicado una contraseña o API key?
Si detectamos una credencial expuesta, actuar rápido es importante.
Un procedimiento básico debería contemplar:
- Revocar o rotar inmediatamente el secreto.
- Determinar durante cuánto tiempo ha estado expuesto.
- Comprobar dónde se ha publicado.
- Revisar los logs asociados a esa credencial.
- Buscar posibles usos no autorizados.
- Identificar otros lugares donde pueda haberse reutilizado.
- Eliminar el secreto de repositorios e históricos cuando corresponda.
- Documentar el incidente.
- Corregir el proceso que permitió la exposición.
Lo primero es importante.
Rotar.
Una API key filtrada y posteriormente borrada de GitHub continúa siendo una API key válida si no la hemos revocado.
No estamos eliminando una fotografía de la llave.
Estamos diciendo que esa llave ya no abre la puerta.
Cómo evitar secretos expuestos en GitHub y repositorios
Hay varias medidas básicas que reducen muchísimo este problema.
No guardes secretos dentro del código
Las credenciales deberían mantenerse separadas del código fuente.
Utiliza mecanismos específicamente diseñados para almacenar secretos y proporcionar acceso únicamente a los procesos que los necesitan.
Utiliza un gestor de secretos
Dependiendo de la infraestructura podríamos utilizar soluciones como:
- AWS Secrets Manager.
- Azure Key Vault.
- HashiCorp Vault.
- Google Secret Manager.
- Gestores de secretos integrados en las plataformas CI/CD.
La idea es sencilla:
El programa necesita utilizar el secreto.
No necesita llevarlo escrito encima.
Utiliza correctamente .gitignore
Los archivos que contienen información local o sensible no deberían terminar en el repositorio.
Por ejemplo:
.env
.env.local
*.key
credentials.json
secrets.yml
Pero recuerda:
.gitignore ayuda a evitar que un fichero nuevo sea añadido accidentalmente.
No convierte en invisible un secreto que ya has publicado.
Utiliza herramientas de secret scanning
Existen herramientas capaces de analizar repositorios buscando patrones que podrían corresponder a secretos.
Esto permite detectar:
- API keys.
- Tokens.
- Claves privadas.
- Credenciales cloud.
- Contraseñas.
Y aquí enlazamos directamente con algo que vimos en el artículo sobre análisis SAST y seguridad del código.
No debemos esperar a producción para empezar a buscar problemas.
Cuanto antes detectemos el error, menos posibilidades existen de que termine convirtiéndose en un incidente.
Revisa los permisos de los logs
No todo el mundo necesita acceder a los logs de CI/CD.
Ni a los logs de producción.
Ni a los logs del sistema de autenticación.
Aplica mínimo privilegio también aquí.
Revisa los permisos del almacenamiento cloud
Especialmente cuando manejamos:
- Backups.
- Exports.
- Logs.
- Información personal.
- Archivos de configuración.
Un bucket creado como prueba puede terminar convirtiéndose en producción.
Y nadie vuelve a mirar sus permisos.
Cómo puede encontrar un pentester información expuesta
Desde el lado ofensivo, todo esto cambia de perspectiva.
Durante un ejercicio de hacking ético autorizado podemos analizar la información pública disponible sobre una organización.
Por ejemplo:
- Repositorios asociados a empleados o a la empresa.
- Commits antiguos.
- Ficheros de configuración.
- Subdominios.
- Documentos públicos.
- Metadatos.
- Aplicaciones web.
- Endpoints.
- Información publicada en redes sociales.
Y esto es algo que considero muy importante cuando alguien está aprendiendo hacking.
Hacking no significa lanzar exploits todo el rato.
Encontrar una credencial válida que una organización ha publicado accidentalmente puede ser mucho más importante que ejecutar cincuenta herramientas.
Reconocimiento.
Enumeración.
Contexto.
Y después, si procede, explotación.
Ese es precisamente el enfoque del curso completo de Hacking Ético de SeguridadSi: construir una metodología y entender por qué hacemos cada cosa, no aprender una lista de comandos de memoria.
Automatizar ayuda, pero no sustituye a una auditoría
Podemos introducir scanners de secretos.
Podemos utilizar SAST.
Podemos escanear dependencias.
Podemos añadir controles al pipeline.
Todo eso está bien.
Pero ninguna herramienta conoce completamente nuestro negocio, nuestra arquitectura y el contexto de nuestra empresa.
Una auditoría técnica debería revisar también:
- Cómo gestionamos credenciales.
- Quién tiene acceso.
- Qué permisos tienen las cuentas.
- Cómo funcionan nuestros pipelines.
- Qué información estamos registrando.
- Qué servicios tenemos expuestos.
- Cómo está configurada nuestra infraestructura cloud.
- Cómo respondemos cuando una credencial se filtra.
Si quieres aprender esta visión más amplia, puedes consultar el Curso Profesional de Auditoría de Ciberseguridad.
Aprender ciberseguridad no consiste en aprender 200 herramientas
Y aquí viene una de mis batallas habituales.
Internet está lleno de:
«10 herramientas que todo hacker debe conocer».
«50 herramientas increíbles de GitHub».
«Los 20 comandos que utiliza un pentester».
Eso está bien para descubrir cosas.
Pero aprender ciberseguridad es otra cosa.
Necesitas comprender:
- Qué estás buscando.
- Por qué puede ser vulnerable.
- Qué información necesitas.
- Cómo comprobar una hipótesis.
- Cómo medir el impacto.
- Cómo documentarlo.
- Cómo corregirlo.
Si quieres empezar sin pagar nada, tienes los recursos gratuitos de ciberseguridad de SeguridadSi, con formación y material sobre hacking ético, Blue Team, Red Team, Azure y fundamentos.
Y si ya tienes una base técnica pero el problema es que vas saltando continuamente entre tutoriales, vídeos, noticias y herramientas, la Membresía de Ciberseguridad de SeguridadSi está pensada precisamente para avanzar mediante rutas, cursos, laboratorios, directos y comunidad en lugar de acumular contenido que nunca terminas.
¿Y si quiero formar al equipo de mi empresa?
Todo lo que hemos visto afecta directamente a desarrolladores, administradores, equipos cloud, DevOps, DevSecOps, sistemas y seguridad.
No es un problema exclusivo del departamento de ciberseguridad.
Un desarrollador puede publicar el secreto.
DevOps puede imprimirlo en un pipeline.
Cloud puede configurar incorrectamente el almacenamiento.
Seguridad puede no detectarlo.
Y negocio puede pagar el incidente.
Si eres una empresa en España y quieres formar a tu equipo técnico, SeguridadSi dispone de formación profesional en ciberseguridad bonificable mediante FUNDAE dentro del programa completo, con cursos orientados a hacking ético, auditoría, SOC, Microsoft, Azure, vulnerabilidades y seguridad defensiva.
Conclusión: muchos incidentes empiezan por cosas sencillas
No todos los incidentes empiezan con una vulnerabilidad desconocida.
A veces empiezan con:
Un .env.
Una API key.
Un log.
Un fichero de configuración.
Un bucket.
Una captura.
Cosas sencillas.
Cosas aburridas.
Cosas que precisamente por parecer sencillas dejamos de revisar.
Y reducir la superficie de ataque empieza muchas veces por hacer bien esas cosas básicas.
No publiques secretos.
No escribas credenciales en el código.
No muestres tokens en los logs.
Revisa los permisos.
Automatiza la detección.
Y si un secreto se expone, rótalo.
No mañana.
Ahora.
Gracias por leerme !!!
Preguntas frecuentes sobre contraseñas, API keys y secretos expuestos
¿Qué pasa si subo un archivo .env a GitHub?
Si el archivo contiene credenciales, API keys o tokens reales, esos secretos podrían quedar expuestos a cualquier persona con acceso al repositorio. Si el repositorio es público, debes considerar las credenciales potencialmente comprometidas y rotarlas.
¿Borrar una API key de GitHub es suficiente?
No necesariamente. Git conserva un historial de los commits y la clave podría continuar presente en versiones anteriores del repositorio. Además de eliminarla del código, debes revocarla o rotarla.
¿Qué es secret scanning?
Secret scanning es el análisis automático de repositorios y otros recursos para localizar cadenas que pueden corresponder a contraseñas, tokens, claves privadas, API keys y otros secretos.
¿Dónde deben almacenarse las API keys?
Las API keys y otras credenciales deberían almacenarse mediante mecanismos destinados específicamente a la gestión de secretos, como Azure Key Vault, AWS Secrets Manager, HashiCorp Vault o soluciones equivalentes, y no escribirse directamente dentro del código fuente.
¿Para qué sirve un archivo .gitignore?
.gitignore permite indicar a Git qué archivos o patrones no deberían añadirse normalmente al repositorio. Es habitual utilizarlo para excluir archivos locales, temporales y ficheros como .env, aunque no elimina secretos que ya hayan sido incluidos previamente en el historial.
¿Un pentester puede buscar secretos publicados en GitHub?
Sí, siempre dentro del alcance y autorización del ejercicio. La revisión de información pública, repositorios, metadatos y otras fuentes forma parte de las técnicas de reconocimiento y OSINT utilizadas durante trabajos profesionales de hacking ético.
¿Dónde puedo aprender hacking ético y ciberseguridad?
Si empiezas desde cero, puedes acceder al curso gratis de hacking ético y ciberseguridad de SeguridadSi. Si ya tienes conocimientos técnicos, puedes consultar el catálogo completo de cursos de ciberseguridad o avanzar mediante la membresía de SeguridadSi.
