David Carrero (Stackscale): “Las amenazas ya no son futuristas, son cotidianas. La resiliencia empieza en el núcleo del sistema”

En un panorama cada vez más automatizado, expuesto y multinube, la seguridad de los servidores Linux en 2025 atraviesa una etapa decisiva. La presión sobre los equipos de sistemas y seguridad ha aumentado ante la proliferación de exploits sofisticados y el abuso continuo de vulnerabilidades conocidas. La infraestructura cloud y bare-metal no escapa a esta realidad.

David Carrero, cofundador de Stackscale (Grupo Aire) y experto en plataformas críticas, advierte: “Ya no basta con aplicar parches. Es necesario rediseñar cómo pensamos la arquitectura de seguridad desde el arranque, desde el firmware hasta las capas de aplicación”.

A continuación, un repaso técnico de las siete vulnerabilidades más críticas que afectan a los servidores Linux este año.

---

1. Escalada de privilegios en SUSE y udisks2 (CVE‑2025‑6018 y CVE‑2025‑6019)

Una cadena de ataque combinada permite a un usuario SSH sin privilegios convertirse en root explotando el módulo pam_env y el demonio udisks2. Afecta a SUSE, Ubuntu, Debian, Fedora y AlmaLinux.

Secuencia del ataque:

1. Usuario SSH manipula variables como XDG_SEAT.
2. PAM le otorga el estado “allow_active”.
3. Udisks2 permite montar una imagen XFS con binario SUID-root.
4. El atacante ejecuta un shell con privilegios de root.

Mitigación inmediata:

• Aplicar los parches emitidos en junio de 2025.
• Modificar Polkit (auth_admin en lugar de allow_active).
• Desactivar user_readenv en SSHD.
• Auditar logs de montajes sospechosos.

🗨 David Carrero: “Lo preocupante de este vector es que no requiere código complejo, solo mala configuración. Es el tipo de fallo que pone en jaque entornos críticos con acceso SSH expuesto.”

---

2. Ejecución remota y MITM en OpenSSH (CVE‑2025‑26465 y CVE‑2025‑26466)

Estas vulnerabilidades, presentes desde OpenSSH 6.8p1 hasta 9.9p1, permiten interceptar conexiones SSH y provocar denegaciones de servicio.

• 26465: ataque man-in-the-middle aceptando claves fraudulentas.
• 26466: paquetes maliciosos pueden colapsar sesiones legítimas.

Solución: actualizar a OpenSSH 9.9p2 o superior.

Refuerzos recomendados:

• Activar StrictHostKeyChecking.
• Deshabilitar algoritmos inseguros como SHA-1 o CBC.
• Limitar accesos con AllowUsers.

🗨 David Carrero: “SSH es la puerta principal en entornos Linux. Si no se audita ni se restringe, cualquier atacante puede aprovechar estas brechas para secuestrar sesiones en producción”.

---

3. Fallos de sincronización en el kernel (CVE‑2025‑1023 y CVE‑2025‑1087)

Detectados en kernels 5.15.0-90 y anteriores (especialmente en Ubuntu 20.04 y 22.04), permiten condiciones de carrera que derivan en escalada de privilegios o denial of service.

Entornos afectados:

• Ubuntu, Debian, RHEL, Fedora y derivados con kernel LTS.

Solución:

• Instalar versiones parcheadas desde los repos oficiales.
• Activar hardening en el kernel (KASLR, CONFIG_DEBUG_RODATA).
• Usar herramientas como AIDE para auditar integridad.

---

4. Spectre-v2 “Training Solo” (CVE‑2024‑28956, CVE‑2025‑24495)

Un nuevo tipo de ataque especulativo en CPUs modernas que anula mitigaciones tradicionales como IBPB y eIBRS.

Riesgo:

• Filtración de memoria del kernel desde procesos usuario.
• Afecta Intel Tiger Lake, Ice Lake, Xeon 2ª–3ª gen, y CPUs ARM.

Mitigación:

• Actualizar microcode (mayo 2025 o superior).
• Instalar kernels con soporte para IBHF.
• Aislar cargas multi-tenant en nubes públicas.

🗨 David Carrero: “Este tipo de ataque demuestra que el aislamiento hardware ya no es suficiente. Las soluciones deben ser multilayered y combinar microcódigo, virtualización segura y segmentación estricta”.

---

5. SSRF modernos en APIs internas cloud

Las vulnerabilidades SSRF (Server-Side Request Forgery) permiten a atacantes acceder a metadatos y configuraciones internas manipulando solicitudes web o API.

Casos reales:

• AWS: exposición de tokens IAM a través de 169.254.169.254.
• Azure y GCP: endpoints de metadatos atacados desde microservicios mal aislados.

Técnicas de evasión 2025:

• Ofuscación de IPs (0xA9FEA9FE).
• DNS rebinding.
• Encadenamiento con LFI o XXE.

Mitigación:

• Bloquear rangos internos desde proxy/firewall.
• Validar URLs con listas blancas.
• Limitar redirecciones y tamaño de respuesta.
• Usar herramientas como ssrfmap o Burp.

---

6. Nuevas brechas en contenedores mal configurados

Aunque no ligadas a CVEs concretos, en 2025 ha habido un aumento en los ataques que escapan de contenedores mal aislados (ej. Docker sin restricciones, --privileged, volúmenes con binarios SUID).

Riesgos habituales:

• Escalada de privilegios al host.
• Acceso a sockets de Docker o Kubernetes.
• Manipulación de imágenes con código persistente.

Recomendaciones:

• Nunca usar contenedores privilegiados en producción.
• Activar AppArmor o seccomp.
• No exponer demonios Docker/Kubelet sin TLS.
• Monitorizar acceso a /proc, /sys y dispositivos virtuales.

🗨 David Carrero: “En cloud y bare-metal, la contenedorización debe ir acompañada de política y control. Las herramientas están, pero pocos se toman en serio la seguridad de bajo nivel en runtime”.

---

7. Repositorios comprometidos o desactualizados

En 2025, varios incidentes en servidores provienen de:

• Uso de repositorios APT/YUM de terceros sin firma.
• Scripts automatizados que instalan paquetes sin verificación GPG.
• Fallos en snap, flatpak o repositorios OCI con imágenes infectadas.

Medidas preventivas:

• Usar solo repos oficiales firmados.
• Activar validación de firmas GPG.
• Aislar entornos de test y producción.
• Monitorizar hashes y cambios inesperados con tripwire.

---

Conclusión

Las vulnerabilidades de 2025 muestran que la superficie de ataque se ha extendido desde el kernel hasta las capas más externas como APIs, contenedores y repositorios. La respuesta debe ser técnica, pero también estratégica.

🗨 David Carrero: “La clave no está solo en los parches, sino en tener visibilidad. La observabilidad, la gestión de configuración y las prácticas de hardening deben integrarse desde el diseño. Esa es la diferencia entre un sistema resiliente y uno expuesto”.

En un mundo donde la disponibilidad y la confianza son factores diferenciales, conocer y mitigar estas siete vulnerabilidades críticas puede ser la diferencia entre la continuidad operativa y un incidente de seguridad devastador.