Configuraciones inseguras, suministro y ATLAS
Qué configuraciones por defecto de plataformas de ML convierten un despliegue en objetivo de reconocimiento, por qué el registro de modelos y la cadena de suministro son críticos, y cómo mapear todo a MITRE ATLAS.
El reconocimiento rinde porque las plataformas de ML arrastran valores por defecto pensados para un entorno de confianza. Esta nota es un inventario defensivo: qué configuraciones convierten un despliegue rutinario en objetivo, qué hacer con ellas y cómo documentarlo con MITRE ATLAS.
Plataformas y sus valores por defecto#
| Plataforma | Configuración que se convierte en riesgo | Qué hacer |
|---|---|---|
| MLflow | Versiones antiguas sin autenticación. Incluso con autenticación, se han publicado credenciales por defecto y fallos graves (CVSS 9.8) en el manejo de artefactos. | Versión actual; cambiar credenciales de fábrica; proxy con SSO; no exponer el 5000; seguir los avisos del proyecto. |
| Kubeflow | Dashboard sin OIDC, publicado con un LoadBalancer o NodePort. Los notebooks que crea van con cuentas de servicio de Kubernetes con permisos amplios. |
OIDC/SSO delante; ClusterIP + ingress autenticado; cuentas de servicio de mínimo privilegio (IRSA). |
| TorchServe | La API de gestión (8081) permite registrar modelos desde una URL. Cargar un archivo de modelo es ejecutar código del archivo. |
Gestión en 127.0.0.1 o red de administración; restringir allowed_urls a orígenes propios; firmar y verificar modelos. |
| SageMaker (notebooks) | DirectInternetAccess: Enabled expone el notebook a internet. Un informe de 2024 sitúa el problema en la gran mayoría de organizaciones que lo usan. |
Disabled + VPC; reglas de Config/Security Hub que lo detecten; roles de ejecución acotados. |
| Ray | La API de jobs (8265) no tiene autenticación por diseño: asume red de confianza. |
Nunca exponerla; ingress autenticado; segmentación de red. |
El hilo común es el de la nota de mapa: componentes diseñados para vivir dentro de un perímetro que en la práctica ya no existe. «Lo documenta el fabricante» no te protege si el puerto está abierto a internet.
Vulnerable
Seguro
apiVersion: v1kind: Servicespec: type: LoadBalancer # abierto a internet, sin OIDCapiVersion: v1kind: Servicespec: type: ClusterIP # solo el ingress con SSO lo alcanzaEl registro de modelos, otra vez#
Ya lo vimos en la enumeración: el registro es el hallazgo más dañino porque guarda el linaje completo: nombres, versiones, etapas (staging, producción, archivado), marcas de tiempo, identificadores de ejecución con todos los metadatos de entrenamiento, URIs de artefactos y el usuario de cada contribuyente. Un solo registro abierto es el mapa de dónde está todo lo demás. Tratarlo como activo crítico significa lectura autenticada, escritura restringida y auditada, y artefactos en buckets privados.
Reconocimiento de la cadena de suministro#
Los sistemas de IA dependen de recursos externos, y esas dependencias se pueden descubrir desde fuera. Es la misma cadena de suministro de siempre, con piezas nuevas:
- Tokens de Hugging Face filtrados en repositorios (
.env), logs de CI/CD o secretos de Kubernetes. Un token comprometido da lectura y escritura sobre los modelos y datasets privados de la organización. - Confusión de dependencias. Los proyectos de ML tienen
requirements.txtenormes con nombres de paquetes internos. Si un nombre interno no está reservado en PyPI, alguien externo puede registrarlo. Los pipelines que instalan paquetes en vivo durante el entrenamiento ejecutarían ese código dentro del clúster. - Orígenes de descarga de modelos. Las rutas al Hugging Face Hub o al PyTorch Hub aparecen en configuración, notebooks y logs de build. Quien consiga inyectar un modelo en el origen, o sustituir uno con un token robado, envenena toda la cadena.
Mapa a MITRE ATLAS#
MITRE ATLAS es el equivalente de ATT&CK para amenazas contra sistemas de IA y ML. Cada hallazgo de esta sección se puede etiquetar con una técnica, y eso da vocabulario común a un informe.
| Qué viste en el reconocimiento | Técnica ATLAS |
|---|---|
| Escaneo de puertos y sondeo de endpoints de servicios de IA | AML.T0006 · Active Scanning |
| Localizar registros de modelos y artefactos por APIs sin proteger | AML.T0007 · Discover ML Artifacts |
| Tokens expuestos y dependencias envenenadas | AML.T0010 · ML Supply Chain Compromise |
| Enumerar configuración del LLM y compatibilidad de la API | AML.T0014 · Discover ML Model Family |
| Todo lo anterior en conjunto | AML.TA0002 · Reconnaissance (táctica) |
En un informe, anota por cada hallazgo: evidencia, ID de técnica, riesgo y cierre. Los identificadores sirven de ancla, pero comprueba el catálogo vigente de ATLAS porque se actualiza.
Caso: ShadowRay#
ShadowRay es el ejemplo más claro de cómo el reconocimiento de un componente de IA acaba en compromiso de infraestructura. La API de jobs de Ray en el 8265 salió sin autenticación por diseño; Anyscale sostuvo que Ray debía correr solo en redes de confianza y discutió el CVE (CVE-2023-48022). Los atacantes localizaron mediante buscadores un número muy elevado de dashboards expuestos (la cifra citada en el curso es de más de 230.000), y las consecuencias fueron:
- Ejecución de trabajos del atacante en clústeres de entrenamiento.
- Robo de credenciales del entorno, incluidos tokens de IAM, y movimiento lateral por la nube.
- Robo de recursos: nodos de GPU dedicados a minería, con el consumo limitado y los procesos camuflados para pasar inadvertidos.
Una variante posterior, a finales de 2025 según el material, añadió persistencia, alojamiento de cargas en repositorios públicos que migraban al ser retirados y uso del cómputo robado como botnet. La lección defensiva no cambia: un servicio sin autenticación por diseño no puede tocar una red que no controlas.
Tu turno#
Tu turno
Auditoría de valores por defecto
Elige tu plataforma de ML (o una de laboratorio) y rellena esta tabla:
- ¿Qué puertos abre por defecto y cuáles de ellos son de gestión?
- ¿Qué autenticación trae de fábrica? ¿Hay credenciales por defecto?
- ¿Cómo se carga un modelo o un job y desde qué orígenes?
- ¿Con qué identidad (cuenta de servicio, rol) corren los notebooks y los jobs?
- Para cada fila, la técnica ATLAS que describe el riesgo y el control que lo cierra.
Reto
¿Por qué sigue pasando si el fabricante lo documenta?
▸Mostrar solución
Porque quien despliega suele ser un equipo de ciencia de datos que prioriza iterar rápido, el
valor por defecto «funciona» y nadie lo revisa antes de abrir el servicio a una red más amplia. La
documentación asume una frontera de confianza que en la nube se deshace con una sola regla de
security group o un LoadBalancer.
En resumen#
- Las plataformas de ML traen valores por defecto de red de confianza: sin autenticación, credenciales de fábrica, APIs de gestión abiertas.
- Cada una tiene su punto crítico: MLflow (versión y credenciales), Kubeflow (OIDC y cuentas de servicio), TorchServe (API de gestión), SageMaker (acceso directo a internet), Ray (sin autenticación).
- El registro de modelos es el activo más sensible: protege lectura, escritura y artefactos.
- La cadena de suministro se reconoce desde fuera: tokens, nombres internos de paquetes y orígenes de modelos.
- Etiqueta cada hallazgo con ATLAS (T0006, T0007, T0010, T0014 y la táctica TA0002).