Qual é a gravidade dessa nova vulnerabilidade de segurança do ASP.NET e como posso solucionar isso?

Acabei de ler na net sobre uma vulnerabilidade de segurança recém-descoberta no ASP.NET. Você pode ler os detalhes aqui.

O problema está na maneira como o ASP.NET implementa o algoritmo de criptografia AES para proteger a integridade dos cookies que esses aplicativos geram para armazenar informações durante as sessões do usuário.

Isso é um pouco vago, mas aqui está uma parte mais assustadora:

O primeiro estágio do ataque leva alguns milhares de solicitações, mas, uma vez bem-sucedido e o invasor obtém as chaves secretas, é totalmente furtivo. O conhecimento criptográfico necessário é muito básico.

Em suma, não estou familiarizado o suficiente com o assunto de segurança / criptografia para saber se isso é realmente sério.

Portanto, todos os desenvolvedores do ASP.NET devem temer esta técnica que pode ser proprietária de qualquer site do ASP.NET em segundos ou o quê?

Como esse problema afeta o desenvolvedor ASP.NET médio? Isso nos afeta? Na vida real, quais são as conseqüências dessa vulnerabilidade? E, finalmente: existe alguma solução alternativa que evita essa vulnerabilidade?

Obrigado por suas respostas!

EDIT: Deixe-me resumir as respostas que recebi

Portanto, este é basicamente um tipo de ataque "padding oracle". O @Sri forneceu uma ótima explicação sobre o que esse tipo de ataque significa. Aqui está um vídeo chocante sobre o assunto!

Sobre a seriedade dessa vulnerabilidade: Sim, é realmente grave. Permite ao invasor conhecer a chave da máquina de um aplicativo. Assim, ele pode fazer coisas muito indesejadas.

• Em posse da chave da máquina do aplicativo, o invasor pode descriptografar os cookies de autenticação.
• Pior ainda, ele pode gerar cookies de autenticação com o nome de qualquer usuário. Assim, ele pode aparecer como qualquer pessoa no site. O aplicativo não consegue diferenciar entre você ou o hacker que gerou um cookie de autenticação com seu nome.
• Ele também permite descriptografar (e também gerar) cookies de sessão , embora isso não seja tão perigoso quanto o anterior.
• Não é tão sério: ele pode descriptografar o ViewState criptografado de páginas. (Se você usa o ViewState para armazenar dados confidenciais, não deve fazer isso de qualquer maneira!)
• Bastante inesperado : com o conhecimento da chave da máquina, o invasor pode baixar qualquer arquivo arbitrário do seu aplicativo da web, mesmo aqueles que normalmente não podem ser baixados! (Incluindo Web.Config , etc.)

Aqui estão algumas práticas recomendadas que não resolvem o problema, mas ajudam a melhorar a segurança geral de um aplicativo Web.

• Você pode criptografar dados confidenciais com o Protected Configuration
• Usar cookies somente HTTP
• Impedir ataques de DoS

Agora, vamos nos concentrar nessa questão.

• Scott Guthrie publicou uma entrada sobre isso em seu blog
• Postagem no blog de ScottGu sobre a vulnerabilidade
• Atualização de ScottGu sobre a vulnerabilidade
• A Microsoft tem um aviso de segurança sobre isso
• Entendendo a vulnerabilidade
• Informações adicionais sobre a vulnerabilidade

A solução

• Ative customErrors e crie uma única página de erro para a qual todos os erros são redirecionados. Sim, até 404s . (ScottGu disse que a diferenciação entre 404 e 500 é essencial para esse ataque.) Além disso, coloque no seu código Application_Errorou Error.aspxcoloque algum código que produza um atraso aleatório. (Gere um número aleatório e use Thread.Sleep para dormir por tanto tempo.) Isso tornará impossível ao invasor decidir o que exatamente aconteceu no seu servidor.
• Algumas pessoas recomendaram voltar ao 3DES. Em teoria, se você não usa o AES, não encontra a fraqueza de segurança na implementação do AES. Como se vê, isso não é recomendado .

Alguns outros pensamentos

• Parece que nem todo mundo pensa que a solução alternativa é boa o suficiente.

Obrigado a todos que responderam à minha pergunta. Aprendi muito não apenas sobre esse problema, mas sobre a segurança da web em geral. Marquei a resposta de @ Mikael como aceita, mas as outras respostas também são muito úteis.

O que devo fazer para me proteger?

[Atualização 29/09/2010]

Boletim de segurança da Microsoft

Artigo da base de dados de referência com a correção

ScottGu tem links para os downloads

[Atualização 25-09-2010]

Enquanto aguardamos a correção, ontem o ScottGu postou uma atualização sobre como adicionar uma etapa extra para proteger seus sites com uma regra URLScan personalizada.

Além disso, adicione um tempo aleatório de suspensão na página de erro para impedir que o invasor cronometre as respostas para obter informações adicionais sobre o ataque.

No web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Isso redirecionará qualquer erro para uma página personalizada retornada com um código de status 200. Dessa forma, um invasor não pode examinar o código de erro ou as informações de erro para obter as informações necessárias para novos ataques.

Também é seguro definir customErrors mode="RemoteOnly", pois isso redirecionará os clientes "reais". Somente a navegação no host local mostrará erros .Net internos.

A parte importante é garantir que todos os erros estejam configurados para retornar a mesma página de erro. Isso requer que você defina explicitamente o defaultRedirectatributo na <customErrors>seção e garanta que nenhum código por status esteja definido.

O que está em jogo?

Se um invasor conseguir usar a exploração mencionada, ele poderá baixar arquivos internos de dentro do seu aplicativo da web. Normalmente, o web.config é um destino e pode conter informações confidenciais, como informações de logon em uma cadeia de conexão de banco de dados, ou até mesmo vincular a um banco de dados sql-express com saída automática, da qual você não deseja que alguém se apegue. Mas se você estiver seguindo as melhores práticas, use a Configuração Protegida para criptografar todos os dados confidenciais no seu web.config.

Links para referências

Leia o comentário oficial da Microsoft sobre a vulnerabilidade em http://www.microsoft.com/technet/security/advisory/2416728.mspx . Especificamente, a parte "Solução alternativa" para obter detalhes de implementação sobre esse problema.

Também algumas informações no blog de ScottGu , incluindo um script para encontrar aplicativos ASP.Net vulneráveis ​​em seu servidor da web.

Para uma explicação sobre "Noções básicas sobre ataques do Oracle Padding", leia a resposta da @ sri .

Comentários ao artigo:

O ataque que Rizzo e Duong implementaram contra aplicativos ASP.NET exige que a implementação de criptografia no site tenha um oráculo que, quando enviado texto cifrado, não apenas descriptografa o texto, mas também transmite ao remetente uma mensagem sobre se o preenchimento no texto cifrado é válido .

Se o preenchimento for inválido, a mensagem de erro recebida pelo remetente fornecerá algumas informações sobre o funcionamento do processo de descriptografia do site.

Para que o ataque funcione, o seguinte deve ser verdadeiro:

• Seu aplicativo deve fornecer uma mensagem de erro sobre o preenchimento ser inválido.
• Alguém deve adulterar seus cookies criptografados ou exibir o estado

Portanto, se você retornar mensagens de erro legíveis por humanos em seu aplicativo como "Algo deu errado, tente novamente" , você deve estar bem seguro. Ler um pouco sobre os comentários no artigo também fornece informações valiosas.

• Armazene um ID de sessão no cookie criptografado
• Armazene os dados reais no estado da sessão (persistido em um banco de dados)
• Adicione uma espera aleatória quando as informações do usuário estiverem incorretas antes de retornar o erro, para que você não possa cronometrar

Dessa forma, um cookie seqüestrado pode ser usado apenas para recuperar uma sessão que provavelmente não está mais presente ou é invalidada.

Será interessante ver o que é realmente apresentado na conferência Ekoparty, mas no momento não estou muito preocupado com essa vulnerabilidade.

Compreendendo os ataques do Oracle Padding

Vamos supor que seu aplicativo aceite uma string criptografada como parâmetro - se o parâmetro é um cookie, um parâmetro de URL ou qualquer outra coisa é irrelevante. Quando o aplicativo tenta decodificá-lo, há 3 resultados possíveis -

1. Resultado 1 : a cadeia de caracteres criptografada descriptografou corretamente e o aplicativo conseguiu fazer sentido. Ou seja, se a sequência criptografada fosse um número de conta de 10 dígitos, após a descriptografia, o aplicativo encontrou algo como "1234567890" e não "abcd1213ef"

2. Resultado 2 : o preenchimento estava correto, mas após a descriptografia, a sequência obtida ficou sem sentido que o aplicativo não conseguiu entender. Por exemplo, a sequência descriptografada para "abcd1213ef", mas o aplicativo esperava apenas números. A maioria dos aplicativos exibirá uma mensagem como "Número de conta inválido".

3. Resultado 3 : o preenchimento estava incorreto e o aplicativo lançou algum tipo de mensagem de erro. A maioria dos aplicativos exibirá uma mensagem genérica como "Ocorreu um erro".

Para que um ataque do Padding Oracle seja bem-sucedido, o invasor deve poder fazer vários milhares de solicitações e classificar a resposta em um dos três depósitos acima sem erros.

Se essas duas condições forem atendidas, o invasor poderá descriptografar a mensagem e depois criptografá-la novamente com o que ele desejar. É apenas uma questão de tempo.

O que pode ser feito para evitá-lo?

1. A coisa mais simples - qualquer coisa sensível nunca deve ser enviada ao cliente, criptografada ou não criptografada. Mantenha-o no servidor.

2. Certifique-se de que o resultado 2 e o resultado 3 na lista acima apareçam exatamente iguais ao invasor. Não deve haver uma maneira de descobrir um do outro. Isso não é tão fácil assim - um invasor pode discriminar usando algum tipo de ataque de tempo.

3. Como última linha de defesa, tenha um Firewall de Aplicativos Web. O ataque de preenchimento do oracle precisa fazer várias solicitações que parecem quase semelhantes (alterando um bit de cada vez), portanto, deve ser possível para um WAF capturar e bloquear tais solicitações.

PS Uma boa explicação sobre o Padding Oracle Attacks pode ser encontrada nesta postagem do blog . Disclaimer: NÃO é o meu blog.

Pelo que li até agora ...

O ataque permite que alguém descriptografe cookies cheirados, que podem conter dados valiosos, como saldos bancários

Eles precisam do cookie criptografado de um usuário que já tenha efetuado login, em qualquer conta. Eles também precisam encontrar dados nos cookies - espero que os desenvolvedores não armazenem dados críticos nos cookies :). E existe uma maneira que eu tenho abaixo de não permitir que o asp.net armazene dados no cookie de login.

Como alguém pode obter o cookie de um usuário que está online se ele não coloca as mãos nos dados do navegador? Ou cheirar o pacote IP?

Uma maneira de impedir isso é não permitir o transporte de cookies sem criptografia SSL.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Além disso, mais uma medida é impedir o armazenamento de funções em cookies.

<roleManager enabled="true" cacheRolesInCookie="false">

Agora, sobre os cookies que não são seguros para as páginas regulares, é necessário pensar um pouco mais sobre o que você deixou seu usuário e o que não, como você confia nele, que verificação extra você pode fazer (por exemplo, se você observar uma alteração no IP , talvez pare de confiar nele até voltar a acessar a página de segurança).

Referência:
algum hacker pode roubar o cookie de um usuário e fazer login com esse nome em um site?

Como verificar de onde vêm os ataques e não devolver informações. Escrevi aqui uma maneira simples de impedir que o preenchimento seja inválido e faça o logon ao mesmo tempo para rastrear os invasores: CryptographicException: o preenchimento é inválido e não pode ser removido e a validação do viewstate MAC falhou

A maneira de rastrear o atacante é verificar se o preenchimento é inválido. Com um procedimento simples, você pode localizá-los e bloqueá-los - eles precisam de milhares de chamadas na sua página para encontrar a chave!

Atualização 1.

Eu tenho o download da ferramenta que suponha que encontre a KEY e descriptografe os dados, e como digo sua armadilha no código acima, verifique a viewstate . Dos meus testes, esta ferramenta tem muito mais para corrigir, por exemplo, não é possível verificar o estado da exibição compactada como está e sua falha nos meus testes.

Se alguém tentar usar essa ferramenta ou esse método, o código acima poderá rastreá-los e você poderá bloqueá-los para fora da sua página com um código simples como "Impedir Negação de Serviço (DOS)" ou como esse código para impedir a Negação de serviço .

Atualização 2

Parece que li até agora que o único que realmente precisa é não fornecer informações sobre o erro , basta colocar uma página de erro personalizada e, se quiser, pode criar um atraso aleatório para esta página.

um vídeo muito interessante sobre esse assunto.

Portanto, todas as opções acima são mais medidas para obter mais proteções, mas não 100% necessárias para esse problema em particular. Por exemplo, usar o cookie ssl é resolver o problema snif, não armazenar os papéis em cookies é bom não enviar e recuperar grandes cookies e evitar alguém que já tenha decifrado o código, apenas para colocar a função de administrador o biscoito dele.

O viewstate rastreia é apenas mais uma medida para encontrar um ataque.

Aqui está a resposta do MS. Tudo se resume a "usar uma página de erro personalizada" e você não fornecerá nenhuma pista.

EDIT
Aqui estão algumas informações mais detalhadas do scottgu.

Adicionando as respostas de ScottGu retiradas da discussão em http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

IHttpModule personalizado em vez de customErrors é afetado?

P: Eu não tenho um elemento declarado no meu web.config, tenho um IHttpModule dentro da seção. Este módulo registra o erro e redireciona para uma página de pesquisa (para 404) ou para uma página de erro (para 500). Eu sou vulnerável?

R: Eu recomendaria atualizar temporariamente o módulo para sempre redirecionar para a página de pesquisa. Uma das maneiras pelas quais esse ataque funciona é procurar diferenciação entre erros 404 e 500. Sempre retornar o mesmo código HTTP e enviá-lo para o mesmo local é uma maneira de ajudar a bloqueá-lo.

Observe que quando o patch sair para corrigir isso, você não precisará fazer isso (e poderá voltar ao comportamento antigo). Mas, por enquanto, eu recomendo não diferenciar entre 404 e 500 para os clientes.

Posso continuar usando erros diferentes para erros 404 e 500?

P: Entendo que ainda podemos ter uma página 404 personalizada definida, além do redirecionamento padrão por erro, sem violar os princípios descritos acima?

R: Não - até lançarmos um patch para a correção real, recomendamos a solução acima, que homogeneiza todos os erros. Uma das maneiras pelas quais esse ataque funciona é procurar diferenciação entre erros 404 e 500. Sempre retornar o mesmo código HTTP e enviá-lo para o mesmo local é uma maneira de ajudar a bloqueá-lo.

Observe que quando o patch sair para corrigir isso, você não precisará fazer isso (e poderá voltar ao comportamento antigo). Mas, no momento, você não deve diferenciar entre 404 e 500 para os clientes.

Como isso permite a exposição do web.config?

P: Como isso permite a exposição do web.config? Isso parece permitir a descriptografia do ViewState apenas. Existe outra vulnerabilidade relacionada que também permite a divulgação de informações? Existe um white paper que detalha o ataque para uma melhor explicação do que está acontecendo?

R: O ataque que foi mostrado em público depende de um recurso do ASP.NET que permite o download de arquivos (normalmente javascript e css) e que é protegido com uma chave enviada como parte da solicitação. Infelizmente, se você conseguir forjar uma chave, poderá usar esse recurso para baixar o arquivo web.config de um aplicativo (mas não os arquivos fora do aplicativo). Obviamente, lançaremos um patch para isso - até então, a solução alternativa fechará o vetor de ataque.

EDIT: FAQs adicionais disponíveis no segundo post do blog em http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Na IMO, não há prevenção geral para isso; ele deve ser tratado caso a caso:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Alguns links significativos:

• Comunicado de Segurança da MS 2416728 (esta é a informação oficial)
• Informações adicionais da equipe de Defesa e Pesquisa de Segurança da MS
  • "Compreendendo a vulnerabilidade do ASP.NET" (17-09-2010)
  • "Informações adicionais sobre a vulnerabilidade do ASP.NET" (20-09-2010)
• Scott Gu: "Importante: Vulnerabilidade de segurança do ASP.NET" (18-09-2010)

[Para responder ao aspecto de seriedade disso (o que foi publicado e as soluções alternativas são cobertas por outras respostas).]

A chave que está sendo atacada é usada para proteger os cookies de estado e de sessão. Normalmente, essa chave é gerada internamente pelo ASP.NET a cada nova instância do aplicativo Web. Isso limitará o escopo de danos ao tempo de vida do processo do operador, é claro que para um aplicativo ocupado, isso pode levar dias (ou seja, não tem muito limite). Durante esse período, o invasor pode alterar (ou injetar) valores no ViewState e alterar sua sessão.

Ainda mais seriamente, se você deseja que as sessões abranjam a vida útil do processo do trabalhador ou permita que farms da Web (ou seja, todas as instâncias do farm possam lidar com qualquer sessão do usuário), a chave precisa ser codificada, isso é feito em web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Essas são, é claro, chaves recém-criadas, eu uso o seguinte PowerShell para acessar o gerador de números aleatórios criptográficos do Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Usando um comprimento de matriz de 20 para a validação e 16 para as chaves de descriptografia.)

Além de modificar as páginas de erro públicas para não vazar o erro específico, parece um bom momento para alterar as chaves acima (ou alternar os processos de trabalho, se estiverem em execução por um tempo).

[Editar 21/09/2010: links adicionados ao topo]

Acabei de publicar minha opinião completa sobre isso no meu blog , após uma pesquisa extra sobre o assunto. Eu acho que é importante esclarecer por que eles estão chegando ao ponto de forjar um cookie de autenticação.

Só quero esclarecer alguns fatos:

1. O ataque não permite que você obtenha a chave da máquina diretamente. Dito isto, é muito parecido com o que tinha, pois permite descriptografar as mensagens e modificar / criptografar novas.
2. da maneira como as chaves são obtidas, usando sua capacidade de modificar re / criptografar como em 1 e obter o web.config. Infelizmente, existem razões pelas quais alguns colocam essas chaves no web.config no nível do site (discussão diferente) e no exemplo de vídeo eles se beneficiam por ser o padrão do DotnetNuke.
3. para obter o web.config completo, ele indica que eles estão usando webresources.axd e / ou scriptresources.axd. Eu pensei que eles funcionavam apenas com recursos incorporados, mas parece que não é o caso.
4. se o aplicativo for asp.net MVC, não precisamos realmente de webresources.axd e / ou scriptresources.axd, para que eles possam ser desativados. Também não usamos o viewstate. Dito isso, não está claro para mim se algum dos outros recursos do asp.net fornece informações diferentes com a solução alternativa, ou seja, não sei se o preenchimento fornece resultados inválidos em erro, enquanto o preenchimento resulta em um ticket de autenticação ignorado (não sei se for ou não o caso) ... a mesma análise deve ser aplicada ao cookie da sessão.
5. O provedor de associação asp.net 'armazena em cache' funções em cookies, desative-o.

Cerca de 1, depois que as mensagens criptografadas não podem ser 100% arbitrárias, é necessário tolerar um pequeno pedaço de lixo em algum lugar da mensagem, pois há 1 bloco na mensagem que descriptografa o valor que não pode ser controlado.

Finalmente, gostaria de dizer que esse problema é o resultado de a Microsoft não seguir sua própria orientação neste caso: um recurso depende de algo enviado ao cliente à prova de violação.

Mais sobre:

Não sei se o preenchimento gera resultados inválidos em erro, enquanto o preenchimento resulta em ticket de autenticação ignorado (não sei se é ou não o caso) ... a mesma análise deve ser aplicada ao cookie da sessão.

O cookie de autenticação é assinado e, pelas informações no documento, eles não devem ser capazes de gerar um cookie assinado se não chegarem às chaves reais (como fizeram no vídeo antes de falsificar o cookie de autenticação).

Como Aristos mencionou, para o ID da sessão no cookie, isso é aleatório para a sessão do usuário, portanto, ele deve ser detectado por um usuário com o nível de segurança de destino e quebrado enquanto essa sessão estiver ativa. Mesmo assim, se você estiver confiando na autenticação para atribuir / autorizar as operações do usuário, o impacto será mínimo / dependerá muito do uso da sessão nesse aplicativo.

Um patch para esse bug foi lançado no Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

O asp.net MVC também é afetado por esse problema (como o Sharepoint, ...)

Abordei a correção para o MVC aqui: O ASP.NET MVC é vulnerável ao ataque de preenchimento da Oracle?