Riesgos de deserialización durante el uso de BinaryFormatter y tipos relacionados

  • Artículo

Este artículo se aplica a los tipos siguientes:

Este artículo se aplica a la implementaciones de .NET siguientes:

  • .NET Framework (todas las versiones)
  • .NET Core 2.1 a 3.1
  • .NET 5 y versiones posteriores

Precaución

El tipo BinaryFormatter es peligroso y no se recomienda para el procesamiento de datos. Las aplicaciones deben dejar de usar BinaryFormatter lo antes posible, aunque crean que los datos que procesan son de confianza. BinaryFormatter no es seguro y no se puede convertir en seguro.

Nota:

A partir de .NET 9, la implementación integrada de BinaryFormatter produce excepciones al usarla, incluso con la configuración que anteriormente habilitaba su uso. También se quitan esas configuraciones. Consulte la guía de migración de BinaryFormatter para obtener más información.

Vulnerabilidades de deserialización

Las vulnerabilidades de deserialización son una categoría de amenazas donde las cargas de solicitud se procesan sin seguridad. Un atacante que aprovecha correctamente estas vulnerabilidades en una aplicación puede provocar ataques por denegación de servicio (DoS), la divulgación de información o la ejecución remota de código dentro de la aplicación de destino. Esta categoría de riesgo se engloba dentro de OWASP Top 10. Los destinos incluyen aplicaciones escritas en diversos lenguajes, incluidos C/C++, Java y C#.

En .NET, el mayor destino de riesgo son las aplicaciones que usan el tipo BinaryFormatter para deserializar datos. BinaryFormatter se utiliza ampliamente en todo el ecosistema de .NET debido a su eficacia y facilidad de uso. Pero esta misma eficacia ofrece a los atacantes la posibilidad de influir en el flujo de control dentro de la aplicación de destino. Los ataques correctos pueden dar lugar a que el atacante pueda ejecutar código en el contexto del proceso de destino.

Como analogía más simple, imagine que la llamada a BinaryFormatter.Deserialize sobre una carga es equivalente a interpretar esa carga como un archivo ejecutable independiente e iniciarlo.

Vulnerabilidades de seguridad de BinaryFormatter

Advertencia

El método BinaryFormatter.Deserializenunca es seguro cuando se usa con una entrada que no es de confianza. Se recomienda encarecidamente que los consumidores consideren el uso de una de las alternativas que se describen más adelante en este artículo.

BinaryFormatter se implementó antes de que las vulnerabilidades de deserialización fueran una categoría de amenaza bien entendida. Como resultado, el código no sigue los procedimientos recomendados modernos. El método Deserialize se puede usar como un vector para que los atacantes realicen ataques DoS contra aplicaciones de consumo. Es posible que estos ataques hagan que la aplicación deje de responder o que se produzca una terminación inesperada del proceso. Esta categoría de ataque no se puede mitigar con SerializationBinder o con cualquier otro modificador de configuración BinaryFormatter. .NET considera que este comportamiento es por diseño y no emite ninguna actualización de código para modificarlo.

BinaryFormatter.Deserialize puede ser vulnerable a otras categorías de ataque, como la divulgación de información o la ejecución remota de código. El uso de características como un elemento SerializationBinder personalizado puede ser insuficiente para mitigar estos riesgos de forma correcta. Existe la posibilidad de que se detecte una vulnerabilidad nueva para la que .NET no pueda publicar de forma práctica una actualización de seguridad. Los consumidores deben evaluar sus escenarios individuales y considerar su posible exposición a estos riesgos.

Se recomienda que los consumidores de BinaryFormatter realicen valoraciones de riesgo individuales en sus aplicaciones. Es responsabilidad exclusiva del consumidor determinar si se usa BinaryFormatter. Si está considerando la posibilidad de usarlo, debe evaluar los riesgos de las consecuencias de seguridad, técnicas, de reputación, legales y normativas.

Alternativas preferidas

.NET ofrece varios serializadores integrados que pueden administrar de forma segura los datos que no son de confianza:

Alternativas peligrosas

Evite los siguientes serializadores:

Los serializadores anteriores realizan una deserialización polimórfica sin restricciones y son peligrosos, como BinaryFormatter.

Riesgos de asumir que los datos son de confianza

Con frecuencia, un desarrollador de aplicaciones podría creer que solo procesa entradas de confianza. El caso de la entrada segura es cierto en algunas circunstancias poco frecuentes. Pero es mucho más común que una carga cruce un límite de confianza sin que el desarrollador sea consciente de ello.

Le recomendamos que use un servidor local en el que los empleados usan un cliente de escritorio desde sus estaciones de trabajo para interactuar con el servicio. Este escenario se podría considerar ingenuamente como una configuración "segura" en la que es aceptable usar BinaryFormatter. Pero este escenario presenta un vector de malware que obtiene acceso al equipo de un único empleado para poder propagarse por toda la empresa. Ese malware puede aprovechar el uso de BinaryFormatter de la empresa para después moverse lateralmente desde la estación de trabajo del empleado hasta el servidor de back-end. Luego, puede extraer datos confidenciales de la empresa, como secretos comerciales o datos de clientes.

Considere también una aplicación que use BinaryFormatter para conservar el estado de guardado. Esto podría parecer inicialmente un escenario seguro, ya que la lectura y escritura de datos en una unidad de disco duro propia representa una amenaza menor. Pero es habitual compartir documentos por correo electrónico o Internet, y la mayoría de los usuarios finales no perciben que abrir estos archivos descargados sea un comportamiento arriesgado.

Este escenario se puede aprovechar con un efecto malintencionado. Si la aplicación es un juego, los usuarios que comparten archivos de guardado se ponen en riesgo sin saberlo. Los propios desarrolladores también pueden ser el objetivo. El atacante podría enviar un correo electrónico al soporte técnico de los desarrolladores, adjuntar un archivo de datos malintencionado y pedir al personal de soporte técnico que lo abra. Este tipo de ataque podría servir al atacante para adentrarse en la empresa.

Otro escenario es cuando el archivo de datos se encuentra en el almacenamiento en la nube y se sincroniza de forma automática entre los equipos del usuario. Un atacante que consiga obtener acceso a la cuenta de almacenamiento en la nube puede envenenar el archivo de datos. Este archivo de datos se sincronizará automáticamente con los equipos del usuario. La próxima vez que el usuario abra el archivo de datos, se ejecutará la carga del atacante. Por tanto, el atacante puede aprovechar un riesgo de la cuenta de almacenamiento en la nube para obtener permisos de ejecución de código completos.

Considere una aplicación que pase de un modelo de instalación de escritorio a un modelo de primero en la nube. Este escenario incluye aplicaciones que se mueven desde una aplicación de escritorio o un modelo de cliente enriquecido a un modelo basado en web. Los modelos de amenazas descritos para la aplicación de escritorio no se aplican necesariamente al servicio basado en la nube. El modelo de amenazas de la aplicación de escritorio podría descartar una amenaza determinada como "no interesante para que el cliente ataque", aunque esa misma amenaza podría resultar interesante cuando considera que un usuario remoto (el cliente) ataca el propio servicio en la nube.

Nota

En términos generales, la intención de la serialización es transmitir un objeto dentro o fuera de una aplicación. Un ejercicio de modelado de amenazas casi siempre marca este tipo de transferencia de datos como el cruce de un límite de confianza.

Consulte también