Dynamic Code Evaluation: Unsafe Deserialization

Desserializar fluxos de objetos controlados pelo usuário em tempo de execução pode permitir que invasores executem código arbitrário no servidor, abusem da lógica do aplicativo e/ou provoquem uma negação de serviço.

A serialização .NET transforma gráficos de objetos em fluxos de bytes ou XML que contêm os objetos propriamente ditos e os metadados necessários para reconstruí-los com base no fluxo de bytes. Os desenvolvedores podem criar um código personalizado para auxiliar no processo de desserialização de objetos .NET, podendo substituir os objetos desserializados por objetos diferentes, ou proxies. O processo de desserialização personalizado ocorre durante a reconstrução dos objetos, antes de eles serem retornados ao aplicativo e convertidos em tipos esperados. Na ocasião em que os desenvolvedores tentarem impor um tipo esperado, o código já pode ter sido executado.

Exemplo 1: A seguinte função obtém um objeto Stream de uma conexão como entrada e a desserializa de volta para um objeto .NET. Em seguida, retorna o resultado depois de convertê-lo em uma lista de objetos de string:

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  var result = (List <string>)bf.Deserialize(input); 
  return result;
}
...

Para melhor compreensão, o Example 1 pode ser regravado desta maneira:

Exemplo 2:

...
List <string> Deserialize(Stream input)
{
  var bf = new BinaryFormatter();
  object tmp = bf.Deserialize(input);
  List <string> result = (List <string>)tmp;
  return result;
}
...

No Example 2, a operação de desserialização será bem-sucedida desde que o fluxo de entrada seja válido, independentemente de se o tipo é List <string> ou não.

As rotinas de desserialização personalizadas são definidas nas classes serializáveis que precisam estar presentes na pasta bin ou no GAC e que não podem ser injetadas pelo invasor. Portanto, a capacidade de exploração desses ataques depende das classes disponíveis no ambiente do aplicativo. Infelizmente, classes comuns de terceiros ou até mesmo classes .NET podem ser abusadas de forma a esgotar os recursos do sistema, excluir arquivos, implantar arquivos mal-intencionados ou executar código arbitrário.