¿Sabe que algún sistema de administración de contenido u otras aplicaciones se ven afectadas por los recientes vulnerabilidades de ImageMagick? (Ya he jugado con la herramienta de conversión que se ofrece en Linux)
No creo que puedas obtener una respuesta sólida para esto. Pero no muchos están en riesgo, incluso si están ejecutando versiones de riesgo de ImageMagick.
Primero, uno tendría que poder averiguar cuántas aplicaciones PHP están activas con ImageMagick instalado y configurado. Ninguna aplicación de CMS o PHP importante requiere la biblioteca ImageMagick. Para la manipulación de imágenes, la biblioteca GD2 es el estándar al que se accede y la GD lib se ha incluido desde PHP 4.2. Entonces, si alguien está usando ImageMagick, tendría que instalarlo y configurarlo para que funcione con PHP por sí mismo. Con aplicaciones como Wordpress tendrían que instalar y habilitar un complemento para usar ImageMagick también. Normalmente, los hosts compartidos no instalan las instalaciones de Image Magick con PHP debido a su historial de vulnerabilidades.
Además, la instalación y el uso de ImageMagick no son suficientes para poder explotar. Por ejemplo, la mayor parte de la manipulación de imágenes se realiza en el extremo posterior de un CMS. (Al cargar una imagen y obtener diferentes tamaños, el CMS puede usar, por ejemplo). Y si el front-end público realiza el procesamiento en tiempo real, tendría que poder explotar el código del front-end para atacar ImageMagick. Así que en este punto estás buscando 2 hazañas. Uno para explotar la aplicación web que interactúa con las API de PHP de ImageMagicks y luego un exploit en ImageMagick que es posible a través de las API de PHP de ImageMagicks.
La vulnerabilidad que mencionaste en tu pregunta es posible a través de una aplicación PHP si todas las lunas están alineadas. Especialmente si la entrada del nombre de archivo es controlada por el usuario que mira al frente Pero el saneamiento básico de entrada o la aplicación PHP que tiene control sobre el nombre de archivo debería ser suficiente para detener este ataque. La prueba de concepto (shell.php) no implementa esto, pero la idea de la prueba de concepto es ver si es explotable, no defendible.
Para resumir: No es probable que se afecten muchas aplicaciones PHP o sistemas de gestión de contenido.
Lea otras preguntas en las etiquetas exploit metasploit