Race Condition
Last updated
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:
इस तकनीक की गहरी समझ प्राप्त करने के लिए https://portswigger.net/research/smashing-the-state-machine में मूल रिपोर्ट देखें
Race Condition हमलों को बढ़ाना
Race conditions का लाभ उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई अनुरोध एक ही समय में संभाले जाएं, उनकी प्रसंस्करण समय में बहुत कम अंतर के साथ—आदर्श रूप से, 1ms से कम।
यहाँ अनुरोधों को समन्वयित करने के कुछ तकनीकें हैं:
HTTP/2 सिंगल-पैकेट हमला बनाम HTTP/1.1 लास्ट-बाइट समन्वय
HTTP/2: एकल TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर के प्रभाव को कम करता है। हालाँकि, सर्वर-साइड भिन्नताओं के कारण, दो अनुरोध एक सुसंगत race condition शोषण के लिए पर्याप्त नहीं हो सकते हैं।
HTTP/1.1 'लास्ट-बाइट सिंक': 20-30 अनुरोधों के अधिकांश भागों को पूर्व-भेजने की अनुमति देता है, एक छोटे टुकड़े को रोकता है, जिसे फिर एक साथ भेजा जाता है, सर्वर पर समानांतर आगमन प्राप्त करता है।
लास्ट-बाइट सिंक के लिए तैयारी में शामिल हैं:
अंतिम बाइट के बिना हेडर और बॉडी डेटा भेजना, स्ट्रीम को समाप्त किए बिना।
प्रारंभिक भेजने के बाद 100ms के लिए रुकना।
अंतिम फ्रेम को बैच करने के लिए Nagle के एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को अक्षम करना।
कनेक्शन को गर्म करने के लिए पिंग करना।
रोकें गए फ्रेम का अगला भेजना एक ही पैकेट में उनके आगमन का परिणाम होना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो आमतौर पर RC हमलों में शामिल नहीं होती हैं।
सर्वर आर्किटेक्चर के अनुकूलन
लक्ष्य की आर्किटेक्चर को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को अलग तरीके से रूट कर सकते हैं, जो समय को प्रभावित करता है। तुच्छ अनुरोधों के माध्यम से पूर्व-निर्धारित सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है।
सत्र-आधारित लॉकिंग को संभालना
PHP के सत्र हैंडलर जैसे ढांचे सत्र द्वारा अनुरोधों को अनुक्रमित करते हैं, संभावित रूप से कमजोरियों को अस्पष्ट करते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को हल कर सकता है।
दर या संसाधन सीमाओं को पार करना
यदि कनेक्शन गर्म करना प्रभावी नहीं है, तो डमी अनुरोधों की बाढ़ के माध्यम से वेब सर्वर की दर या संसाधन सीमा विलंब को जानबूझकर सक्रिय करना एकल-पैकेट हमले को सुविधाजनक बना सकता है, जिससे सर्वर-साइड विलंब उत्पन्न होता है जो race conditions के लिए अनुकूल है।
हमले के उदाहरण
Tubo Intruder - HTTP2 सिंगल-पैकेट हमला (1 एंडपॉइंट): आप अनुरोध को Turbo intruder (
Extensions->Turbo Intruder->Send to Turbo Intruder) पर भेज सकते हैं, आप अनुरोध में उस मान को बदल सकते हैं जिसे आप%sके लिए ब्रूट फोर्स करना चाहते हैं जैसेcsrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%sऔर फिर ड्रॉप डाउन सेexamples/race-single-packer-attack.pyका चयन करें:
यदि आप विभिन्न मान भेजने जा रहे हैं, तो आप कोड को इस कोड के साथ संशोधित कर सकते हैं जो क्लिपबोर्ड से वर्डलिस्ट का उपयोग करता है:
यदि वेब HTTP2 का समर्थन नहीं करता (केवल HTTP1.1) तो Engine.THREADED या Engine.BURP का उपयोग करें, Engine.BURP2 के बजाय।
Tubo Intruder - HTTP2 एकल-पैकेट हमला (कई एंडपॉइंट): यदि आपको 1 एंडपॉइंट पर एक अनुरोध भेजने की आवश्यकता है और फिर RCE को ट्रिगर करने के लिए अन्य एंडपॉइंट्स पर कई अनुरोध भेजने की आवश्यकता है, तो आप
race-single-packet-attack.pyस्क्रिप्ट को इस तरह बदल सकते हैं:
यह Repeater में Burp Suite के नए 'Send group in parallel' विकल्प के माध्यम से भी उपलब्ध है।
limit-overrun के लिए आप समूह में एक ही अनुरोध 50 बार जोड़ सकते हैं।
connection warming के लिए, आप group के शुरुआत में कुछ अनुरोध जोड़ सकते हैं जो वेब सर्वर के कुछ गैर-स्थिर भाग पर हों।
delaying प्रक्रिया के लिए एक अनुरोध और दूसरे के बीच प्रसंस्करण में 2 उप-राज्य चरणों में, आप दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं।
multi-endpoint RC के लिए, आप request भेजना शुरू कर सकते हैं जो hidden state की ओर जाता है और फिर इसके तुरंत बाद 50 requests जो hidden state का लाभ उठाते हैं।
Automated python script: इस स्क्रिप्ट का लक्ष्य एक उपयोगकर्ता के ईमेल को बदलना है जबकि इसे लगातार सत्यापित किया जा रहा है जब तक कि नए ईमेल का सत्यापन टोकन अंतिम ईमेल पर नहीं पहुंचता (यह इसलिए है क्योंकि कोड में एक RC देखा जा रहा था जहां एक ईमेल को संशोधित करना संभव था लेकिन सत्यापन पुराने पर भेजा गया था क्योंकि ईमेल को इंगित करने वाला चर पहले से पहले वाले के साथ भरा हुआ था)। जब प्राप्त ईमेल में "objetivo" शब्द पाया जाता है, तो हम जानते हैं कि हमें बदले गए ईमेल का सत्यापन टोकन प्राप्त हुआ है और हम हमले को समाप्त कर देते हैं।
Improving Single Packet Attack
मूल शोध में यह बताया गया है कि इस हमले की सीमा 1,500 बाइट्स है। हालाँकि, इस पोस्ट में यह बताया गया है कि कैसे एकल पैकेट हमले की 1,500-बाइट सीमा को IP लेयर फ्रैग्मेंटेशन का उपयोग करके TCP की 65,535 B विंडो सीमा तक बढ़ाया जा सकता है (एकल पैकेट को कई IP पैकेट में विभाजित करना) और उन्हें अलग-अलग क्रम में भेजना, जिससे पैकेट को फिर से इकट्ठा करने से रोका जा सके जब तक सभी टुकड़े सर्वर तक नहीं पहुँच जाते। इस तकनीक ने शोधकर्ता को लगभग 166ms में 10,000 अनुरोध भेजने की अनुमति दी।
ध्यान दें कि हालांकि यह सुधार RC में हमले को अधिक विश्वसनीय बनाता है जिसमें सैकड़ों/हजारों पैकेट एक साथ आने की आवश्यकता होती है, लेकिन इसके कुछ सॉफ़्टवेयर सीमाएँ भी हो सकती हैं। कुछ लोकप्रिय HTTP सर्वर जैसे Apache, Nginx और Go में SETTINGS_MAX_CONCURRENT_STREAMS सेटिंग क्रमशः 100, 128 और 250 है। हालाँकि, अन्य जैसे NodeJS और nghttp2 में यह असीमित है।
इसका मतलब यह है कि Apache एकल TCP कनेक्शन से केवल 100 HTTP कनेक्शनों पर विचार करेगा (इस RC हमले को सीमित करना)।
आप इस तकनीक का उपयोग करते हुए कुछ उदाहरण https://github.com/Ry0taK/first-sequence-sync/tree/main पर पा सकते हैं।
Raw BF
पिछले शोध से पहले कुछ पेलोड्स का उपयोग किया गया था जो बस पैकेट को जितनी जल्दी हो सके भेजने की कोशिश करते थे ताकि एक RC का कारण बन सके।
Repeater: पिछले अनुभाग से उदाहरण देखें।
Intruder: Intruder को request भेजें, Options menu के अंदर threads की संख्या को 30 पर सेट करें, और पेलोड के रूप में Null payloads का चयन करें और 30 उत्पन्न करें।
Turbo Intruder
Python - asyncio
RC Methodology
Limit-overrun / TOCTOU
यह रेस कंडीशन का सबसे बुनियादी प्रकार है जहाँ कमजोरियाँ उन स्थानों पर प्रकट होती हैं जो आपको एक क्रिया करने के लिए कितनी बार सीमित करते हैं। जैसे कि एक वेब स्टोर में एक ही छूट कोड का कई बार उपयोग करना। एक बहुत आसान उदाहरण इस रिपोर्ट या इस बग** में पाया जा सकता है।**
इस प्रकार के हमले के कई रूप हैं, जिनमें शामिल हैं:
एक उपहार कार्ड को कई बार भुनाना
एक उत्पाद को कई बार रेटिंग देना
अपने खाते के बैलेंस से अधिक नकद निकालना या स्थानांतरित करना
एक ही CAPTCHA समाधान का पुन: उपयोग करना
एंटी-ब्रूट-फोर्स दर सीमा को बायपास करना
Hidden substates
जटिल रेस कंडीशनों का शोषण अक्सर छिपे हुए या अनपेक्षित मशीन उप-राज्यों के साथ बातचीत करने के लिए संक्षिप्त अवसरों का लाभ उठाने में शामिल होता है। इसे इस प्रकार से निपटें:
संभावित छिपे हुए उप-राज्यों की पहचान करें
उन एंडपॉइंट्स को पहचानने से शुरू करें जो महत्वपूर्ण डेटा को संशोधित या बातचीत करते हैं, जैसे उपयोगकर्ता प्रोफाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान केंद्रित करें:
स्टोरेज: सर्वर-साइड स्थायी डेटा को संभालने वाले एंडपॉइंट्स को प्राथमिकता दें, न कि क्लाइंट-साइड डेटा को संभालने वाले।
क्रिया: उन ऑपरेशनों की तलाश करें जो मौजूदा डेटा को बदलते हैं, जो नए डेटा जोड़ने की तुलना में शोषण योग्य स्थितियाँ बनाने की अधिक संभावना रखते हैं।
कीइंग: सफल हमले आमतौर पर उसी पहचानकर्ता पर की गई ऑपरेशनों में शामिल होते हैं, जैसे उपयोगकर्ता नाम या रीसेट टोकन।
प्रारंभिक परीक्षण करें
पहचाने गए एंडपॉइंट्स पर रेस कंडीशन हमलों के साथ परीक्षण करें, किसी भी अपेक्षित परिणामों से विचलन के लिए अवलोकन करें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन व्यवहार में परिवर्तन एक कमजोरी का संकेत दे सकते हैं।
कमजोरी का प्रदर्शन करें
हमले को कमजोरियों का शोषण करने के लिए आवश्यक न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस चरण में सटीक समय के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है।
Time Sensitive Attacks
अनुरोधों के समय में सटीकता कमजोरियों को प्रकट कर सकती है, विशेष रूप से जब सुरक्षा टोकनों के लिए पूर्वानुमानित विधियों जैसे टाइमस्टैम्प का उपयोग किया जाता है। उदाहरण के लिए, टाइमस्टैम्प के आधार पर पासवर्ड रीसेट टोकन उत्पन्न करना समानांतर अनुरोधों के लिए समान टोकन की अनुमति दे सकता है।
शोषण करने के लिए:
सटीक समय का उपयोग करें, जैसे एकल पैकेट हमला, समानांतर पासवर्ड रीसेट अनुरोध करने के लिए। समान टोकन एक कमजोरी का संकेत देते हैं।
उदाहरण:
एक ही समय में दो पासवर्ड रीसेट टोकन का अनुरोध करें और उनकी तुलना करें। मेल खाते टोकन टोकन उत्पन्न करने में एक दोष का सुझाव देते हैं।
इसे आजमाने के लिए PortSwigger Lab को देखें।
Hidden substates case studies
Pay & add an Item
इसे देखने के लिए PortSwigger Lab पर जाएँ कि कैसे भुगतान करें और एक अतिरिक्त आइटम जोड़ें जिसके लिए आपको भुगतान करने की आवश्यकता नहीं है।
Confirm other emails
विचार यह है कि एक ईमेल पते की पुष्टि करें और इसे एक अलग में बदलें यह देखने के लिए कि क्या प्लेटफ़ॉर्म नए बदले गए को सत्यापित करता है।
Change email to 2 emails addresses Cookie based
इस शोध के अनुसार, Gitlab इस तरीके से अधिग्रहण के लिए कमजोर था क्योंकि यह एक ईमेल के ईमेल सत्यापन टोकन को दूसरे ईमेल पर भेज सकता है।
इसे आजमाने के लिए PortSwigger Lab को देखें।
Hidden Database states / Confirmation Bypass
यदि 2 अलग-अलग लेखन का उपयोग करके जानकारी को डेटाबेस के अंदर जोड़ने के लिए किया जाता है, तो एक छोटा सा समय होता है जहाँ केवल पहला डेटा डेटाबेस के अंदर लिखा गया है। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है, तो उपयोगकर्ता नाम और पासवर्ड लिखे जा सकते हैं और फिर टोकन नए बनाए गए खाते की पुष्टि करने के लिए लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए खाते की पुष्टि करने के लिए टोकन शून्य है।
इसलिए एक खाता पंजीकृत करना और तुरंत पुष्टि करने के लिए एक खाली टोकन के साथ कई अनुरोध भेजना (token= या token[]= या किसी अन्य भिन्नता) एक ऐसा खाता पुष्टि करने की अनुमति दे सकता है जहाँ आप ईमेल को नियंत्रित नहीं करते हैं।
इसे आजमाने के लिए PortSwigger Lab को देखें।
Bypass 2FA
निम्नलिखित प्सेउडो-कोड रेस कंडीशन के प्रति संवेदनशील है क्योंकि बहुत छोटे समय में 2FA लागू नहीं होता जबकि सत्र बनाया जाता है:
OAuth2 शाश्वत स्थायीता
कई OAUth प्रदाता हैं। ये सेवाएँ आपको एक एप्लिकेशन बनाने और उन उपयोगकर्ताओं को प्रमाणित करने की अनुमति देंगी जिन्हें प्रदाता ने पंजीकृत किया है। ऐसा करने के लिए, क्लाइंट को आपके एप्लिकेशन को OAUth प्रदाता के अंदर उनके कुछ डेटा तक पहुँचने की अनुमति देनी होगी। तो, यहाँ तक बस एक सामान्य लॉगिन है जैसे google/linkedin/github... जहाँ आपको एक पृष्ठ पर संकेत दिया जाता है: "एप्लिकेशन <InsertCoolName> आपकी जानकारी तक पहुँचने की इच्छा रखता है, क्या आप इसे अनुमति देना चाहते हैं?"
authorization_code में रेस कंडीशन
authorization_code में रेस कंडीशनसमस्या तब उत्पन्न होती है जब आप इसे स्वीकार करते हैं और स्वचालित रूप से एक authorization_code को दुर्भावनापूर्ण एप्लिकेशन को भेजते हैं। फिर, यह **एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए authorization_code से एक से अधिक AT/RT (Authentication Token/Refresh Token) उत्पन्न कर सके। मूल रूप से, यह इस तथ्य का दुरुपयोग करेगा कि आपने एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति दी है ताकि कई खाते बनाए जा सकें। फिर, यदि आप एप्लिकेशन को अपने डेटा तक पहुँचने की अनुमति देना बंद कर देते हैं, तो AT/RT का एक जोड़ा हटा दिया जाएगा, लेकिन अन्य अभी भी मान्य रहेंगे।
Refresh Token में रेस कंडीशन
Refresh Token में रेस कंडीशनएक बार जब आप एक मान्य RT प्राप्त कर लेते हैं तो आप इसका दुरुपयोग करने की कोशिश कर सकते हैं ताकि कई AT/RT उत्पन्न किए जा सकें और **यहां तक कि यदि उपयोगकर्ता दुर्भावनापूर्ण एप्लिकेशन के लिए अपनी डेटा तक पहुँचने की अनुमति रद्द कर देता है, तो भी कई RTs मान्य रहेंगे।
RC वेब सॉकेट्स में
WS_RaceCondition_PoC में आप एक PoC पा सकते हैं जो Java में वेब सॉकेट संदेशों को समानांतर में भेजने के लिए है ताकि वेब सॉकेट्स में रेस कंडीशंस का दुरुपयोग किया जा सके।
संदर्भ
Trickest का उपयोग करें ताकि आसानी से वर्कफ़्लो बनाएं और स्वचालित करें जो दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित हों। आज ही एक्सेस प्राप्त करें:
