Workaround de Codificação para o Boletim de Segurança Microsoft MS11–100: .NET Framework

Autor:
Marcelo Bianchi, Support Engineer – CTS LATAM

Revisores:
Roberto Cavalcanti, Technical Support Lead – CTS LATAM
Daniel Mauser, Sr. Support Escalation Engineer – CTS LATAM              

Introdução

No último dia 29 de dezembro a Microsoft lançou o boletim extra de segurança MS11-100 que disponibiliza uma atualização de segurança para quatro vulnerabilidades no .NET Framework. É importante salientar que a recomendação da Microsoft é que atualização seja instalada. Abaixo estamos disponibilizando um guia informativo sobre as possíveis alternativas (workarounds) para caso haja algum impedimento na instalação da atualização, de como deve ser feita a codificação no ASP.NET para que sejam evitadas as seguintes vulnerabilidades:

- Vulnerabilidade Denial of Service (CVE-2011-3414)
- Vulnerabilidade Spoofing (CVE-2011-3415)
- VulnerabilidadeElevation of Privilege (CVE-2011-3416)
- Vulnerabilidade Elevation of Privilege (CVE-2011-3417)

Vulnerabilidade Denial of Service (CVE-2011-3414)

A vulnerabilidade Denial of Service (CVE-2011-3414) existe na forma que o ASP.NET Framework processa valores em um post de um form, causando o que é chamado de hash collision no qual permite ao invasor causar um ataque de denial of service enviando uma pequena quantidade de posts especialmente codificados para o servidor ASP.NET.

Codificação do workaround:

Limitar o tamanho máximo do request no qual o ASP.NET irá aceitar de um cliente. Para isso você deverá adicionar ao arquivo root web.config ou ao applicationhost.config linhas de código para que seja executada a configuração e dessa forma todos os sites ASP.NET no servidor serão afetados.

Open the file root web.config:

a) Caso a sua aplicação utilize o conceito de View State adicione a seguinte configuração que irá fazer com que o tamanho máximo do request vindo do cliente para o ASP.NET seja limitado para 200 KB.  

<configuration> <system.web> <httpRuntime maxRequestLength=”200”/> </system.web></configuration>

 b) Se a sua aplicação não utiliza o conceito de ASP.NET View State, adicione as seguintes configurações que irão limitar o tamanho máximo do request do cliente para o ASP.NET no valor de 20 KB.

<configuration> <system.web> <httpRuntime maxRequestLength=”20”/> </system.web></configuration>

Informação Complementar :

O conceito de ASP.NET View State é que existe um campo escondido armazenado da codificação de uma página HTML que foi gerada através de codificação ASP .NET
Através da View State a página e seus components são concatenadas com um hash code que é gerado pelo servidor para que sejam evitados ataques no qual alguém com más intensões modifique o conteúdo e dessa forma realize o postback para o servidor.

Exemplo:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional //EN”><html> <head> <title> </title> </head><body> <form name=”_ctl0” method=”post” action =”WebForm1.aspx” id=”_ctl0”> <input type=”hidden” name=”_VIEWSTATE” value = “dDwtNjU0MzcyMTklOzs++0nkj9wYEIHhJubPoNiG5UGjjaI=”/> </form></body></html>

Cada componente que existe dentro da página ASP.NET salve esse estado de View State e a cada vez que acontece um postback esse componente retorna e dessa forma pode ser visualizado como era antes, ou seja, não há a necessidade de fazer uma nova inicialização ou então ir buscar os dados do banco de dados novamente.
Para maiores informações existe um link sobre esse assunto na parte de referências.

VulnerabilidadeSpoofing (CVE-2011-3415)

A vulnerabilidade Spoofing vulnerability (CVE-2011-3415) existe na forma que o .NET Framework verifica o retorno de URLs durante o processo de autenticação e isso poderia permitir que um invasor redirecionasse os usuários para outro website que o invasor desejar, sem o prévio conhecimento do usuário.

Codificação de workaround:

  • Desabilitar Forms Authentication no arquivo web.config:

set forms authentication = "None"

Vulnerabilidade Elevation of Privilege (CVE-2011-3416)

A vulnerabilidade Elevation of Privilege (CVE-2011-3416) existe na forma que o .NET Framework autentica usuários, no qual utilizando uma conta de usuário válida, o invasor poderá criar uma nova conta de usuário e essa nova conta poderá ter altos privilégios em uma aplicação ASP.NET. Isso é realizado enviando um web request especialmente codificado.

 Codificação do workaround:

  • Ajustar a propriedade ticketCompatibilityMode para o Framework 4.0, para isso altere o código da sua aplicação incluindo:

ConfigurationPropertyAttribute("ticketCompatibilityMode", DefaultValue = TicketCompatibilityMode.Framework40)]public TicketCompatibilityMode TicketCompatibilityMode { get; set; }

 InformaçãoComplementar:

A propriedade Ticket Compatibility Model define o formato de data e hora que será utilizado para a expiração do ticket. Os valores podem ser ajustados para horário local para caso seja escolhida a opção Framework 2.0 ou então podem ser ajustado para UTC (Coordinated Universal Time) caso seja escolhida a opção Framework 4.0.

Para maiores informações, existe um link sobre esse assunto na parte de referências.

  • Desabilitar Forms Authentication no arquivo root web.config

set forms authentication = "None"

Vulnerabilidade Elevation of Privilege (CVE-2011-3417)

 Para a vulnerabilidade Elevation of Privilege (CVE-2011-3417) exista na forma que o ASP.NET Framework lhe dá com o conteúdo do cache quando o Forms authentication é usado com Sliding Expiry, no qual poderia permitir que um invasor fizesse qualquer ação em um site se passando como se fosse o usuário real. Mas para que seja possível é necessário que o usuário clique em um link com código malicioso.

  Codificação de workaround:

  • Restringir osforms authentication cookies para utilizer somente SSL channels

Para que seja possível restringir os forms authentication cookies para utilizar somente SSL channels, altere o código incluindo:

 <forms loginUrl="Secure\Login.aspx" requireSSL="true" ...

                                                />

Informação Complementar:

Para prevenir que forms authentication cookies sejam capturados enquanto estiverem atravessando a rede, tenha certeza de somente utilize conexões SSL, com todas as páginas que requerem acesso autenticado e restrinja os forms authentication tickets para utilizar somente SSL channels ajustando requireSSL= “true” no <forms>.

Realizando o ajuste de requireSSL= "true" , você irá configurar a propriedade do cookie que determine se os navegadores poderão enviar o cookie de volta ao servidor. Com a opção secure configurada, os cookies que são enviados pelo navegador para páginas através do HTTPS URL.

Observação: Caso o usuário esteja utilizando sessões cookieless, se certifique que o authentication ticket nunca será transmitido através de um canal inseguro.

  • Desabilitando sliding expiration para os forms authentication cookies, altere o código da sua aplicação incluindo:  

<forms forms slidingExpiration=”false” ... />

Informação Complementar :

Redução do tempo de vida do ticket

Considere reduzir o tempo de vida do cookie, reduzindo a janela de tempo no qual um invasor poderá usar para poder capturar o cookie e ganhar acesso à aplicação utilizando a técnica spoofed identity. Isso é particularmente importante se você não estiver utilizando SSL. O timeout padrão para um authentication cookie é de 30 minutos, mas considere realizar uma redução para 10 minutos.

O sliding expiration redefine o tempo de expiração para um authentication cookie. Será feito um request que passará mais do que a metade do intervalo de tempo total predefinido como limitar de expiração, caso isso ocorra o usuário deverá ser autenticado novamente. Definindo a propriedade sliding expiration para false, será realizada uma significativa melhora na segurança da web application, pois dessa forma o limite de tempo válido para um authentication cookie ocorrerá de acordo com o limite de tempo pré-configurado, não havendo possibilidade de renovação automática de mais uma janela de tempo.

  • Desativaro Output Caching

Existem várias maneiras de se desabilitar o output cache e uma delas é adicionando o seguinte código:

Adicione essas linhas de código na meta section de suas páginas HTML:<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">< META HTTP-EQUIV="EXPIRES" CONTENT="0">

Adicione essa linha de código ao page_load da sua web application:Response.Cache.SetCacheability(HttpCacheability.NoCache);

Informação Complementar:

Output Caching

O tipo de cache padrão que web applications utilizam é o output caching. O Output caching proporciona armazenar HTML que já foi renderizado pelo web server. O HTML armazenado é útil em resposta a subsequentes requests para a mesma página. Você poderá usar o output caching para realizar o cache de todas as páginas web ou então somente a saída de um controle ASP .NET.

Referências :

Microsoft Security Bulletin MS11-100 - Critical
https://technet.microsoft.com/en-ca/security/bulletin/ms11-100

IIS OutputCash
https://msdn.microsoft.com/en-us/library/ms178597.aspx

ASP Net Authentication Forms
https://msdn.microsoft.com/en-us/library/ff648341.aspx

ASP Net Authentication Cookies
https://support.microsoft.com/kb/910443/en-us

ASP Net View State
https://msdn.microsoft.com/en-us/library/ms972976.aspx

Denial of Service vulnerability (CVE-2011-3414)
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3414

A Spoofing vulnerability (CVE-2011-3415)
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3415

An Elevation of Privilege vulnerability (CVE-2011-3416)
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3416

An Elevation of Privilege vulnerability (CVE-2011-3417)
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3417