Riscos de desserialização no uso do BinaryFormatter e tipos relacionados

  • Artigo

Este artigo se aplica aos seguintes tipos:

Este artigo se aplica às seguintes implementações do .NET:

  • .NET Framework todas as versões
  • .NET Core 2.1 – 3.1
  • .NET 5 e posteriores

Aviso

O tipo BinaryFormatter é perigoso e não é recomendado para processamento de dados. Os aplicativos devem parar de usar BinaryFormatter o mais rápido possível, mesmo que acreditem que os dados que estão processando são confiáveis. BinaryFormatter não é seguro e não pode ser tornado seguro.

Vulnerabilidades de desserialização

As vulnerabilidades de desserialização são uma categoria de ameaça em que as cargas de solicitação são processadas de maneira insegura. Um invasor que aproveita com êxito essas vulnerabilidades em um aplicativo pode causar DoS (negação de serviço), divulgação de informações ou execução de código remoto dentro do aplicativo de destino. Essa categoria de risco consistentemente fica no Top 10 do OWASP. Os destinos incluem aplicativos escritos em uma variedade de linguagens, incluindo C/C++, Java e C#.

No .NET, o alvo de maior destino são os aplicativos que usam o tipo BinaryFormatter para desserializar dados. BinaryFormatter é amplamente usado em todo o ecossistema do .NET devido ao seu poder e sua facilidade de uso. No entanto, esse mesmo poder permite que os invasores influenciem o fluxo de controle dentro do aplicativo de destino. Ataques bem-sucedidos podem fazer com que o invasor possa executar o código dentro do contexto do processo de destino.

Como uma analogia mais simples, suponha que chamar BinaryFormatter.Deserialize sobre um conteúdo seja o equivalente a interpretar esse conteúdo como um executável autônomo e iniciá-lo.

Vulnerabilidades de segurança do BinaryFormatter

Aviso

O método BinaryFormatter.Deserializenunca é seguro quando usado com entrada não confiável. Recomendamos fortemente que os consumidores considerem usar uma das alternativas descritas posteriormente neste artigo.

BinaryFormatter foi implementado antes de vulnerabilidades de desserialização serem uma categoria de ameaça bem compreendida. Assim, o código não segue as práticas recomendadas modernas. O método Deserialize pode ser usado como um vetor para invasores executarem ataques DoS contra aplicativos de consumo. Esses ataques podem fazer com que o aplicativo deixe de responder ou resultar em um encerramento inesperado do processo. Essa categoria de ataque não pode ser atenuada com um SerializationBinder ou qualquer outro comutador de configuração BinaryFormatter. O .NET considera esse comportamento padrão e não emitirá uma atualização de código para modificá-lo.

BinaryFormatter.Deserialize pode ser vulnerável a outras categorias de ataque, como divulgação de informações ou execução remota de código. Utilizar recursos como um SerializationBinder personalizado pode ser insuficiente para atenuar corretamente esses riscos. Existe a possibilidade de que seja descoberta uma nova vulnerabilidade para a qual o .NET não consiga publicar de modo prático uma atualização de segurança. Os consumidores devem avaliar seus cenários individuais e considerar sua potencial exposição a esses riscos.

Recomendamos que os consumidores do BinaryFormatter realizem avaliações de risco individuais em seus aplicativos. É responsabilidade exclusiva do consumidor determinar se ele deve utilizar o BinaryFormatter. Se estiver considerando usá-lo, avalie os riscos das consequências de segurança, técnicas, de reputação, legais e regulatórias.

Alternativas preferenciais

O .NET oferece vários serializadores in-box que podem lidar com os dados não confiáveis com segurança:

Alternativas perigosas

Evite os seguintes serializadores:

Todos os serializadores anteriores executam desserialização polimórfica irrestrita e são perigosos, assim como BinaryFormatter.

Os riscos de presumir que os dados são confiáveis

Frequentemente, um desenvolvedor de aplicativos pode acreditar que está processando apenas entrada confiável. O caso de entrada segura é verdadeiro em algumas circunstâncias raras. Contudo, é muito mais comum que um conteúdo cruze um limite de confiança sem que o desenvolvedor perceba.

Considere um servidor local em que os funcionários usam um cliente da área de trabalho de suas estações de trabalho para interagir com o serviço. Esse cenário pode ser visto ingenuamente como uma configuração "segura" em que a utilização BinaryFormatter é aceitável. No entanto, esse cenário apresenta um vetor para malware que ganha acesso ao computador de um só funcionário para se espalhar por toda a empresa. Esse malware pode aproveitar o uso BinaryFormatter pela empresa para se mover lateralmente da estação de trabalho do funcionário para o servidor de back-end. Então ele pode exfiltrar os dados confidenciais da empresa. Esses dados podem incluir segredos comerciais ou dados do cliente.

Considere também um aplicativo que usa BinaryFormatter para persistir o estado de salvamento. À primeira vista, isso pode parecer um cenário seguro, pois ler e gravar dados em um disco rígido próprio representa uma pequena ameaça. Porém, o compartilhamento de documentos por email ou pela Internet é comum e a maioria dos usuários finais não perceberia a abertura desses arquivos baixados como um comportamento arriscado.

Esse cenário pode ser aproveitado para efeito nefasto. Se o aplicativo for um jogo, os usuários que compartilham arquivos de salvamento se colocam em risco inadvertidamente. Os próprios desenvolvedores também podem ser alvos. O invasor pode enviar por email o suporte técnico dos desenvolvedores anexando um arquivo de dados mal-intencionado e solicitando que a equipe de suporte o abra. Esse tipo de ataque pode abrir as portas para o invasor entrar na empresa.

Outro cenário é quando o arquivo de dados é armazenado no armazenamento em nuvem e sincronizado automaticamente entre os computadores do usuário. Um invasor que consegue obter acesso à conta de armazenamento em nuvem pode envenenar o arquivo de dados. Esse arquivo de dados será sincronizado automaticamente com os computadores do usuário. Na próxima vez que o usuário abrir o arquivo de dados, o conteúdo do invasor será executado. Portanto, o invasor poderá aproveitar um compromisso de conta de armazenamento em nuvem para obter permissões de execução de código completas.

Considere um aplicativo que passa de um modelo de instalação da área de trabalho para um modelo primeiro na nuvem. Esse cenário inclui aplicativos que se movem de um aplicativo da área de trabalho ou modelo de cliente avançado para um modelo baseado na Web. Os modelos de ameaça elaborados para o aplicativo da área de trabalho não são necessariamente aplicáveis ao serviço baseado em nuvem. O modelo de risco para o aplicativo da área de trabalho pode descartar uma determinada ameaça como "não interessante para o cliente atacar a si mesmo". Mas essa mesma ameaça pode se tornar interessante quando considera um usuário remoto (o cliente) atacando o serviço de nuvem em si.

Observação

Em termos gerais, a intenção de serialização é transmitir um objeto para dentro ou para fora de um aplicativo. Um exercício de modelagem de ameaças quase sempre marca esse tipo de transferência de dados como cruzando um limite de confiança.

Confira também