¿Por qué no tenemos aun un apolalipsis PHP? ¿Por qué con mil millones de webs con PHP, tras 4 días no está saltando medio mundo por los aires? Alguno dirá que es porque hemos aplicado parches, cierto, muchos lo hemos hecho, pero muchos no lo han hecho ni lo harán, hay millones de sistemas vulnerables por el mundo y los delincuentes no dan nunca segundas oportunidades, los que lidiamos a diario con esto sabemos que como te descuides con una actualización de un simple plugin de WordPress acabas con cientos, miles o millones de webs comprometidas y con persistencia instalada. Aquí está pasando algo más complicado y llevo dándole vueltas todo el día, hasta que me acordé del principio de indeterminación de Heisenberg, si cambiamos la física cuántica por procesos de computación, podríamos redactar algo parecido a una "ley de la indeterminación del PHP2Shell" que se podría definir como: "La dificultad de conocer y controlar simultáneamente múltiples propiedades de un proceso remoto". Creo que lo que está pasando es precisamente esto, igual que la ley de indeterminación de Heisenberg desmontó al demonio de Laplace, creo que mi "ley de indeterminación de PHP2Shell" hace inviable que sea explotable, tirando por tierra toda la alarma generada. Si hacemos un análisis de lo que está pasando, parafraseando a Conan Doyle, una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad. Lo que está demostrado que puede hacer PHP2Shell: - Provocar corrupción de memoria - Provocar caída de workers - Conseguir RCE en mod_php - Conseguir RCE en PHP-FPM de laboratorio Lo que no se ha demostrado a fecha de hoy: - Que exista un exploit remoto genérico contra PHP-FPM - Explotación exitosa de PHP2Shell en PHP-FPM de producción Después de revisar los análisis publicados hasta hoy, 25 de octubre, al menos todos los que he podido encontrar, tengo indicios sólidos que me permiten afirmar que, no es que sea difícil desarrollar un exploit, sino que existen condiciones que hacen poco menos que imposible explotar PHP2Shell en una instalación "real" de PHP-FPM (casi todas). El 22 de octubre, Sophos comunicó que había observado una explotación exitosa de PHP2Shell contra uno de sus clientes, cinco horas después se retractaron, porque al revisar la telemetría descubrieron que había habido escaneos e intentos fallidos, pero no una intrusión exitosa. En esta rectificación, su propio equipo de investigación ofensiva estaba teniendo dificultades para conseguir un exploit funcional, incluso utilizando IA (1). El 23 de octubre, CrowdStrike publicó (2) que: - No había observado explotación exitosa en sus honeypots ni en entornos reales monitorizados. - No había encontrado un exploit capaz de funcionar de manera generalizada. - Había conseguido reproducir RCE tanto en mod_php como en PHP-FPM, pero en condiciones de laboratorio. - Los exploits requerían adaptaciones específicas de versión, aplicación y entorno. Creo que se ha infravalorando la dificultad de controlar el heap. Para que un exploit multipetición funcione, pueden tener que coincidir varias de estas condiciones: - Alcanzar el código vulnerable - Preparar el estado de memoria adecuado - Provocar la corrupción sin perder el proceso - Conseguir que la siguiente operación alcance el estado corrupto - Sortear ASLR y otras protecciones de memoria - Desviar la ejecución de manera controlada No basta con acertar en la dirección de memoria o con alcanzar el mismo worker, además tiene que sobrevivir un estado de memoria aprovechable y producirse después la secuencia apropiada de operaciones. Si un zend_bailout() interrumpe la inicialización y el worker termina, el estado desaparece, y esto no es especulación mía, Red Hat identifica precisamente ese comportamiento como uno de los motivos por los que PHP-FPM es mucho más difícil de explotar que mod_php (3), eso puede suponer un obstáculo estructural, porque no importa cuántas veces se repita el ataque si el proceso siempre termina antes de alcanzar el punto explotable. En la publicación de CrowdStrike se distinguen dos variables, una relacionada con el contexto de serialización y otra con el estado global de las sesiones. En ambas, un zend_bailout() puede dejar referencias a memoria que posteriormente se liberan. Para explotarlas hay que conseguir que se vuelva a utilizar esa referencia antes de que el estado se restablezca o resulte inservible. No basta con volver al mismo worker (que de por si no es predecible o al menos no fácilmente), además hay que conseguir que las asignaciones posteriores permitan controlar de manera útil la memoria liberada. Y tenemos que añadir a esto el ASLR (Address Space Layout Randomization), un proceso de protección de las áreas de memoria que cambia cada vez los datos críticos de posición, precisamente para impedir este tipo de ataques, y que PHP usa hace años. También hay que sumarle el asignador de memoria de PHP, las características del binario, el estado de la aplicación y las extensiones cargadas. Es decir, nos falta una pata en todo este proceso, como en el método científico, la reproducibilidad. En un laboratorio puedes fijar la versión exacta de PHP, libc, extensiones, límites de memoria, número de workers y aplicación. También puedes repetir el experimento con un estado inicial conocido y crear así tu PoC (proof of concept), pero en producción y con condiciones imposibles de controlar, entra en juego mi inventada "ley de la indeterminación del PHP2Shell". Creo que hacer un exploit utilizable masivamente con bots de malware es inviable, al menos en instalaciones PHP-FPM, que hoy en día son la mayoría. Seguro que alguno me sacará la intrusión "supuestamente real" contra una entidad gubernamental europea, con ejecución de comandos y movimientos posteriores en la red que publicó Unit 42 (4). Sin embargo, su publicación no demuestra que PHP2Shell fuese el vector inicial ni identifica la SAPI utilizada. Por tanto, no permite afirmar que se haya demostrado una explotación real de PHP2Shell en PHP-FPM. Quiero recordar que casualidad no significa causalidad. Así que volvemos al punto de partida, no hay ni una sola prueba de que se pueda explotar PHP2Shell en un PHP-FPM en producción. Para mi, la hipótesis más sólida es que las vulnerabilidades son reales, pero las formas conocidas de explotarlo no funcionan por la cantidad de variables desconocidas. Creo que todos nos hemos puesto muy nerviosos porque nos hemos acordado al instante de Log4Shell (CVE-2021-44228), una vulnerabilidad crítica de ejecución remota de código (RCE) en la biblioteca Java Apache Log4j, que apareció hace 5 años provocando el caos y que a día de hoy se sigue explotando, a pesar de ser de uso bastante restringido. Es el mismo tipo de vulnerabilidad que PHP2Shell, así que de ser igualmente explotable ya tendríamos un apocalipsis, como dije inicialmente, porque afectaría a mil millones de webs. Pero lo cierto es que no ha pasado nada grave, de hecho lo más grave es que sysadmins de muchas administraciones han apagado sus webs PHP, en una demostración de incompetencia que no tiene parangón, porque da igual cual sea el PHP que tienes, a las muy malas haces un backport usando Claude o Codex, lo compilas y listo, pero no apagas la web. Esto si que da miedo, pensar en la cantidad de gente incapaz al mando de infraestructuras que hay a lo largo y ancho del mundo. Así que, en mi desquiciada opinión (ojo que no digo que esté en posesión de la verdad absoluta), creo que PHP2Shell no es ni será explotable en entornos reales, tal vez pueda serlo como un ataque dirigido con mucho esfuerzo, que está por ver, pero no va a ser la pesadilla de Log4Shell ni creo que vayamos a ver un RCE masivo. Y dejo aquí una pregunta, que creo que es la clave de todo esto: ¿Puede alguien demostrar una cadena de RCE reproducible contra un PHP-FPM estándar, con ASLR activado, varios workers, límites de memoria habituales y sin conocer previamente su configuración interna? Yo creo que no, pero acepto opiniones. Los links de referencia: (1) sophos.com/en-us/blog/proof-… (2) crowdstrike.com/en-us/blog/o… (3) access.redhat.com/security/v… (4) unit42.paloaltonetworks.com/…