Las actualizaciones de seguridad de PHP del 21 de octubre siguen siendo la única solución para PHP2Shell, un par de vulnerabilidades que pueden permitir a un atacante no autenticado tomar el control de un servidor vulnerable. Los parches protegen un servidor solo después de que su propietario los instale y reinicie PHP.

El CEO de Cloudflare, Matthew Prince, dijo que los intentos de explotación en la red de la empresa pasaron de miles a millones. La agencia federal de ciberseguridad de Alemania, la BSI, y el gobierno de Japón dijeron que no habían confirmado ninguna intrusión exitosa. La PHP Foundation, que financia el trabajo sobre PHP, dijo que identificó por primera vez señales de una de las fallas en 2024 y calificó el retraso en resolverla como "un fallo estructural".

Estos acontecimientos llegaron un día después de que las dos fallas de PHP llevaran a gobiernos y organizaciones a desconectar sitios web. La pregunta inmediata para los usuarios de internet es si es seguro navegar con normalidad. La respuesta corta es que internet en sí no se rompió, y que la mayoría de los usuarios enfrentan el riesgo a través de los sitios web que visitan, no a través de sus propios teléfonos o computadoras. Sin embargo, muchos servidores aún deben ser parcheados.

PHP, un lenguaje de código abierto del lado del servidor, se utiliza en segundo plano en aproximadamente el 70% de los sitios web cuyo lenguaje de programación del lado del servidor es conocido. Ese alcance es la razón por la que una falla en el propio PHP se convierte en un evento de parcheo a escala web y no en el problema de una sola empresa. Las dos vulnerabilidades, apodadas colectivamente PHP2Shell, pueden permitir a un desconocido tomar el control de un servidor vulnerable sin iniciar sesión.

¿Está corregido PHP2Shell?

PHP lanzó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre, según sus notas de la versión. La publicación indica: "No existen mitigaciones completas, actualizar es la única opción segura". Al 22 de octubre, PHP no había emitido ningún parche de seguimiento.\nLa disponibilidad de un parche no significa que todos los sitios web afectados estén protegidos. PHP no se actualiza por sí solo, por lo que las empresas de hosting, los departamentos de TI y los propietarios individuales de sitios web deben instalar la versión correspondiente en sus propios servidores y reiniciar el software para que el cambio surta efecto. En la práctica, la protección avanza al ritmo del mantenimiento de los servidores, no al momento de la publicación, por lo que cuántos servidores siguen expuestos dependerá de la rapidez con que los operadores completen esos despliegues.

PHP 8.1 y versiones anteriores ya no reciben lanzamientos oficiales, lo que convierte a los servidores antiguos en un punto débil particular. El equipo de seguridad de PHP publicó parches básicos para las versiones 7.4, 8.0 y 8.1 para quienes compilan el software por sí mismos.

¿Se comprometieron servidores?

Los atacantes comenzaron a sondear sistemas vulnerables rápidamente. Prince dijo que Cloudflare vio miles de intentos de explotación durante las 10 horas previas al anuncio público, decenas de miles durante los 45 minutos siguientes, cientos de miles dentro de las dos horas y millones después.

https://x.com/eastdakota/status/2113079352682570051?ref_src=twsrc%5Etfw

Amazon dijo que sus servidores señuelo registraron un intento el 17 de octubre, cuatro días antes de que las vulnerabilidades fueran divulgadas públicamente. El CISO de Amazon, CJ Moses, escribió que "sigue sin estar claro cómo el actor obtuvo información sobre la explotación antes de la divulgación", y señaló que PHP2Shell "ahora está siendo ampliamente explotado en la práctica".

En una publicación de blog de seguridad, Amazon dijo que la actividad se había observado antes de la divulgación pública.

Los gobiernos, sin embargo, no habían reportado intrusiones exitosas confirmadas en ese momento. Thomas Caspers, vicepresidente de la agencia federal de ciberseguridad de Alemania, la BSI, dijo que la agencia había observado ataques pero ninguna explotación exitosa de las fallas. Agregó: "Parece un poco más complicado de explotar de lo esperado". El Secretario Jefe del Gabinete de Japón, Minoru Kihara, dijo asimismo que no se habían confirmado ataques que explotaran las vulnerabilidades.

Un intento de explotación y una intrusión exitosa son eventos distintos. Pueden ocurrir millones de intentos sin que se haya identificado ninguna intrusión confirmada, y las intrusiones exitosas pueden descubrirse después de los hechos y no en tiempo real. Para quienes siguen la historia, esto significa que las actualizaciones sobre brechas confirmadas, si las hay, llegarían a través de investigaciones posteriores y divulgaciones oficiales en lugar de anuncios en tiempo real.

¿Por qué no se corrigió el problema antes?

La PHP Foundation dijo que su trabajo de seguridad en 2024 "encontró las primeras señales del problema OOM detrás de CVE-2026-109618", refiriéndose al error de falta de memoria en el centro de una de las dos vulnerabilidades.

Según el relato de la fundación sobre la actualización de seguridad, el equipo desarrolló "varios enfoques competencia" pero "tuvo dificultades para elegir entre ellos y temía las repercusiones de enviar la elección incorrecta". La fundación dijo que su financiación hizo posible que varias personas trabajaran en el problema a tiempo completo.

"No fingiremos lo contrario: el retraso fue un fallo estructural, causado tanto por el proceso de decisiones del equipo de seguridad como por su falta de recursos", escribió la fundación. Indicó que el equipo de seguridad, que antes requería consenso, ahora tomará decisiones por mayoría de votos.

La fundación también dijo que el trabajo de seguridad sobre el software que ejecuta gran parte de la web "aún depende de un pequeño grupo de desarrolladores financiados por la fundación y un poco de ayuda voluntaria".

¿Por qué algunos sitios web quedaron fuera de línea?

El parcheo lleva tiempo, y a las organizaciones que no podían aplicar la corrección de inmediato se les aconsejó desconectar los sistemas. El National Cyber Security Centre del Reino Unido dijo a las organizaciones que consideraran "desconectar el sistema hasta que pueda mitigarse por completo" en su guía.

Según TechRadar, los sitios web y servicios afectados el 21 de octubre incluyeron los servicios de Wikimedia, los sitios web y aplicaciones de Orange en docenas de países, 32 servicios del gobierno del Reino Unido, hospitales holandeses y el proveedor federal de TI de Alemania, ITZBund.

La Office for Budget Responsibility del Reino Unido y el sitio web del ayuntamiento de Edimburgo volvieron a estar en línea el 22 de octubre. Otros servicios, incluido el sitio web holandés de denuncia anónima de delitos Meld Misdaad Anoniem, seguían fuera de línea la mañana del jueves, según DutchNews.

¿Deben los usuarios cambiar sus contraseñas?

No únicamente por PHP2Shell, al menos según la información disponible. No se había vinculado ninguna brecha de datos confirmada a las vulnerabilidades, y cambiar todas las contraseñas no protegería un sitio web cuyo servidor siguiera sin parchear.

Las medidas de seguridad estándar siguen siendo útiles: usar una contraseña única para cada cuenta, activar la autenticación de dos factores y estar atento a los avisos de las empresas sobre posibles brechas en las próximas semanas. Si una empresa confirma una brecha, los usuarios deben cambiar la contraseña afectada y cualquier otra contraseña que se haya reutilizado.

Los propietarios de sitios web tienen trabajo adicional porque aplicar un parche cierra la vulnerabilidad, pero no revela si un atacante accedió al servidor previamente. La empresa de seguridad Tag1 aconseja buscar archivos PHP que no se hayan subido, nuevas tareas programadas y cuentas recién creadas. También recomienda rotar las contraseñas de bases de datos y las claves de API en cualquier servidor con exposición a internet que haya ejecutado una versión vulnerable. La guía de Tag1 está disponible aquí.

¿Qué significa PHP2Shell para los usuarios de cripto?

El fundador de Binance, Changpeng Zhao, advirtió a los usuarios en X: "Llámenme paranoico, pero sean muy cuidadosos al visitar CUALQUIER sitio web en los próximos días".

https://x.com/cz_binance/status/2113029289155178716

Un servidor web comprometido puede mostrar una versión falsa de un sitio legítimo. En el sector cripto, esa página podría pedir al usuario que conecte su wallet y apruebe una transacción que la vacíe. Una red blockchain puede permanecer intacta mientras los sitios web que dan acceso a ella están comprometidos.

Los usuarios deben verificar cuidadosamente lo que firman, guardar en favoritos los sitios web en lugar de seguir enlaces y usar una hardware si tienen una. Ningún exchange de cripto había reportado públicamente una brecha vinculada a PHP2Shell al 22 de octubre.

¿Es seguro navegar?

Navegar por la web era, en términos generales, tan seguro como la semana anterior, aunque ninguna actividad en internet está libre de riesgos. La exposición principal estaba en los servidores que no habían sido parcheados. La empresa de seguridad Mallory contabilizó aproximadamente 884.000 hosts con exposición a internet que ejecutan versiones de PHP que ya no reciben una corrección oficial.

Amazon instó a los defensores a no asumir que la fecha de divulgación pública fue la fecha más temprana de explotación. "Los defensores no deben asumir que la fecha de divulgación pública es la fecha más temprana de explotación", dijo la empresa. Cualquier servidor que haya ejecutado una versión vulnerable de PHP desde al menos el 17 de octubre debe ser investigado, no solo parcheado.

Fuente original: Decrypt