sarpantkeltiek/cve-2024-37010CVE-2024-37010 के लिए शोषण: अन्य उपयोगकर्ता के बाहरी भंडारण तक पहुंच और पार्श्व गति
CVE-2024-37010 के लिए शोषण: अन्य उपयोगकर्ता के बाहरी संग्रहण और पार्श्व गति तक पहुंच:
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
Owncloud एक सर्वर को फ़ाइलों को संग्रहीत करने के लिए एक क्लाउड में बदल देता है, जैसे Google Drive। यह कंपनियों को, उदाहरण के लिए, कर्मचारियों के लिए एक क्लाउड प्रदान करने में सक्षम बनाता है, बिना इसे किसी तीसरे पक्ष द्वारा प्रबंधित किए।
यदि प्रशासकों ने इसे इस तरह से कॉन्फ़िगर किया है, तो उपयोगकर्ता फ़ाइलों को एक ही क्लाउड पर केंद्रीकृत करने और इस प्रकार उपयोगकर्ताओं के लिए जीवन को आसान बनाने के लिए बाहरी संग्रहण, जैसे अन्य क्लाउड, FTP या Google Drive, को भी कनेक्ट कर सकते हैं।
एक बार जब हम अपना बाहरी संग्रहण बना लेते हैं, तो हम इस फ़ॉर्म को अपडेट करके, उदाहरण के लिए, "फ़ोल्डर नाम" फ़ील्ड को बदल सकते हैं। जब फ़ॉर्म अपडेट किया जाता है, तो JSON प्रारूप में पूरे फ़ॉर्म के साथ एक अनुरोध भेजा जाता है। इस फ़ॉर्म में, 'ID' फ़ील्ड, एक पूर्णांक होने के नाते, हमारे बाहरी संग्रहण का पहचानकर्ता है, जो सर्वर द्वारा हमारे संग्रहण बनाने पर उत्पन्न होता है।
आइए कल्पना करें कि Owncloud पर एक अन्य उपयोगकर्ता, उदाहरण के लिए प्रशासक, के पास भी बाहरी संग्रहण है, जिसका ID "18" है।
अब, चलिए "normal_user" उपयोगकर्ता के रूप में, बिना किसी विशेष अधिकार के, फ़ॉर्म अपडेट अनुरोध को फिर से चलाते हैं, लेकिन ID को 18, प्रशासक के बाहरी संग्रहण में बदल देते हैं।
![[images/req.png]](images/req.png)
एक बार अनुरोध भेजे जाने के बाद, सर्वर को 404 त्रुटि (4) का सामना करना पड़ता है और वह हमें बताता है कि उसे हमारे द्वारा निर्दिष्ट ID के साथ कोई संग्रहण नहीं मिला है (5)।
हालांकि, जब हम प्रशासक खाते से कनेक्ट करते हैं, तो हम यह देखते हैं:
![[pwned_article.png]](images/pwned_article.png)
प्रशासक का संग्रहण अपडेट कर दिया गया है।
यदि हम "normal_user" के रूप में फिर से लॉग इन करते हैं, तो हम देख सकते हैं कि अब हमारे पास "storage_pwned", प्रशासक के संग्रहण तक पहुंच है।
![[access.png]](images/access.png)
उपयोगकर्ता A उपयोगकर्ता B के संग्रहण को अपडेट करने और उस तक पहुंच अधिकार पुनः प्राप्त करने में सफल रहा। हम आपको याद दिलाते हैं कि उपयोगकर्ता A को अपडेट अनुरोध के दौरान होस्ट को संशोधित नहीं करना चाहिए, ताकि उपयोगकर्ता B के कॉन्फ़िगरेशन को न तोड़े और फिर बाद की फ़ाइलों तक पहुंच सके।
यहाँ बाहरी संग्रहण को अपडेट करने के लिए उपयोग किया गया कोड है।
![[Pasted image 20241016114714.png]](images/2.png)
सबसे पहले, हम देख सकते हैं कि अनुरोध करने वाले उपयोगकर्ता के अधिकारों का कोई सत्यापन नहीं है। कोड यह जांच नहीं करता है कि संग्रहण अनुरोध करने वाले उपयोगकर्ता का है या नहीं। यह बताता है कि "normal_user" प्रशासक के संग्रहण को अपडेट करने में सक्षम क्यों था।
दूसरा, हम देख सकते हैं कि प्रत्येक अपडेट पर, कोड अनुरोध करने वाले उपयोगकर्ता को संग्रहण से कनेक्ट करने के लिए अधिकृत उपयोगकर्ताओं में जोड़ता है, इस प्रकार यह बताता है कि क्यों "normal_user" को अपडेट के बाद जादुई रूप से प्रशासक के संग्रहण तक पहुंच प्रदान की गई।
इस उदाहरण में, हमने देखा है कि कैसे एक उपयोगकर्ता के लिए किसी अन्य उपयोगकर्ता के बाहरी संग्रहण तक पूर्ण पहुंच प्राप्त करना और इस प्रकार उनकी व्यक्तिगत फ़ाइलों तक पहुंच प्राप्त करना संभव था। यह पहले से ही इसे काफी महत्वपूर्ण भेद्यता बनाता है।
इस स्तर पर, जैसा कि आप देख सकते हैं, यह IDOR (असुरक्षित प्रत्यक्ष वस्तु संदर्भ) पहले से ही एक प्रमुख भेद्यता है। लेकिन आइए इसका प्रभाव बढ़ाने के लिए इसे शोषण करना जारी रखने का प्रयास करें।
ऐसा करने के लिए, फ़ाइलों को पुनर्प्राप्त करने के लिए Owncloud सर्वर द्वारा बाहरी संग्रहण के लिए किए गए प्रमाणीकरण प्रक्रिया को समझें। एक साधारण लॉगिन/पासवर्ड जोड़ी का उपयोग करने वाले बुनियादी प्रमाणीकरण सिस्टम के लिए, क्लाउड सर्वर बस
![[Pasted image 20241017162909.png]](images/20241017162909.png)
अब, आइए कल्पना करें कि एक हमलावर इस कॉन्फ़िगरेशन को अपडेट करके होस्ट को एक ऐसे पते पर बदलने का प्रबंधन करता है जिसे वह नियंत्रित करता है। इसका मतलब है कि Owncloud सर्वर अब क्रेडेंशियल्स को इस नए पते पर भेजेगा, जो हमलावर द्वारा नियंत्रित है।
![[Pasted image 20241017163143.png]](images/20241017163143.png)
यह वही है जो हम अपनी भेद्यता के कारण कर सकते हैं।
जब हम किसी अन्य उपयोगकर्ता के संग्रहण ID को निर्दिष्ट करके अपडेट अनुरोध को पुनः चलाते हैं, तो हमें केवल होस्ट को बदलना होता है, उदाहरण के लिए, हमारा collaborator Burp निर्दिष्ट करके।
![[Pasted image 20241017163326.png]](images/20241017163326.png)
इस तरह, जब उपयोगकर्ता पुनः कनेक्ट होता है, तो Owncloud सर्वर उपयोगकर्ता के क्रेडेंशियल्स भेजकर हमारे collaborator से प्रमाणीकरण करने का प्रयास करता है।
![[Pasted image 20241017163644.png]](images/20241017163644.png)
जादुई रूप से, collaborator Owncloud सर्वर से Base64-एन्कोडेड क्रेडेंशियल्स के साथ प्रमाणीकरण अनुरोध प्राप्त करता है।
![[Pasted image 20241017163945.png]](images/20241017163945.png)
इसलिए हमने अभी-अभी प्रशासक के बाहरी संग्रहण के स्पष्ट पाठ क्रेडेंशियल्स को पुनर्प्राप्त किया है।
बाहरी संग्रहण पर प्रमाणीकरण के लिए, आप लॉग इन करने के लिए अपने स्वयं के Owncloud क्रेडेंशियल्स का उपयोग कर सकते हैं, यदि आप उदाहरण के लिए एक ही पासवर्ड का उपयोग करते हैं। बाहरी संग्रहण अपडेट का अनुरोध करते समय, आप "authMechanism" फ़ील्ड में "password::sessioncredentials" निर्दिष्ट कर सकते हैं।
Owncloud सर्वर तब अगली बार कनेक्ट होने पर हमारे क्रेडेंशियल्स को स्पष्ट पाठ में सहेज लेगा, और उन्हें प्रमाणीकरण के लिए हमारे बाहरी संग्रहण डिवाइस पर स्थानांतरित कर देगा।
तो आप देख सकते हैं कि क्या होने वाला है...
इसका मतलब है कि एक हमलावर इस तंत्र को किसी अन्य उपयोगकर्ता के बाहरी संग्रहण के लिए भी सक्रिय कर सकता है और इस प्रकार पीड़ित के Owncloud सत्र के स्पष्ट पाठ क्रेडेंशियल्स को एक ऐसे होस्ट पर स्थानांतरित कर सकता है जिसे वह नियंत्रित करता है, जैसा कि हमने अभी किया है।
CVE-2024-37010 इस प्रकार Owncloud सर्वर पर खाता रखने वाले हमलावर को अनुमति देता है:
