Deserialization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Serialization को एक ऑब्जेक्ट को एक ऐसे प्रारूप में परिवर्तित करने की विधि के रूप में समझा जाता है जिसे संरक्षित किया जा सके, जिसका उद्देश्य या तो ऑब्जेक्ट को संग्रहीत करना है या इसे संचार प्रक्रिया के हिस्से के रूप में प्रसारित करना है। इस तकनीक का सामान्यत: उपयोग यह सुनिश्चित करने के लिए किया जाता है कि ऑब्जेक्ट को बाद में फिर से बनाया जा सके, इसकी संरचना और स्थिति को बनाए रखते हुए।
Deserialization, इसके विपरीत, वह प्रक्रिया है जो serialization का प्रतिकार करती है। इसमें उस डेटा को लेना शामिल है जिसे एक विशिष्ट प्रारूप में संरचित किया गया है और इसे फिर से एक ऑब्जेक्ट में पुनर्निर्माण करना शामिल है।
Deserialization खतरनाक हो सकता है क्योंकि यह संभावित रूप से हमलावरों को अनुक्रमित डेटा में हेरफेर करने की अनुमति देता है ताकि हानिकारक कोड निष्पादित किया जा सके या ऑब्जेक्ट पुनर्निर्माण प्रक्रिया के दौरान एप्लिकेशन में अप्रत्याशित व्यवहार उत्पन्न कर सके।
PHP में, serialization और deserialization प्रक्रियाओं के दौरान विशिष्ट जादुई विधियों का उपयोग किया जाता है:
__sleep
: जब एक ऑब्जेक्ट को अनुक्रमित किया जा रहा होता है, तब इसे बुलाया जाता है। यह विधि उन सभी गुणों के नामों का एक ऐरे लौटाना चाहिए जिन्हें अनुक्रमित किया जाना चाहिए। इसका सामान्यत: उपयोग लंबित डेटा को समर्पित करने या समान सफाई कार्य करने के लिए किया जाता है।
__wakeup
: जब एक ऑब्जेक्ट को deserialized किया जा रहा होता है, तब इसे बुलाया जाता है। इसका उपयोग उन किसी भी डेटाबेस कनेक्शनों को फिर से स्थापित करने के लिए किया जाता है जो serialization के दौरान खो गए हो सकते हैं और अन्य पुनः आरंभ कार्य करने के लिए।
__unserialize
: यह विधि __wakeup
के बजाय (यदि यह मौजूद है) तब बुलाई जाती है जब एक ऑब्जेक्ट को deserialized किया जा रहा होता है। यह __wakeup
की तुलना में deserialization प्रक्रिया पर अधिक नियंत्रण देती है।
__destruct
: यह विधि तब बुलाई जाती है जब एक ऑब्जेक्ट नष्ट होने वाला होता है या जब स्क्रिप्ट समाप्त होती है। इसका सामान्यत: उपयोग सफाई कार्यों के लिए किया जाता है, जैसे फ़ाइल हैंडल या डेटाबेस कनेक्शनों को बंद करना।
__toString
: यह विधि एक ऑब्जेक्ट को एक स्ट्रिंग के रूप में व्यवहार करने की अनुमति देती है। इसका उपयोग फ़ाइल पढ़ने या इसके भीतर फ़ंक्शन कॉल के आधार पर अन्य कार्यों के लिए किया जा सकता है, प्रभावी रूप से ऑब्जेक्ट का एक पाठ्य प्रतिनिधित्व प्रदान करता है।
यदि आप परिणामों को देखें तो आप देख सकते हैं कि फ़ंक्शन __wakeup
और __destruct
तब कॉल होते हैं जब ऑब्जेक्ट को डीसिरियलाइज़ किया जाता है। ध्यान दें कि कई ट्यूटोरियल में आप पाएंगे कि __toString
फ़ंक्शन तब कॉल होता है जब कुछ विशेषता को प्रिंट करने की कोशिश की जाती है, लेकिन स्पष्ट रूप से यह अब नहीं हो रहा है।
यदि इसे क्लास में लागू किया गया है, तो मेथड __unserialize(array $data)
__wakeup()
के बजाय कॉल किया जाता है। यह आपको ऑब्जेक्ट को डीसिरियलाइज़ करने की अनुमति देता है, जिसमें सीरियलाइज़ किया गया डेटा एक एरे के रूप में प्रदान किया जाता है। आप इस मेथड का उपयोग प्रॉपर्टीज़ को डीसिरियलाइज़ करने और डीसिरियलाइज़ेशन के दौरान आवश्यक कार्य करने के लिए कर सकते हैं।
आप एक समझाया हुआ PHP उदाहरण यहाँ पढ़ सकते हैं: https://www.notsosecure.com/remote-code-execution-via-php-unserialize/, यहाँ https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf या यहाँ https://securitycafe.ro/2015/01/05/understanding-php-object-injection/
आप PHP ऑटोलोड कार्यक्षमता का दुरुपयोग करके मनमाने php फ़ाइलों को लोड कर सकते हैं और अधिक:
यदि किसी कारणवश आप एक मान को दूसरे सीरियलाइज़ किए गए मान के संदर्भ के रूप में सीरियलाइज़ करना चाहते हैं, तो आप कर सकते हैं:
PHPGGC आपको PHP deserializations का दुरुपयोग करने के लिए payloads उत्पन्न करने में मदद कर सकता है।
ध्यान दें कि कई मामलों में आप ऐप्लिकेशन के स्रोत कोड में deserialization का दुरुपयोग करने का कोई तरीका नहीं पाएंगे लेकिन आप बाहरी PHP एक्सटेंशनों के कोड का दुरुपयोग कर सकते हैं।
तो, यदि आप कर सकते हैं, तो सर्वर का phpinfo()
जांचें और इंटरनेट पर खोजें (यहां तक कि PHPGGC के gadgets पर) कुछ संभावित gadgets जिन्हें आप दुरुपयोग कर सकते हैं।
यदि आपने एक LFI पाया है जो केवल फ़ाइल को पढ़ रहा है और इसके अंदर PHP कोड को निष्पादित नहीं कर रहा है, उदाहरण के लिए file_get_contents(), fopen(), file() या file_exists(), md5_file(), filemtime() या filesize()** का उपयोग करके।** आप phar प्रोटोकॉल का उपयोग करके फ़ाइल पढ़ते समय होने वाली deserialization का दुरुपयोग करने का प्रयास कर सकते हैं। अधिक जानकारी के लिए निम्नलिखित पोस्ट पढ़ें:
जब ऑब्जेक्ट unpickle होता है, तो फ़ंक्शन __reduce__ निष्पादित होगा। जब इसका दुरुपयोग किया जाता है, तो सर्वर एक त्रुटि वापस कर सकता है।
Before checking the bypass technique, try using print(base64.b64encode(pickle.dumps(P(),2)))
to generate an object that is compatible with python2 if you're running python3.
For more information about escaping from pickle jails check:
The following page present the technique to abuse an unsafe deserialization in yamls python libraries and finishes with a tool that can be used to generate RCE deserialization payload for Pickle, PyYAML, jsonpickle and ruamel.yaml:
JS के पास "जादुई" फ़ंक्शन नहीं हैं जैसे PHP या Python जो केवल एक ऑब्जेक्ट बनाने के लिए निष्पादित होंगे। लेकिन इसमें कुछ फ़ंक्शन हैं जो अक्सर बिना सीधे उन्हें कॉल किए उपयोग किए जाते हैं जैसे toString
, valueOf
, toJSON
।
यदि deserialization का दुरुपयोग करते हैं तो आप इन फ़ंक्शनों को अन्य कोड निष्पादित करने के लिए समझौता कर सकते हैं (संभावित रूप से प्रोटोटाइप प्रदूषण का दुरुपयोग करते हुए) जब इन्हें कॉल किया जाता है तो आप मनमाना कोड निष्पादित कर सकते हैं।
एक और "जादुई" तरीका एक फ़ंक्शन को कॉल करने का बिना सीधे इसे कॉल किए है एक ऑब्जेक्ट को समझौता करना जो एक async फ़ंक्शन द्वारा लौटाया जाता है (प्रॉमिस)। क्योंकि, यदि आप उस लौटाए गए ऑब्जेक्ट को एक अन्य प्रॉमिस में "then" नामक फ़ंक्शन प्रकार की प्रॉपर्टी के साथ परिवर्तित करते हैं, तो यह निष्पादित होगा बस इसलिए कि यह एक अन्य प्रॉमिस द्वारा लौटाया गया है। अधिक जानकारी के लिए इस लिंक का पालन करें.
__proto__
और prototype
प्रदूषणयदि आप इस तकनीक के बारे में जानना चाहते हैं तो निम्नलिखित ट्यूटोरियल पर एक नज़र डालें:
यह पुस्तकालय कार्यों को अनुक्रमित करने की अनुमति देता है। उदाहरण:
The serialised object will looks like: सीरियलाइज्ड ऑब्जेक्ट इस तरह दिखेगा:
आप उदाहरण में देख सकते हैं कि जब एक फ़ंक्शन को सीरियलाइज़ किया जाता है तो _$$ND_FUNC$$_
फ़्लैग सीरियलाइज़ किए गए ऑब्जेक्ट में जोड़ा जाता है।
फाइल node-serialize/lib/serialize.js
के अंदर आप वही फ़्लैग और कोड का उपयोग कैसे किया जा रहा है, पा सकते हैं।
जैसा कि आप अंतिम कोड के टुकड़े में देख सकते हैं, यदि फ़्लैग पाया जाता है तो eval
का उपयोग फ़ंक्शन को डीसिरियलाइज़ करने के लिए किया जाता है, इसलिए मूल रूप से उपयोगकर्ता इनपुट eval
फ़ंक्शन के अंदर उपयोग किया जा रहा है।
हालांकि, सिर्फ फ़ंक्शन को सीरियलाइज़ करना इसे निष्पादित नहीं करेगा क्योंकि यह आवश्यक होगा कि कोड का कुछ भाग y.rce
को कॉल कर रहा हो हमारे उदाहरण में और यह अत्यधिक असंभव है।
वैसे, आप बस सीरियलाइज़ किए गए ऑब्जेक्ट को संशोधित कर सकते हैं कुछ कोष्ठकों को जोड़कर ताकि जब ऑब्जेक्ट को डीसिरियलाइज़ किया जाए तो सीरियलाइज़ किया गया फ़ंक्शन स्वचालित रूप से निष्पादित हो जाए।
अगले कोड के टुकड़े में अंतिम कोष्ठक पर ध्यान दें और कैसे unserialize
फ़ंक्शन स्वचालित रूप से कोड को निष्पादित करेगा:
जैसा कि पहले संकेत दिया गया था, यह पुस्तकालय _$$ND_FUNC$$_
के बाद कोड प्राप्त करेगा और इसे eval
का उपयोग करके निष्पादित करेगा। इसलिए, कोड को स्वचालित रूप से निष्पादित करने के लिए आप कार्य निर्माण भाग और अंतिम कोष्ठक को हटा सकते हैं और बस एक JS एकल पंक्ति निष्पादित कर सकते हैं जैसे कि निम्नलिखित उदाहरण में:
आप यहाँ खोज सकते हैं इस कमजोरियों का शोषण करने के बारे में अधिक जानकारी।
funcster का एक महत्वपूर्ण पहलू मानक अंतर्निर्मित वस्तुओं की अनुपलब्धता है; ये सुलभ दायरे से बाहर हैं। यह प्रतिबंध उन कोडों के निष्पादन को रोकता है जो अंतर्निर्मित वस्तुओं पर विधियों को कॉल करने का प्रयास करते हैं, जिससे "ReferenceError: console is not defined"
जैसी अपवाद उत्पन्न होते हैं जब console.log()
या require(something)
जैसे कमांड का उपयोग किया जाता है।
इस सीमा के बावजूद, सभी मानक अंतर्निर्मित वस्तुओं सहित वैश्विक संदर्भ तक पूर्ण पहुंच को पुनर्स्थापित करना एक विशिष्ट दृष्टिकोण के माध्यम से संभव है। वैश्विक संदर्भ का सीधे लाभ उठाकर, कोई इस प्रतिबंध को बायपास कर सकता है। उदाहरण के लिए, निम्नलिखित स्निपेट का उपयोग करके पुनः पहुंच स्थापित की जा सकती है:
अधिक जानकारी के लिए इस स्रोत को पढ़ें यहाँ.
serialize-javascript पैकेज विशेष रूप से अनुक्रमण के उद्देश्यों के लिए डिज़ाइन किया गया है, जिसमें कोई अंतर्निहित अव्यवस्थित करने की क्षमताएँ नहीं हैं। उपयोगकर्ता अव्यवस्थित करने के लिए अपनी स्वयं की विधि लागू करने के लिए जिम्मेदार हैं। अनुक्रमित डेटा को अव्यवस्थित करने के लिए आधिकारिक उदाहरण द्वारा eval
का प्रत्यक्ष उपयोग सुझाया गया है:
यदि इस फ़ंक्शन का उपयोग ऑब्जेक्ट्स को डीसिरियलाइज़ करने के लिए किया जाता है, तो आप इसे आसानी से शोषण कर सकते हैं:
के लिए अधिक जानकारी के लिए इस स्रोत को पढ़ें.
निम्नलिखित पृष्ठों पर आप इस पुस्तकालय का दुरुपयोग करके मनमाने आदेशों को निष्पादित करने के बारे में जानकारी पा सकते हैं:
Java में, deserialization callbacks deserialization की प्रक्रिया के दौरान निष्पादित होते हैं। इस निष्पादन का दुरुपयोग उन हमलावरों द्वारा किया जा सकता है जो ऐसे दुर्भावनापूर्ण payloads तैयार करते हैं जो इन callbacks को ट्रिगर करते हैं, जिससे हानिकारक क्रियाओं के संभावित निष्पादन की संभावना होती है।
कोडबेस में संभावित serialization कमजोरियों की पहचान करने के लिए खोजें:
कक्षाएँ जो Serializable
इंटरफ़ेस को लागू करती हैं।
java.io.ObjectInputStream
, readObject
, readUnshare
फ़ंक्शंस का उपयोग।
विशेष ध्यान दें:
XMLDecoder
का उपयोग बाहरी उपयोगकर्ताओं द्वारा परिभाषित पैरामीटर के साथ किया गया।
XStream
का fromXML
विधि, विशेष रूप से यदि XStream संस्करण 1.46 या उससे कम है, क्योंकि यह serialization समस्याओं के प्रति संवेदनशील है।
ObjectInputStream
जो readObject
विधि के साथ जुड़ा हुआ है।
readObject
, readObjectNodData
, readResolve
, या readExternal
जैसी विधियों का कार्यान्वयन।
ObjectInputStream.readUnshared
।
Serializable
का सामान्य उपयोग।
ब्लैक बॉक्स परीक्षण के लिए, विशेष हस्ताक्षर या "मैजिक बाइट्स" की तलाश करें जो java serialized objects को दर्शाते हैं (जो ObjectInputStream
से उत्पन्न होते हैं):
हेक्साडेसिमल पैटर्न: AC ED 00 05
।
बेस64 पैटर्न: rO0
।
HTTP प्रतिक्रिया हेडर जिनमें Content-type
application/x-java-serialized-object
पर सेट है।
पूर्व संकुचन को दर्शाने वाला हेक्साडेसिमल पैटर्न: 1F 8B 08 00
।
पूर्व संकुचन को दर्शाने वाला बेस64 पैटर्न: H4sIA
।
.faces
एक्सटेंशन वाले वेब फ़ाइलें और faces.ViewState
पैरामीटर। इन पैटर्नों की खोज एक वेब एप्लिकेशन में एक परीक्षा का संकेत देती है जैसा कि Java JSF ViewState Deserialization के बारे में पोस्ट में विस्तृत किया गया है।
यदि आप जानना चाहते हैं कि Java Deserialized exploit कैसे काम करता है तो आपको Basic Java Deserialization, Java DNS Deserialization, और CommonsCollection1 Payload पर एक नज़र डालनी चाहिए।
आप यह जांच सकते हैं कि क्या कोई ऐसा एप्लिकेशन स्थापित है जिसमें ज्ञात कमजोरियाँ हैं।
आप सभी लाइब्रेरीज़ की जांच करने की कोशिश कर सकते हैं जो ज्ञात हैं कि वे कमजोर हैं और Ysoserial इसके लिए एक शोषण प्रदान कर सकता है। या आप Java-Deserialization-Cheat-Sheet पर निर्दिष्ट लाइब्रेरीज़ की जांच कर सकते हैं। आप संभावित गैजेट चेन खोजने के लिए gadgetinspector का भी उपयोग कर सकते हैं। gadgetinspector चलाते समय (इसे बनाने के बाद) उन सभी चेतावनियों/त्रुटियों की परवाह न करें जिनसे यह गुजर रहा है और इसे पूरा करने दें। यह सभी निष्कर्षों को gadgetinspector/gadget-results/gadget-chains-year-month-day-hore-min.txt के तहत लिखेगा। कृपया ध्यान दें कि gadgetinspector एक शोषण नहीं बनाएगा और यह झूठे सकारात्मक संकेत दे सकता है।
Burp एक्सटेंशन gadgetprobe का उपयोग करके आप कौन सी लाइब्रेरीज़ उपलब्ध हैं (और यहां तक कि संस्करण) की पहचान कर सकते हैं। इस जानकारी के साथ, कमजोरी का शोषण करने के लिए एक पेलोड चुनना आसान हो सकता है।
गैजेटप्रोब के बारे में अधिक जानने के लिए इसे पढ़ें।
GadgetProbe ObjectInputStream
deserializations पर केंद्रित है।
Burp एक्सटेंशन Java Deserialization Scanner का उपयोग करके आप कमजोर लाइब्रेरीज़ की पहचान कर सकते हैं जिन्हें ysoserial के साथ शोषित किया जा सकता है।
Java Deserialization Scanner के बारे में अधिक जानने के लिए इसे पढ़ें।
Java Deserialization Scanner ObjectInputStream
deserializations पर केंद्रित है।
आप Burp में deserializations कमजोरियों का पता लगाने के लिए Freddy का भी उपयोग कर सकते हैं। यह प्लगइन केवल ObjectInputStream
से संबंधित कमजोरियों का पता नहीं लगाएगा बल्कि Json और Yml deserialization लाइब्रेरीज़ से भी कमजोरियों का पता लगाएगा। सक्रिय मोड में, यह नींद या DNS पेलोड का उपयोग करके उन्हें पुष्टि करने की कोशिश करेगा।
आप यहां Freddy के बारे में अधिक जानकारी प्राप्त कर सकते हैं।
Serialization परीक्षण
सिर्फ यह जांचना नहीं है कि क्या कोई कमजोर लाइब्रेरी सर्वर द्वारा उपयोग की जा रही है। कभी-कभी आप serialized object के अंदर डेटा को बदलने और कुछ जांचों को बायपास करने में सक्षम हो सकते हैं (शायद आपको एक वेब ऐप के अंदर प्रशासनिक विशेषाधिकार प्रदान करें)। यदि आप एक जावा serialized object पाते हैं जो एक वेब एप्लिकेशन को भेजा जा रहा है, तो आप उपयोग कर सकते हैं SerializationDumper जिससे आप भेजे गए serialization object को अधिक मानव-पठनीय प्रारूप में प्रिंट कर सकते हैं। यह जानना कि आप कौन सा डेटा भेज रहे हैं, इसे संशोधित करना और कुछ जांचों को बायपास करना आसान होगा।
जावा deserializations का शोषण करने के लिए मुख्य उपकरण ysoserial है (यहां डाउनलोड करें)। आप ysoseral-modified का उपयोग करने पर भी विचार कर सकते हैं जो आपको जटिल कमांड (उदाहरण के लिए पाइप के साथ) का उपयोग करने की अनुमति देगा।
ध्यान दें कि यह उपकरण ObjectInputStream
के शोषण पर केंद्रित है।
मैं RCE पेलोड से पहले "URLDNS" पेलोड का उपयोग करना शुरू करूंगा यह परीक्षण करने के लिए कि क्या इंजेक्शन संभव है। वैसे भी, ध्यान दें कि शायद "URLDNS" पेलोड काम नहीं कर रहा है लेकिन अन्य RCE पेलोड काम कर रहा है।
जब java.lang.Runtime.exec() के लिए एक payload बनाते हैं, तो आप विशेष वर्ण जैसे ">" या "|" का उपयोग नहीं कर सकते हैं ताकि निष्पादन का आउटपुट पुनर्निर्देशित किया जा सके, "$()" का उपयोग करके आदेश निष्पादित कर सकें या यहां तक कि कमांड के लिए तर्क पास कर सकें जो स्पेस द्वारा अलग किए गए हों (आप echo -n "hello world"
कर सकते हैं लेकिन आप python2 -c 'print "Hello world"'
नहीं कर सकते)। payload को सही तरीके से एन्कोड करने के लिए आप इस वेबपेज का उपयोग कर सकते हैं।
Windows और Linux के लिए सभी संभावित कोड निष्पादन payloads बनाने के लिए अगले स्क्रिप्ट का उपयोग करने के लिए स्वतंत्र महसूस करें और फिर उन्हें कमजोर वेब पृष्ठ पर परीक्षण करें:
आप इसका उपयोग कर सकते हैं https://github.com/pwntester/SerialKillerBypassGadgetCollection और ysoserial के साथ अधिक एक्सप्लॉइट बनाने के लिए। इस टूल के बारे में अधिक जानकारी बातचीत की स्लाइड्स में है जहाँ टूल प्रस्तुत किया गया था: https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1
marshalsec का उपयोग विभिन्न Json और Yml सीरियलाइजेशन लाइब्रेरीज़ को एक्सप्लॉइट करने के लिए पेलोड बनाने के लिए किया जा सकता है।
प्रोजेक्ट को संकलित करने के लिए मुझे pom.xml
में ये dependencies जोड़नी थीं:
maven स्थापित करें, और परियोजना को संकलित करें:
इस Java JSON पुस्तकालय के बारे में अधिक पढ़ें: https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html
यदि आप कुछ ysoserial payloads का परीक्षण करना चाहते हैं, तो आप इस वेब ऐप को चला सकते हैं: https://github.com/hvqzao/java-deserialize-webapp
Java विभिन्न उद्देश्यों के लिए बहुत सारी serialization का उपयोग करता है जैसे:
HTTP requests: Serialization का व्यापक रूप से प्रबंधन के लिए उपयोग किया जाता है जैसे कि parameters, ViewState, cookies, आदि।
RMI (Remote Method Invocation): Java RMI प्रोटोकॉल, जो पूरी तरह से serialization पर निर्भर करता है, Java अनुप्रयोगों में दूरस्थ संचार के लिए एक आधारशिला है।
RMI over HTTP: यह विधि Java-आधारित मोटे क्लाइंट वेब अनुप्रयोगों द्वारा सामान्यतः उपयोग की जाती है, जो सभी ऑब्जेक्ट संचार के लिए serialization का उपयोग करती है।
JMX (Java Management Extensions): JMX नेटवर्क पर ऑब्जेक्ट्स को भेजने के लिए serialization का उपयोग करता है।
Custom Protocols: Java में, मानक प्रथा कच्चे Java ऑब्जेक्ट्स के संचरण में शामिल होती है, जिसे आगामी exploit उदाहरणों में प्रदर्शित किया जाएगा।
एक वर्ग जो Serializable
को लागू करता है, वह वर्ग के अंदर किसी भी ऑब्जेक्ट को transient
के रूप में लागू कर सकता है जिसे serializable नहीं होना चाहिए। उदाहरण के लिए:
उन परिदृश्यों में जहां कुछ ऑब्जेक्ट्स को Serializable
इंटरफेस को लागू करना आवश्यक है, वहां अनजाने में डीसिरियलाइजेशन का जोखिम होता है। इसे रोकने के लिए, सुनिश्चित करें कि ये ऑब्जेक्ट्स गैर-डीसिरियलाइज करने योग्य हैं, एक final
readObject()
मेथड को परिभाषित करके जो लगातार एक अपवाद फेंकता है, जैसा कि नीचे दिखाया गया है:
java.io.ObjectInputStream
को अनुकूलित करना deserialization प्रक्रियाओं को सुरक्षित करने के लिए एक व्यावहारिक दृष्टिकोण है। यह विधि तब उपयुक्त है जब:
Deserialization कोड आपके नियंत्रण में है।
Deserialization के लिए अपेक्षित कक्षाएँ ज्ञात हैं।
resolveClass()
विधि को ओवरराइड करें ताकि केवल अनुमत कक्षाओं तक deserialization सीमित हो सके। यह किसी भी कक्षा के deserialization को रोकता है सिवाय उन कक्षाओं के जो स्पष्ट रूप से अनुमत हैं, जैसे कि निम्नलिखित उदाहरण में जो deserialization को केवल Bicycle
कक्षा तक सीमित करता है:
सुरक्षा सुधार के लिए एक जावा एजेंट का उपयोग तब एक बैकअप समाधान प्रदान करता है जब कोड संशोधन संभव नहीं होता। यह विधि मुख्य रूप से हानिकारक कक्षाओं की ब्लैकलिस्टिंग के लिए लागू होती है, एक JVM पैरामीटर का उपयोग करते हुए:
यह गतिशील रूप से डेसिरियलाइजेशन को सुरक्षित करने का एक तरीका प्रदान करता है, जो उन वातावरणों के लिए आदर्श है जहाँ तात्कालिक कोड परिवर्तन व्यावहारिक नहीं हैं।
एक उदाहरण देखें rO0 by Contrast Security
Serialization Filters को लागू करना: Java 9 ने ObjectInputFilter
इंटरफ़ेस के माध्यम से serialization filters पेश किए, जो डेसिरियलाइजेशन से पहले serialized वस्तुओं को पूरा करने के लिए मानदंड निर्दिष्ट करने के लिए एक शक्तिशाली तंत्र प्रदान करते हैं। ये फ़िल्टर वैश्विक रूप से या प्रति स्ट्रीम लागू किए जा सकते हैं, जो डेसिरियलाइजेशन प्रक्रिया पर बारीक नियंत्रण प्रदान करते हैं।
Serialization filters का उपयोग करने के लिए, आप एक वैश्विक फ़िल्टर सेट कर सकते हैं जो सभी डेसिरियलाइजेशन संचालन पर लागू होता है या इसे विशिष्ट स्ट्रीम के लिए गतिशील रूप से कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए:
बाहरी पुस्तकालयों का लाभ उठाना सुरक्षा को बढ़ाने के लिए: पुस्तकालय जैसे NotSoSerial, jdeserialize, और Kryo जावा डेसिरियलाइजेशन को नियंत्रित और मॉनिटर करने के लिए उन्नत सुविधाएँ प्रदान करते हैं। ये पुस्तकालय अतिरिक्त सुरक्षा परतें प्रदान कर सकते हैं, जैसे कि कक्षाओं की व्हाइटलिस्टिंग या ब्लैकलिस्टिंग, डेसिरियलाइजेशन से पहले अनुक्रमित वस्तुओं का विश्लेषण करना, और कस्टम अनुक्रमण रणनीतियों को लागू करना।
NotSoSerial डेसिरियलाइजेशन प्रक्रियाओं को रोकता है ताकि अविश्वसनीय कोड का निष्पादन न हो सके।
jdeserialize अनुक्रमित जावा वस्तुओं का विश्लेषण करने की अनुमति देता है बिना उन्हें डेसिरियलाइज किए, संभावित रूप से दुर्भावनापूर्ण सामग्री की पहचान करने में मदद करता है।
Kryo एक वैकल्पिक अनुक्रमण ढांचा है जो गति और दक्षता पर जोर देता है, कॉन्फ़िगर करने योग्य अनुक्रमण रणनीतियाँ प्रदान करता है जो सुरक्षा को बढ़ा सकती हैं।
डेसिरियलाइजेशन और ysoserial वार्ता: http://frohoff.github.io/appseccali-marshalling-pickles/
gadgetinspector के बारे में वार्ता: https://www.youtube.com/watch?v=wPbW6zQ52w8 और स्लाइड: https://i.blackhat.com/us-18/Thu-August-9/us-18-Haken-Automated-Discovery-of-Deserialization-Gadget-Chains.pdf
जावा और .Net JSON डेसिरियलाइजेशन पेपर: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, वार्ता: https://www.youtube.com/watch?v=oUAeWhW5b8c और स्लाइड: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
डेसिरियलाइजेशन CVEs: https://paper.seebug.org/123/
जानें कि JNDI इंजेक्शन क्या है, इसे RMI, CORBA और LDAP के माध्यम से कैसे दुरुपयोग करें और log4shell का शोषण कैसे करें (और इस कमजोरियों का उदाहरण) निम्नलिखित पृष्ठ में:
जावा संदेश सेवा (JMS) API एक जावा संदेश-उन्मुख मध्यवर्ती API है जो दो या अधिक क्लाइंट के बीच संदेश भेजने के लिए है। यह उत्पादक-उपभोक्ता समस्या को संभालने के लिए एक कार्यान्वयन है। JMS जावा प्लेटफ़ॉर्म, एंटरप्राइज संस्करण (Java EE) का एक हिस्सा है, और इसे सन माइक्रोसिस्टम्स द्वारा विकसित एक विनिर्देशन द्वारा परिभाषित किया गया था, लेकिन तब से इसे जावा समुदाय प्रक्रिया द्वारा मार्गदर्शित किया गया है। यह एक संदेश मानक है जो जावा EE पर आधारित अनुप्रयोग घटकों को संदेश बनाने, भेजने, प्राप्त करने और पढ़ने की अनुमति देता है। यह एक वितरित अनुप्रयोग के विभिन्न घटकों के बीच संचार को ढीला, विश्वसनीय और असिंक्रोनस बनाता है। (स्रोत विकिपीडिया)।
इस मध्यवर्ती का उपयोग करके संदेश भेजने वाले कई उत्पाद हैं:
तो, मूल रूप से, JMS का उपयोग करने वाली कई सेवाएँ खतरनाक तरीके से हैं। इसलिए, यदि आपके पास इन सेवाओं को संदेश भेजने के लिए पर्याप्त विशेषाधिकार हैं (आमतौर पर आपको मान्य क्रेडेंशियल की आवश्यकता होगी) तो आप दुर्भावनापूर्ण वस्तुएँ भेजने में सक्षम हो सकते हैं जो उपभोक्ता/सदस्य द्वारा डेसिरियलाइज की जाएंगी। इसका मतलब है कि इस शोषण में सभी क्लाइंट जो उस संदेश का उपयोग करने जा रहे हैं संक्रमित हो जाएंगे।
आपको याद रखना चाहिए कि भले ही कोई सेवा कमजोर हो (क्योंकि यह उपयोगकर्ता इनपुट को असुरक्षित रूप से डेसिरियलाइज कर रही है) आपको अभी भी कमजोरियों का शोषण करने के लिए मान्य गैजेट खोजने की आवश्यकता है।
उपकरण JMET को इन सेवाओं से कनेक्ट और हमला करने के लिए बनाया गया था, जो ज्ञात गैजेट्स का उपयोग करके कई दुर्भावनापूर्ण वस्तुएँ भेजता है। ये शोषण तब काम करेंगे जब सेवा अभी भी कमजोर हो और यदि उपयोग किए गए गैजेट में से कोई भी कमजोर अनुप्रयोग के अंदर हो।
JMET वार्ता: https://www.youtube.com/watch?v=0h8DWiOWGGA
.Net के संदर्भ में, डेसिरियलाइजेशन शोषण जावा में पाए जाने वाले तरीकों के समान काम करते हैं, जहां गैजेट्स का शोषण किया जाता है ताकि किसी वस्तु के डेसिरियलाइजेशन के दौरान विशिष्ट कोड चल सके।
स्रोत कोड की जांच की जानी चाहिए कि:
TypeNameHandling
JavaScriptTypeResolver
ध्यान उन अनुक्रमकों पर होना चाहिए जो उपयोगकर्ता नियंत्रण के तहत एक चर द्वारा प्रकार निर्धारित करने की अनुमति देते हैं।
खोज को बेस64 एन्कोडेड स्ट्रिंग AAEAAAD///// या किसी समान पैटर्न पर लक्षित किया जाना चाहिए जो सर्वर-साइड पर डेसिरियलाइज हो सकता है, जिससे डेसिरियलाइज होने वाले प्रकार पर नियंत्रण प्राप्त होता है। इसमें शामिल हो सकता है, लेकिन सीमित नहीं है, JSON या XML संरचनाएँ जिनमें TypeObject
या $type
शामिल हैं।
इस मामले में आप उपकरण ysoserial.net का उपयोग कर सकते हैं ताकि डेसिरियलाइजेशन शोषण बनाए जा सकें। एक बार गिट रिपॉजिटरी डाउनलोड करने के बाद, आपको उपकरण को संकलित करना चाहिए उदाहरण के लिए Visual Studio का उपयोग करके।
यदि आप जानना चाहते हैं कि ysoserial.net अपने शोषण को कैसे बनाता है तो आप इस पृष्ठ की जांच कर सकते हैं जहां ObjectDataProvider गैजेट + ExpandedWrapper + Json.Net फॉर्मेटर समझाया गया है।
ysoserial.net के मुख्य विकल्प हैं: --gadget
, --formatter
, --output
और --plugin
।
--gadget
का उपयोग शोषण करने के लिए गैजेट को इंगित करने के लिए किया जाता है (उस कक्षा/कार्य को इंगित करें जिसका शोषण डेसिरियलाइजेशन के दौरान आदेश निष्पादित करने के लिए किया जाएगा)।
--formatter
, शोषण को अनुक्रमित करने के लिए विधि को इंगित करने के लिए उपयोग किया जाता है (आपको यह जानने की आवश्यकता है कि बैक-एंड किस पुस्तकालय का उपयोग कर रहा है ताकि लोड को डेसिरियलाइज किया जा सके और उसी का उपयोग करके इसे अनुक्रमित किया जा सके)।
--output
का उपयोग यह इंगित करने के लिए किया जाता है कि क्या आप शोषण को कच्चे या बेस64 एन्कोडेड में चाहते हैं। ध्यान दें कि ysoserial.net लोड को UTF-16LE (Windows पर डिफ़ॉल्ट रूप से उपयोग की जाने वाली एन्कोडिंग) का उपयोग करके एन्कोड करेगा, इसलिए यदि आप कच्चे लोड को प्राप्त करते हैं और इसे लिनक्स कंसोल से केवल एन्कोड करते हैं, तो आपको कुछ एन्कोडिंग संगतता समस्याएँ हो सकती हैं जो शोषण को सही तरीके से काम करने से रोक सकती हैं (HTB JSON बॉक्स में लोड UTF-16LE और ASCII दोनों में काम करता है लेकिन इसका मतलब यह नहीं है कि यह हमेशा काम करेगा)।
--plugin
ysoserial.net विशिष्ट ढांचों के लिए शोषण बनाने के लिए प्लगइन्स का समर्थन करता है जैसे ViewState
--minify
एक छोटा लोड प्रदान करेगा (यदि संभव हो)।
--raf -f Json.Net -c "anything"
यह सभी गैजेट्स को इंगित करेगा जो एक प्रदान किए गए फॉर्मेटर (Json.Net
इस मामले में) के साथ उपयोग किए जा सकते हैं।
--sf xml
आप एक गैजेट (-g
) को इंगित कर सकते हैं और ysoserial.net "xml" (केस संवेदनशील नहीं) वाले फॉर्मेटर्स की खोज करेगा।
ysoserial उदाहरण शोषण बनाने के लिए:
ysoserial.net में एक बहुत दिलचस्प पैरामीटर है जो हर एक्सप्लॉइट के काम करने के तरीके को बेहतर समझने में मदद करता है: --test
यदि आप इस पैरामीटर को इंगित करते हैं, तो ysoserial.net स्थानीय रूप से एक्सप्लॉइट करने की कोशिश करेगा, ताकि आप यह परीक्षण कर सकें कि आपका पेलोड सही ढंग से काम करेगा या नहीं।
यह पैरामीटर सहायक है क्योंकि यदि आप कोड की समीक्षा करते हैं, तो आप निम्नलिखित कोड के टुकड़े पाएंगे (से ObjectDataProviderGenerator.cs):
इसका मतलब है कि एक्सप्लॉइट का परीक्षण करने के लिए कोड serializersHelper.JsonNet_deserialize को कॉल करेगा।
In the पिछले कोड में बनाए गए एक्सप्लॉइट के लिए संवेदनशीलता है। इसलिए यदि आप किसी .Net एप्लिकेशन में कुछ समान पाते हैं, तो इसका मतलब है कि वह एप्लिकेशन भी संभवतः संवेदनशील है।
इसलिए --test
पैरामीटर हमें यह समझने की अनुमति देता है कि कौन से कोड के टुकड़े deserialization एक्सप्लॉइट के लिए संवेदनशील हैं जो ysoserial.net बना सकता है।
कैसे .Net के __ViewState पैरामीटर का शोषण करने की कोशिश करें को देखें ताकि मनमाने कोड को निष्पादित किया जा सके। यदि आप पहले से ही पीड़ित मशीन द्वारा उपयोग किए गए रहस्यों को जानते हैं, तो कोड निष्पादित करने के लिए यह पोस्ट पढ़ें।
.Net में deserialization से संबंधित जोखिमों को कम करने के लिए:
डेटा स्ट्रीम को उनके ऑब्जेक्ट प्रकारों को परिभाषित करने की अनुमति देने से बचें। जब संभव हो, DataContractSerializer
या XmlSerializer
का उपयोग करें।
JSON.Net
के लिए, TypeNameHandling
को None
पर सेट करें: %%%TypeNameHandling = TypeNameHandling.None%%%
JavaScriptSerializer
का उपयोग JavaScriptTypeResolver
के साथ करने से बचें।
उन प्रकारों की सीमा निर्धारित करें जिन्हें deserialized किया जा सकता है, .Net प्रकारों के अंतर्निहित जोखिमों को समझते हुए, जैसे System.IO.FileInfo
, जो सर्वर फ़ाइलों की संपत्तियों को संशोधित कर सकता है, जिससे सेवा से इनकार के हमलों की संभावना हो सकती है।
खतरनाक गुणों वाले प्रकारों के साथ सतर्क रहें, जैसे System.ComponentModel.DataAnnotations.ValidationException
इसके Value
गुण के साथ, जिसका शोषण किया जा सकता है।
प्रकार के निर्माण को सुरक्षित रूप से नियंत्रित करें ताकि हमलावर deserialization प्रक्रिया को प्रभावित न कर सकें, जिससे DataContractSerializer
या XmlSerializer
भी संवेदनशील हो जाएं।
BinaryFormatter
और JSON.Net
के लिए एक कस्टम SerializationBinder
का उपयोग करके श्वेत सूची नियंत्रण लागू करें।
.Net में ज्ञात असुरक्षित deserialization गैजेट्स के बारे में सूचित रहें और सुनिश्चित करें कि deserializers ऐसे प्रकारों का निर्माण न करें।
संभावित खतरनाक कोड को इंटरनेट एक्सेस वाले कोड से अलग करें ताकि ज्ञात गैजेट्स, जैसे WPF एप्लिकेशनों में System.Windows.Data.ObjectDataProvider
, को अविश्वसनीय डेटा स्रोतों के लिए उजागर करने से बचा जा सके।
Java और .Net JSON deserialization पेपर: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, टॉक: https://www.youtube.com/watch?v=oUAeWhW5b8c और स्लाइड: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
Ruby में, serialization marshal पुस्तकालय के भीतर दो विधियों द्वारा सुगम बनाया गया है। पहली विधि, जिसे dump के रूप में जाना जाता है, का उपयोग एक ऑब्जेक्ट को बाइट स्ट्रीम में परिवर्तित करने के लिए किया जाता है। इस प्रक्रिया को serialization कहा जाता है। इसके विपरीत, दूसरी विधि, load, का उपयोग बाइट स्ट्रीम को वापस एक ऑब्जेक्ट में परिवर्तित करने के लिए किया जाता है, जिसे deserialization कहा जाता है।
Serialized ऑब्जेक्ट्स को सुरक्षित करने के लिए, Ruby HMAC (Hash-Based Message Authentication Code) का उपयोग करता है, जो डेटा की अखंडता और प्रामाणिकता सुनिश्चित करता है। इस उद्देश्य के लिए उपयोग की जाने वाली कुंजी कई संभावित स्थानों में से एक में संग्रहीत होती है:
config/environment.rb
config/initializers/secret_token.rb
config/secrets.yml
/proc/self/environ
Ruby 2.X सामान्य deserialization से RCE गैजेट श्रृंखला (अधिक जानकारी के लिए https://www.elttam.com/blog/ruby-deserialization/):
अन्य RCE श्रृंखला जो Ruby On Rails का शोषण करती है: https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/
जैसा कि इस सुरक्षा रिपोर्ट में समझाया गया है, यदि कुछ उपयोगकर्ता का असंसाधित इनपुट एक ruby ऑब्जेक्ट की .send()
विधि तक पहुँचता है, तो यह विधि ऑब्जेक्ट के किसी भी अन्य विधि को किसी भी पैरामीटर के साथ आमंत्रित करने की अनुमति देती है।
उदाहरण के लिए, eval को कॉल करना और फिर ruby कोड को दूसरे पैरामीटर के रूप में देना मनमाने कोड को निष्पादित करने की अनुमति देगा:
इसके अलावा, यदि केवल एक पैरामीटर .send()
का एक हमलावर द्वारा नियंत्रित किया जाता है, जैसा कि पिछले लेख में उल्लेख किया गया है, तो किसी भी ऐसे ऑब्जेक्ट के मेथड को कॉल करना संभव है जिसे आर्गुमेंट्स की आवश्यकता नहीं है या जिनके आर्गुमेंट्स के डिफ़ॉल्ट मान हैं।
इसके लिए, ऑब्जेक्ट के सभी मेथड्स को उन आवश्यकताओं को पूरा करने वाले कुछ दिलचस्प मेथड्स खोजने के लिए एन्यूमरेट करना संभव है।
यह तकनीक इस ब्लॉग पोस्ट से ली गई थी।
अन्य Ruby पुस्तकालय हैं जिन्हें ऑब्जेक्ट्स को सीरियलाइज़ करने के लिए उपयोग किया जा सकता है और इसलिए इसका दुरुपयोग करके असुरक्षित डेसिरियलाइजेशन के दौरान RCE प्राप्त किया जा सकता है। निम्नलिखित तालिका इनमें से कुछ पुस्तकालयों और उन विधियों को दिखाती है जिन्हें लोड की गई पुस्तकालय के अनसीरियलाइज होने पर कॉल किया जाता है (RCE प्राप्त करने के लिए दुरुपयोग करने के लिए मूल रूप से कार्य):
पुस्तकालय
इनपुट डेटा
क्लास के अंदर किक-ऑफ विधि
Marshal (Ruby)
बाइनरी
_load
Oj
JSON
hash
(क्लास को हैश(map) में कुंजी के रूप में डालना आवश्यक है)
Ox
XML
hash
(क्लास को हैश(map) में कुंजी के रूप में डालना आवश्यक है)
Psych (Ruby)
YAML
hash
(क्लास को हैश(map) में कुंजी के रूप में डालना आवश्यक है)
init_with
JSON (Ruby)
JSON
json_create
([json_create के बारे में नोट्स देखें अंत में](#table-vulnerable-sinks))
बुनियादी उदाहरण:
Oj का दुरुपयोग करने की कोशिश के मामले में, एक गैजेट क्लास मिलना संभव था जो अपने hash
फ़ंक्शन के अंदर to_s
को कॉल करेगा, जो spec को कॉल करेगा, जो fetch_path को कॉल करेगा, जिससे इसे एक यादृच्छिक URL लाने के लिए बनाया जा सकता था, जो इन प्रकार की अस्वच्छ deserialization कमजोरियों का एक बड़ा डिटेक्टर प्रदान करता है।
इसके अलावा, यह पाया गया कि पिछले तकनीक के साथ एक फ़ोल्डर भी सिस्टम में बनाया जाता है, जो एक अन्य गैजेट का दुरुपयोग करने की आवश्यकता है ताकि इसे कुछ इस तरह से पूर्ण RCE में परिवर्तित किया जा सके:
Check for more details in the original post.
सीखें और AWS हैकिंग का अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) सीखें और GCP हैकिंग का अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)