El día en que PHP se detuvo, PHP2Shell

Esto es para nardos, sysadmins y algún ocasional que tiene su propio servidor en la web. Como muchos lo saben, aunque se que la gran mayoría no, el 70% de Internet funciona gracias a PHP.

Odiado, maltratado, pero siempre fiel, PHP es el motor de este blog desde hace 24 años y anoche habían anunciado que se venía un parche por una vulnerabilidad (dos en realidad) de categoría 9.8 que eran básicamente el "apocalipsis" si no se parcheaban.

Lamentablemente uno no tuvo mejor idea que publicar un exploit como si se tratara de algo normal y, bueno, lo que siguió fue la hecatombe.

El error se da en el manejo de sesión, si se interrumpen ciertos pedidos al servidor básicamente se lo deja en calzones y luego el atacante puede inyectar lo que quiera en la máquina vulnerable. 

PHP2Shell básicamente deja pasar de largo al atacante directo al sistema. No depende de qué sitio en PHP tengas, es PHP el afectado! Cualquier plataforma va a caer si no se actualiza.

Ayer en el sitio oficial de PHP habían anunciado parche para hoy, y hoy explicaron bien cómo funcionaba todo, también hay varios informes con detalles al respecto.

El primer paso para contener fue cambiar en el php.ini el session.upload_progress de On a Off, no es muy difícil, pero implica entrar a cada servidor. Como tengo mis propios VPS esto fue fácil para mí, pero para otros que usan un servidor "shared" donde el administrador controla todo, esto puede quedar vulnerable.

session.upload_progress.enabled = Off

Luego salió la versión actualizada, para cada versión:

PHP 8.5: Actualizar a 8.5.12
PHP 8.4: Actualizar a 8.4.27
PHP 8.3: Actualizar a 8.3.36
PHP 8.2: Actualizar a 8.2.35

Pero he aquí el problema: muchos usan versiones no-oficiales de paquetes de PHP, especialmente las publicadas por Ondrej, aquí otro problema:

El sitio de LaunchpadContent, desde donde todos bajamos los paquetes de PHP actualizados, estuvo caido casi todo el día. Si tenías suerte de usar un paquete de otro origen que fue actualizado pronto, bien, sino jodete.

Al momento de escribir esto no pude actualizar todos los servidores porque cada dos minutos se caen los repositorios actualizados.

El peor "mal" de todo esto fue la publicación de exploits con el único fin de obtener fama y "prestigio" en la comunidad hacker, pero bueno, creo que eso salió bastante mal.

Es que el nivel de exposición y la cantidad de sitios afectados es bestial.

Cloudflare hizo algo muy loable, buscó todos los métodos que se usaban de exploit y puso filtros automáticamente tanto en cuentas gratuitas como pagas.

Ahora bien, antes de que empiecen los detractores de PHP a quejarse, PHP es, como cualquier otra plataforma, un framework que está permanentemente expuesto a Internet.

La puerta de entrada puede ser cualquier otra, Next.js es un caso de ataques permanentes de cadena de suministro, donde te cuelan paquetes con vulnerabilidades y troyanos, PHP no podía ser menos porque con el uso masivo de LLMs para buscar vulnerabilidades se empieza a hilar muy fino.

En este mismo blog hice ya varias pasadas de seguridad, a cada nuevo modelo, una nueva revisión, nuevas detecciones, nuevas protecciones.

En muchos sitios que no usan una plataforma propia se "descansa" en terceros, como Wordpress, Joomla, Drupal, Laravel, Symphony, Magento, y un largo etcétera, esto crea una distancia entre el código y el usuario muy grande, especialmente en sistemas complejos.

Hay que estar atentos, si somos dueños de sitios, a los parches de seguridad y agregar capas de separación entre la web abierta y nuestras bases de datos y servidores. Entiendo que muchos creen que vivimos con las mismas reglas de hace 3-4 años, pero no, es un mundo totalmente distinto.

La cantidad de previsiones de seguridad que tengo cuando hago el deploy de un sitio nuevo no las tuve nunca en mi vida, luego me llaman para arreglar el sitio que hizo otro "experto" y resulta que es un colador.

Estén antentos a esto (o de última me contratan 😁)