IIS - Internet Information Services
परीक्षण एक्जीक्यूटेबल फ़ाइल एक्सटेंशन:
asp
aspx
config
php
आंतरिक आईपी पता फासला
किसी भी IIS सर्वर पर जहां आपको 302 मिलता है, वहां आप Host हेडर को हटाने का प्रयास कर सकते हैं और HTTP/1.0 का उपयोग कर सकते हैं और प्रतिक्रिया के अंदर Location हेडर आपको आंतरिक आईपी पता पर पहुंचा सकता है:
आंतरिक आईपी जानकारी उजागर करने वाला प्रतिक्रिया:
फ़ाइलें .config फ़ाइलें निष्पादित करें
आप .config फ़ाइलें अपलोड कर सकते हैं और इस्तेमाल कर सकते हैं कोड निष्पादित करने के लिए। इसे करने का एक तरीका फ़ाइल के अंत में कोड जोड़ना है जो एचटीएमएल टिप्पणी के भीतर हो: यहाँ उदाहरण डाउनलोड करें
इस विकल्प को उत्पन्न करने और इस भेदभाव का शोधन करने के तकनीकों के बारे में अधिक जानकारी यहाँ
IIS डिस्कवरी ब्रूटफ़ोर्स
मैंने बनाया हुआ सूची डाउनलोड करें:
यह निम्नलिखित सूचियों की सामग्री को मिलाकर बनाया गया था:
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/aspx.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt
किसी भी एक्सटेंशन को जोड़े बिना इसका उपयोग करें, जिन फ़ाइलों की आवश्यकता है, उनमें पहले से ही है।
पथ ट्रावर्सल
स्रोत कोड लीक
पूरी विवरण जांचें: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html
सारांश के रूप में, एप्लिकेशन के फ़ोल्डरों में कई web.config फ़ाइलें हैं जिनमें "assemblyIdentity" फ़ाइलों और "नेमस्पेस" का संदर्भ है। इस जानकारी के साथ कहाँ निष्पादनीय स्थान हैं और उन्हें डाउनलोड करने की संभावना है। डाउनलोड किए गए Dlls से नए नेमस्पेस ढूंढने और पहुंचने की कोशिश करने चाहिए जहां आपको नए नेमस्पेस और assemblyIdentity पाने के लिए web.config फ़ाइल मिल सकती है। इसके अलावा, फ़ाइलें connectionstrings.config और global.asax में दिलचस्प जानकारी हो सकती है।
.Net MVC एप्लिकेशन में, web.config फ़ाइल ने "assemblyIdentity" XML टैग के माध्यम से एप्लिकेशन द्वारा निर्भर किए जाने वाले प्रत्येक बाइनरी फ़ाइल को निर्दिष्ट करने का महत्वपूर्ण भूमिका निभाई है।
बाइनरी फ़ाइलों का अन्वेषण
नीचे दिखाया गया है कि web.config फ़ाइल तक पहुंचने का एक उदाहरण:
यह अनुरोध विभिन्न सेटिंग्स और आवश्यकताओं को प्रकट करता है, जैसे:
EntityFramework संस्करण
AppSettings वेबपेज, क्लाइंट मान्यता, और जावास्क्रिप्ट के लिए
प्रमाणीकरण और रनटाइम के लिए System.web कॉन्फ़िगरेशन
System.webServer मॉड्यूल सेटिंग्स
Microsoft.Owin, Newtonsoft.Json, और System.Web.Mvc जैसी कई पुस्तकालयों के लिए Runtime एसेम्बली बाइंडिंग
ये सेटिंग्स सुझाती हैं कि कुछ फ़ाइलें, जैसे /bin/WebGrease.dll, एप्लिकेशन के /bin फ़ोल्डर में स्थित हैं।
रूट निर्देशिका फ़ाइलें
रूट निर्देशिका में पाई जाने वाली फ़ाइलें, जैसे /global.asax और /connectionstrings.config (जिसमें संवेदनशील पासवर्ड होते हैं), एप्लिकेशन के कॉन्फ़िगरेशन और परिचालन के लिए आवश्यक हैं।
नेमस्पेस और Web.Config
MVC एप्लिकेशन विशेष नेमस्पेस के लिए अतिरिक्त web.config फ़ाइलें परिभाषित करती हैं ताकि प्रत्येक फ़ाइल में दोहराव न हो, जैसे किसी और web.config को डाउनलोड करने के लिए एक अनुरोध के साथ दिखाया गया है:
DLLs डाउनलोड करना
एक कस्टम नेमस्पेस का उल्लेख एक DLL के बारे में संकेत देता है जिसका नाम "WebApplication1" है जो /bin निर्देशिका में मौजूद है। इसके बाद, WebApplication1.dll को डाउनलोड करने का अनुरोध दिखाया गया है:
यह अन्य महत्वपूर्ण DLL की मौजूदगी का सुझाव देता है, जैसे System.Web.Mvc.dll और System.Web.Optimization.dll, /bin निर्देशिका में।
एक स्थिति में जहां एक DLL एक नेमस्पेस आयात करती है जिसे WebApplication1.Areas.Minded कहा जाता है, एक हमलावता अन्य web.config फ़ाइलों की मौजूदगी का अंदाजा लगा सकता है, जैसे /area-name/Views/, विशेष विन्यास और /bin फ़ोल्डर में अन्य DLL को संदर्भित करते हुए। उदाहरण के लिए, /Minded/Views/web.config पर एक अनुरोध वहाँ अन्य DLL, WebApplication1.AdditionalFeatures.dll की मौजूदगी की संकेत देने वाले विन्यास और नेमस्पेस उजागर कर सकता है।
सामान्य फ़ाइलें
से यहाँ
HTTPAPI 2.0 404 त्रुटि
यदि आप निम्नलिखित त्रुटि देखते हैं:
इसका मतलब है कि सर्वर सही डोमेन नाम को Host हेडर के अंदर नहीं प्राप्त किया। वेब पृष्ठ तक पहुंचने के लिए आप सर्वित SSL प्रमाणपत्र की जांच कर सकते हैं और शायद आप वहां डोमेन/सबडोमेन नाम पा सकते हैं। यदि वहां नहीं है तो आपको ब्रूट फ़ोर्स VHosts करने की आवश्यकता हो सकती है जब तक आप सही वाला नहीं मिल जाता।
पुराने IIS सुरक्षादायकताओं में खोज करने लायक
माइक्रोसॉफ्ट IIS टिल्ड वर्ण “~” सुरक्षादायकता/सुविधा – छोटा फ़ाइल/फ़ोल्डर नाम भेद
आप इस तकनीक का उपयोग करके प्रत्येक पाए गए फ़ोल्डर के भीतर फ़ोल्डर और फ़ाइलों की गणना कर सकते हैं (यदि यह बेसिक प्रमाणीकरण की आवश्यकता है)। इस तकनीक की मुख्य सीमा यदि सर्वर वंर्नरबल है तो यह है कि यह केवल प्रत्येक फ़ाइल/फ़ोल्डर के नाम के पहले 6 अक्षर और फ़ाइलों के एक्सटेंशन के पहले 3 अक्षर तक का पता लगा सकता है।
आप इस वर्नरबिलिटी के लिए टेस्ट करने के लिए https://github.com/irsdl/IIS-ShortName-Scanner का उपयोग कर सकते हैं:java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/
मूल शोध: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
आप metasploit भी उपयोग कर सकते हैं: use scanner/http/iis_shortname_scanner
बेसिक प्रमाणीकरण बायपास
बेसिक प्रमाणीकरण को बायपास करें (IIS 7.5) ताकि आप /admin:$i30:$INDEX_ALLOCATION/admin.php
या /admin::$INDEX_ALLOCATION/admin.php
तक पहुंचने का प्रयास कर सकें।
आप इस वर्नरबिलिटी और पिछली वर्नरबिलिटी को मिलाकर नए फ़ोल्डर खोजने और प्रमाणीकरण को बायपास करने की कोशिश कर सकते हैं।
ASP.NET Trace.AXD सक्षम डीबगिंग
ASP.NET में एक डीबगिंग मोड शामिल है और इसका फ़ाइल नाम trace.axd
है।
यह समयावधि के दौरान एक एप्लिकेशन को किए गए सभी अनुरोधों का एक बहुत विस्तृत लॉग रखता है।
यह जानकारी दूरस्थ ग्राहक आईपी, सत्र आईडी, सभी अनुरोध और प्रतिक्रिया कुकीज़, भौतिक पथ, स्रोत कोड जानकारी, और संभावित उपयोक्ता नामों को भी शामिल कर सकती है।
https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/
ASPXAUTH कुकी
ASPXAUTH निम्नलिखित जानकारी का उपयोग करता है:
validationKey
(स्ट्रिंग): हेक्स-एन्कोडेड कुंजी को सिग्नेचर वैधता के लिए उपयोग करने के लिए।decryptionMethod
(स्ट्रिंग): (डिफ़ॉल्ट “AES”)।decryptionIV
(स्ट्रिंग): हेक्स-एन्कोडेड प्रारंभीकरण वेक्टर (जीरोज़ का एक वेक्टर डिफ़ॉल्ट)।decryptionKey
(स्ट्रिंग): डिक्रिप्शन के लिए उपयोग करने के लिए हेक्स-एन्कोडेड कुंजी।
हालांकि, कुछ लोग इन पैरामीटरों के डिफ़ॉल्ट मान का उपयोग करेंगे और उपयोक्ता के ईमेल को कुकी के रूप में उपयोग करेंगे। इसलिए, यदि आप उस वेबसाइट को खोज सकते हैं जो ASPXAUTH कुकी का उपयोग कर रही है और आप हमले के लिए आक्रमण हो रहे सर्वर पर उस उपयोक्ता के ईमेल के साथ एक उपयोक्ता बना सकते हैं, तो आप शायद पहले वाले सर्वर में दूसरे सर्वर से कुकी का उपयोग करके उपयोक्ता का अनुकरण कर सकते हैं। यह हमला इस लेखन में कामयाब रहा।
IIS प्रमाणीकरण बायपास के साथ कैश किए गए पासवर्ड (CVE-2022-30209)
पूरी रिपोर्ट यहाँ: कोड में एक बग ने उपयोक्ता द्वारा दिए गए पासवर्ड की सही जांच नहीं की, इसलिए एक हमलावर जिसका पासवर्ड हैश एक कुंजी को हिट करता है जो पहले से ही कैश में है, उस उपयोक्ता के रूप में लॉगिन कर सकेगा।
Last updated