mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

Translator a68372623f Translated ['README.md', 'backdoors/salseo.md', 'forensics/basic-forensi

2023-12-16 15:25:38 +00:00

30 KiB

Raw Blame History

रेस कंडीशन

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

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप चाहते हैं कि आपकी कंपनी HackTricks में विज्ञापित हो? या क्या आपको PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
The PEASS Family की खोज करें, हमारा विशेष संग्रह NFTs
आधिकारिक PEASS & HackTricks swag प्राप्त करें
💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का** अनुसरण करें।**
अपने हैकिंग ट्रिक्स को hacktricks repo और hacktricks-cloud repo में PR जमा करके साझा करें।

RC का शोषण करना

RC का दुष्प्रभाव उन अनुरोधों को प्रोसेस करने की आवश्यकता है जो बहुत कम समय के अंतराल में पारलेल रूप से होते हैं (आमतौर पर >1ms)। इस अनुभाग में, इसे संभव बनाने के लिए विभिन्न समाधान प्रस्तावित किए गए हैं।

एकल-पैकेट हमला (HTTP/2) / अंतिम-बाइट सिंक (HTTP/1.1)

HTTP2 की अनुमति है कि एकल TCP कनेक्शन में 2 अनुरोध भेजे जा सकते हैं (जबकि HTTP/1.1 में वे क्रमशः होने चाहिए)।
एकल TCP पैकेट का उपयोग करने से पूरी तरह से नेटवर्क जिटर का प्रभाव समाप्त हो जाता है, इसलिए यह रेस कंडीशन हमलों के लिए भी संभावना है। हालांकि, दो अनुरोध एक सुरक्षित रेस हमले के लिए पर्याप्त नहीं हैं धन्यवाद है सर्वर-साइड जिटर के लिए - अनियंत्रित कारकों द्वारा उत्पन्न अनुप्रबंधन के समय अनुप्रयोग की अनुरोध-प्रसंस्करण समय में विभिन्नताएं।

लेकिन, HTTP/1.1 'अंतिम-बाइट सिंक' तकनीक का उपयोग करके आप बड़े हिस्से को पूरे अनुरोध से पहले रोक सकते हैं और फिर एकल TCP पैकेट के साथ 20-30 अनुरोध पूरे कर सकते हैं।

प्रत्येक अनुरोध के बड़े हिस्से को पहले भेजें:

यदि अनुरोध में कोई बॉडी नहीं है, तो सभी हैडर भेजें, लेकिन END_STREAM फ़्लैग सेट न करें। END_STREAM सेट करने वाले एक खाली डेटा फ़्रेम रोकें।
यदि अनुरोध में एक बॉडी है, तो हेडर और अंतिम बाइट को छोड़कर सभी बॉडी डेटा भेजें। अंतिम बाइट युक्त डेटा फ़्रेम रोकें।

अगले, अंतिम फ़्रेम भेजने के लिए तैयार हों:

पहले फ़्रेम भेजने के लिए 100ms तक प्रतीक्षा करें।
सुनिश्चित करें कि TCP_NODELAY अक्षम है - नागल के एल्गोरिदम के द्वारा अंतिम फ़्रेम को बैच में भेजना महत्वपूर्ण है।
स्थानीय कनेक्शन को गर्म करने के लिए पिंग पैकेट भेजें। यदि आप ऐसा नहीं करते हैं, तो ओएस नेटवर्क स्टैक प

दर या संसाधन सीमाओं का दुरुपयोग

यदि कनेक्शन वार्मिंग कोई फर्क नहीं पड़ता है, तो इस समस्या का हल करने के विभिन्न समाधान हैं।

Turbo Intruder का उपयोग करके, आप एक छोटी समय-संबंधी देरी प्रविष्ट कर सकते हैं। हालांकि, यह आपके वास्तविक हमला अनुरोधों को कई TCP पैकेटों में विभाजित करने के कारण, आपको एकल-पैकेट हमला तकनीक का उपयोग नहीं कर सकेंगे। इस परिणामस्वरूप, उच्च-जिटर लक्ष्यों पर, आपके निर्धारित देरी के बावजूद, हमला संभवतः स्थिरता से काम नहीं करेगा।

इसके बजाय, आप सामान्य सुरक्षा सुविधा का दुरुपयोग करके इस समस्या को हल कर सकते हैं।

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

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

हमला उदाहरण

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

Limit-overrun / TOCTOU

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

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

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

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

अन्य सबसे जटिल RC में हमलावर मशीन स्थिति में उप-स्थितियों का शोषण किया जाएगा जिससे हमलावर को पहुंच हो सकती है जिसकी उसे पहुंच होने की कोई योजना नहीं थी, लेकिन हमलावर को उस तक पहुंचने का एक छोटा समय-खिड़की होता है।

छिपी हुई और दिलचस्प उप-स्थितियों की संभावना का अनुमान लगाएं

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

हम तीन मुख्य प्रश्नों का उपयोग कर सकते हैं ताकि संभावित टकराव का कारण नहीं होने वाले एंडपॉइंट्स को बाहर किया जा सके। प्रत्येक ऑब्जेक्ट और संबंधित एंडपॉइंट्स के लिए पूछें:

स्थिति कैसे संग्रहीत होती है?

स्थायी सर्वर-साइड डेटा संरचना में संग्रहीत डेटा उत्कृष्ट है। कुछ एंडपॉइंट्स अपनी स्थिति को पूरी तरह से क्लाइंट-साइड में संग्रहीत करते हैं, जैसे कि एक जेडबीटी द्वारा काम करने वाले पासवर्ड रीसेट - इन्हें सुरक्षित रूप से छोड़ा जा सकता है।

अनुप्रयोगों में अक्सर कुछ स्थिति उपयोगकर्ता सत्र में संग्रहीत करते हैं। इन्हें अक्सर उप-स्थितियों के खिलाफ संरक्षित किया जाता है - इस पर बाद में अधिक जानकारी होगी।

क्या हम संपादन या जोड़ने का कार्य कर रहे हैं?

मौजूदा डेटा को संपादित करने वाले कार्यों (जैसे कि खाता का प्राथमिक ईमेल पता बदलना) में पर्याप्त टकराव की संभावना होती है, जबकि मौजूदा डेटा में सिर्फ जोड़ने के कार्यों (जैसे कि एक अतिरिक्त ईमेल पता जोड़ना) को केवल सीमित होने की संभावना होती है, अन्य किसी चीज़ के अलावा।

ऑपरेशन किस पर की जाती है?

अधिकांश एंडपॉइंट्स एक विशेष रिकॉर्ड पर कार्य करते हैं, जिसे एक 'कुंजी' का उपयोग करके खोजा जाता है, जैसे उपयोगकर्ता नाम, पासवर्ड रीसेट टोकन या फ़ाइल नाम। सफल हमले के लिए, हमें दो ऑपरेशन चाहिए जो एक ही कुंजी का उपयोग करते हैं। उदाहरण के लिए, दो संभावित पासवर्ड रीसेट के अमलियों की तस्वीर करें:

संकेतों के लिए प्रोब करें

इस बिंदु पर यह समय है कि पोटेंशियल दिलचस्प एंडपॉइंट्स पर कुछ RC हमल

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

जैसा कि आप देख सकते हैं, यह वास्तव में एक एकल अनुरोध के दौरान कई चरणों का अनुक्रम है। सबसे महत्वपूर्ण बात यह है कि इसमें एक उप-स्थिति के माध्यम से यूजर के पास एक मान्य लॉग-इन सत्र होता है, लेकिन MFA अभी लागू नहीं हो रहा है। किसी हमलावर्धी व्यक्ति द्वारा इसका उपयोग करके लॉगिन अनुरोध भेजकर संवेदनशील, प्रमाणित अंतर्निहित अंत बिंदु के साथ एक अनुरोध को भेजकर इसे उत्पन्न किया जा सकता है।

OAuth2 अविनाशी टिकाकरण

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

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

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

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

एक बार जब आपने एक मान्य RT प्राप्त कर लिया है तो आप कोशिश कर सकते हैं कि इसे दुष्प्रभावी ऐप्लिकेशन के लिए कई AT/RT उत्पन्न करें और यदि उपयोगकर्ता ऐप्लिकेशन के लिए अनुमतियां रद्द कर देता है तो कई RT अभी भी मान्य रहेंगे।

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

WS_RaceCondition_PoC में आपको पैरलेल में वेबसॉकेट संदेश भेजने के लिए जावा में एक PoC मिलेगा, जिसका उपयोग वेब सॉकेट में भी रेस कंडीशन का दुरुपयोग करने के लिए किया जा सकता है।

संदर्भ