hacktricks/pentesting-web/race-condition.md

रेस कंडीशन

Trickest का उपयोग करें और आसानी से ऑटोमेट वर्कफ़्लो बनाएं जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित हैं।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान देखें!
• आधिकारिक PEASS और HackTricks स्वैग प्राप्त करें
• हमारे विशेष NFTs संग्रह, The PEASS Family की खोज करें
• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।
• HackTricks और HackTricks Cloud github repos में PRs सबमिट करके अपने हैकिंग ट्रिक्स साझा करें।

{% hint style="warning" %} इस तकनीक को गहरी समझने के लिए मूल रिपोर्ट की जांच करें https://portswigger.net/research/smashing-the-state-machine {% endhint %}

रेस कंडीशन हमलों को बढ़ाना

रेस कंडीशन का लाभ उठाने में मुख्य बाधा यह है कि सुनिश्चित किया जाए कि कई अनुरोध समायोजित समय में हैं, उनके प्रसंस्करण समय में बहुत कम अंतर—आदर्श रूप से, 1ms से कम।

यहाँ आपको समकालिक अनुरोधों के लिए कुछ तकनीक मिलेगी:

HTTP/2 Single-Packet हमला vs. HTTP/1.1 लास्ट-बाइट समकालन

• HTTP/2: एक ही TCP कनेक्शन पर दो अनुरोध भेजने का समर्थन करता है, नेटवर्क जिटर प्रभाव को कम करता है। हालांकि, सर्वर-साइड विविधताओं के कारण, दो अनुरोध एक स्थिर रेस कंडीशन हमले के लिए पर्याप्त नहीं हो सकते।
• HTTP/1.1 'लास्ट-बाइट सिंक': 20-30 अनुरोधों के अधिकांश हिस्से को पूर्व-भेजन की अनुमति देता है, एक छोटा टुकड़ा रोकता है, जिसे फिर साथ में भेजा जाता है, सर्वर पर समकालिक पहुंच को प्राप्त करते हैं।

लास्ट-बाइट सिंक के लिए तैयारी शामिल है:

1. स्ट्रीम समाप्त किए बिना हेडर और बॉडी डेटा भेजना।
2. प्रारंभिक भेजन के बाद 100ms के लिए ठहराव।
3. अंतिम फ्रेम के बैचिंग के लिए Nagle's एल्गोरिदम का उपयोग करने के लिए TCP_NODELAY को अक्षम करना।
4. कनेक्शन को गर्म करने के लिए पिंग करना।

बाधित फ्रेम्स के बाद के भेजन से उनकी एक ही पैकेट में पहुंचना चाहिए, जिसे Wireshark के माध्यम से सत्यापित किया जा सकता है। यह विधि स्थिर फ़ाइलों पर लागू नहीं होती है, जो सामान्यत: RC हमलों में शामिल नहीं होती हैं।

सर्वर वास्तुकला को अनुकूलित करना

लक्षित की गई वास्तुकला को समझना महत्वपूर्ण है। फ्रंट-एंड सर्वर अनुरोधों को विभिन्न रूप से मार्गित कर सकते हैं, जो समय पर प्रभाव डाल सकते हैं। अर्थहीन अनुरोधों के माध्यम से पूर्वानुमानित सर्वर-साइड कनेक्शन गर्म करना, अनुरोध समय को सामान्य कर सकता है।

सत्र-आधारित लॉकिंग का संभालन

PHP की सत्र हैंडलर जैसे फ्रेमवर्क सत्र द्वारा अनुरोधों को सीरियलाइज कर सकते हैं, संकेतों को छिपा सकते हैं। प्रत्येक अनुरोध के लिए विभिन्न सत्र टोकन का उपयोग इस समस्या को टाल सकता है।

दर या संसाधन सीमाएं पार करना

यदि कनेक्शन गर्म करना असफल है, तो वेब सर्वर की दर या संसाधन सीमाओं को जानबूझकर ट्रिगर करना, डमी अनुरोधों की बाढ़ के माध्यम से एक सिंगल-पैकेट हमले को सुविधाजनक बना सकता है जो रेस कंडीशन के लिए उपयुक्त सर्वर-साइड देरी को उत्पन्न कर सकता है।

हमले के उदाहरण

• Tubo Intruder - HTTP2 single-packet attack (1 endpoint): आप Turbo intruder में अनुरोध भेज सकते हैं (Extensions -> Turbo Intruder -> Send to Turbo Intruder), आप जिसे ब्रूट फ़ोर्स करना चाहते हैं उसके लिए अनुरोध में %s जैसे की csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s जैसे वैल्यू को बदल सकते हैं और फिर ड्रॉप डाउन से examples/race-single-packer-attack.py का चयन कर सकते हैं:

यदि आप विभिन्न मान भेजने जा रहे हैं, तो आप कोड को इस वाले से मॉडिफ़ाई कर सकते हैं जो क्लिपबोर्ड से एक वर्डलिस्ट का उपयोग करता है:

passwords = wordlists.clipboard
for password in passwords:
engine.queue(target.req, password, gate='race1')

{% hint style="warning" %} यदि वेब HTTP2 का समर्थन नहीं करता (केवल HTTP1.1), तो Engine.BURP2 की बजाय Engine.THREADED या Engine.BURP का उपयोग करें। {% endhint %}

• Tubo Intruder - HTTP2 single-packet attack (Several endpoints): यदि आपको RCE को ट्रिगर करने के लिए 1 एंडपॉइंट को रिक्वेस्ट भेजने की आवश्यकता है और फिर अन्य एंडपॉइंट्स पर कई रिक्वेस्ट भेजने की आवश्यकता है, तो आप race-single-packet-attack.py स्क्रिप्ट को निम्नलिखित तरह से बदल सकते हैं:

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2
)

# Hardcode the second request for the RC
confirmationReq = '''POST /confirm?token[]= HTTP/2
Host: 0a9c00370490e77e837419c4005900d0.web-security-academy.net
Cookie: phpsessionid=MpDEOYRvaNT1OAm0OtAsmLZ91iDfISLU
Content-Length: 0

'''

# For each attempt (20 in total) send 50 confirmation requests.
for attempt in range(20):
currentAttempt = str(attempt)
username = 'aUser' + currentAttempt

# queue a single registration request
engine.queue(target.req, username, gate=currentAttempt)

# queue 50 confirmation requests - note that this will probably sent in two separate packets
for i in range(50):
engine.queue(confirmationReq, gate=currentAttempt)

# send all the queued requests for this attempt
engine.openGate(currentAttempt)

• यह भी रिपीटर में उपलब्ध है बर्प स्वीट के नए 'समूह को पैरलल में भेजें' विकल्प के माध्यम से।
• लिमिट-ओवरन के लिए आप बस समूह में 50 बार एक ही अनुरोध जोड़ सकते हैं।
• कनेक्शन वार्मिंग के लिए, आप वेब सर्वर के कुछ गैर स्थिर हिस्से के लिए समूह की शुरुआत में कुछ अनुरोध जोड़ सकते हैं।
• एक अनुरोध से दूसरे अनुरोध की प्रोसेसिंग के बीच प्रक्रिया को विलंबित करने के लिए, आप दोनों अनुरोधों के बीच अतिरिक्त अनुरोध जोड़ सकते हैं।
• मल्टी-एंडपॉइंट आरसी के लिए आप छिपे हुए स्थिति को जाने वाला अनुरोध भेजना शुरू कर सकते हैं और फिर इसके बाद 50 अनुरोध भेज सकते हैं जो छिपे हुए स्थिति का शोषण करते हैं।

रॉ बीएफ

पिछले शोध से पहले ये कुछ पेलोड्स थे जो बस एक आरसी को उत्पन्न करने के लिए पैकेट्स को जितनी जल्दी संभव हो भेजने की कोशिश करते थे।

• रिपीटर: पिछले खंड से उदाहरण देखें।
• इंट्रूडर: इंट्रूडर को अनुरोध भेजें, विकल्प मेनू में स्थान की संख्या 30 पर सेट करें, पेलोड के रूप में नल पेलोड का चयन करें और 30 जेनरेट करें।
• टर्बो इंट्रूडर

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
pipeline=False
)
a = ['Session=<session_id_1>','Session=<session_id_2>','Session=<session_id_3>']
for i in range(len(a)):
engine.queue(target.req,a[i], gate='race1')
# open TCP connections and send partial requests
engine.start(timeout=10)
engine.openGate('race1')
engine.complete(timeout=60)

def handleResponse(req, interesting):
table.add(req)

• Python - asyncio

import asyncio
import httpx

async def use_code(client):
resp = await client.post(f'http://victim.com', cookies={"session": "asdasdasd"}, data={"code": "123123123"})
return resp.text

async def main():
async with httpx.AsyncClient() as client:
tasks = []
for _ in range(20): #20 times
tasks.append(asyncio.ensure_future(use_code(client)))

# Get responses
results = await asyncio.gather(*tasks, return_exceptions=True)

# Print results
for r in results:
print(r)

# Async2sync sleep
await asyncio.sleep(0.5)
print(results)

asyncio.run(main())

RC Methodology

सीमा-अतिरिक्त / TOCTOU

यह सबसे मौलिक प्रकार की रेस कंडीशन है जहाँ कम संख्या में क्रिया करने की सीमा होती है जिसमें सुरक्षा कमियाँ हो सकती हैं। जैसे किसी वेब स्टोर में एक ही डिस्काउंट कोड का कई बार उपयोग करना। एक बहुत ही सरल उदाहरण इस रिपोर्ट या इस बग में देखा जा सकता है।

इस प्रकार के हमलों के कई रूप हो सकते हैं, जैसे:

• एक गिफ्ट कार्ड को कई बार रिडीम करना
• उत्पाद को कई बार रेट करना
• अपने खाता शेष राशि से अधिक नकदी निकालना या स्थानांतरित करना
• एक ही CAPTCHA समाधान का पुनः उपयोग करना
• एक एंटी-ब्रूट-फोर्स दर सीमा को छलकरना

छिपी हुई उप-स्थितियाँ

जटिल रेस कंडीशन का शोध करना अक्सर छोटे अवसरों का लाभ उठाने का मतलब होता है जो छिपी या अनजान मशीन उप-स्थितियों के साथ बातचीत करने के लिए होते हैं। यहाँ इसका तरीका है:

1. छिपी हुई उप-स्थितियों की पहचान करें

• सर्वाधिक महत्वपूर्ण डेटा को संशोधित या बातचीत करने वाले अंत-बिंदुओं की पहचान करके शुरू करें, जैसे उपयोगकर्ता प्रोफ़ाइल या पासवर्ड रीसेट प्रक्रियाएँ। ध्यान दें:
• स्टोरेज: उन अंत-बिंदुओं को पसंद करें जो सर्वर-साइड स्थायी डेटा को संचालित करते हैं उनके बजाय जो डेटा क्लाइंट-साइड संभालते हैं।
• क्रिया: मौजूदा डेटा को बदलने वाली क्रियाओं की खोज करें, जो उनसे अधिक उत्पादनीय स्थितियाँ बनाने की संभावना हैं जो नए डेटा जोड़ने वाले की तुलना में।
• कींग: सफल हमले आम तौर पर एक ही पहचानकर्ता पर आधारित क्रियाओं को शामिल करते हैं, जैसे उपयोगकर्ता नाम या रीसेट टोकन।

2. प्रारंभिक जांच करें

• निर्धारित अंत-बिंदुओं को रेस कंडीशन हमलों के साथ जांचें, अपेक्षित परिणामों से किसी भिन्नता के लिए ध्यान दें। अप्रत्याशित प्रतिक्रियाएँ या एप्लिकेशन के व्यवहार में परिवर्तन एक संकट संकेत कर सकते हैं।

3. संकट को प्रदर्शित करें

• संकट को उत्पन्न करने के लिए आवश्यकतानुसार हमले को न्यूनतम अनुरोधों की संख्या तक सीमित करें, अक्सर केवल दो। इस कदम में समयित होने के कारण कई प्रयासों या स्वचालन की आवश्यकता हो सकती है।

समय संवेदनशील हमले

अनुरोधों में समयितता में सटीकता संकेतित कर सकती है, विशेषकर सुरक्षा टोकन के लिए समय-चिह्नों जैसे पूर्वानुमानित विधियों का उपयोग करने पर। उदाहरण के लिए, समय-चिह्नों पर आधारित पासवर्ड रीसेट टोकन उत्पन्न करने से समयितता के दौरान एक ही टोकन समान अनुरोधों के लिए संकेतित कर सकता है।

उत्पादन करने के लिए:

• समान समय पर पासवर्ड रीसेट अनुरोध करने के लिए सटीक समय का उपयोग करें। समान टोकन एक संकट का संकेत देते हैं।

उदाहरण:

• दो पासवर्ड रीसेट टोकन का एक साथ अनुरोध करें और उन्हें तुलना करें। मेल खाता उत्पन्न करने में दोष सुझाते हैं।

इसे जांचने के लिए PortSwigger Lab का अवलोकन करें।

छिपी उप-स्थितियों के मामले की अध्ययन

भुगतान करें और आइटम जोड़ें

दुकान में भुगतान करने और एक अतिरिक्त आइटम जोड़ने के बारे में जानने के लिए इस PortSwigger Lab की जांच करें।

अन्य ईमेल की पुष्टि करें

विचार यह है कि एक ईमेल पते की पुष्टि करें और उसे एक अलग ईमेल पते पर बदलें ताकि पता चले कि प्लेटफ़ॉर्म नया जोड़ा गया है या नहीं।

ईमेल को 2 ईमेल पतों में बदलें कुकी आधारित

इस शोध के अनुसार Gitlab इस तरीके से लेने-देन में भेद्य था क्योंकि यह एक ईमेल से दूसरे ईमेल पर ईमेल पुष्टि टोकन भेज सकता था।

इसे जांचने के लिए PortSwigger Lab का अवलोकन करें।

छिपी डेटाबेस स्थितियाँ / पुष्टि बाइपास

यदि डेटाबेस में जानकारी जोड़ने के लिए 2 विभिन्न लेखन का उपयोग किया जाता है, तो एक छोटे समय का अंश होता है जब केवल पहला डेटा डेटाबेस में लिखा गया होता है। उदाहरण के लिए, जब एक उपयोगकर्ता बनाया जाता है तो उपयोगकर्ता नाम और पासवर्ड लिखा जा सकता है और फिर नए बनाए गए खाते की पुष्टि के लिए टोकन लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए खाते की पुष्टि करने के लिए एक खाता खाली हो सकता है।

इसलिए एक खाता पंजीकरण करना और खाते की पुष्टि करने के लिए कई अनुरोध भेजना (token= या token[]= या किसी अन्य विविधता) खाते की पुष्टि करने की अनुमति दे सकता है जहाँ आपके पास ईमेल का नियंत्रण नहीं है।

इसे जांचने के लिए PortSwigger Lab का अवलोकन करें।

2FA को बाइपास करें

निम्नलिखित प्यूडो-कोड एक रेस कंडीशन के लिए भेद्य है क्योंकि एक बहुत छोटे समय के लिए 2FA लागू नहीं होता जबकि सत्र बनाया जाता है:

session['userid'] = user.userid
if user.mfa_enabled:
session['enforce_mfa'] = True
# generate and send MFA code to user
# redirect browser to MFA code entry form

OAuth2 शाश्वत स्थिरता

कई OAUth प्रदाताएं हैं। ये सेवाएं आपको एक एप्लिकेशन बनाने और प्रदाता जिन्होंने पंजीकृत किया है, को प्रमाणित करने की अनुमति देंगी। इसे करने के लिए ग्राहक को अपने डेटा में से कुछ डेटा तक पहुंचने की अनुमति देनी होगी OAUth प्रदाता के अंदर।
तो, यहाँ तक सिर्फ एक सामान्य लॉगिन गूगल/लिंक्डइन/गिटहब... जहां आपको एक पृष्ठ के साथ प्रोम्प्ट किया जाता है: "एप्लिकेशन <InsertCoolName> आपकी जानकारी तक पहुंचना चाहता है, क्या आप इसे अनुमति देना चाहते हैं?"

authorization_code में रेस कंडीशन

समस्या उत्पन्न होती है जब आप इसे स्वीकार करते हैं और स्वचालित रूप से एक authorization_code को दुर्भाग्यपूर्ण एप्लिकेशन को भेजते हैं। फिर, यह एप्लिकेशन OAUth सेवा प्रदाता में रेस कंडीशन का दुरुपयोग करता है ताकि आपके खाते के लिए एटी/आरटी (प्रमाणीकरण टोकन/रिफ्रेश टोकन) से अधिक एटी/आरटी उत्पन्न कर सके। मूल रूप से, यह आपके डेटा तक पहुंचने की अनुमति देने के लिए आपने एप्लिकेशन को स्वीकृत किया है इस तथ्य का दुरुपयोग करेगा और कई खाते बनाएगा। फिर, अगर आप एप्लिकेशन को अपने डेटा तक पहुंचने की अनुमति देना बंद कर देते हैं तो एक जोड़ा एटी/आरटी हटा दिया जाएगा, लेकिन अन्य वाले अभी भी मान्य रहेंगे।

Refresh Token में रेस कंडीशन

एक वैध आरटी प्राप्त करने के बाद आप इसे दुरुपयोग करने के लिए कई एटी/आरटी उत्पन्न करने की कोशिश कर सकते हैं और यदि उपयोगकर्ता दुर्भाग्यपूर्ण एप्लिकेशन के लिए अपने डेटा तक पहुंचने की अनुमति रद्द कर देता है तो कई आरटी अभी भी मान्य रहेंगे।

वेबसॉकेट में RC

WS_RaceCondition_PoC में आपको जावा में वेबसॉकेट संदेश भेजने के लिए PoC मिलेगा पैरलल में दुर्भाग्यपूर्ण स्थितियों का दुरुपयोग करने के लिए वेब सॉकेट में भी।

संदर्भ

• https://hackerone.com/reports/759247
• https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html
• https://hackerone.com/reports/55140
• https://portswigger.net/research/smashing-the-state-machine
• https://portswigger.net/web-security/race-conditions

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• हमारे विशेष NFTs संग्रह The PEASS Family खोजें
• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर** फॉलो करें।
• हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos को PRs सबमिट करके।

Trickest का उपयोग करें और आसानी से वर्कफ़्लो बनाएं और स्वचालित करें जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित हैं।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}