यह नई ASP.NET सुरक्षा भेद्यता कितनी गंभीर है और मैं इसे कैसे हल कर सकता हूं?

Question

मैंने ASP.NET में एक नए खोजे गए सुरक्षा भेद्यता के बारे में नेट पर पढ़ा है। आप यहां विवरण पढ़ सकते हैं।

समस्या यह है कि ASP.NET एईएस एन्क्रिप्शन एल्गोरिथ्म को लागू करता है कुकीज़ की अखंडता की रक्षा के लिए ये एप्लिकेशन उपयोगकर्ता सत्रों के बारे में जानकारी संग्रहीत करने के लिए उत्पन्न करते हैं।

यह थोड़ा अस्पष्ट है, लेकिन यहाँ एक और भयावह हिस्सा है:

हमले का पहला चरण कुछ हज़ार अनुरोधों को लेता है, लेकिन एक बार जब यह सफल हो जाता है और हमलावर को गुप्त कुंजी मिल जाती है, तो यह पूरी तरह से गुप्त है। क्रिप्टोग्राफ़िक ज्ञान की आवश्यकता बहुत ही बुनियादी है।

सभी में, मैं यह जानने के लिए पर्याप्त सुरक्षा / क्रिप्टोग्रैपी विषय से परिचित नहीं हूं कि क्या यह वास्तव में गंभीर है।

तो, क्या सभी ASP.NET डेवलपर्स को इस तकनीक से डरना चाहिए जो सेकंड या किसी भी ASP.NET वेबसाइट का मालिक हो सकता है ?

यह समस्या औसत ASP.NET डेवलपर को कैसे प्रभावित करती है? क्या यह हमें बिल्कुल प्रभावित करता है? वास्तविक जीवन में, इस भेद्यता के परिणाम क्या हैं? और, अंत में: क्या कुछ समाधान है जो इस भेद्यता को रोकता है?

आपके उत्तर के लिए धन्यवाद!

---

संपादित करें: मुझे मिली प्रतिक्रियाओं को संक्षेप में बताऊँ

तो, यह मूल रूप से एक "पैडिंग ओरेकल" प्रकार का हमला है। @ श्री ने इस प्रकार के हमले का क्या मतलब है, इसके बारे में एक शानदार विवरण प्रदान किया। यहाँ इस मुद्दे के बारे में एक चौंकाने वाला वीडियो है!

इस भेद्यता की गंभीरता के बारे में: हां, यह वास्तव में गंभीर है। यह हमलावर को किसी एप्लिकेशन की मशीन कुंजी जानने की अनुमति देता है। इस प्रकार, वह कुछ बहुत ही अवांछित चीजें कर सकता है ।

• ऐप की मशीन कुंजी के कब्जे में, हमलावर प्रमाणीकरण कुकीज़ को डिक्रिप्ट कर सकता है।
• इससे भी बदतर, वह किसी भी उपयोगकर्ता के नाम के साथ प्रमाणीकरण कुकीज़ उत्पन्न कर सकता है । इस प्रकार, वह साइट पर किसी के रूप में दिखाई दे सकता है। एप्लिकेशन आपके या उस हैकर के बीच अंतर करने में असमर्थ है जिसने अपने लिए अपने नाम के साथ एक प्रमाणीकरण कुकी उत्पन्न की है।
• यह उसे सत्र कुकीज़ को डिक्रिप्ट (और उत्पन्न) करने की भी अनुमति देता है , हालांकि यह पिछले एक की तरह खतरनाक नहीं है।
• इतना गंभीर नहीं: वह पृष्ठों के एन्क्रिप्टेड ViewState को डिक्रिप्ट कर सकता है। (यदि आप विश्वासपात्र डेटा संग्रहीत करने के लिए ViewState का उपयोग करते हैं, तो आपको यह वैसे भी नहीं करना चाहिए!)
• काफी अनपेक्षित : मशीन कुंजी के ज्ञान के साथ, हमलावर आपके वेब एप्लिकेशन से कोई भी मनमानी फ़ाइल डाउनलोड कर सकता है , यहां तक ​​कि वे भी जो सामान्य रूप से डाउनलोड नहीं किए जा सकते हैं! ( Web.Config , आदि सहित )

यहाँ मुझे मिली अच्छी प्रथाओं का एक समूह है जो इस मुद्दे को हल नहीं करता है लेकिन वेब एप्लिकेशन की सामान्य सुरक्षा को बेहतर बनाने में मदद करता है।

• आप संरक्षित कॉन्फ़िगरेशन के साथ संवेदनशील डेटा को एन्क्रिप्ट कर सकते हैं
• HTTP केवल कुकीज़ का उपयोग करें
• DoS हमलों को रोकें

अब, आइए इस मुद्दे पर ध्यान दें।

• स्कॉट गुथ्री ने अपने ब्लॉग पर इसके बारे में एक प्रविष्टि प्रकाशित की
• स्कॉटगू की FAQ ब्लॉग पोस्ट भेद्यता के बारे में है
• स्कॉटगू की भेद्यता पर अद्यतन
• Microsoft के पास इसके बारे में एक सुरक्षा सलाह है
• भेद्यता को समझना
• भेद्यता के बारे में अतिरिक्त जानकारी

समाधान

• CustomErrors सक्षम करें और एक एकल त्रुटि पृष्ठ बनाएं जिसमें सभी त्रुटियों को पुनर्निर्देशित किया गया है। हां, 404 भी । (स्कॉटग्यू ने कहा कि इस हमले के लिए 404 और 500 के बीच अंतर करना आवश्यक है।) इसके अलावा, आपके कोड में Application_Errorया Error.aspxकुछ कोड डालते हैं जो एक यादृच्छिक देरी करता है। (एक यादृच्छिक संख्या उत्पन्न करें, और उस लंबे समय तक सोने के लिए Thread.Sleep का उपयोग करें।) इससे हमलावर को यह तय करना असंभव हो जाएगा कि आपके सर्वर पर वास्तव में क्या हुआ था।
• कुछ लोगों ने 3 डीईएस पर वापस जाने की सिफारिश की। सिद्धांत रूप में, यदि आप एईएस का उपयोग नहीं करते हैं, तो आप एईएस कार्यान्वयन में सुरक्षा कमजोरी का सामना नहीं करते हैं। जैसा कि यह पता चला है, यह बिल्कुल अनुशंसित नहीं है ।

कुछ अन्य विचार

• ऐसा लगता है कि सभी को नहीं लगता कि वर्कअराउंड काफी अच्छा है।

मेरे सवाल का जवाब देने वाले सभी को धन्यवाद। मैंने न केवल इस मुद्दे के बारे में बहुत कुछ सीखा, लेकिन सामान्य रूप से वेब सुरक्षा। मैंने @ मिकेल के उत्तर को स्वीकार के रूप में चिह्नित किया है, लेकिन अन्य उत्तर भी बहुत उपयोगी हैं।

Comments

वेनेमो, क्या मैं सिर्फ इतना कह सकता हूं कि मुझे नहीं लगता कि यह इस अनुरोध के लिए एक अच्छी जगह है (जवाबों को देखते हुए)। मतदान इस प्रश्न को हल करने का एक अच्छा तरीका नहीं है, इसका जवाब एक विशेषज्ञ द्वारा दिया जाना चाहिए (और आपको मतदान करने के लिए विशेषज्ञ होने की आवश्यकता नहीं है)। मेरा सुझाव है: mail-archive.com/[e-mail]/maillist.html या, जैसा कि नीचे किसी ने बताया है, Microsoft की आधिकारिक टिप्पणी है, जो क्लाइंट को कोई त्रुटि संदेश नहीं भेजना है। यह सही तरीका है। 3DES के लिए डाउनग्रेड न करें। यह चौंकाने वाली सलाह है।

— दोपहर रेशम

MS से अधिक: blogs.technet.com/b/srd/archive/2010/09/17/…

— bobince

@ RPM1984 - मैं सहमत नहीं हूँ। यहाँ बहुत प्रयोग करने योग्य प्रतिक्रियाएँ हैं। @Dan, क्यों?

— वेनमो

ठीक है, हमारे पास SO पर एक प्रश्न की अलग व्याख्या है। मेरे लिए, अगर यह सही ढंग से उत्तर दिया जा सकता है, तो ठीक है। उत्तर दिलचस्प / सहायक हैं, मुझे गलत मत समझो, लेकिन यह मेरे लिए एक मुद्दा है जहां केवल "उत्तर" एक समाधान है - जब तक कि एमएस एक रिलीज को ठीक नहीं करता। मेरे लिए, यह एक विकी होना चाहिए।

— RPM1984

यदि कोई व्यक्ति इस थ्रेड पर वापस आता है, तो सुरक्षा फिक्स की तलाश में, वे microsoft.com/technet/security/bulletin/MS10-070.mspx (अपना OS और .NET संस्करण चुनें) पर स्थित हैं।

— एंडी

Answer 1

अपनी रक्षा के लिए मुझे क्या करना चाहिए?

[अद्यतन २०१०-०९ -२९]

Microsoft सुरक्षा बुलेटिन

तय के संदर्भ में KB आलेख

स्कॉटगू के डाउनलोड के लिए लिंक हैं

[अद्यतन २०१०-०९ -२५]

जब हम ठीक होने का इंतजार कर रहे हैं, कल स्कॉटगू ने अपडेट किया कि कैसे कस्टम URLScan नियम के साथ अपनी साइटों की सुरक्षा के लिए एक अतिरिक्त कदम जोड़ा जाए।

---

मूल रूप से सुनिश्चित करें कि आप एक कस्टम त्रुटि पृष्ठ प्रदान करते हैं ताकि एक हमलावर आंतरिक .Net त्रुटियों के संपर्क में न आए, जिसे आपको हमेशा रिलीज / उत्पादन मोड में रखना चाहिए।

इसके अतिरिक्त, हमलावर पृष्ठ पर आक्रमण की जानकारी के लिए प्रतिक्रियाओं को समय से रोकने के लिए त्रुटि पृष्ठ में एक यादृच्छिक समय नींद जोड़ें ।

Web.config में

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

यह 200 स्थिति कोड के साथ लौटे कस्टम पेज पर किसी भी त्रुटि को पुनर्निर्देशित करेगा। इस तरह एक हमलावर आगे के हमलों के लिए आवश्यक जानकारी के लिए त्रुटि कोड या त्रुटि जानकारी को नहीं देख सकता है।

यह सेट करना भी सुरक्षित है customErrors mode="RemoteOnly", क्योंकि यह "वास्तविक" क्लाइंट को रीडायरेक्ट करेगा। केवल लोकलहोस्ट से ब्राउज़ करने पर आंतरिक .Net त्रुटियाँ दिखाई देंगी।

महत्वपूर्ण हिस्सा यह सुनिश्चित करना है कि सभी त्रुटियों को एक ही त्रुटि पृष्ठ पर लौटने के लिए कॉन्फ़िगर किया गया है। इसके लिए आपको अनुभाग defaultRedirectपर विशेषता को स्पष्ट रूप से सेट करना होगा <customErrors>और यह सुनिश्चित करना होगा कि कोई भी प्रति-स्थिति कोड निर्धारित न हो।

दांव पर क्या है?

यदि कोई हमलावर उल्लिखित कारनामे का उपयोग करने का प्रबंधन करता है, तो वह आपके वेब एप्लिकेशन से आंतरिक फ़ाइलों को डाउनलोड कर सकता है। आमतौर पर web.config एक लक्ष्य है और इसमें डेटाबेस कनेक्शन स्ट्रिंग में लॉगिन जानकारी, या यहां तक ​​कि एक स्वचालित sql-express डेटाबेस से लिंक जैसी संवेदनशील जानकारी हो सकती है, जिसे आप किसी को पकड़ना नहीं चाहते हैं। लेकिन अगर आप सबसे अच्छा अभ्यास कर रहे हैं तो आप अपने web.config में सभी संवेदनशील डेटा को एन्क्रिप्ट करने के लिए संरक्षित कॉन्फ़िगरेशन का उपयोग करते हैं।

संदर्भ के लिए लिंक

Http://www.microsoft.com/technet/security/advisory/2416728.mspx पर भेद्यता के बारे में Microsoft की आधिकारिक टिप्पणी पढ़ें । विशेष रूप से इस मुद्दे पर कार्यान्वयन विवरण के लिए "समाधान" भाग।

स्कॉटगू के ब्लॉग पर भी कुछ जानकारी , अपने वेब सर्वर पर असुरक्षित ASP.Net एप्लिकेशन खोजने के लिए एक स्क्रिप्ट सहित ।

"अंडरस्टैंडिंग पैडिंग ओरेकल अटैक्स" पर स्पष्टीकरण के लिए, @ श्री का उत्तर पढ़ें ।

---

लेख के लिए टिप्पणियाँ:

एएसपी.नेट ऐप्स के खिलाफ रेज़ियो और डुओंग ने जो हमला किया है, उसके लिए ज़रूरी है कि वेब साइट पर क्रिप्टो कार्यान्वयन के लिए एक ऑरेकल हो, जो कि सिफरटेक्स्ट भेजे जाने पर, न केवल पाठ को डिक्रिप्ट करेगा, बल्कि भेजने वाले को इस बारे में एक संदेश देगा कि सिफरटेक्स्ट में पैडिंग है या नहीं। मान्य है ।

यदि पैडिंग अमान्य है, तो प्रेषक को मिलने वाला त्रुटि संदेश उसे साइट की डिक्रिप्शन प्रक्रिया के काम करने के तरीके के बारे में कुछ जानकारी देगा।

हमले के लिए निम्नलिखित काम करने के लिए सही होना चाहिए:

• आपके आवेदन को पैडिंग अमान्य होने के बारे में एक त्रुटि संदेश देना होगा।
• किसी को आपके एन्क्रिप्टेड कुकीज या व्यूस्टेट के साथ छेड़छाड़ करनी चाहिए

इसलिए, यदि आप अपने ऐप में मानव पठनीय त्रुटि संदेश लौटाते हैं जैसे "कुछ गलत हुआ, कृपया फिर से प्रयास करें" तो आपको बहुत सुरक्षित होना चाहिए। लेख पर टिप्पणियों पर थोड़ा पढ़ना भी बहुमूल्य जानकारी देता है।

• क्रिप्टेड कुकी में एक सत्र आईडी स्टोर करें
• सत्र स्थिति में वास्तविक डेटा संग्रहीत करें (db में जारी)
• त्रुटि वापस करने से पहले उपयोगकर्ता की जानकारी गलत होने पर एक यादृच्छिक प्रतीक्षा जोड़ें, ताकि आप इसे समय नहीं दे सकें

इस तरह से एक अपहृत कुकी का उपयोग केवल एक सत्र को पुनः प्राप्त करने के लिए किया जा सकता है, जिसकी सबसे अधिक संभावना अब मौजूद या अमान्य नहीं है।

यह देखना दिलचस्प होगा कि वास्तव में एकोपार्टी सम्मेलन में क्या प्रस्तुत किया गया है, लेकिन अभी मैं इस भेद्यता के बारे में बहुत चिंतित नहीं हूं।

Comments

@Venemo। प्रतिक्रिया का शीर्षक। कूकीज। एड। (नया एचटीटीपीसी ("भूमिका", "एडमिन")); आप ऐसा करेंगे: string sessionId = Guid.NewGuid ()। ToString (); सत्र [sessionId] = "भूमिका = व्यवस्थापक"; प्रतिक्रिया। कूकीज। जोड़ें (नया HttpCookie ("s", sessionId)); और हमले को क्रिप्टो करने के लिए प्रतिक्रियाओं के समय को मापने के लिए अतिसंवेदनशील है। तो एक प्रतिक्रिया के अंत में एक Thread.Sleep (...) जोड़ें, ऐसे समय को रोक देगा। त्रुटि के रूप में मैं मानता हूं (और यह लगभग निश्चित है) यह एक ऐप त्रुटि है, लेकिन इसे स्वयं कुछ का परीक्षण करने की आवश्यकता है। इसलिए कस्टम त्रुटि पेज होने से गद्दी त्रुटि नहीं दिखेगी।

— मिकेल स्वेन्सन

@ मिकेल, धन्यवाद! वैसे भी, एक कुकी में भूमिकाओं को संग्रहीत करने के लिए क्या अर्थ होगा? अगर मैं उपयोग करता हूं तो क्या मैं सुरक्षित हूं Roles.AddUserToRole("Joe", "Admin")लेकिन मैं वास्तव में कुकी में स्टोर नहीं करता हूं?

— वेनमो

@Venemo: मेरा संपादन और ब्लॉग पोस्ट का लिंक पढ़ें। आमतौर पर फ़ॉर्म लॉगिन साइट कुकी में भूमिका को संग्रहीत करती है, लेकिन जैसा कि @Arisos ने अपनी प्रतिक्रिया में उल्लेख किया है, इसे बंद किया जा सकता है, और इसे बंद कर दिया जाना चाहिए।

— मिकेल स्वेनसन

पृथ्वी पर क्या ...; 3DES के लिए डाउनग्रेड न करें, यह बिल्कुल भी मदद नहीं करेगा, और वास्तव में बुरी सलाह है।

— दोपहर रेशम

@ मिकेल आप स्कॉटगू के ब्लॉग का लिंक भी जोड़ सकते हैं, जिसमें कुछ अतिरिक्त जानकारी है: weblogs.asp.net/scottgu/archive/2010/09/18/…

— Eilon

Answer 2

पेडिंग ओरेकल हमलों को समझना

मान लें कि आपका एप्लिकेशन एक एन्क्रिप्टेड स्ट्रिंग को एक पैरामीटर के रूप में स्वीकार करता है - चाहे पैरामीटर एक कुकी हो, एक url पैरामीटर या कुछ और ही सार है। जब एप्लिकेशन इसे डीकोड करने की कोशिश करता है, तो 3 संभावित परिणाम हैं -

1. परिणाम 1 : एन्क्रिप्टेड स्ट्रिंग को ठीक से डिक्रिप्ट किया गया था, और एप्लिकेशन इसके बारे में समझ बनाने में सक्षम था। मतलब, अगर एन्क्रिप्ट किया गया स्ट्रिंग 10 अंकों का खाता नंबर था, तो डिक्रिप्शन के बाद एप्लिकेशन को "1234567890" और "abcd1213ef" जैसा कुछ नहीं मिला।

2. परिणाम 2 : पैडिंग सही थी, लेकिन डिक्रिप्शन के बाद प्राप्त स्ट्रिंग में खिंचाव था जिसे ऐप समझ नहीं सका। उदाहरण के लिए, स्ट्रिंग को "abcd1213ef" में डिक्रिप्ट किया गया था, लेकिन ऐप केवल संख्या की उम्मीद कर रहा था। अधिकांश एप्लिकेशन "अमान्य खाता संख्या" जैसे संदेश दिखाएंगे।

3. परिणाम 3 : पैडिंग गलत थी, और एप्लिकेशन ने किसी प्रकार का त्रुटि संदेश फेंक दिया था। अधिकांश ऐप एक सामान्य संदेश दिखाएंगे जैसे "कुछ त्रुटि हुई"।

एक पेडिंग ओरेकल हमले को सफल बनाने के लिए, हमलावर को कई हजारों अनुरोध करने में सक्षम होना चाहिए , और त्रुटि के बिना उपरोक्त 3 बाल्टी में से एक में प्रतिक्रिया को वर्गीकृत करने में सक्षम होना चाहिए।

यदि ये दोनों स्थितियां पूरी हो जाती हैं, तो हमलावर अंततः संदेश को डिक्रिप्ट कर सकता है, और फिर वह जो चाहे उसके साथ फिर से एन्क्रिप्ट कर सकता है। यह सिर्फ समय का सवाल है।

इसे रोकने के लिए क्या किया जा सकता है?

1. सबसे सरल बात - संवेदनशील कुछ भी कभी भी ग्राहक को नहीं भेजा जाना चाहिए, एन्क्रिप्टेड या कोई एन्क्रिप्टेड नहीं। इसे सर्वर पर रखें।

2. सुनिश्चित करें कि उपरोक्त सूची में परिणाम 2 और परिणाम 3 हमलावर के समान ही दिखाई देते हैं । एक से दूसरे का पता लगाने का कोई तरीका नहीं होना चाहिए। यह सब इतना आसान नहीं है, हालांकि - एक हमलावर किसी प्रकार के समय के हमले का उपयोग कर भेदभाव कर सकता है।

3. रक्षा की अंतिम पंक्ति के रूप में, एक वेब अनुप्रयोग फ़ायरवॉल है। पैडिंग ओरेकल हमले को कई अनुरोध करने की आवश्यकता है जो लगभग समान दिखते हैं (एक समय में एक बिट को बदलते हुए), इसलिए इस तरह के अनुरोधों को पकड़ने और ब्लॉक करने के लिए एक WAF के लिए संभव होना चाहिए।

PS इस ब्लॉग पोस्ट में पेडिंग ओरेकल हमलों का एक अच्छा विवरण पाया जा सकता है । अस्वीकरण: यह मेरा ब्लॉग नहीं है।

Comments

+1 महान स्पष्टीकरण, धन्यवाद! एक प्रश्न: "यह सुनिश्चित करें कि उपरोक्त सूची में परिणाम 2 और परिणाम 3 हमलावर के समान ही दिखाई देते हैं।" -> मैं ASP.NET में इसे कैसे प्राप्त कर सकता हूं?

— वेनमो

उन्हें एक ही प्रदर्शित करने के लिए, आपको परिणाम त्रुटि संदेश 2 और 3 के लिए आउटपुट करना चाहिए, जिसका अर्थ है अधिक सामान्य त्रुटि। इस तरह से उन्हें विभेदित नहीं किया जा सकता है। एक अच्छी त्रुटि हो सकती है: "एक त्रुटि हुई, कृपया पुनः प्रयास करें"। दोष यह हो सकता है कि आप उपयोगकर्ता को कम जानकारी वाले संदेश दें।

— मिकेल स्वेन्सन

तो यह कैसे लोगों को web.config डाउनलोड करने देता है ??

— डैनियल लिटिल

@Lavinski - अभी तक कोई स्पष्ट जानकारी नहीं है, लेकिन यह माना जाता है कि WebResource.axd आपको सही कुंजी देने पर web.config (और अन्य संसाधन) डाउनलोड करने की अनुमति देता है। और कुंजी को उत्पन्न करने के लिए, किसी को गद्दी की आवश्यकता होती है।

— श्रीपति कृष्णन

Answer 3

अब तक जो मैंने पढ़ा उससे ...

हमले से किसी को सूँघी हुई कुकीज़ को डिक्रिप्ट करने की अनुमति मिलती है, जिसमें बैंक बैलेंस जैसे मूल्यवान डेटा हो सकते हैं

उन्हें किसी ऐसे उपयोगकर्ता की एन्क्रिप्टेड कुकी की आवश्यकता होती है जो पहले से ही किसी भी खाते में लॉग इन किया गया हो। उन्हें कुकीज़ में डेटा खोजने की भी आवश्यकता है - मुझे उम्मीद है कि डेवलपर्स कुकीज़ में महत्वपूर्ण डेटा को स्टोर नहीं करते हैं :)। और एक तरीका यह है कि मेरे पास लॉगिन कुकी में डेटा को asp.net स्टोर डेटा न करने के लिए नीचे है।

कोई व्यक्ति किसी उपयोगकर्ता की कुकी कैसे प्राप्त कर सकता है जो ऑनलाइन है यदि वह ब्राउज़र डेटा पर अपने हाथ नहीं लाता है? या आईपी पैकेट सूँघो?

इसे रोकने का एक तरीका यह है कि कुकीज़ को ssl एन्क्रिप्शन के बिना परिवहन की अनुमति न दें।

<httpCookies httpOnlyCookies="true" requireSSL="true" />

इसके अलावा एक और उपाय कुकीज़ में रोल्स को रोकने के लिए है।

<roleManager enabled="true" cacheRolesInCookie="false">

अब उन कुकीज़ के बारे में जो नियमित पृष्ठों के लिए सुरक्षित नहीं हैं, इसके लिए कुछ और सोच की ज़रूरत है कि आपने अपने उपयोगकर्ता को क्या छोड़ा है और क्या नहीं, आप कैसे उस पर भरोसा करते हैं, आप क्या अतिरिक्त जांच कर सकते हैं (उदाहरण के लिए अगर आप आईपी पर बदलाव देखते हैं , शायद उस पर भरोसा करना बंद कर दें, जब तक कि सुरक्षा पृष्ठ से पुनर्जन्म न हो जाए)।

संदर्भ:
क्या कोई हैकर किसी उपयोगकर्ता से कुकी चुरा सकता है और वेब साइट पर उस नाम से लॉगिन कर सकता है?

कैसे जांच करें कि हमले कहां से आते हैं और वापस नहीं देते। मैंने यहां लिखा है कि पेडिंग को रोकने के लिए एक सरल तरीका अमान्य है और हमलावरों को ट्रैक करने के लिए उसी समय लॉगिंग कर रहा है: CryptographicException: पैडिंग अमान्य है और इसे हटाया नहीं जा सकता है और व्यूस्टेट मेट की मान्यता विफल हुई

हमलावर को ट्रैक करने का तरीका पैडिंग की जांच करना अमान्य है। एक सरल प्रक्रिया के साथ आप उन्हें ट्रैक कर सकते हैं और उन्हें ब्लॉक कर सकते हैं - कुंजी खोजने के लिए उन्हें आपके पेज पर कुछ हजारों कॉल की आवश्यकता है!

अपडेट १।

मेरे पास वह टूल डाउनलोड है जो मान लेता है कि कुंजी को ढूंढ रहा है और डेटा को डिक्रिप्ट करता है, और जैसा कि मैं ऊपर दिए गए कोड पर इसके जाल को कहता हूं जो कि व्यूस्टेट की जांच करता है । मेरे परीक्षणों से इस उपकरण को ठीक करने के लिए और भी बहुत कुछ है, उदाहरण के लिए संकुचित दृश्य स्थिति को स्कैन नहीं कर सकता है क्योंकि यह मेरे परीक्षणों पर क्रैश है।

यदि कोई इस उपकरण या इस पद्धति का उपयोग करने का प्रयास करता है, तो उपरोक्त कोड उन्हें नीचे ट्रैक कर सकता है और आप उन्हें अपने पृष्ठ से इस सरल कोड की तरह ब्लॉक कर सकते हैं जैसे "सेवा रोकना (डॉस) रोकना" , या इनकार को रोकने के लिए इस कोड की तरह सेवा की ।

अपडेट २

इसका ऐसा लगता है कि मैंने अब तक जो भी पढ़ा है , केवल यही लगता है कि त्रुटि के बारे में जानकारी वापस न देने के लिए वास्तव में इसकी आवश्यकता है , और बस एक कस्टम त्रुटि पृष्ठ रखें और यदि आप चाहें तो बस इस पृष्ठ पर एक यादृच्छिक विलंब कर सकते हैं।

इस मुद्दे पर एक बहुत ही दिलचस्प वीडियो ।

तो उपरोक्त सभी अधिक सुरक्षा के लिए इसके अधिक उपाय लेकिन इस विशेष मुद्दे के लिए 100% आवश्यक नहीं। उदाहरण के लिए ssl कुकी का उपयोग करने के लिए सूँघना समस्या को हल करना है, न कि कुकीज़ को रोल्स को कुकीज़ में भेजना और इसे बड़ी कुकीज़ को वापस नहीं भेजना अच्छा है, और कुछ से बचने के लिए जो सभी तैयार दरार कोड हैं, बस व्यवस्थापक भूमिका को स्थान पर रखें। उसी की कुकी।

व्यूस्टेट ने हमले को खोजने के लिए इसके सिर्फ एक और उपाय को ट्रैक किया।

Comments

Aristos, इसलिए, आखिरकार, यह बहुत ज्यादा किसी भी अन्य सामान्य कुकी-चोरी-आधारित विधि की तरह दिखता है, है ना? तो वे क्यों कहते हैं कि यह गंभीर है?

— वेनमो

@ वेनमो क्योंकि अगर वे वास्तव में उस कुंजी को प्राप्त कर सकते हैं, तो शायद किसी भी पृष्ठ पर डेटा पर पोस्ट पर कुछ और नुकसान कर सकते हैं क्योंकि वे उस सुरक्षा को तोड़ते हैं ... यह गंभीर है लेकिन इसके लिए अगले चरण और वास्तविक पर ले जाना असंभव है सिस्टम पर ब्रेक। उदाहरण के लिए इस साइट mypetfriend.gr की अनुमति देता है sql इंजेक्शन। लेकिन क्या आप इसे तोड़ सकते हैं? भले ही सुरक्षा इतनी कम हो?

— अरिस्तोस

@ वेनमो मुझे लगता है कि अंतिम रैपराउंड कि आप इस हमले पर विशिष्ट पूछते हैं नीचे ट्रैक करने और आईपीएस को लॉक करना है जो कि उत्पाद को सामान्य से अधिक पैडिंग करता है! (और यह वह है जो मैं अगले दिनों में तय करने जा रहा हूं) :)

— अरस्तू

@ अरिस्तोस - मैंने आपके द्वारा जुड़े अन्य प्रश्न का उत्तर पढ़ा। हालांकि यह Viewstate से संबंधित है। चूंकि मैं ASP.NET MVC का उपयोग करता हूं, इसलिए मैं ViewState का उपयोग नहीं करता हूं। और मैं यह पता नहीं लगा सका कि यह विवरण इस सुरक्षा मुद्दे पर कैसे अनुवाद करता है?

— वेनमो

@ वीवीसी एमवीसी के लिए मैं नहीं कह सकता क्योंकि मुझे नहीं पता। ViewState वह हिस्सा है जो कुंजी खोजने के लिए हमला करता है। MVC उस पृष्ठ की अखंडता को ट्रैक करता है जिसे मैं नहीं जानता।

— अरस्तू

Answer 4

यहाँ एमएस प्रतिक्रिया है। यह सब "कस्टम त्रुटि पृष्ठ का उपयोग करने" के लिए उबलता है और आप किसी भी सुराग को दूर नहीं करेंगे।

EDIT
यहाँ scottgu से कुछ अधिक विस्तृत जानकारी है।

Comments

धन्यवाद, यह वही है जो मैं सभी से पूछ रहा हूं। तो मूल रूप से एक साधारण कस्टम त्रुटि पृष्ठ मुझे इस भेद्यता के सभी निहितार्थों से बचा सकता है?

— वेनमो

@ वेनेमो: हां, और 3 डीईएस की सिफारिश करने वाले लोगों को वास्तव में चुप कराया जाना चाहिए; यह अविश्वसनीय रूप से गैर जिम्मेदाराना है और मुख्य मुद्दे को संबोधित भी नहीं करता है! यह काफी चौंकाने वाला है। कृपया, मुझे आशा है कि कोई भी उनकी सलाह का पालन नहीं करता है और वह करता है जो Microsoft अधिकारी सलाह देता है।

— दोपहर रेशम

@ नून - ठीक है, इस प्रकार का कस्टम एरर पेज किसी भी प्रोडक्शन साइट के लिए होना चाहिए, इसलिए जैसा कि यह पता चला है, यह इस्स्यू इतना गंभीर नहीं है । :)

— वेनमो

Answer 5

Http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx पर चर्चा से ली गई स्कॉटग्यू की प्रतिक्रियाओं को जोड़ना

क्या कस्टम के बजाय कस्टम IHttpModule प्रभावित हुआ है?

प्रश्न: मेरे पास मेरे web.config में घोषित तत्व नहीं है, मेरे पास अनुभाग के अंदर IHttpModule है। यह मॉड्यूल त्रुटि को लॉग करता है और किसी खोज पृष्ठ (404 के लिए) या त्रुटि पृष्ठ (500 के लिए) पर रीडायरेक्ट करता है। क्या मैं असुरक्षित हूं?

उ: मैं अस्थायी रूप से मॉड्यूल को हमेशा खोज पृष्ठ पर पुनर्निर्देशित करने के लिए अद्यतन करने की सलाह दूंगा। इस हमले का एक तरीका यह है कि 404 और 500 त्रुटियों के बीच विभेदीकरण दिखता है। हमेशा एक ही एचटीटीपी कोड को वापस करना और उन्हें एक ही जगह पर भेजना, इसे ब्लॉक करने में मदद करने का एक तरीका है।

ध्यान दें कि जब पैच इसे ठीक करने के लिए निकलता है, तो आपको ऐसा करने की आवश्यकता नहीं होगी (और पुराने व्यवहार पर वापस लौट सकते हैं)। लेकिन अभी मैं ग्राहकों के लिए 404s और 500s के बीच अंतर न करने की सलाह दूंगा।

क्या मैं 404 और 500 त्रुटियों के लिए विभिन्न त्रुटियों का उपयोग जारी रख सकता हूं?

प्रश्न: मुझे लगता है कि हम अभी भी एक कस्टम 404 पृष्ठ को परिभाषित कर सकते हैं, जो त्रुटि पर डिफ़ॉल्ट पुनर्निर्देशित के अलावा परिभाषित है, ऊपर वर्णित सिद्धांतों का उल्लंघन किए बिना?

ए: नहीं - जब तक हम वास्तविक फिक्स के लिए एक पैच जारी नहीं करते हैं, हम उपरोक्त वर्कअराउंड की अनुशंसा करते हैं जो सभी त्रुटियों को समरूप करता है। इस हमले का एक तरीका यह है कि 404 और 500 त्रुटियों के बीच विभेदीकरण दिखता है। हमेशा एक ही एचटीटीपी कोड को वापस करना और उन्हें एक ही जगह पर भेजना, इसे ब्लॉक करने में मदद करने का एक तरीका है।

ध्यान दें कि जब पैच इसे ठीक करने के लिए निकलता है, तो आपको ऐसा करने की आवश्यकता नहीं होगी (और पुराने व्यवहार पर वापस लौट सकते हैं)। लेकिन अभी आपको ग्राहकों के लिए 404s और 500s के बीच अंतर नहीं करना चाहिए।

यह web.config के प्रदर्शन की अनुमति कैसे देता है?

प्रश्न: यह web.config के प्रदर्शन की अनुमति कैसे देता है? यह केवल ViewState के डिक्रिप्टिंग को सक्षम करने के लिए लगता है, क्या कोई अन्य संबंधित भेद्यता है जो जानकारी के प्रकटीकरण की भी अनुमति देता है? क्या एक श्वेतपत्र है जो हमले के बारे में बेहतर विवरण के लिए हमले का विवरण देता है?

A: जनता पर जो हमला दिखाया गया था, वह ASP.NET में एक विशेषता पर निर्भर करता है जो फ़ाइलों (आमतौर पर जावास्क्रिप्ट और सीएसएस) को डाउनलोड करने की अनुमति देता है, और जिसे एक कुंजी के साथ सुरक्षित किया जाता है जिसे अनुरोध के भाग के रूप में भेजा जाता है। दुर्भाग्य से यदि आप एक कुंजी बनाने में सक्षम हैं, तो आप इस सुविधा का उपयोग किसी एप्लिकेशन की वेब.कॉन्फ़िग फ़ाइल (लेकिन एप्लिकेशन के बाहर की फ़ाइलें नहीं) को डाउनलोड करने के लिए कर सकते हैं। हम स्पष्ट रूप से इसके लिए एक पैच जारी करेंगे - तब तक उपरोक्त वर्कअराउंड अटैक वेक्टर को बंद कर देता है।

संपादित करें: http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx पर दूसरे ब्लॉगपोस्ट में उपलब्ध अतिरिक्त FAQ

Comments

दूसरे प्रश्न का उत्तर दो तारांकन के साथ समाप्त होता है। क्या कुछ फुटनोट या क्वालीफायर टेक्स्ट को कहीं जोड़ा गया है?

— स्कॉट मिशेल

@ स्कॉट मिशेल: नहीं, यह केवल मेरा टाइपो है। (पाठ का हिस्सा पोस्ट के पहले संस्करण में बोल्ड था और जब पाठ संपादित किया गया था तो मैं सभी फ़ॉर्मेटिंग कोड को निकालना भूल गया था)। फिक्स्ड। आपको गुमराह करने के लिए क्षमा करें।

— मार्टिन वोब्र

Answer 6

IMO, इसके लिए कोई संपूर्ण बोर्ड रोकथाम नहीं है, इसे केस-दर-मामला आधार पर संभालने की आवश्यकता है:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Answer 7

कुछ महत्वपूर्ण लिंक:

• MS 'सुरक्षा सलाहकार 2416728 (यह आधिकारिक सूचना है)
• एमएस 'सुरक्षा अनुसंधान और रक्षा टीम से अतिरिक्त जानकारी
  • "ASP.NET भेद्यता को समझना" (2010-09-17)
  • "ASP.NET भेद्यता के बारे में अतिरिक्त जानकारी" (2010-09-20)
• स्कॉट गु: "महत्वपूर्ण: ASP.NET सुरक्षा कमजोरता" (2010-09-18)

[इस के गंभीर पहलू का जवाब देने के लिए (जो प्रकाशित किया गया है और वर्कअराउंड अन्य उत्तरों द्वारा कवर किया गया है)।]

हमला की जाने वाली कुंजी का उपयोग दृश्य स्थिति और सत्र कुकीज़ दोनों की सुरक्षा के लिए किया जाता है। आम तौर पर यह कुंजी वेब ऐप के प्रत्येक नए उदाहरण के साथ ASP.NET द्वारा आंतरिक रूप से तैयार की जाती है। यह कार्यकर्ता प्रक्रिया के जीवनकाल में नुकसान की गुंजाइश को सीमित कर देगा, निश्चित रूप से एक व्यस्त आवेदन के लिए यह दिन हो सकता है (यानी एक सीमा से अधिक नहीं)। इस समय के दौरान व्यूअरस्टेट में हमलावर मान बदल सकता है (या इंजेक्ट कर सकता है) और अपना सत्र बदल सकता है।

इससे भी अधिक गंभीरता से अगर आप चाहते हैं कि सत्र कार्यकर्ता प्रक्रिया को जन्म देने में सक्षम हों, या वेब फार्मों की अनुमति दें (अर्थात खेत में सभी उदाहरण किसी भी उपयोगकर्ता सत्र को संभाल सकते हैं) तो हार्ड कोडित होने की आवश्यकता है, यह इसमें किया जाता है web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

वे, निश्चित रूप से, नई बनाई गई कुंजियाँ हैं, मैं विंडोज़ क्रिप्टोग्राफ़िक यादृच्छिक संख्या जनरेटर का उपयोग करने के लिए निम्न पॉवरशेल का उपयोग करता हूं:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(सत्यापन के लिए 20 की एक सरणी लंबाई और डिक्रिप्शन कुंजी के लिए 16 का उपयोग करना।)

विशिष्ट त्रुटि को लीक न करने के लिए सार्वजनिक त्रुटि पृष्ठों को संशोधित करने के साथ-साथ, उपरोक्त कुंजियों (या यदि वे थोड़ी देर से चल रहे हैं तो साइकिल कार्यकर्ता प्रक्रियाओं को बदलने के लिए) एक अच्छा समय लगेगा।

[संपादित करें 2010-09-21: शीर्ष में जोड़े गए लिंक]

Comments

डिफ़ॉल्ट कार्यकर्ता प्रक्रियाओं को 27-29 घंटों के बाद (आपके IIS संस्करण के आधार पर) पुनर्नवीनीकरण किया जाता है यदि वे लंबे समय तक चलते हैं, तो आपको भारी ट्रैफ़िक साइट पर भी दिनों के लिए एक नहीं होना चाहिए।

— 12

Answer 8

मैंने अभी इस मुद्दे पर अतिरिक्त शोध के बाद, अपने ब्लॉग पर इस पर अपनी पूरी पोस्ट पोस्ट की । मुझे लगता है कि इसकी महत्वपूर्ण समाशोधन क्यों वे एक कुकी बनाने के रूप में दूर हो रही है।

---

बस कुछ तथ्यों को सीधे प्राप्त करना चाहते हैं:

1. हमले से आपको मशीन की चाबी सीधे नहीं मिलती। उस ने कहा, इसकी बहुत पसंद थी, क्योंकि यह संदेशों को डिक्रिप्ट करने की अनुमति देता है, और नए लोगों को पुनः एन्क्रिप्ट / संशोधित करता है।
2. जिस तरह से वास्तविक कुंजी प्राप्त होती है वह 1 के रूप में पुनः / एन्क्रिप्ट को संशोधित करने और web.config प्राप्त करने की उनकी क्षमता का उपयोग करके है। दुर्भाग्य से ऐसे कारण हैं कि कुछ ने इन कुंजियों को साइट स्तर (अलग-अलग चर्चा) में web.config में डाल दिया, और नमूना वीडियो में वे DotnetNuke के डिफ़ॉल्ट होने का लाभ उठाते हैं।
3. web.config प्राप्त करने के लिए वहाँ सभी इंगित करते हैं कि वे webresource.axd और / या scriptresource.axd का उपयोग कर रहे हैं। मैंने सोचा कि ये केवल एम्बेडेड संसाधनों के साथ काम करते हैं, लेकिन ऐसा लगता है कि यह सिर्फ मामला नहीं है।
4. अगर एप्लिकेशन asp.net MVC है, तो हमें वास्तव में webresources.axd और / या scriptresources.axd की आवश्यकता नहीं है, इसलिए उन्हें बंद किया जा सकता है। हम व्यूस्टेट का भी उपयोग नहीं करते हैं। उस ने कहा, अगर अन्य asp.net सुविधाओं में से कोई भी जगह में वर्कअराउंड के साथ अलग-अलग जानकारी देता है, तो मुझे यह स्पष्ट नहीं है कि अगर पैडिंग को नजरअंदाज किए गए प्रमाणीकरण टिकट में वैध परिणाम डालते समय त्रुटि का अमान्य परिणाम देता है (पता नहीं) अगर इसका मामला है या नहीं) ... एक ही विश्लेषण सत्र कुकी पर लागू होना चाहिए।
5. कुकीज़ में asp.net सदस्यता प्रदाता 'कैश' की भूमिका, बंद करें।

1 के बारे में, एन्क्रिप्ट किए गए संदेशों को संदेश में कहीं न कहीं कचरे के एक छोटे टुकड़े को सहन करने के लिए 100% मनमाने ढंग से संदेश की आवश्यकता नहीं हो सकती है, क्योंकि संदेश में 1 ब्लॉक है जो मूल्य को डिक्रिप्ट करता है जिसे नियंत्रित नहीं किया जा सकता है।

अंत में मैं यह कहना चाहूंगा कि यह मुद्दा इस मामले में अपने स्वयं के मार्गदर्शन का पालन नहीं करने का नतीजा है: एक विशेषता ग्राहक को भेजे गए कुछ पर निर्भर करती है जो छेड़छाड़ का सबूत है।

---

अधिक:

मुझे नहीं पता कि यदि पैनी नज़र में गलती से अमान्य परिणाम देता है, तो अनदेखा प्रमाणीकरण टिकट में वैध परिणाम डालते हैं (यह नहीं जानते कि क्या है या नहीं) ... एक ही विश्लेषण सत्र कुकी पर लागू होना चाहिए।

ऑर्टिकल कुकी पर हस्ताक्षर किए गए हैं, और कागज में जानकारी से वे एक हस्ताक्षरित कुकी उत्पन्न करने में सक्षम नहीं होना चाहिए, यदि वे वास्तविक कुंजी को प्राप्त नहीं करते हैं (जैसा कि उन्होंने वीडियो को कुकी बनाने से पहले बनाया था)।

जैसा कि अरिस्टोस ने उल्लेख किया है कि कुकी में सत्र आईडी के लिए, यह उपयोगकर्ता सत्र के लिए यादृच्छिक है, इसलिए इसे उपयोगकर्ता से लक्ष्य सुरक्षा स्तर के साथ सूँघना होगा और उस सत्र के सक्रिय होने पर क्रैक किया जाएगा। फिर भी यदि आप उपयोगकर्ता के संचालन को असाइन / अधिकृत करने के लिए प्रमाणीकरण में भरोसा कर रहे हैं, तो प्रभाव न्यूनतम होगा / यह उस ऐप में सत्र के लिए उपयोग किए जाने वाले कार्यों में बहुत कुछ निर्भर करेगा।

Answer 9

इस बग के लिए एक पैच विंडोज अपडेट पर जारी किया गया है: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Answer 10

Asp.Net MVC भी इस समस्या से प्रभावित है (जैसा कि शेयरपॉइंट, ...)

मैंने यहाँ MVC के लिए फिक्स को कवर किया है: ASP.NET MVC ओरेकल पैडिंग अटैक के लिए असुरक्षित है?