- क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की इच्छा है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
**इस पोस्ट की सामग्री निम्नलिखित स्रोत से निकाली गई है** [**https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/**](https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/)
यह सामान्यतः संभव होता है कि एक वेब सर्वर पर कोड चलाया जा सके जहां एक मान्य ViewState जाली बनाई जा सकती है। यह किया जा सकता है जब **MAC सत्यापन** सुविधा को **अक्षम** कर दिया गया हो या जानते हों:
हेरफेर आक्रमणों को रोकने के लिए, .NET Framework वह ViewState को **साइन और एन्क्रिप्ट** कर सकता है जो `LosFormatter` कक्षा का उपयोग करके संकलित किया गया है। फिर यह संकेत सत्यापन मेकेनिज़्म का उपयोग करके हस्ताक्षर की सत्यापन करता है। `ObjectStateFormatter` कक्षा साइन करने, एन्क्रिप्ट करने और सत्यापन करने के कार्य करती है। साइन और/या एन्क्रिप्शन करने के लिए आवश्यक **कुंजी** को संग्रहीत किया जा सकता है **`web.config`** (एप्लिकेशन स्तर) या **`machine.config`** (मशीन स्तर) फ़ाइलों के **`machineKey`** खंड में। यह सामान्यतः उस स्थिति में होता है जब एक ही एप्लिकेशन को सेवा करने के लिए बहुत सारे वेब सर्वर उपयोग किए जाते हैं, जो अक्सर एक वेब फ़ार्म या क्लस्टर में एक लोड बैलेंसर के पीछे होते हैं। निम्नलिखित में एक ASP.NET एप्लिकेशन के एक कॉन्फ़िगरेशन फ़ाइल में `machineKey` खंड का प्रारूप दिखाया गया है जो .NET Framework संस्करण 2.0 या उससे ऊपर का उपयोग करता है:
ध्यान देना चाहिए कि जब कॉन्फ़िगरेशन फ़ाइल में `machineKey` धारा परिभाषित नहीं होती है या जब `validationKey` और `decryptionKey` विशेषताएँ `AutoGenerate` पर सेट की जाती हैं, तो **एप्लिकेशन एक क्रिप्टोग्राफिकली यादृच्छिक गुप्त से आधारित आवश्यक मानों को डाइनामिक रूप से उत्पन्न करता है**। एल्गोरिदम भी स्वचालित रूप से चुने जा सकते हैं। वर्तमान में .NET Framework के नवीनतम संस्करण में, डिफ़ॉल्ट मान्यता एल्गोरिदम `HMACSHA256` है और डिफ़ॉल्ट डिक्रिप्शन एल्गोरिदम `AES` है। अधिक जानकारी के लिए [\[13\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection) देखें।
पहले, `enableViewStateMac` संपत्ति को `False` पर सेट करके **MAC सत्यापन को अक्षम करना** संभव था। माइक्रोसॉफ्ट ने सितंबर 2014 में एक पैच जारी किया [\[3\]](https://devblogs.microsoft.com/aspnet/farewell-enableviewstatemac/) जिससे .NET Framework के सभी संस्करणों में इस संपत्ति को अनदेखा करके MAC सत्यापन को प्रभावी बनाया गया है। हालांकि, हम में से कुछ लोग यह मान सकते हैं कि "_ViewState MAC अब और अक्षम नहीं किया जा सकता है_" [\[4\]](https://www.owasp.org/index.php/Anti\_CSRF\_Tokens\_ASP.NET), लेकिन **अब भी MAC सत्यापन सुविधा को अक्षम करना संभव है** जब `AspNetEnforceViewStateMac` रजिस्ट्री कुंजी को शून्य पर सेट किया जाता है:
जब ViewState MAC सत्यापन अक्षम हो जाता है, तो [YSoSerial.Net](https://github.com/pwntester/ysoserial.net) परियोजना का उपयोग करके `LosFormatter` payloads को ViewState के रूप में उत्पन्न किया जा सकता है ताकि सर्वर पर अनियंत्रित कोड चलाया जा सके।
**.NET Framework** संस्करण **4.5** से **पहले**, `__VIEWSTATE` पैरामीटर **एन्क्रिप्ट किया जा सकता था** जबकि MAC सत्यापन सुविधा अक्षम थी। यह ध्यान देने योग्य है कि **अधिकांश****स्कैनर****इस दुर्बलता की पहचान करने के लिए एक अनएन्क्रिप्टेड ViewState पैरामीटर भेजने का प्रयास नहीं करते हैं। इसलिए, `__VIEWSTATE` पैरामीटर को एन्क्रिप्ट किया जाता है तो MAC सत्यापन अक्षम है या नहीं यह जांचने के लिए **मैन्युअल****टेस्टिंग** की आवश्यकता होती है। इसे `__VIEWSTATE` पैरामीटर में एक छोटी सी यादृच्छिक base64 स्ट्रिंग भेजकर जांचा जा सकता है। निम्नलिखित URL में एक उदाहरण दिखाया गया है:
स्वचालित स्कैनर्स को सर्वर-साइड पर एक छोटी संविलम्ब का कारण करने वाले **पेलोड** का उपयोग करना चाहिए। इसे निम्नलिखित ASP.NET कोड को निष्पादित करके प्राप्त किया जा सकता है, जो एक 10 सेकंड की देरी बनाने के लिए उदाहरण के रूप में कार्य करता है:
पुराने संस्करणों (**4.5 से पहले**) में, .NET Framework **`TemplateSourceDirectory`** property [\[15\]](https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.control.templatesourcedirectory) का उपयोग करता है जब एक serialized object को **साइन करता है**. हालांकि, **4.5 संस्करण** से, यह **`Purpose`** strings का उपयोग करके हैश बनाने के लिए करता है. इन दोनों मेकेनिज़म्स **अनुप्रयोग निर्देशिका की जड़ में लक्ष्य पृष्ठ का उपयोग करते हैं**. ये पैरामीटर **URL से निकाले जा सकते हैं**.
ऐसे अनुप्रयोग जो **पुराने framework का उपयोग करते हैं** और ViewState एन्क्रिप्शन को लागू करते हैं, वे **एन्क्रिप्शन के बिना साइन किए गए ViewState को भी स्वीकार कर सकते हैं**. इसका मतलब है कि एक वेबसाइट को उत्पन्न करने के लिए **सत्यापन कुंजी और उसकी एल्गोरिदम को जानना पर्याप्त होता है**. लगता है ViewState डिफ़ॉल्ट रूप से एन्क्रिप्टेड होता है **4.5 संस्करण के बाद से** जबकि `viewStateEncryptionMode` property को `Never` सेट किया गया हो. इसका मतलब है कि नवीनतम .NET Framework संस्करणों में **डिक्रिप्शन कुंजी और उसकी एल्गोरिदम भी आवश्यक होते हैं** एक payload बनाने के लिए.
ASP.NET ViewState में `ViewStateUserKey` property होती है [\[16\]](https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms972969\(v=msdn.10\)) जिसका उपयोग cross-site request forgery (CSRF) हमलों [\[4\]](https://www.owasp.org/index.php/Anti\_CSRF\_Tokens\_ASP.NET) के जोखिम को कम करने के लिए किया जा सकता है. **`ViewStateUserKey`** property की मान (जब यह `null` नहीं होती है**) ViewState साइनिंग** प्रक्रिया के दौरान भी उपयोग की जाती है. यह पैरामीटर की मान न जानने से हमारे हमले को रोक सकती है, **इसकी मान अक्सर कुकीज़ या एक छिपी हुई इनपुट** पैरामीटर में पाई जा सकती है ([\[17\]](https://software-security.sans.org/developer-how-to/developer-guide-csrf) में एक लागू उदाहरण दिखाता है).
YSoSerial.Net मास्टर और YSoSerial.Netv2 में आपको एक प्लगइन मिलेगा ([**यह**](https://github.com/pwntester/ysoserial.net/blob/master/ysoserial/Plugins/ViewStatePlugin.cs) और [**यह**](https://github.com/pwntester/ysoserial.net/blob/v2/ysoserial/Plugins/ViewStatePlugin.cs)) जो इस तकनीक का उपयोग करने के लिए जानकारी जब सभी जानकारी उपलब्ध होती है.
_यह डिफ़ॉल्ट रूप से ActivitySurrogateSelector गैजेट का उपयोग करता है जो YSoSerial.Net प्रोजेक्ट में ExploitClass.cs कक्षा को कंपाइल करने की आवश्यकता होती है। ViewState payload को भी **एन्क्रिप्ट किया जा सकता है****WAFs से बचने के लिए जब decryptionKey मान्यता वाला होता है**:_
**नोट:** YSoSerial.Net में उपयोग किए गए गैजेट्स की प्रकृति के कारण, लक्षित ASP.NET पेज हमेशा त्रुटि के साथ प्रतिक्रिया करता है, यहां तक कि जब सर्वर-साइड पर सफलतापूर्वक एक शोषण किया जाता है।
यदि आप IIS में वर्चुअल डायरेक्टरी और एप्लिकेशन शब्दों के बारे में अवगत नहीं हैं, तो आप [\[20\]](https://docs.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis) देख सकते हैं।
यदि हमें पता नहीं होता कि "app2" एक एप्लिकेशन नाम है, तो हम **प्रयोग और त्रुटि का उपयोग करके URL में सभी निर्देशिका नामों की परीक्षा कर सकते हैं** एक-एक करके, जब तक हम एक ViewState नहीं मिलता जो सर्वर पर कोड को निष्पादित कर सकता है (शायद DNS अनुरोध प्राप्त करके या देरी का कारण बनाकर)।
इस मामले में, `--जेनरेटर` तर्क का उपयोग किया जा सकता है। `--isdebug` तर्क का उपयोग किया जा सकता है ताकि जब `--पथ` और `--apppath` तर्क प्रदान किए गए हों, तो प्लगइन भी वही गणक `__VIEWSTATEGENERATOR` पैरामीटर की गणना करता है या नहीं।
.NET Framework v4.0 या उससे नीचे का उपयोग करने वाले एप्लिकेशनों को शोषित करने के लिए, YSoSerial.Net v2.0 शाखा [\[21\]](https://github.com/nccgroup/VulnerableDotNetHTTPRemoting/tree/master/ysoserial.net-v2) का उपयोग किया जा सकता है (यह पहले से ही एक अन्य शोध [\[22\]](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2019/march/finding-and-exploiting-.net-remoting-over-http-using-deserialisation/) के हिस्से के रूप में विकसित किया गया था)। हालांकि, इस परियोजना में केवल कुछ संख्या के गैजेट्स का समर्थन होता है, और इसके लिए लक्ष्य बॉक्स में .NET Framework 3.5 या उससे ऊपर स्थापित होना आवश्यक होता है।
ऐसा लगता है कि Immunity Canvas, जब ज्ञात होते हैं तो वे वैधीकरण और एन्क्रिप्शन कुंजी का उपयोग करके ViewState पैरामीटर बना सकता है [\[29\]](https://vimeopro.com/user18478112/canvas/video/260982761)। निम्नलिखित उपकरणों को भी यही समय पर जारी किया गया था जब मैं अपना काम प्रकाशित करने के बारे में सोच रहा था, जो काफी आश्चर्यजनक था:
मुझे लगता है कि ये उपकरण वर्तमान में **.NET के विभिन्न संस्करणों में अंतर नहीं करते हैं** और पुरानी गुप्तिलिपि को लक्ष्य बनाते हैं। इसके अलावा, ये **`ViewStateUserKey`** पैरामीटर का उपयोग नहीं करते हैं जो CSRF हमलों को रोकने के लिए उपयोग में हो सकता है।
पहले ही कहा गया है कि .NET Framework 4.0 और नीचे के संस्करणों (v2.0 से v4.0 पर परीक्षण किया गया) को शोषित करते समय `__VIEWSTATE` पैरामीटर को एन्क्रिप्ट करने की आवश्यकता नहीं होती है, यहां तक कि जब `ViewStateEncryptionMode` संपत्ति को `Always` सेट किया गया हो। ASP.NET यह निर्धारित करता है कि क्या ViewState एन्क्रिप्ट किया गया है या नहीं, अनुरोध में `__VIEWSTATEENCRYPTED` पैरामीटर को खोजकर (इसके पास कोई मान होने की आवश्यकता नहीं होती है)। इसलिए, एक अनएन्क्रिप्टेड ViewStated को भेजने के लिए `__VIEWSTATEENCRYPTED` पैरामीटर को अनुरोध से हटा कर भेजा जा सकता है।
यह भी इसका मतलब है कि जब प्रमाणीकरण कुंजी या इसके एल्गोरिदम को बदलने के बावजूद जब जासूसी कुंजी और इसके एल्गोरिदम को चोरी कर लिया गया हो, तो हमलों को रोकने के लिए नहीं रोक सकता है।
जब एक अवैध `__VIEWSTATE` पैरामीटर का उपयोग किया जाता है, तो एक ASP.NET पेज त्रुटि प्रदर्शित करता है। हालांकि, पृष्ठ अपने इनपुट प्राप्त कर सकता है जब कोड के लिए सीधे `Request.Form` का उपयोग किया जाता है, उदाहरण के लिए `Request.Form["txtMyInput"]` का उपयोग करके `txtMyInput.Text` के बजाय। **CSRF हमला उस अनुरोध से `__VIEWSTATE` पैरामीटर को हटाकर या अवैध मान के साथ `__PREVIOUSPAGE` पैरामीटर ज
जब `__EVENTVALIDATION` पैरामीटर को उपयोग करके अभिक्षम किया जाता है, तो अनुरोध में `__VIEWSTATE` पैरामीटर की मान खाली हो सकती है, लेकिन यह मौजूद होना चाहिए।
.NET Framework 4.5 और उससे ऊपर का उपयोग करने के लिए `Purpose` स्ट्रिंग का उपयोग करता है जो एक मान्य हस्ताक्षर बनाने के लिए उपयोग किया जाता है, जो पैरामीटर के आधार पर अलग होता है। निम्नलिखित तालिका में .NET Framework में परिभाषित `Purpose` स्ट्रिंग दिखाई गई है:
जब अनुरोध में **`__PREVIOUSPAGE`** पैरामीटर मौजूद होता है और उसमें **अमान्य** डेटा होता है, तो **एप्लिकेशन****`__VIEWSTATE`** पैरामीटर को **डिसीरियलाइज़** नहीं करता है। `__CALLBACKID` पैरामीटर प्रदान करने से इस व्यवहार को रोका जा सकता है।
पहले से बताया गया है कि कभी-कभी हम यह जांचने के लिए त्रुटियों का उपयोग करते हैं कि क्या एक उत्पन्न ViewState मान्य है। ASP.NET एक अमान्य `__VIEWSTATEGENERATOR` पैरामीटर का उपयोग करने पर डिफ़ॉल्ट रूप से MAC सत्यापन त्रुटि नहीं दिखाता है। यह व्यवहार बदल जाता है जब `ViewStateUserKey` संपत्ति का उपयोग किया जाता है, क्योंकि ASP.NET अब MAC सत्यापन त्रुटियों को दबाने की कोशिश नहीं करेगा।
इसके अलावा, ASP.NET वेब एप्लिकेशन `ViewStateUserKey` संपत्ति का उपयोग करते हुए भी निम्नलिखित सेटिंग के साथ MAC सत्यापन त्रुटियों को नजरअंदाज कर सकती है:
यदि हमलावर एक अनुप्रयोग की मूल रूट में **`web.config`** को **बदल सकते हैं**, तो वे सर्वर पर कोड को **आसानी से चला सकते हैं**। हालांकि, एक हमलावर के लिए अनुप्रयोग पर एक छिपी हुई पिछवाड़ा सम्मिलित करना एक अच्छा विकल्प हो सकता है। इसे **MAC सत्यापन को अक्षम करके** और `viewStateEncryptionMode` संपत्ति को `Always` सेट करके किया जा सकता है। इसका मतलब है कि सभी ASP.NET पेज जो `ViewStateEncryptionMode` संपत्ति को `Auto` या `Never` सेट नहीं करते हैं, हमेशा एन्क्रिप्टेड ViewState पैरामीटर का उपयोग करते हैं। हालांकि, **ViewState MAC सत्यापन सुविधा का उपयोग न करने के कारण, वे अब अविश्वसनीय डेटा के द्वारा दूरस्थ कोड निष्पादन के प्रति संवेदनशील हो गए हैं**। निम्नलिखित एक उदाहरण दिखाता है:
यह ध्यान देना चाहिए कि `EnableViewState` संपत्ति को `False` पर सेट करने से यह हमला रोका नहीं जा सकता है क्योंकि ASP.NET द्वारा अभी भी ViewState को पार्स किया जाएगा।
- क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने की अनुमति** चाहिए? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
- **अपने हैकिंग ट्रिक्स को [hacktricks रेपो](https://github.com/carlospolop/hacktricks) और [hacktricks-cloud रेपो](https://github.com/carlospolop/hacktricks-cloud) में पीआर जमा करके साझा करें।**
