Fue clave para que las páginas dejaran de ser folletos que solo se leían y pasaran a guardar datos, mostrar contenido a medida y recibir comentarios: la base de los blogs y las redes sociales de los 2000. Sobre él se construyeron WordPress, el programa más usado para publicar sitios, y Drupal, además de Facebook en sus inicios y Wikipedia.
Por eso el hallazgo encendió las alarmas. Según Santiago Pérez y Yago Méndez, analistas de Team Capybara, un grupo independiente de investigación en ciberinteligencia enfocado en América Latina, las dos fallas, bautizadas como PHP2Shell, llevaban 14 años escondidas en el código.
Si un sitio web fuera un edificio, PHP sería la estructura sobre la que está levantado: las paredes y las vigas que nadie ve pero que sostienen todo. Según Danilo Espino, ingeniero especializado en ciberseguridad, esa estructura está detrás de entre el 70% y el 75% de los sitios del mundo.
En Uruguay la proporción es parecida. Según un relevamiento del sitio WMTips citado por Andrés Gómez, CEO de la empresa uruguaya de ciberseguridad Nexa, el 68% de los sitios uruguayos están hechos con PHP.
Qué puede hacer un atacante
La falla equivale a una puerta trasera que quedó sin llave en todos esos edificios a la vez. Para entrar, alcanza con mandarle al servidor –la computadora donde está guardado el sitio– un pedido armado de cierta forma, explicó Richard Pérez, experto en ciberseguridad.
Tener una página bien hecha no sirve de escudo. Según Team Capybara, en las configuraciones más comunes la falla se activa antes de que el sitio llegue a leer el pedido, así que da igual cuán cuidado esté su diseño.
No hace falta usuario ni contraseña. "En criollo, podrían dejar que ciberdelincuentes tomen el control de servidores web sin necesidad de siquiera autenticar en un sistema", dijo Gómez. En la escala internacional que mide la gravedad de estas fallas, recibió 9,2 puntos sobre 10.
Una vez adentro, el atacante puede usar ese servidor como si fuera propio. "El alcance de esto es infinito", afirmó Richard Pérez. "Podrías acceder a una base de datos, podrías borrar, podrías obviamente entrar a caminar después dentro de una organización", es decir, saltar desde ahí a otras computadoras de la misma empresa u organismo.
Marcela Mercapidez, CEO de la empresa uruguaya de ciberseguridad Sabyk, matizó ese alcance: "Las consecuencias dependerían de los permisos que tuviera el servidor y de las demás medidas de seguridad".
La empresa de seguridad CrowdStrike confirmó en pruebas que es posible darle órdenes a un servidor con un pedido común, como los que hace cualquier navegador, sin contraseña. Pero, advirtió Mercapidez, "esto no demuestra que todos los servidores PHP sean explotables ni que se hayan comprometido datos personales".
Para quien usa esos sitios, el riesgo principal está en los datos personales que guardan. El CERTuy, el centro del Estado que responde ante incidentes de seguridad, advirtió que un ataque podría permitir que alguien lea o modifique esa información.
Gómez agregó otros dos riesgos: que un sitio confiable sea usado para distribuir contenido malicioso a sus visitantes, o que directamente quede fuera de servicio.
Team Capybara suma uno más: que alguien modifique en silencio una tienda en línea para capturar contraseñas o datos de tarjetas de crédito en el momento en que el cliente compra.
Agesic se anticipó a ese escenario. Junto al CERTuy –que emitió su alerta el 21 de octubre, según Mercapidez– y los distintos organismos, dio de baja los portales del Estado antes de que pudieran ser atacados, para aplicarles los arreglos. En palabras de Richard Pérez, decidieron "bajar la llave temporalmente".
Una carrera contrarreloj
El problema se agravó por la forma en que se difundió. Madeline Lawrence, cofundadora de la firma belga Aikido Security, señaló que los detalles se hicieron públicos antes de que existieran los arreglos y que a partir de ahí empezaron a registrarse ataques. Según Team Capybara, el anuncio se adelantó un día porque la información se filtró en un foro anónimo.
Incluso antes ya circulaban herramientas para aprovechar la falla. Según Gómez, Nexa detectó desde el 17 de octubre programas listos para atacar que se ofrecían en la dark web, la parte de internet que no aparece en los buscadores y donde se comercian este tipo de herramientas.
Las empresas compiten contra atacantes que usan inteligencia artificial para encontrar sitios vulnerables. Los investigadores que descubrieron PHP2Shell también usaron IA: lo hicieron en agosto, dentro de la iniciativa Parchea el planeta, impulsada por OpenAI.
La IA también sembró confusión. Según Team Capybara, internet se llenó de pruebas falsas generadas con IA que prometían detectar si un servidor era vulnerable. Muchas no funcionaban y otras eran trampas: escondían programas maliciosos para infectar a los técnicos que, apurados, las probaban.
Espino citó un reporte de un ejecutivo de Cloudflare: "La cantidad de ataques fue evolucionando de a cientos, de a miles y de a millones en cuestión de horas".
La PHP Foundation, que mantiene el lenguaje desde 2021, publicó el miércoles 21 de octubre un arreglo urgente –el equivalente a cambiar la cerradura– y pidió instalarlo de inmediato. En paralelo, bancos, aerolíneas, trenes, oficinas de impuestos y gobiernos de distintos países tuvieron que cerrar servicios de emergencia.
Satya Nadella, CEO de Microsoft, dijo el jueves en un evento en Colonia (Alemania) que fue una jornada larga para los equipos de informática y seguridad, y que hacía mucho tiempo que no veía algo así.
Qué sitios uruguayos cayeron
Los portales del Estado, agrupados bajo gub.uy, funcionan con Drupal, un gestor de contenidos hecho sobre PHP: el sistema que permite cargar, ordenar y publicar textos, fotos y formularios sin tener que tocar código.
Si PHP es la estructura del edificio, Drupal es la administración que trabaja adentro: la que actualiza la cartelera, decide qué se exhibe en cada vidriera y qué ventanillas atienden al público. Si la estructura tiene una puerta sin llave, toda esa administración queda expuesta.
"Todos los sitios del Estado, el gub.uy, como está hecho con la plataforma Drupal, es uno de los grandes afectados", dijo Espino. Gómez coincidió: todos los organismos que usan Drupal "eran o son potencialmente vulnerables".
Entre la tarde del miércoles 21 y la mañana del jueves 22 hubo caídas en los portales de varios ministerios, como Desarrollo Social, Turismo y Transporte y Obras Públicas, según Team Capybara. En la mayoría de los casos estuvieron fuera de línea algunas horas y volvieron de a poco.
El CEO de Nexa fue más allá. "Claramente existen servicios críticos afectados por esta vulnerabilidad", afirmó, aunque prefirió no nombrarlos "por razones obvias".
Team Capybara marca un límite: los sistemas que controlan plantas industriales o el núcleo de los bancos funcionan con otra tecnología y no quedaron expuestos. Sí lo estuvieron las "ventanillas digitales": portales de ministerios, prestadores de salud, plataformas educativas y sitios de trámites.
Espino cuestionó el cierre total. "Antes de decir 'bajo la cortina y no dejo entrar a nadie', hubiese dejado por lo menos una capa de funcionalidad básica, que solamente se muestren las noticias o algo más", afirmó. "No una solución tan violenta como poner una página de 'sitio en mantenimiento'".
Mercapidez lo ve de otra forma. "Es probable que veamos algunas indisponibilidades por maniobras de actualización, que son esperables y saludables", sostuvo.
Por ahora no hay ataques confirmados que hayan usado esta falla en Uruguay, y el CERTuy tampoco los registró. "No tengo reportes, pero no quiere decir que no haya sido así", aclaró Espino. Richard Pérez tampoco conoce casos en la región, pero advirtió: "Probablemente suceda".
Lo que sí se vio, según Team Capybara, fueron rastreos automáticos desde todo el mundo: programas que recorren internet probando qué servidores tienen la puerta abierta.
Además, un ataque puede pasar inadvertido. "Un servidor puede seguir funcionando normalmente aun cuando se haya vulnerado", explicó Mercapidez. "El atacante podía conseguir ejecutar instrucciones sin que un visitante notara nada extraño".
Cuántos sistemas siguen expuestos en Uruguay
Richard Pérez rastreó el país con Shodan y Censys, dos buscadores que encuentran equipos conectados a internet. Detectó unos 1.500 servidores en Uruguay que todavía tienen las versiones vulnerables de PHP.
Si se suman los sitios terminados en .uy, la cifra sube a cerca de 3.000 servicios, públicos y privados, que hoy podrían ser atacados. "Estas dos vulnerabilidades la verdad son bastante graves", dijo.
Team Capybara llega a un número mayor. Detectó más de 15.400 servidores web visibles desde internet en el país y, en un primer rastreo, entre 3.500 y 4.200 resultaron vulnerables. Para eso revisó qué versión de PHP declara cada servidor y qué programas usa.
Mercapidez pide cautela con las cifras. "Todavía no hay una cifra oficial publicada que permita decir cuántos sitios uruguayos eran realmente explotables", dijo. Para saberlo habría que revisar la versión, las actualizaciones y la configuración de cada servidor: "No alcanza con saber que un sitio utiliza esa tecnología".
Según el relevamiento de Team Capybara, la exposición se concentra en tres grupos: intendencias, organismos y plataformas educativas, que suelen actualizar más lento por la burocracia; tiendas en línea y pymes; y sistemas viejos hechos a medida, como programas de facturación, que quedaron conectados a internet.
Para Mercapidez, el rubro pesa menos que la tecnología: pueden estar expuestos desde organismos públicos hasta servicios financieros, "siempre que utilizaran versiones vulnerables de PHP".
El problema no se limita a las páginas web. Richard Pérez encontró cámaras de videovigilancia cuyo panel de control, la pantalla desde donde se manejan, funciona con PHP y está abierto a internet. Un atacante podría tomar el control de esas cámaras.
Lo mismo puede pasar con routers, los aparatos que reparten internet en una casa u oficina, y otros equipos que se manejan desde una página web. "Si está expuesto a internet y ese sitio, que es muy probable, use PHP, hay una probabilidad de poder ser atacado", explicó.
Cuánto lleva arreglarlo
La demora depende del tamaño de cada sitio. En una página sencilla, hecha con WordPress y con pocos agregados, el arreglo es rápido: "Actualizar PHP no lleva más que cinco minutos", sostuvo Espino.
Lo único a revisar en esos casos son los plugins, los accesorios que se le suman a una página, como un formulario de contacto. "Revisás que todo esté funcionando, que no se haya roto ningún plugin, y listo", resumió.
El Estado, en cambio, maneja una estructura mucho más grande. "Hay una cantidad de cosas que tienen instaladas, y verificar que todo lo que está funcionando en ese Drupal efectivamente sigue funcionando puede llevar más tiempo", señaló.
A eso se suman los trámites internos de cada organización. Instalar el arreglo "no es simplemente presionar un botón", dijo Mercapidez. "Actualizar rápidamente es fundamental, pero es una actividad que requiere planificación, pruebas, autorizaciones".
En los casos más complejos hay "proyectos que van a llevar algún tiempo en ser actualizados", según Gómez. Mientras tanto se aplican medidas provisorias: algo así como poner una tranca en la puerta hasta que llega la cerradura nueva.
Nexa empezó a aplicarlas apenas detectó las herramientas de ataque. Desde que salió el arreglo oficial, la empresa está actualizando y revisando los sistemas de sus clientes, según Gómez.
Espino recibió la primera alerta por los avisos de PHP y del servicio de ciberseguridad del FBI. "En ese mismo momento empezamos a aplicar parches de seguridad y a notificar a nuestros clientes", contó. Su empresa también avisó a la Cuti y al CERTuy, que ya estaban al tanto.
"No nos llevó más de cuatro horas", dijo sobre la actualización de todos sus sitios, que no afectó el funcionamiento de sus clientes. Su recomendación para el resto es directa: "Que actualicen no ahora, no ya, sino ayer".
El arreglo, sin embargo, no le llega a todos. Según Team Capybara, PHP solo lo publicó para sus versiones más nuevas, pero más del 70% de los servidores que muestran su versión usan otras más viejas, que ya no reciben mantenimiento oficial.
Esas organizaciones no pueden simplemente instalar la actualización: si saltan a una versión nueva, el sitio viejo suele romperse. Quedan entre dejarlo caído, pagar para reprogramarlo a contrarreloj o esperar que otra empresa publique un arreglo adaptado.
Otro problema son los sitios tercerizados. Muchas empresas y organismos encargaron su página a un proveedor cuyo contrato de mantenimiento venció hace años. En esos casos, según Team Capybara, nadie tiene las llaves ni la responsabilidad de entrar a actualizar, y el sitio queda expuesto sin fecha de cierre.
Richard Pérez y Gómez comparan el caso con Log4Shell, una falla masiva de 2021 en una herramienta usada por programas de todo el mundo. "Desde Log4Shell no había algo con este nivel de impacto", dijo Pérez. Gómez recordó que, años después, todavía aparecen sistemas sin aquel arreglo.
"Durante bastante tiempo van a quedar sistemas expuestos en Uruguay y el resto del mundo", advirtió Gómez. Richard Pérez coincidió: "Esto recién inicia, va a ser bastante movido".