IIS - Internet Information Services
परीक्षण निष्पादन योग्य फ़ाइल एक्सटेंशन:
asp
aspx
config
php
आंतरिक IP पता लीक
किसी भी IIS सर्वर पर जहाँ आपको 302 मिलता है, आप होस्ट हेडर को हटाने और HTTP/1.0 का उपयोग करने की कोशिश कर सकते हैं और प्रतिक्रिया के अंदर स्थान हेडर आपको आंतरिक IP पते की ओर इंगित कर सकता है:
आंतरिक IP का खुलासा करने वाली प्रतिक्रिया:
Execute .config files
आप .config फ़ाइलें अपलोड कर सकते हैं और उनका उपयोग कोड निष्पादित करने के लिए कर सकते हैं। इसे करने का एक तरीका फ़ाइल के अंत में HTML टिप्पणी के अंदर कोड जोड़ना है: Download example here
इस भेद्यता का शोषण करने के लिए अधिक जानकारी और तकनीकें यहाँ हैं।
IIS Discovery Bruteforce
मैंने जो सूची बनाई है उसे डाउनलोड करें:
यह निम्नलिखित सूचियों की सामग्री को मिलाकर बनाई गई थी:
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
इसे बिना किसी एक्सटेंशन के उपयोग करें, जिन फ़ाइलों को इसकी आवश्यकता है, उनमें पहले से ही है।
Path Traversal
Leaking source code
पूर्ण लेखन की जांच करें: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html
संक्षेप में, एप्लिकेशन के फ़ोल्डरों के अंदर कई web.config फ़ाइलें हैं जिनमें "assemblyIdentity" फ़ाइलों और "namespaces" के संदर्भ हैं। इस जानकारी के साथ यह जानना संभव है कि executables कहाँ स्थित हैं और उन्हें डाउनलोड करें। डाउनलोड की गई Dlls से यह भी संभव है कि नए namespaces खोजें जहाँ आपको पहुँचने का प्रयास करना चाहिए और web.config फ़ाइल प्राप्त करनी चाहिए ताकि नए namespaces और assemblyIdentity मिल सकें। इसके अलावा, फ़ाइलें connectionstrings.config और global.asax दिलचस्प जानकारी रख सकती हैं।\
.Net MVC अनुप्रयोगों में, web.config फ़ाइल एक महत्वपूर्ण भूमिका निभाती है, जो प्रत्येक बाइनरी फ़ाइल को निर्दिष्ट करती है जिस पर एप्लिकेशन निर्भर करता है "assemblyIdentity" XML टैग के माध्यम से।
Exploring Binary Files
web.config फ़ाइल तक पहुँचने का एक उदाहरण नीचे दिखाया गया है:
यह अनुरोध विभिन्न सेटिंग्स और निर्भरताओं को प्रकट करता है, जैसे:
EntityFramework संस्करण
AppSettings वेबपेज, क्लाइंट मान्यता, और JavaScript के लिए
System.web प्रमाणीकरण और रनटाइम के लिए कॉन्फ़िगरेशन
System.webServer मॉड्यूल सेटिंग्स
Runtime असेंबली बाइंडिंग्स कई पुस्तकालयों के लिए जैसे Microsoft.Owin, Newtonsoft.Json, और System.Web.Mvc
ये सेटिंग्स यह संकेत देती हैं कि कुछ फ़ाइलें, जैसे /bin/WebGrease.dll, अनुप्रयोग के /bin फ़ोल्डर के भीतर स्थित हैं।
रूट डायरेक्टरी फ़ाइलें
रूट डायरेक्टरी में पाई जाने वाली फ़ाइलें, जैसे /global.asax और /connectionstrings.config (जो संवेदनशील पासवर्ड रखती है), अनुप्रयोग की कॉन्फ़िगरेशन और संचालन के लिए आवश्यक हैं।
Namespaces और Web.Config
MVC अनुप्रयोग अतिरिक्त web.config फ़ाइलें भी परिभाषित करते हैं विशिष्ट namespaces के लिए ताकि प्रत्येक फ़ाइल में दोहरावदार घोषणाओं से बचा जा सके, जैसा कि एक अन्य web.config डाउनलोड करने के अनुरोध के साथ प्रदर्शित किया गया है:
DLLs डाउनलोड करना
कस्टम नामस्थान का उल्लेख /bin निर्देशिका में मौजूद "WebApplication1" नामक DLL की ओर इशारा करता है। इसके बाद, WebApplication1.dll डाउनलोड करने के लिए एक अनुरोध दिखाया गया है:
यह अन्य आवश्यक DLLs की उपस्थिति का सुझाव देता है, जैसे System.Web.Mvc.dll और System.Web.Optimization.dll, /bin निर्देशिका में।
एक परिदृश्य में जहां एक DLL एक नामस्थान आयात करता है जिसे WebApplication1.Areas.Minded कहा जाता है, एक हमलावर अन्य web.config फ़ाइलों के अस्तित्व का अनुमान लगा सकता है जो पूर्वानुमानित पथों में हैं, जैसे /area-name/Views/, जिसमें विशिष्ट कॉन्फ़िगरेशन और /bin फ़ोल्डर में अन्य DLLs के संदर्भ शामिल हैं। उदाहरण के लिए, /Minded/Views/web.config के लिए एक अनुरोध कॉन्फ़िगरेशन और नामस्थान प्रकट कर सकता है जो एक अन्य DLL, WebApplication1.AdditionalFeatures.dll की उपस्थिति को इंगित करता है।
सामान्य फ़ाइलें
HTTPAPI 2.0 404 Error
यदि आप निम्नलिखित त्रुटि देखते हैं:
इसका मतलब है कि सर्वर ने Host header के अंदर सही डोमेन नाम नहीं प्राप्त किया। वेब पृष्ठ तक पहुँचने के लिए, आप सर्वर द्वारा प्रदत्त SSL Certificate को देख सकते हैं और शायद आप वहां डोमेन/सबडोमेन नाम पा सकते हैं। यदि यह वहाँ नहीं है, तो आपको सही एक को खोजने के लिए VHosts को ब्रूट फोर्स करने की आवश्यकता हो सकती है।
Old IIS vulnerabilities worth looking for
Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure
आप इस technique का उपयोग करके हर खोजे गए फ़ोल्डर के अंदर फोल्डर्स और फ़ाइलों को सूचीबद्ध करने की कोशिश कर सकते हैं (यहां तक कि यदि यह Basic Authentication की आवश्यकता है)। यदि सर्वर कमजोर है, तो इस तकनीक की मुख्य सीमा यह है कि यह प्रत्येक फ़ाइल/फ़ोल्डर के नाम के पहले 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
Basic Authentication bypass
Bypass एक बेसिक ऑथेंटिकेशन (IIS 7.5) को एक्सेस करने की कोशिश करते हुए: /admin:$i30:$INDEX_ALLOCATION/admin.php
या /admin::$INDEX_ALLOCATION/admin.php
आप नए फोल्डर्स खोजने और ऑथेंटिकेशन को bypass करने के लिए इस vulnerability और पिछले वाले को मिश्रित करने की कोशिश कर सकते हैं।
ASP.NET Trace.AXD enabled debugging
ASP.NET में एक डिबगिंग मोड शामिल है और इसका फ़ाइल नाम trace.axd
है।
यह एक निश्चित समय अवधि में एक एप्लिकेशन के लिए किए गए सभी अनुरोधों का बहुत विस्तृत लॉग रखता है।
इस जानकारी में दूरस्थ क्लाइंट IP, सत्र आईडी, सभी अनुरोध और प्रतिक्रिया कुकीज़, भौतिक पथ, स्रोत कोड की जानकारी, और संभावित रूप से उपयोगकर्ता नाम और पासवर्ड भी शामिल होते हैं।
https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F31736688%2F112974448-2690b000-915b-11eb-896c-f41c27c44286.png&width=768&dpr=4&quality=100&sign=2de6df0b&sv=1)
ASPXAUTH Cookie
ASPXAUTH निम्नलिखित जानकारी का उपयोग करता है:
validationKey
(string): हस्ताक्षर सत्यापन के लिए उपयोग करने के लिए हेक्स-कोडित कुंजी।decryptionMethod
(string): (डिफ़ॉल्ट “AES”)।decryptionIV
(string): हेक्स-कोडित प्रारंभिक वेक्टर (शून्य के वेक्टर पर डिफ़ॉल्ट)।decryptionKey
(string): डिक्रिप्शन के लिए उपयोग करने के लिए हेक्स-कोडित कुंजी।
हालांकि, कुछ लोग इन पैरामीटर के डिफ़ॉल्ट मानों का उपयोग करेंगे और कुकी के रूप में उपयोगकर्ता का ईमेल का उपयोग करेंगे। इसलिए, यदि आप एक वेब खोज सकते हैं जो ASPXAUTH कुकी का उपयोग कर रहा है और आप हमले के तहत सर्वर पर उस उपयोगकर्ता के ईमेल के साथ एक उपयोगकर्ता बनाते हैं जिसे आप अनुकरण करना चाहते हैं, तो आप पहले सर्वर में दूसरे सर्वर की कुकी का उपयोग कर सकते हैं और उपयोगकर्ता का अनुकरण कर सकते हैं। यह हमला इस writeup में काम किया।
IIS Authentication Bypass with cached passwords (CVE-2022-30209)
पूर्ण रिपोर्ट यहाँ: कोड में एक बग उपयोगकर्ता द्वारा दिए गए पासवर्ड की सही जांच नहीं करता, इसलिए एक हमलावर जिसका पासवर्ड हैश एक कुंजी पर हिट करता है जो पहले से ही कैश में है, उस उपयोगकर्ता के रूप में लॉगिन करने में सक्षम होगा।
Last updated