Las aplicaciones web que facilitan la subida de archivos se han convertido en un elemento esencial para numerosas organizaciones, ya que actúan como portales a través de los cuales clientes, socios y empleados pueden compartir diversos tipos de documentos y archivos. Por ejemplo, una empresa de recursos humanos podría permitir a los usuarios subir currículos, o una empresa podría facilitar a sus socios el intercambio de archivos a través de una plataforma web especializada.
A pesar de las medidas de seguridad reforzadas y los procesos de validación más estrictos, los atacantes siguen aprovechando las vulnerabilidades mediante métodos sofisticados. Archivos que parecen inofensivos, como las imágenes, pueden manipularse para comprometer la seguridad de un servidor web.
Los archivos poliglotas son archivos que pueden considerarse válidos como varios tipos a la vez, lo que permite a los atacantes eludir las medidas de seguridad basadas en el tipo de archivo. Algunos ejemplos son los archivos GIFAR, que funcionan tanto como archivos GIF como RAR; los archivos poliglotas JavaScript/JPEG, que se interpretan tanto como JavaScript como JPEG; y los archivos Phar-JPEG, que se reconocen tanto como un archivo Phar como una imagen JPEG. Estos archivos poliglotas pueden pasar desapercibidos gracias a extensiones engañosas o vacías que «engañan» a los sistemas haciéndoles creer que se trata de un tipo de archivo inofensivo (como una imagen o un PDF), mientras que en realidad contienen código malicioso no detectado.
Validación de la carga de archivos
Permitir que los usuarios suban archivos sin una validación adecuada o exhaustiva supone una amenaza significativa para las aplicaciones web. Si un atacante logra subir un archivo malicioso, como un «web shell», podría hacerse con el control del servidor, poniendo en peligro tanto el sistema como los datos confidenciales. Para mitigar estos riesgos, se han establecido una serie de buenas prácticas destinadas a orientar a los desarrolladores en la aplicación de medidas de validación eficaces. Estas prácticas contribuyen a garantizar un procesamiento seguro de las subidas de archivos, minimizando así el riesgo de que se produzcan vulnerabilidades.
Entre los aspectos clave a tener en cuenta para garantizar la seguridad de la subida de archivos se incluyen:
- Validación de extensiones: Implemente una lista negra o una lista blanca de extensiones de archivo para garantizar que solo se acepten los tipos de archivo permitidos.
- Sanización de nombres de archivo: Generar cadenas aleatorias para los nombres de archivo al subirlos.
- Validación del tipo de contenido: comprueba el tipo MIME del archivo subido para asegurarte de que coincide con el formato esperado.
- Validación del encabezado de la imagen: Para la subida de imágenes, se pueden utilizar funciones como getimagesize() en PHP para confirmar la validez del archivo comprobando su encabezado.
Elusión del filtro de subida de archivos
A pesar de la implementación de estas medidas de protección, los atacantes perfeccionan continuamente sus métodos para eludir los mecanismos de validación. Técnicas como la inyección de caracteres nulos, las extensiones dobles y las extensiones vacías pueden socavar la validación de extensiones: un archivo puede aparecer con un nombre como «file.php.jpg», «file.php%00.jpg», «file.PhP» o «file.php/» para evadir la detección. La validación del tipo MIME puede eludirse modificando los bytes mágicos iniciales del archivo, por ejemplo, cambiándolos a GIF89a, el encabezado asociado a los archivos GIF, lo que puede engañar al sistema para que identifique el archivo como un formato legítimo. Además, se puede subir un archivo .htaccess malicioso para manipular las configuraciones del servidor, lo que permite la ejecución de archivos con extensiones no autorizadas.

Ataques de archivos poliglotas
A pesar de la implementación de rigurosos procesos de validación que combinan múltiples medidas de seguridad para impedir la técnica de elusión del filtro de subida de archivos, los ataques sofisticados dirigidos a archivos o imágenes poliglotas siguen representando una importante amenaza para la seguridad. Este método permite a los atacantes crear archivos —como imágenes— que se ajustan a la estructura binaria esperada para los archivos de imagen, pero que, al mismo tiempo, pueden ejecutar código malicioso cuando se interpretan en un contexto diferente. La doble naturaleza de estos archivos les permite eludir los mecanismos de validación tradicionales y aprovechar vulnerabilidades en situaciones concretas.

Archivo Polyglot sencillo con ExifTool
Una técnica sencilla para generar una imagen poliglota consiste en utilizar ExifTool. Esta potente aplicación está diseñada para leer, escribir y modificar diversos formatos de metadatos, como EXIF, XMP, JFIF y Photoshop IRB. Sin embargo, personas malintencionadas pueden aprovechar ExifTool para llevar a cabo acciones perjudiciales, incluida la creación de una imagen poliglota con fines maliciosos. Al utilizar ExifTool para incrustar código malicioso en los metadatos EXIF de una imagen —especialmente en campos como UserComment e ImageDescription—, los atacantes pueden generar una imagen poliglota y aumentar sus posibilidades de llevar a cabo con éxito un ataque.
A continuación se muestran los metadatos EXIF de la imagen, que proporcionan información detallada sobre la misma.

Mediante el uso de ExifTool, un actor malintencionado puede incrustar código malicioso en los metadatos EXIF de una imagen, creando así un archivo poliglota que podría eludir los mecanismos de validación.

Aunque la validación del tipo MIME puede restringir la subida de archivos de shell web básicos, esta imagen poliglota puede eludir estas restricciones, lo que permite a un atacante subir un shell web poliglota.


Posteriormente, el atacante puede aprovechar el shell web poliglota para hacerse con el control del servidor web.

Archivo poliglota en JavaScript/JPEG
Un archivo poliglota JavaScript/JPEG está estructurado de tal forma que es válido tanto como imagen JPEG como como script de JavaScript. Para lograrlo, un atacante debe tener un conocimiento profundo de la estructura interna de un archivo JPEG. Este conocimiento le permite incrustar con precisión datos binarios maliciosos en la imagen, garantizando que puedan ser procesados por un motor de JavaScript sin afectar a su validez como imagen JPEG.
Una imagen JPEG tiene la siguiente estructura:
| Bytes | Nombre |
| 0xFF, 0xD8 | Inicio de la imagen |
| 0xFF, 0xE0, 0x00, 0x10, … | Encabezado predeterminado |
| 0xFF, 0xFE, … | Comentario sobre la imagen |
| 0xFF, 0xDB, … | Tabla de cuantificación |
| 0xFF, 0xC0, … | Inicio de fotograma |
| 0xFF, 0xC4, … | Tabla de Huffman |
| 0xFF, 0xDA, … | Inicio del escaneo |
| 0xFF, 0xD9 | Fin de la imagen |

Formato JPEG – fuente: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
En la estructura de una imagen JPEG, tras el encabezado viene la información sobre la longitud. Como se muestra en el ejemplo anterior, el encabezado comienza con la secuencia 0xFF 0xE0 0x00 0x10, donde 0x00 0x10 representa específicamente la longitud del segmento, es decir, 16 bytes. El marcador 0xFF 0xD9 señala el final de la imagen.

Para crear un archivo poliglota JavaScript/JPEG, es necesario modificar los valores hexadecimales de la imagen para garantizar que el motor de JavaScript pueda reconocerlos y procesarlos.
En primer lugar, en JavaScript, la secuencia 0xFF 0xD8 0xFF 0xE0 puede interpretarse como valores no ASCII, pero 0x00 0x10 no es válida y debe modificarse. El sustituto adecuado para estos valores hexadecimales es 0x2F 0x2A, que es la representación hexadecimal de /*, una sintaxis utilizada para abrir un comentario en JavaScript. Esta sustitución permite que los datos binarios restantes se ignoren como parte del comentario.
Sin embargo, dado que 0x00 0x10 representa originalmente la longitud del encabezado JPEG, modificarlo a 0x2F 0x2A —lo que en decimal equivale a 12074— requiere redefinir el encabezado JPEG para mantener su validez. Para lograrlo, es necesario añadir bytes nulos, y la carga útil de JavaScript debe colocarse después del marcador 0xFF 0xFE, que indica un comentario de imagen en la estructura JPEG.
Por ejemplo, si la carga útil es */=alert(document.domain);/*, que tiene una longitud de 28 bytes, los bytes nulos necesarios se calcularían de la siguiente manera: 12074 (nueva longitud) - 16 (longitud original del encabezado) - 2 (para el marcador 0xFF 0xFE ) - 28 (longitud de la carga útil) = 12 028 bytes nulos.
Por lo tanto, el código JavaScript incluido en la imagen JPEG tendría un aspecto similar al siguiente:



Por último, la secuencia 0x2A 0x2F 0x2F 0x2F (que corresponde a *///) debe colocarse justo antes del marcador de fin de JPEG 0xFF 0xD9. Este paso cierra el comentario de JavaScript y garantiza que la carga útil se ejecute correctamente sin alterar la estructura del archivo JPEG.

Tras esta modificación, la imagen sigue pudiendo interpretarse como una imagen válida, al tiempo que contiene código JavaScript ejecutable.

Cuando un archivo HTML carga esta imagen como código fuente de JavaScript, sigue siendo válido y puede ejecutar el código JavaScript incrustado:


Los archivos de imagen poliglotas plantean riesgos no solo para la explotación del lado del cliente, sino también para los ataques del lado del servidor en determinadas circunstancias. Un ejemplo de ello es el archivo poliglota Phar/JPEG, que puede interpretarse tanto como un archivo PHP (Phar) como una imagen JPEG. La estructura del archivo Phar permite la incrustación de datos serializados en los metadatos, lo que supone un riesgo potencial de vulnerabilidades de deserialización, especialmente en determinadas versiones de PHP. Como resultado, los archivos poliglotas Phar/JPEG pueden aprovecharse para eludir la validación de la subida de archivos y explotar servidores vulnerables.
El formato de archivo Phar tiene la estructura «stub/manifest/contents/signature» y almacena la información esencial sobre el contenido del archivo Phar en su manifiesto:
- Stub: El stub es un fragmento de código PHP que se ejecuta cuando se accede al archivo en un contexto ejecutable. No hay restricciones en cuanto al contenido del stub, salvo el requisito de que termine con `__HALT_COMPILER();`.
- Manifiesto: Esta sección contiene metadatos sobre el archivo y su contenido, que pueden incluir metadatos Phar serializados almacenados en formato serialize().
- Contenido del archivo: Los archivos originales que se incluyen en el archivo comprimido.
- Firma (opcional): contiene información de firma para la verificación de la integridad.

Dado que el stub no impone ninguna restricción de contenido más allá de la estipulación de __HALT_COMPILER(), un actor malintencionado puede inyectar los valores hexadecimales de una imagen en el stub. Al colocar estos valores al principio del archivo PHAR, este puede identificarse como una imagen válida. En consecuencia, se puede crear fácilmente un archivo PHAR/JPEG poliglota añadiendo los bytes hexadecimales de una imagen JPEG al principio, tal y como se muestra en el siguiente ejemplo:

Mediante este método, el archivo poliglota generado funciona tanto como una imagen válida como un archivo PHAR legítimo y, por lo tanto, puede utilizarse para eludir ciertos mecanismos de validación de la carga de archivos.


Aunque este archivo poliglota puede eludir los filtros de subida de archivos, actualmente no es capaz de explotar el servidor web. Para explotar y comprometer con éxito un servidor web utilizando un archivo PHAR o un archivo PHAR poliglota, es esencial inyectar metadatos maliciosos serializados en el manifiesto del archivo.
Cuando se accede al archivo PHAR a través del envoltorio PHAR (phar://) en determinadas funciones de PHP (PHP ≤7.x) relacionadas con operaciones de archivos —como file(), file_exists(), file_get_contents(), fopen(), rename() o unlink()—, se activa la función unserialize() para los metadatos serializados. En definitiva, al utilizar PHPGGC, una herramienta muy utilizada para construir cadenas de gadgets PHP, los actores maliciosos pueden explotar la vulnerabilidad de deserialización a través de un archivo PHAR poliglota, comprometiendo así el servidor de la aplicación web.
La combinación de archivos multiformato PHAR/JPEG y vulnerabilidades de deserialización permite a los atacantes infiltrarse en un servidor de aplicaciones web, incluso cuando se han implementado filtros de subida de archivos. Cabe destacar que esta intrusión puede producirse incluso durante el procesamiento de un archivo de imagen.


Al aprovechar los archivos «polyglot» para eludir los filtros de subida de archivos y añadir el prefijo PHAR (phar://) a la ruta del archivo, los atacantes pueden engañar al servidor web para que trate el archivo como un archivo PHAR. Esta manipulación puede provocar posteriormente una vulnerabilidad de deserialización, lo que da lugar a la ejecución remota de código a través de funciones de gestión de archivos.

Para ilustrar los riesgos asociados a los archivos «polyglot» en su aplicación, hemos simulado un entorno en el que la aplicación utiliza filtros estrictos de subida de archivos para impedir la subida de archivos maliciosos o «web shells». A pesar de estas medidas de seguridad, una imagen «polyglot» puede eludir el proceso de validación y, en determinados contextos, dar lugar a la ejecución remota de código, lo que acabaría comprometiendo el servidor de la aplicación web vulnerable.
Este ejemplo muestra una aplicación web convencional que permite compartir archivos entre clientes, socios y organizaciones:
MetaDefender Core MetaDefender ICAP Server sus aplicaciones web frente a estas amenazas y mejoran la seguridad de su red e infraestructura.
MetaDefender ICAP Server MetaDefender Core conjuntamente para proteger su servidor web frente a ataques sofisticados que utilizan archivos maliciosos PHAR/JPEG multiformato de las siguientes maneras:
Cuando se sube un archivo multiformato PHAR/JPEG a la aplicación web, primero se reenvía a MetaDefender Core Server MetaDefender ICAP Server un proceso de depuración exhaustivo mediante nuestra tecnología Deep CDR™. A diferencia de los simples verificadores de tipos de archivo, la tecnología Deep CDR™ analiza a fondo la estructura del archivo subido, eliminando scripts, macros y contenido que incumpla las políticas, y reconstruyendo el archivo JPEG para que incluya únicamente los datos necesarios.
Este proceso elimina el contenido PHAR malicioso añadido tras el marcador de fin de JPEG (0xFF 0xD9), lo que garantiza que el archivo depurado sea estrictamente un JPEG. Como resultado, la aplicación web queda protegida frente a ataques «poliglotas» de tipo PHAR/JPEG; incluso si un atacante lograra alterar el esquema de procesamiento de archivos para inyectar un contenedor PHAR, no podría explotar el servidor web.

Las organizaciones que cuentan con una infraestructura de seguridad de red consolidada —ya sea que utilicen WAF (cortafuegos de aplicaciones web), servidores proxy o controladores de entrada— ahora pueden reforzar sus mecanismos de defensa mediante MetaDefender ICAP Server. Esta solución crea una interfaz entre los servidores web existentes y MetaDefender Core, estableciendo un punto de control de seguridad transparente para todos los archivos entrantes. Cualquier contenido que se enrute a través de la ICAP se analizará y procesará antes de llegar a su servidor web, lo que garantiza que solo el contenido seguro y legítimo entre en su red y llegue a los usuarios finales.

Este enfoque permite a las organizaciones aprovechar sus inversiones actuales en seguridad y, al mismo tiempo, añadir una capa adicional y eficaz de protección. Las organizaciones que utilizan el controlador de entrada de NGINX pueden integrarServer ICAP MetaDefender Server su infraestructura actual mediante la configuración del proxy.

El enfoque OPSWAT va más allá de la detección tradicional de amenazas. En lugar de limitarse a señalar los archivos sospechosos, MetaDefender Core neutralizaCore las amenazas potenciales, transformando los archivos peligrosos en contenido seguro y utilizable. Cuando se integra con su servidor web, MetaDefender ICAP Server una protección integral contra amenazas de día cero y ataques poliglotas.
Guiándose por la filosofía «No confíes en ningún archivo. No confíes en ningún dispositivo. ™», OPSWAT los retos de clientes de todo el mundo mediante tecnologías patentadas en todos los niveles de su infraestructura, protegiendo sus redes, datos y dispositivos, y previniendo amenazas conocidas y desconocidas, ataques de día cero y malware.
