<summary><strong>जीरो से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* अगर आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स देखें**](https://github.com/sponsors/carlospolop)!
**इस पोस्ट का एक हिस्सा यह शानदार पोस्ट पर आधारित है:** [**https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology**](https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology)\
आप बस डेटा में हस्तक्षेप कर सकते हैं, हस्ताक्षर को छोड़कर, और देख सकते हैं कि सर्वर हस्ताक्षर की जांच कर रहा है या नहीं। उदाहरण के लिए अपना उपयोगकर्ता नाम "व्यवस्थापक" में बदलने का प्रयास करें।
इस वंशक का उपयोग करने के लिए बर्प एक्सटेंशन कॉल "JSON वेब टोकन" का उपयोग करें और इस दुर्बलता का प्रयास करने के लिए JWT के भीतर विभिन्न मानों को बदलने के लिए (अनुरोध को रिपीटर में भेजें और "JSON वेब टोकन" टैब में आप टोकन के मानों को संशोधित कर सकते हैं। आप यह भी चुन सकते हैं कि "एल्ग" फील्ड के मान को "कोई" में डालें।)
यदि आप एल्गोरिथ्म को RS256 से HS256 में बदलते हैं, तो बैक एंड कोड सार्वजनिक कुंजी के रूप में सुरक्षित कुंजी का उपयोग करता है और फिर हस्ताक्षर की पुष्टि करने के लिए HS256 एल्गोरिथ्म का उपयोग करता है।
फिर, सार्वजनिक कुंजी का उपयोग करके और RS256 को HS256 में बदलकर हम एक मान्य हस्ताक्षर बना सकते हैं। आप इसे निष्कर्षित कर सकते हैं वेब सर्वर का प्रमाणपत्र निष्पादित करके यह करके:
openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
निर्देश एक विधि का विवरण देते हैं जो JWT टोकनों की सुरक्षा का मूल्यांकन करने के लिए है, विशेष रूप से उन टोकनों के लिए जो "jku" हेडर क्लेम का उपयोग करते हैं। यह क्लेम उस JWKS (JSON Web Key Set) फ़ाइल को लिंक करना चाहिए जिसमें टोकन की सत्यापन के लिए आवश्यक सार्वजनिक कुंजी हो।
* आपके निर्दिष्ट URL पर HTTP अनुरोधों का अवलोकन करना सर्वर की कोशिशों को सूचित करता है कि वह आपके प्रदत्त लिंक से कुंजियाँ प्राप्त करने का प्रयास कर रहा है।
* इस प्रक्रिया के लिए `jwt_tool` का उपयोग करते समय, टेस्टिंग को सुविधाजनक बनाने के लिए अपनी व्यक्तिगत JWKS स्थान को `jwtconf.ini` फ़ाइल में अपडेट करना महत्वपूर्ण है।
एक वैकल्पिक हेडर क्लेम जिसे `kid` के रूप में जाना जाता है, एक विशेष कुंजी की पहचान के लिए प्रयोग किया जाता है, जो टोकन सिग्नेचर सत्यापन के लिए एकाधिक कुंजियों की मौजूदगी में विशेष रूप से महत्वपूर्ण हो जाता है। यह क्लेम टोकन के सिग्नेचर की सत्यापन के लिए उचित कुंजी का चयन करने में मदद करता है।
जब `kid` क्लेम हेडर में मौजूद होता है, तो सुझाव दिया जाता है कि संबंधित फ़ाइल या उसके विविधताएँ के लिए वेब निर्देशिका में खोज की जाए। उदाहरण के लिए, यदि `"kid":"key/12345"` निर्दिष्ट है, तो फ़ाइल _/key/12345_ और _/key/12345.pem_ की वेब रूट में खोजी जानी चाहिए।
`kid` क्लेम का उपयोग फ़ाइल सिस्टम के माध्यम से चलने के लिए भी किया जा सकता है, जिससे किसी भी विचित्र फ़ाइल का चयन करने की संभावना हो सकती है। विशेष फ़ाइलों या सेवाओं को लक्षित करने के लिए `kid` मान को बदलकर कनेक्टिविटी का परीक्षण करना या सर्वर-साइड अनुरोध फर्जी (SSRF) हमले को क्रियाशील करने की संभावना है। `jwt_tool` में `kid` मान को बदलने के लिए JWT में हस्ताक्षर को बनाए रखते हुए `-T` ध्वज का उपयोग करके इस प्रक्रिया को प्राप्त किया जा सकता है, जैसा कि नीचे दिखाया गया है:
By targeting files with predictable content, it's possible to forge a valid JWT. For instance, the `/proc/sys/kernel/randomize_va_space` file in Linux systems, known to contain the value **2**, can be used in the `kid` parameter with **2** as the symmetric password for JWT generation.
यदि `kid` क्लेम की सामग्री का उपयोग डेटाबेस से पासवर्ड प्राप्त करने के लिए किया जाता है, तो `kid` पेलोड को संशोधित करके SQL इंजेक्शन को सुविधाजनक बनाया जा सकता है। जेडब्ल्यूटी साइनिंग प्रक्रिया को संशोधित करने के लिए एक उदाहरण पेलोड शामिल है:
एक स्थिति जहाँ `kid` पैरामीटर एक कमांड निष्पादन संदर्भ में उपयोग किए जाने वाले फ़ाइल पथ को निर्दिष्ट करता है, रिमोट कोड निष्पादन (RCE) जोखिमों की ओर ले जा सकता है। `kid` पैरामीटर में कमांड इंजेक्शन करके, निजी कुंजीयों को उजागर करना संभव है। RCE और कुंजी उजागर करने के लिए एक उदाहरण पेलोड है:
यदि टोकन एक “**jku**” **Header** क्लेम का उपयोग करता है तो **प्रदत्त URL की जाँच करें**। यह एक URL पर पोइंट करना चाहिए जिसमें JWKS फ़ाइल होती है जो टोकन को सत्यापित करने के लिए सार्वजनिक कुंजी रखती है। टोकन को तबादला करें ताकि jku मान एक वेब सेवा की ओर पोइंट करे जिस पर आप ट्रैफ़िक का मॉनिटरिंग कर सकते हैं।
तो आप उदाहरण के लिए [**jwt.io**](https://jwt.io) का उपयोग कर सकते हैं नए JWT बनाने के लिए **निर्मित सार्वजनिक और निजी कुंजीयों के साथ और पैरामीटर jku को बनाए गए प्रमाणपत्र पर प्वाइंट करके।** एक वैध jku प्रमाणपत्र बनाने के लिए आप मूल प्रमाणपत्र को डाउनलोड कर सकते हैं और आवश्यक पैरामीटर बदल सकते हैं।
X.509 URL. एक URI जो X.509 (एक प्रमाण पत्र प्रारूप मानक) सार्वजनिक प्रमाण पत्रों का सेट को PEM रूप में कोडित करने के लिए पॉइंट करता है। सेट में पहला प्रमाण पत्र वह होना चाहिए जिसका उपयोग इस JWT को साइन करने के लिए किया गया है। आगामी प्रमाण पत्र पिछले प्रमाण पत्र को हर एक साइन करता है, जिससे प्रमाण पत्र श्रृंखला पूरी हो जाती है। X.509 को RFC 5280 में परिभाषित किया गया है। प्रमाण पत्रों को स्थानांतरित करने के लिए परिवहन सुरक्षा आवश्यक है।
इस हेडर को **अपने नियंत्रण में एक URL में बदलने** का प्रयास करें और देखें कि क्या कोई अनुरोध प्राप्त होता है। उस मामले में आप **JWT को बिगाड़ सकते हैं**।
तो आप उदाहरण के लिए [**jwt.io**](https://jwt.io) का उपयोग कर सकते हैं नए JWT बनाने के लिए **निर्मित सार्वजनिक और निजी कुंजीयों के साथ और पैरामीटर x5u को चिह्नित करते हुए प्रमाणपत्र .crt बनाया गया।**
अगर हमलावर **स्व-साइन किया गया प्रमाणपत्र उत्पन्न** करता है और उसके संबंधित निजी कुंजी का उपयोग करके एक जाली टोकन बनाता है और "x5c" पैरामीटर के मान को नए उत्पन्न प्रमाणपत्र से बदल देता है और अन्य पैरामीटरों, अर्थात् n, e और x5t को संशोधित करता है तो मूल रूप से जाली टोकन को सर्वर द्वारा स्वीकार कर लिया जाएगा।
n ="ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8";
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
एक नए निजी/सार्वजनिक कुंजी उत्पन्न करना संभव है, नए सार्वजनिक कुंजी को टोकन के अंदर समाहित करना और इसका उपयोग एक नया हस्ताक्षर उत्पन्न करने के लिए कर सकते हैं:
यहां एक उदाहरण है: [ECDSA: एक ही नॉन्स का उपयोग करते समय निजी कुंजी का प्रकटीकरण, यदि SECP256k1 का उपयोग किया गया है](https://asecuritysite.com/encryption/ecd5)
हालांकि, एक स्थिति की कल्पना करें जहां ID की अधिकतम लंबाई 4 है (0001-9999)। अनुरोध 0001 और 10001 एक ही ID का उपयोग करेंगे। इसलिए यदि बैकएंड प्रत्येक अनुरोध पर ID को बढ़ा रहा है तो आप इसका दुरुपयोग कर सकते हैं **एक अनुरोध को पुनः चलाने के लिए** (प्रत्येक सफल पुनः चलाने के बीच 10000 अनुरोध भेजने की आवश्यकता है)।
कुछ वेब एप्लिकेशनों पर ध्यान दिया गया है कि वे अपने टोकनों का उत्पादन और प्रबंधन करने के लिए एक विश्वसनीय JWT सेवा पर निर्भर हैं। उन्होंने देखा गया है कि एक टोकन, जो JWT सेवा द्वारा एक ग्राहक के लिए उत्पन्न किया गया था, उसी JWT सेवा के दूसरे ग्राहक द्वारा स्वीकार किया गया था। यदि तीसरे पक्ष की सेवा के माध्यम से एक JWT का जारी किया जाना या नवीकरण देखा जाता है, तो उसी उपयोगकर्ता के लिए एक खाता खोलने की संभावना होनी चाहिए जिसमें एक ही उपयोगकर्ता नाम/ईमेल का उपयोग किया जा रहा है। फिर उस लक्ष्य को एक अनुरोध में पुनः चलाने के लिए प्राप्त टोकन को पुनः चलाने का प्रयास किया जाना चाहिए।
* आपके टोकन को स्वीकृति मिलने पर एक महत्वपूर्ण मुद्दा संकेतित हो सकता है, जो किसी भी उपयोगकर्ता के खाते का धोखा देने की संभावना है। हालांकि, यह ध्यान देने योग्य है कि यदि तीसरे पक्ष एप्लिकेशन पर साइन अप करने के लिए अधिक टेस्टिंग की अनुमति चाहिए, क्योंकि यह कानूनी ग्रे क्षेत्र में प्रवेश कर सकता है।
टोकन की समय सीमा "exp" पेयलोड दावा का उपयोग करके जांची जाती है। जबकि जेडब्ल्यूटी अक्षमता के बिना अक्सर JWT का उपयोग किया जाता है, सावधान व्यवस्था की आवश्यकता होती है। अक्सर, दूसरे उपयोगकर्ता के JWT को कैप्चर करना और पुनः चलाना उस उपयोगकर्ता का अनुकरण करने की संभावना बना सकता है। JWT RFC टोकन के लिए एक समय सीमा सेट करने के लिए "exp" दावा का उपयोग करके JWT पुनः चलाने हमलों को कम करने की सिफारिश करता है। इसके अतिरिक्त, एप्लिकेशन द्वारा इस मूल्य की प्रसंस्करण और समय सीमा समाप्त हो गए टोकनों की अस्वीकृति सुनिश्चित करने के लिए उचित जांचों का कार्यान्वयन महत्वपूर्ण है। यदि टोकन में "exp" दावा शामिल है और परीक्षण समय सीमाएं अनुमति देती हैं, तो टोकन को स्टोर करना और समय सीमा समाप्त होने के बाद इसे पुनः चलाने की सिफारिश की जाती है। टोकन की सामग्री, समय चिह्नांकन और समाप्ति की जांच (समय चिह्नांक UTC में) को jwt_tool के -R ध्वज का उपयोग करके पढ़ा जा सकता है।
* एक सुरक्षा जोखिम मौजूद हो सकता है यदि एप्लिकेशन अब भी टोकन की पुष्टि करता है, क्योंकि यह इस संकेत का अर्थ हो सकता है कि टोकन कभी समाप्त नहीं हो सकता।
यदि आप **हैकिंग करियर** में रुचि रखते हैं और अहैकेबल को हैक करना चाहते हैं - **हम नियुक्ति कर रहे हैं!** (_फ्लूएंट पोलिश लिखने और बोलने की आवश्यकता है_)
<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* यदि आप अपनी कंपनी का विज्ञापन देखना चाहते हैं या **PDF में HackTricks डाउनलोड** करना चाहते हैं तो [**सब्सक्रिप्शन प्लान**](https://github.com/sponsors/carlospolop) देखें!
