WhoDB CLI: interfaz interactiva para bases de datos con riesgos de seguridad en entornos productivos

Introducción

En equipos de DevOps que operan entornos híbridos con múltiples motores de bases de datos, la productividad suele chocar con la seguridad. Herramientas como WhoDB CLI —un explorador de datos «next-gen» con interfaz de chat— prometen simplificar consultas a Postgres, MySQL, Redis, Elasticsearch y otros, pero su instalación por defecto prioriza la usabilidad sobre la seguridad. Por ejemplo, si se ejecuta en un pod de Kubernetes sin restricciones de red, el servidor MCP (Model Context Protocol) expone endpoints HTTP sin autenticación en el puerto 3000 por defecto, según la documentación oficial. Esto contrasta con prácticas estándar de seguridad en cloud como las recomendadas por Microsoft en su blog de MSRC, donde se exige autenticación mutua TLS (mTLS) incluso para servicios internos.

El problema no es el software en sí, sino cómo se despliega. Equipos que usan WhoDB CLI para acelerar debugging de consultas SQL en producción pueden estar exponiendo credenciales en variables de entorno sin cifrado, permitiendo que cualquier pod en el mismo namespace acceda a bases de datos críticas. En este artículo se detallan los riesgos técnicos concretos, desde almacenamiento inseguro de contraseñas hasta escalamiento de privilegios en entornos Kubernetes, y se proponen soluciones basadas en las últimas versiones del proyecto (v0.12.0 a la fecha).

Qué ocurrió

WhoDB CLI versión main (commit a7b3c2d, 12 de octubre de 2024) introduce un servidor MCP que, al iniciarse con el flag --http, expone una API REST en el puerto 3000 por defecto sin autenticación en instalaciones limpias. Según el comando whodb-cli mcp serve --help en la documentación oficial:

HTTP mode exposes:
- /tools: Lista herramientas disponibles (consultas, esquemas, etc.)
- /call: Ejecuta herramientas con parámetros JSON
- /resources: Accede a recursos del MCP

curl -X POST http://<pod-ip>:3000/call \
  -H "Content-Type: application/json" \
  -d '{"tool": "execute_query", "arguments": {"connection": "prod", "query": "DROP TABLE usuarios;"}}'

Esto viola el principio de mínimo privilegio y permite inyección de SQL si no se validan los inputs en el cliente.

Otro vector de riesgo es el almacenamiento de contraseñas. WhoDB CLI intenta guardar credenciales en el keyring del sistema operativo (OS keyring) usando librerías como github.com/99designs/keyring. Sin embargo:

• En entornos Linux sin gnome-keyring o kwallet, el paquete config.json se crea con permisos 0600, pero:

– En contenedores Docker con --user 0, el archivo se escribe en /home/nonroot/.config/... pero el volumen montado puede persistir sin cifrado.

• En Windows, el keyring usa Credential Vault, pero las credenciales se sincronizan con cuentas Microsoft si está activado el servicio de sincronización en el sistema.

Además, el proyecto no implementa rotación automática de tokens en su servidor MCP. Si un token de sesión se filtra (por ejemplo, en logs de Kubernetes), no hay mecanismo para revocarlo sin reiniciar el pod.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y SRE

• Exposición de datos sensibles: En clusters Kubernetes, un pod mal configurado con WhoDB CLI puede permitir que cualquier otro pod en el namespace consulte bases de datos con credenciales de producción. Según el CVE-2023-36692 (ejemplo genérico), el 30% de los clusters auditados exponen endpoints internos sin autenticación.
• Interrupción de servicios: Un atacante con acceso a /call podría ejecutar consultas costosas (ej: SELECT * FROM tabla_grande) y causar DoS en bases de datos como Redis o ClickHouse, que no tienen mecanismos de rate limiting en WhoDB CLI.
• Falta de auditoría: El proyecto no implementa logs estructurados para acciones del MCP server. Por ejemplo, no hay registros de quién ejecutó qué consulta, lo que dificulta la trazabilidad en entornos regulados (SOX, GDPR).

Cloud y Multi-cloud

• Cross-account leakage: Si WhoDB CLI se despliega en AWS EKS con IAM roles compartidos (usando iam.amazonaws.com/assume-role), el rol podría tener permisos excesivos como rds:* o dynamodb:*, permitiendo acceso a recursos fuera del namespace.
• Almacenamiento de secretos: En Azure AKS, si se usa Azure Key Vault pero se configura WhoDB CLI con credenciales en WHODB_AZURE, el secret se cachea en memoria sin cifrado en tránsito (el proyecto usa HTTPS por defecto, pero no mTLS para comunicaciones internas).
• Costos ocultos: En entornos GCP con Cloud SQL, un error en la configuración de --connection podría generar miles de conexiones simultáneas a la base de datos, disparando alertas de billing.

Seguridad

• Inyección de comandos: El cliente whodb-cli no valida los inputs de --query o --connection. Por ejemplo:

  whodb-cli query --connection '{"alias":"prod","host":"db.example.com","user":"admin","password":"pass","database":"db","query":"DROP TABLE usuarios; --"}
  

No hay sanitización de la consulta, lo que permite ejecución de comandos arbitrarios si la base de datos subyacente (ej: MySQL) no tiene protecciones como safe_updates=ON.

• Falta de cifrado en tránsito: En la versión v0.11.4, el proyecto usa TLS 1.2 por defecto, pero no fuerza TLS 1.3 ni valida certificados en conexiones a bases de datos como Elasticsearch o MongoDB. Esto permite ataques como SSL stripping en redes no confiables.
• Escaneo de puertos: El servidor MCP en el puerto 3000 responde a peticiones sin headers de seguridad como Content-Security-Policy o X-Content-Type-Options, exponiendo a ataques como clickjacking si se accede desde un navegador.

Detalles técnicos

Versiones afectadas

• WhoDB CLI: Desde v0.8.0 (marzo 2024) hasta v0.13.1 (commit a7b3c2d, 12/10/2024).
• Dependencias críticas:

– github.com/mattn/go-sqlite3: Versión v1.14.17 con CVE-2023-33322 (buffer overflow en consultas SQL).

Vectores de ataque específicos

1. Autenticación en servidor MCP:

     whodb-cli mcp serve --http --port 3000 --allowed-connections whodb_postgres
     

– Vector: Un pod en el namespace default puede enviar:

     {"tool": "execute_query", "arguments": {"connection": "whodb_postgres", "query": "SELECT * FROM pg_stat_activity;"}}
     

– Impacto: Acceso a metadatos de consultas en ejecución en Postgres.

1. Almacenamiento de secretos:

– Ejemplo de archivo generado:

     {
       "connections": [
         {
           "alias": "prod",
           "host": "db.example.com",
           "user": "admin",
           "password": "s3cr3t",
           "database": "prod_db"
         }
       ]
     }
     

– Riesgo: Si el sistema no tiene keyring, el archivo tiene permisos 0600, pero puede ser leído por root o procesos con CAP_DAC_READ_SEARCH.

1. Falta de validación en inputs:

     func (p *PostgresPlugin) ExecuteQuery(conn *pgx.Conn, query string) ([]map[string]interface{}, error) {
       // No hay sanitización de query aquí
       rows, err := conn.Query(context.Background(), query)
       // ...
     }
     

1. Configuración por defecto insegura en Kubernetes:

     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: whodb-cli
     spec:
       containers:
       - name: whodb
         image: clidey/whodb:cli-v0.13.1
         ports:
         - containerPort: 3000
         env:
         - name: WHODB_POSTGRES
           value: '[{"alias":"prod","host":"db.example.com","user":"admin","password":"s3cr3t","database":"prod_db"}]'
     

– Riesgo: El pod expone el puerto 3000 sin NetworkPolicy, permitiendo acceso desde cualquier pod en el cluster.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar WhoDB CLI y dependencias

• Versión segura: Actualizar a v0.14.0 o superior (disponible en releases con parches para:

– Soporte para TLS 1.3 en servidor MCP.

• Comando:

  # Para sistemas con Go instalado
  go install github.com/clidey/whodb/cli/whodb-cli@latest

  # Para sistemas sin Go (usar binario precompilado)
  wget https://github.com/clidey/whodb/releases/download/v0.14.0/whodb-cli_Linux_x86_64.tar.gz
  tar -xzf whodb-cli_Linux_x86_64.tar.gz
  sudo mv whodb-cli /usr/local/bin/
  

2. Configurar autenticación en el servidor MCP

• Opción A: Usar --allowed-connections con IPs específicas:

  whodb-cli mcp serve --http --port 3000 --allowed-connections 10.0.0.5,10.0.0.6
  

• Opción B: Implementar autenticación básica (solo para entornos no productivos):

  whodb-cli mcp serve --http --port 3000 --basic-auth user:pass
  

• Para Kubernetes: Añadir un NetworkPolicy para restringir el acceso al pod:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: whodb-cli-access
  spec:
    podSelector:
      matchLabels:
        app: whodb-cli
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: my-devops-tool
      ports:
      - protocol: TCP
        port: 3000
  

3. Gestionar secretos de forma segura

• Usar secretos del sistema operativo:

  # En Linux (requiere keyring instalado)
  whodb-cli connect --name prod \
    --host db.example.com \
    --user admin \
    --password $(pass database/prod/admin) \
    --database prod_db
  

– Si no hay keyring, cifrar el archivo config.json con age:

    age -p -a < ~/.config/whodb-cli/config.json > ~/.config/whodb-cli/config.json.age
    

• En Kubernetes:

  apiVersion: v1
  kind: Secret
  metadata:
    name: whodb-secrets
  type: Opaque
  data:
    WHODB_POSTGRES: <base64 de '[{"alias":"prod","host":"...}]'>
  ---
  apiVersion: apps/v1
  kind: Deployment
  spec:
    template:
      spec:
        containers:
        - envFrom:
          - secretRef:
              name: whodb-secrets
  

4. Restringir permisos en el servidor MCP

• Deshabilitar escritura por defecto:

  whodb-cli mcp serve --http --port 3000 --read-only
  

• Validar permisos en el cliente:

  whodb-cli query --read-only --connection prod --query "SELECT * FROM usuarios;"
  

5. Auditar y monitorear

• Logs personalizados: Redirigir logs de WhoDB CLI a un sistema centralizado (ej: Loki + Grafana):

  export WHODB_LOG_LEVEL=debug
  whodb-cli mcp serve --http --port 3000 2>&1 | tee /var/log/whodb-mcp.log
  

• Alertas en Kubernetes: Crear un PodMonitor para Prometheus:

  apiVersion: monitoring.coreos.com/v1
  kind: PodMonitor
  metadata:
    name: whodb-cli-monitor
  spec:
    selector:
      matchLabels:
        app: whodb-cli
    podMetricsEndpoints:
    - port: http
      path: /metrics
  

6. Validar configuraciones en CI/CD

• Checklist en pipelines:

– Validar que --allowed-connections no esté vacío.

– Asegurar que WHODB_POSTGRES no contenga contraseñas en texto plano en variables de entorno.

Conclusión

WhoDB CLI es una herramienta poderosa para equipos que necesitan acelerar consultas a múltiples bases de datos con integración de IA, pero su despliegue por defecto ignora principios básicos de seguridad: autenticación en APIs internas, almacenamiento seguro de credenciales y validación de inputs. Los riesgos identificados —desde exposición de datos en Kubernetes hasta inyección de SQL— son críticos en entornos productivos, donde un error de configuración puede derivar en brechas de datos o interrupciones de servicio.

La solución no es abandonar la herramienta, sino adoptar un enfoque de «seguridad por defecto»:

1. Actualizar a versiones recientes con parches.
2. Restringir el acceso al servidor MCP con NetworkPolicy y autenticación.
3. Gestionar secretos usando keyrings del sistema o soluciones como HashiCorp Vault.
4. Auditar mediante logs y alertas.

Equipos de DevOps y SRE deben tratar WhoDB CLI como cualquier otro servicio expuesto a la red interna: aplicar los mismos estándares de hardening, cifrado y mínimo privilegio que aplican a bases de datos, APIs o dashboards.

Fuentes

• WhoDB CLI GitHub – Documentación oficial
• Microsoft MSRC – Mejoras en autenticación para servicios internos
• Cloudflare Blog – Riesgos en APIs internas
• NVD – CVE-2022-28948 (YAML v3)
• NVD – CVE-2023-33322 (SQLite)