Exploit encadenado PHP2Shell obtiene root en 25 servidores, incluidos servidores del Gobierno de EE. UU.

Artículo original ↗ Discusión en Hacker News ↗

Una cadena de exploit recientemente divulgada que apunta a una vulnerabilidad crítica de análisis de solicitudes de PHP (“PHP2Shell”) se ha utilizado para obtener acceso root en al menos 25 servidores, incluidos sistemas detrás de un importante proveedor de firewalls y un entorno afiliado al Gobierno de EE. UU. Los comentaristas debaten cuán grave y extendido es realmente el fallo subyacente de PHP, señalando que se ejecuta antes del código de la aplicación o de las comprobaciones de autenticación y a menudo debe encadenarse con escaladas de privilegios del kernel Linux, al tiempo que apuntan que el impacto en el mundo real ha sido limitado por detalles de despliegue, parches y configuración. El incidente plantea preocupaciones más amplias sobre la fragilidad de la infraestructura central de Internet, la postura de seguridad de los firewalls comerciales y de los sistemas del sector público, y el papel creciente de las herramientas de IA tanto para encontrar como para explotar este tipo de errores.

Gravedad y explotabilidad de PHP2Shell

  • Problema central: RCE en el análisis de solicitudes de PHP, antes de cualquier código de la aplicación o autenticación, así que el “código PHP seguro” y las comprobaciones de autenticación habituales no ayudan.
  • Algunos argumentan que se exageró porque:
    • Solo un pequeño número de sistemas del mundo real (25 de ~15k escaneados) terminaron completamente comprometidos mediante esta cadena.
    • Muchas implementaciones de PHP en realidad no eran explotables en la práctica debido a detalles de despliegue o parches.
  • Otros insisten en que es uno de los peores errores en años:
    • RCE preautenticación a nivel de plataforma en un intérprete ubicuo.
    • Las únicas mitigaciones fiables antes de parchear eran básicamente “no ejecutar PHP” o sacar los servicios fuera de línea.
  • El desafío “stealmybitcoin” causó confusión:
    • Inicialmente estaba mal configurado (sin un endpoint real de PHP), luego se corrigió y fue explotado en unas ~2 horas.
    • Se usó para argumentar tanto que era “más difícil de lo anunciado” como que era “definitivamente real y peligroso.”

Cadena de ataque y sistemas afectados

  • Las intrusiones reportadas usaron una cadena:
    • PHP2Shell para la ejecución inicial de código como www-data.
    • Una escalada local de privilegios del kernel Linux (XFRM ESP-in-TCP / probablemente “Dirty Frag”) para obtener root.
  • En este incidente solo se vio afectado PHP sin parchear en una plataforma concreta de firewall; el CVE público está parcheado aguas arriba.

Gestión del firewall, pila del proveedor y mala configuración

  • Fuerte crítica a que las interfaces de administración del firewall estuvieran expuestas directamente a Internet en lugar de estar aisladas en redes de gestión.
  • Consenso del hilo en que el proveedor es Palo Alto Networks (PAN-OS), basándose en:
    • Las versiones de PHP mencionadas.
    • La configuración de SELinux.
    • La pila Appweb + PHP.
  • Debate sobre por qué un “firewall de primera clase” sigue ejecutando PHP:
    • Contexto histórico: PHP era una elección natural en los 2000.
    • Una vez que existen grandes interfaces gráficas, reescribirlas en una pila más segura/simple es caro, así que el legado persiste.

IA, exageración y desarrollo de exploits

  • Varios comentaristas informan que LLMs (Claude Code, DeepSeek, Qwen, otros) ayudaron a construir y optimizar exploits (por ejemplo, una extenuación de memoria más eficiente).
  • Opiniones divididas:
    • Algunos ven el papel de la IA y la narrativa mediática como una exageración de “marketing de seguridad de IA” y clickbait.
    • Otros sostienen que los críticos están minimizando un cambio real en la capacidad de explotación habilitado por la IA.

Superficie de ataque del kernel Linux y endurecimiento

  • Preocupación de que Linux incluya una superficie de ataque muy amplia:
    • Funciones como XFRM, MPTCP, algif_aead, SMB, io_uring+DMABUF a menudo habilitadas por defecto.
  • Algunos usuarios responden auditando los módulos cargados y deshabilitando subsistemas innecesarios.
  • Se reconoce que las distribuciones de propósito general habilitan “todo” por compatibilidad, mientras que configuraciones endurecidas (por ejemplo, Gentoo con kernels personalizados, Android + SELinux) pueden reducir la exposición.

Preocupaciones más amplias de seguridad y confianza

  • Frustración porque sistemas cercanos al gobierno con estrictas exigencias regulatorias siguen exponiendo equipos mal configurados y vulnerables.
  • Algunos cuestionan si la nube pública / SaaS (p. ej., O365) es realmente más segura, dado el flujo constante de nuevas cadenas de exploits.
  • Una minoría especula con trasladar más funcionalidad crítica a hardware/FPGA para lograr determinismo, mientras que otros señalan que eso dificultaría corregir fallos de diseño.