मज़े और जेल की सज़ा तक ले जाने वाली IIS सर्वर reconnaissance

 (mll.sh)
2 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • IIS का डिफॉल्ट पेज बंद गली नहीं, बल्कि bug bounty reconnaissance की शुरुआत हो सकता है; Shodan, Google dork, और response headers की मदद से exposed servers और छिपे vhost को संकुचित किया जा सकता है
  • HTTP/1.0 request, HTTPAPI 2.0 404, SSL certificate, और Host header brute-forcing internal IP, Exchange hostname, और virtual host खोजने के शुरुआती संकेत बन सकते हैं
  • IIS की DOS 8.3 आधारित tilde shortname enumeration directory listing बंद होने पर भी छोटे file/directory names उजागर कर सकती है, और GitHub search, BigQuery, LLM, तथा crunch से पूरे नाम के candidates का अनुमान लगाया जा सकता है
  • IIS/.NET-विशिष्ट fuzzing में web.config, trace.axd, elmah.axd, appsettings.*.json, .aspx/.ashx/.asmx/.config जैसे high-value paths और extensions को पहले निशाना बनाया जाता है
  • web.config exposure, cookieless session path normalization, reverse proxy path confusion, NTFS alternate data stream, upload extension bypass, और HPP यह दिखाते हैं कि misconfiguration और legacy behavior attack surface में बदल सकते हैं

IIS सर्वर खोजने के reconnaissance तरीके

  • IIS targets को पहले search engines और internet asset search services में खोजा जा सकता है
  • Shodan query target domain के SSL certificate, organization name, और http.title:"IIS" के संयोजन से IIS servers को संकुचित करती है
    • उदाहरण targets में staging servers, भुला दिए गए admin panels, और internet पर exposed internal tools शामिल हो सकते हैं
    • Shodan के अलावा fofa, censys, netlas, और odin भी अलग-अलग internet indexes प्रदान करते हैं
  • Google dorking का उपयोग indexed pages में IIS के संकेत खोजने के लिए होता है
    • aspnet_client folder और _vti_bin को IIS संकेत माना जाता है
    • ext:aspx ASP.NET pages खोजता है और उसके पीछे IIS होने का संकेत देता है
    • site:*.target.com, site:*.*.target.com जैसे wildcard searches सामान्य subdomain enumeration से छूटे nested subdomains खोजने में उपयोगी होते हैं
  • Response headers IIS पहचानने का सबसे आसान संकेत हैं
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • बड़े पैमाने पर जांच के लिए httpx या nuclei से IIS targets की सूची बनाई जा सकती है

IIS की पुष्टि के बाद मिलने वाले शुरुआती संकेत

  • कुछ IIS configurations, खासकर Exchange या OWA fronts, HTTP/1.0 requests पर internal information उजागर कर सकते हैं
  • Location header में https://192.168.5.237/owa/ जैसे internal IP हो सकते हैं
  • X-FEServer header Exchange server का internal hostname प्रकट कर सकता है
  • यह जानकारी आगे के चरणों में काम आने वाले information disclosure में बदल सकती है

Automation और छिपे virtual host ढूँढना

  • IIS targets की सूची मिल जाने के बाद nuclei को microsoft, windows, asp, aspx, iis, azure, config, exposure जैसे tags के साथ चलाकर दोहराए जाने वाले काम कम किए जा सकते हैं
  • HTTPAPI 2.0 404 का मतलब हमेशा यह नहीं होता कि वास्तव में वहाँ कुछ नहीं है
    • हो सकता है IIS instance किसी खास virtual host से bind हो, और request का Host header मेल न खाने पर 404 मिले
  • छिपे vhost खोजने के दो तरीके हैं
    • SSL certificate के subject या SAN fields से आवश्यक hostname निकालना
    • अगर certificate मदद न करे तो ffuf और Host header wordlist से vhost brute-force करना
  • सही hostname मिल जाने पर सामान्य 404 के बजाय असली application response दे सकती है

IIS tilde shortname enumeration

  • IIS पुराने DOS 8.3 filename rules से जुड़े behavior के कारण विशेष requests से files और directories के छोटे नाम enumerate कर सकता है
  • Directory listing disabled होने पर भी WEB~1.CON, GLOBAL~1.ASA, SITEBA~1.ZIP, ADMIN~1 जैसे टुकड़े उजागर हो सकते हैं
  • shortscan IIS shortname enumeration के लिए इस्तेमाल होने वाला tool है
  • burp’s IIS Tilde Enumeration Scanner भी एक विकल्प है
  • छोटे नामों को पूरे filenames में बदलने के कई तरीके हैं
    • LLM: shortname fragments को शामिल करने वाले संभावित filename candidates बनाना
    • GitHub code search: ~1 से पहले के पहले 6 अक्षरों और extension के आधार पर असली filenames खोजना
    • GSNW: shortname fragments लेकर GitHub code search से matching filenames इकट्ठा करता है
    • GitHub-IIS-Shortname-Generator: समान तरीके से wordlist बनाता है
    • shortnameguesser: scanner output से कई sources को query करके target wordlist बनाता है
  • BigQuery तरीका Google BigQuery के public GitHub dataset में shortname patterns से मेल खाने वाले file paths खोजता है
    • SITEBA~1.ZIP के लिए sitebackup.zip, sitebase.zip जैसे वास्तविक project filename candidates मिल सकते हैं
    • यह तरीका Assetnote की IIS hidden files BigQuery research से प्रेरित है
  • अगर LLM, GitHub, BigQuery विफल हों, तो crunch से बचे हुए string combinations की wordlist बनाकर ffuf से आज़माया जा सकता है
    • hyphen, underscore, URL-encoded space, और बिना separator वाले filename variants भी साथ में जांचे जाते हैं
    • Windows filenames में spaces की अनुमति देता है और IIS भी उन्हें serve कर सकता है

IIS/.NET-विशिष्ट fuzzing

  • सिर्फ सामान्य wordlists पर निर्भर रहने से IIS/.NET ecosystem की विशिष्ट files और endpoints छूट सकते हैं
  • पहले जांचने लायक high-value targets में ये शामिल हैं
    • /web.config, /web.config.bak, /web.config.old, /web.config.txt
    • /global.asax
    • /trace.axd
    • /elmah.axd
    • /connectionstrings.config
    • /appsettings.json, /appsettings.Development.json, /appsettings.Staging.json, /appsettings.Production.json, /appsettings.Local.json
    • /secrets.json
    • /WS_FTP.LOG
    • /_vti_pvt/service.cnf
  • trace.axd ASP.NET trace viewer है; अगर enabled हो तो headers, cookies, और कभी-कभी credentials सहित request/response logs उजागर हो सकते हैं
  • elmah.axd ऐसा debug endpoint हो सकता है जिसे developers ने disable नहीं किया हो, और यह error logs दिखा सकता है
  • IIS-विशिष्ट extension fuzzing targets में .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json शामिल हैं
  • उपयोगी wordlists में ये शामिल हैं
    • secLists IIS.txt: इसमें basic IIS paths, common handlers, और legacy files शामिल हैं
    • orwa’s iis.txt: इसे वास्तविक bug bounty programs में इस्तेमाल की गई IIS list के रूप में बताया गया है
    • orwa’s aspx.txt: यह .aspx endpoints-केंद्रित सूची है
    • wfuzz iis.txt: ज्ञात vulnerable IIS paths पर केंद्रित छोटी सूची
    • dirbuster-ng iis.txt: IIS-विशिष्ट कमजोरियों को निशाना बनाने वाली compact सूची
    • Assetnote wordlists: वास्तविक crawling data से auto-generate की जाती हैं, हर महीने update होती हैं, और ASP तथा ASPX lists की सिफारिश की जाती है
    • OneListForAll: onelistforallshort.txt target runs के लिए, और पूरी सूची लंबे runs के लिए उपयोगी है
  • IIS case-sensitive नहीं है, इसलिए mixed-case wordlists duplicate requests बना सकती हैं
    • lower-case lists का उपयोग करना या tr '[:upper:]' '[:lower:]' | sort -u से normalize करना आम तरीका है

web.config और code exposure

  • अगर web.config को path traversal, गलत तरीके से exposed backup files, या shortname-आधारित discovery से पढ़ा जा सके, तो IIS targets पर इसका असर बड़ा हो सकता है
  • IIS web.config में ViewState signing और encryption में इस्तेमाल होने वाली machine keys हो सकती हैं
  • machine keys मिलने पर malicious serialized ViewState payload forge करके deserialization-आधारित remote code execution तक पहुँचा जा सकता है
  • ysoserial.net key उपलब्ध होने पर payload generation में मदद करता है
  • अगर file download या file read parameter हो, तो ../../web.config और उसके URL-encoded variants आज़माने की दिशा में आगे बढ़ा जा सकता है
  • ASP.NET का legacy cookieless session feature (S(X)) जैसे session tokens को URL path में डाल सकता है
    • IIS path normalization के दौरान उस segment को हटाकर /bin directory access block को bypass कर सकता है
    • Newtonsoft.Json.dll अपने-आप में एक basic library है, इसलिए ज़रूरी नहीं कि उसमें application secrets हों
    • लेकिन अगर वास्तविक application DLL मिल जाए, तो dotPeek या dnSpy से decompile करके hardcoded credentials, API keys, internal endpoint logic, और custom authentication implementations देखी जा सकती हैं

Path normalization, NTFS, upload, और WAF bypass

  • जब IIS reverse proxy के पीछे हो या खुद reverse proxy की भूमिका निभा रहा हो, तो path normalization differences access control bypass में बदल सकती हैं
    • proxy encoded path को अलग resource मानकर आगे भेज सकता है, जबकि IIS %2f को / में decode कर traversal समझकर protected path serve कर सकता है
  • IIS 7.5 और समान versions में NTFS alternate data streams और index allocation behavior के कारण basic authentication bypass संभव हो सकता है
    • authentication module protected path के रूप में नहीं पहचानता, लेकिन file system उसे वास्तविक directory की तरह interpret कर सकता है
  • file upload features में .aspx, .asp blocked होने पर भी IIS द्वारा default रूप से HTML के रूप में serve किए जाने वाले extensions से stored XSS संभव हो सकता है
    • HTML rendering extensions के उदाहरण: .cer, .hxt, .htm
    • XML-आधारित XSS vector extensions के उदाहरण: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • IIS filename के अंत में लगे dot को हटा सकता है, इसलिए shell.aspx., shell.aspx.., shell.aspx... जैसे upload filter bypass संभव हो सकते हैं
  • server-side includes targets के लिए .stm, .shtm, .shtml extensions सुझाए गए हैं
  • जब WAF payload block करे, तो HTTP Parameter Pollution से duplicate parameters में payload को बाँटकर भेजा जा सकता है
    • IIS और ASP.NET डिफॉल्ट रूप से duplicate parameter values को comma से जोड़ते हैं, और WAF के पीछे payload दोबारा assembled हो सकता है

IIS bug bounty से मिलने वाले सबक और संसाधन

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियाँ

  • हर honeypot के सामने IIS landing page लगाने की वजह ही यही है कि blackhat लोग उसकी तरफ खिंचे चले आते हैं
    यह सोचकर ही बड़ी खुशी होती है कि वे अपनी ही पूँछ पकड़ने में घंटों बर्बाद कर चुके होंगे

    • वहीं क्यों रुकें, सामने सचमुच का IIS server रखो, फिर honeypot को matryoshka dolls की तरह परत-दर-परत लगाओ और देखो वे कितनी दूर तक घुसते हैं
    • अगर मौजूदा संगठन के IP range पर honeypot नहीं चला रहे, तो आखिर में मिलता सिर्फ bot traffic ही है
      ऊपर के blackhat बड़े targets के पीछे जाते हैं, और नीचे वाले Shodan पर मिले आसान शिकार या खुद खोजे गए application zero-day पर ध्यान देते हैं
    • Noise सच में security की बहुत कम आंकी गई layer है
    • मैंने Plex और Nintendo Switch ports खोल दिए थे, तो scans पागलों की तरह आने लगे
      अगर port scanners को परेशान करने के और तरीके हों, तो उनके बारे में और जानना चाहूँगा
    • aspnet_client/admin.php जैसी URL बनाकर उस पर WebObjects headers लौटाना भी एक अच्छा शौक हो सकता है

  • “IIS में पुराने DOS 8.3 filename rules से विरासत में मिला legacy behavior है” — क्या इसका मतलब यह है कि, IIS document root का default रूप से C:\Inetpub होना मिलकर underlying operating system behavior को उजागर कर देता है?
    Windows 10/11 में C drive पर 8.3 filenames default रूप से enabled हैं, लेकिन दूसरी drives पर default रूप से disabled हैं
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C: पर 8dot3 name creation is ENABLED, और fsutil 8dot3name query U: पर DISABLED आता है

    • थोड़ा अलग मुद्दा है, लेकिन याद आया कि Windows update ने “protection hardening” जैसी धुंधली वजह बताकर servers के अलावा हर PC पर c:\inetpub बना दिया था
      https://www.pcworld.com/article/2684062/why-is-windows-11-la...
    • इस विषय पर मूल research यहाँ है: https://soroush.me/downloadable/microsoft_iis_tilde_characte...
    • Windows 10 मशीन पर DisplayVersion command ने जवाब नहीं दिया, और पुराने versions जैसे LTSC में शायद नीचे की तरह ReleaseId इस्तेमाल करना पड़ता है
      (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId → 1809

  • लेख की writing style काफ़ी अजीब है

    • मुझे कई बार लगा कि क्या यह Claude ने लिखा है

  • वाह, इससे तो पुरानी यादें ताज़ा हो गईं
    एक समय था जब IIS scanners इतने ज़्यादा थे कि server logs लगभग बेकार हो जाते थे
    एक directory traversal vulnerability थी जिसमें बस ../ को URL encode करना होता था, और उसने कई महीनों तक पूरे internet को जला कर रख दिया था

    • ऐसे traversal attempts आज भी PHP/WordPress script kiddie attacks के साथ-साथ बेहद आम दिखते हैं

  • क्या अभी भी कहीं IIS इस्तेमाल होता है?

    • होता है। Windows Server और IIS इस्तेमाल करने पर मशीन domain-joined होती है, और आमतौर पर HOST/MACHINE.DOMAIN जैसी SPN होती है
      Windows services और IIS App Pool Identity, (g)MSA या virtual accounts (NT Service*) से log in करते हैं, इसलिए 30/60/90 दिन के password rotation को हाथ से संभाले बिना managed Kerberos environment ठीक से चल जाता है
      MS SQL Server में Kerberos से log in करना, और दूसरे webapps के OAuth2 flow में भी Kerberos से log in करना — सब कुछ स्वाभाविक रूप से काम करता है
      default Windows shell से WinRM भी बिना खास setup के चल जाता है, और तकनीकी रूप से 2FA को bypass भी कर सकता है, क्योंकि व्यवहार में यह ऐसे ही काम करता है
      Linux पर भी यह संभव है, लेकिन ठीक से configure होने की संभावना workplace के हिसाब से बदलती है, और मेरे अनुभव में अब तक बहुत ज़्यादा नहीं रही
    • corporate IT departments में आज भी बहुत ज़्यादा इस्तेमाल होता है
    • मैं अक्सर उन लोगों से बात करता हूँ जो अब भी Windows Server पर IIS चला रहे हैं
      पुराने apps सच में बहुत हैं, और उनमें से कई काफ़ी महत्वपूर्ण भी हैं
    • कुछ banks अब भी IIS इस्तेमाल करते हैं
      अगर कोई enterprise इतना बड़ा है कि intranet चलाता हो, तो कहीं न कहीं, शायद हर जगह IIS चल रहा होगा
      यह AD के साथ बहुत अच्छी तरह integrate होता है, इसलिए काफ़ी जटिल काम भी बेहिसाब आसान हो जाते हैं
      दुनिया AWS की ओर शिफ्ट होने से इसका इस्तेमाल कम हुआ है, लेकिन वह भी आखिर एक vendor के proprietary product (Amazon) से बंध जाना ही है, इसलिए वही मूर्खता है। बस फ़र्क इतना है कि इस बार hardware भी आपका अपना नहीं है
      public sector IT को IIS पसंद है। किसी local government tax या real estate website को देखें, तो अच्छी संभावना है कि वहाँ .aspx scripts भरे पड़े हों
      मैंने इसे यूरोप के public sector webapps में भी देखा है, और SQL Server backend वाले custom .NET applications अक्सर पूरी local government चलाते हैं
      एशिया, खासकर चीन और ताइवान, IIS को पसंद करते दिखे, और वे इसका इस्तेमाल हर तरह की hosting के लिए करते लगे
      दुनिया ज़्यादातर आगे बढ़ चुकी है, यह सही है, लेकिन शहरों और महत्वपूर्ण संस्थाओं को चलाने वाला बहुत सारा legacy code अभी भी IIS पर पड़ा है और शायद बदलेगा नहीं
      अगर आपको यह बुरा लगता है, तो अभी भी वेब पर AS/400, Lotus Notes, और Novell GroupWise चलाने वाली जगहें मौजूद हैं
    • सही बात। और एक अनजान आदमी की तरह पूछूँ तो, आजकल फिर इस्तेमाल क्या करना चाहिए?
      मान लीजिए कोई छोटी कंपनी enterprise .NET Framework code बनाती है, सब कुछ Windows है, customers cloud अपनाना नहीं चाहते, SOAP अब भी मुख्यधारा में है, और अकेले IT admin के पास 2010 के बाद क्या हुआ यह जानने का भी समय नहीं है
      पूरा rewrite व्यावहारिक नहीं है, security का कुछ फ़ायदा चाहिए, लेकिन settings में गहराई तक जाने की क्षमता नहीं है, और Kubernetes जैसी जटिल चीज़ पर दाँव भी नहीं लगाया जा सकता

  • nginx पर भी ऐसा analysis post देखना चाहूँगा

  • पूरे desktop browser के हिसाब से design सच में बहुत अच्छा है, और content भी बढ़िया है

    • पता नहीं यह तंज़ है या नहीं, लेकिन मेरे desktop browser में sidebar main panel पर चढ़ जाती है और text के ऊपर text आ जाता है
      फिर भी, उसके अलावा बाकी presentation मुझे पसंद आई
    • “बढ़िया” कहना 2000 के शुरुआती दौर के script kiddie स्तर की सामग्री के लिए कुछ ज़्यादा ही उदारता है
      लेखक को शायद अभी यह सीखना बाकी है कि सभ्यता कितनी हद तक उन लोगों पर टिकी है जो बिना किसी खास वजह एक-दूसरे के साथ बुरा व्यवहार नहीं करते

  • समझ नहीं आता कि बाईं sidebar main text के ऊपर क्यों चढ़ रही है