En resumen: Según los informes, CERT-EU aconseja registrar las instalaciones de PHP, parchear de inmediato y aislar las aplicaciones accesibles públicamente si no pueden parchearse a tiempo. CERT-Bund y el BSI (Oficina Federal alemana para la Seguridad de la Información) recomiendan en su alerta la actualización inmediata y, si no es posible, desconectar temporalmente de la red los servidores web afectados. Las recomendaciones coinciden en lo esencial: primero la actualización, el aislamiento como solución de emergencia y las medidas provisionales solo como complemento.
¿Quién alerta y para quién?
Con PHP2Shell, varios organismos oficiales reaccionaron en pocas horas. Para las empresas en Alemania, el BSI, con su equipo de respuesta a emergencias informáticas CERT-Bund (el CERT del Gobierno alemán), es la primera dirección a la que acudir. CERT-EU es el servicio de ciberseguridad de las instituciones de la UE; sus avisos se dirigen en primer lugar a ellas, pero se leen en toda Europa. Según BleepingComputer, también alertó el National Cyber Security Centre británico. Del sector privado se pronunciaron, entre otros, Huntress y Cloudflare.
Para usted como administrador, el origen importa menos que la coincidencia. Cuando varios organismos independientes aconsejan lo mismo, es una señal fuerte.
CERT-Bund, CERT-EU y otros: las alertas sobre PHP comparadas
| Organismo | Recomendación principal | Particularidad |
|---|---|---|
| BSI / CERT-Bund | actualizar de inmediato; si no, desconectar temporalmente el servidor web de la red | nivel de alerta 3 / naranja |
| CERT-EU | registrar las instalaciones de PHP, parchear de inmediato; si no, aislar las aplicaciones públicas | según los informes, consideraba posible que estuvieran afectadas las versiones desde PHP 5 |
| UK NCSC | actualizar de inmediato o desconectar de la red los sistemas afectados hasta el parche | según BleepingComputer |
| php.net | actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35; las medidas provisionales solo como protección parcial | fuente primaria de versiones y ajustes |
Ninguno de los organismos recomienda confiar únicamente en un cortafuegos de aplicaciones web (Web Application Firewall) o en ajustes del php.ini. Todos señalan la actualización como la verdadera solución. Lo que aconseja el BSI además, en detalle, figura en la página Qué recomienda el BSI sobre PHP2Shell.
La cuestión de las versiones: qué significa «desde PHP 5»
Según los informes, CERT-EU consideraba posible que estuvieran afectadas las versiones desde PHP 5. Según informes especializados, el organismo se basó en información que circulaba antes del aviso oficial. La prensa especializada habla de casi todas las versiones hasta PHP 5.4.
En la práctica, el límite exacto cambia poco. Para PHP 8.1 y anteriores, el proyecto PHP ya no ofrece actualizaciones oficiales. Existen backports mínimos del código fuente para 7.4, 8.0 y 8.1, pero no versiones publicadas. Quien aún opera PHP 5 o 7 depende de las distribuciones, de terceros o de una migración. Si su distribución ha entregado una corrección lo muestran sus propias páginas de seguridad, por ejemplo el Debian Security Tracker, los Ubuntu Security Notices o los avisos de Red Hat. También existen ofertas comerciales de soporte a largo plazo para versiones antiguas de PHP; si cubren PHP2Shell, conviene que el proveedor se lo confirme por escrito. Los detalles sobre las ramas figuran en ¿Qué versiones de PHP están afectadas? y PHP 8.1 y anteriores.
Aislar: cómo aplicar la recomendación
«Aislar» suena abstracto. Se refiere a que las peticiones desde internet dejen de llegar a la aplicación PHP vulnerable. Según la aplicación, hay varios niveles:
- Desconectar por completo: la web se sustituye por una página de emergencia estática sin PHP. Es la variante más segura.
- Restringir el acceso: la aplicación sigue en funcionamiento, pero solo es accesible por VPN o desde direcciones IP determinadas, por ejemplo para portales internos.
- Inicio de sesión previo: una autenticación a nivel de servidor web o de proxy antes de la aplicación. Atención: con mod_php se demostró un exploit antes de que se ejecute el código de la aplicación. Por eso la autenticación tiene que actuar antes de PHP, no dentro de la aplicación.
- Bloquear el acceso directo al origen: quien use un servicio de proxy o de CDN debería asegurarse de que el servidor no sea además accesible directamente.
Una restricción en el servidor web puede tener este aspecto, como configuración inofensiva para Apache:
# Permitir el acceso solo desde la red interna (adapte el rango de ejemplo)
<Location "/">
Require ip 192.0.2.0/24
</Location>
Pruebe el efecto desde fuera, por ejemplo mediante una conexión de datos móviles. Un aislamiento que solo se ha comprobado en la red de la oficina no es un aislamiento comprobado.
Aislar es una solución transitoria. Al aislar, fije enseguida para cuándo llegará la actualización y quién la aplicará. De lo contrario, la solución de emergencia se convierte en un estado permanente.
Lo que exigen en común las recomendaciones: un inventario
Todos los organismos oficiales dan por supuesto que usted sabe dónde se ejecuta PHP. Justo ahí fallan muchas empresas: microsites de campañas antiguas, un portal de clientes olvidado, un sistema de pruebas con dirección pública, una aplicación en un NAS. CERT-EU menciona expresamente el registro de las instalaciones de PHP como primer paso.
Los sistemas olvidados se encuentran con más probabilidad por tres vías: las zonas DNS de sus dominios, la lista de certificados TLS emitidos y los contratos con agencias, proveedores de alojamiento y proveedores de software. Cada entrada de la que nadie sepa decir enseguida qué hay detrás debe ir a la lista de revisión. Justo esos sistemas son peligrosos en una situación como PHP2Shell, porque nadie los parchea y nadie los echa de menos cuando se ven comprometidos.
Un inventario útil contiene por cada sistema: dirección, finalidad, responsable, versión de PHP y modo de ejecución, origen de los paquetes y la persona de contacto para las actualizaciones. Cómo crearlo y mantenerlo al día lo muestra el artículo Inventario de todos los sitios web y servidores.
¿Cómo ayuda PHP SOS en concreto?
- Registro: identificamos sus sistemas PHP accesibles públicamente y los ordenamos por riesgo.
- Parche o aislamiento: aplicamos actualizaciones o aislamos las aplicaciones que no pueden parchearse de inmediato, y comprobamos el efecto desde fuera.
- Versiones antiguas: para los sistemas con PHP 8.1 y anterior, planificamos con usted el camino hacia una versión compatible.
- Justificante: usted recibe una documentación de las recomendaciones aplicadas en cada sistema.
Cómo llevamos las aplicaciones antiguas a versiones compatibles lo describe el servicio de migración de PHP para sistemas heredados.
Conclusión
CERT-EU, CERT-Bund, el BSI y el proyecto PHP hablan con una sola voz: actualizar y, donde no sea posible de inmediato, aislar. Las diferencias están en detalles como el límite de versiones. Para su práctica cuenta el primer paso que todos dan por supuesto: saber dónde se ejecuta PHP en todas partes.
Preguntas frecuentes
¿Qué diferencia hay entre CERT-Bund y CERT-EU?
CERT-Bund es el equipo de respuesta a emergencias informáticas del BSI (Oficina Federal alemana para la Seguridad de la Información) y alerta en Alemania sobre vulnerabilidades. CERT-EU es el servicio de ciberseguridad de las instituciones y organismos de la Unión Europea. Ambos publican recomendaciones que también son útiles para las empresas.
¿Qué significa aislar una aplicación PHP?
Después, la aplicación ya no es accesible libremente desde internet. Es posible mediante una página de emergencia, mediante acceso solo por VPN o desde determinadas direcciones IP, o mediante una desconexión completa. Lo decisivo es que las peticiones desde fuera dejen de llegar al proceso de PHP vulnerable.
¿Según CERT-EU, también están afectadas las versiones de PHP 5?
Según los informes, CERT-EU consideraba posible que estuvieran afectadas las versiones desde PHP 5, basándose en información que circulaba antes del aviso oficial. La prensa especializada menciona casi todas las versiones hasta PHP 5.4. Para versiones tan antiguas no hay actualizaciones oficiales.
¿Existen indicadores oficiales para reconocer ataques?
No. Hasta ahora no hay indicadores de compromiso (Indicators of Compromise) publicados ni confirmados sobre PHP2Shell. La detección se basa en el análisis del comportamiento, por ejemplo procesos del servidor web que lanzan shells o archivos PHP nuevos en las carpetas de subida.