मैं कौन हूँ

मैं जुआन फेलिप ओज़ ( @JF0x0r ) हूँ, एक सुरक्षा शोधकर्ता जो ओपन सोर्स सुरक्षा के प्रति जुनूनी है। मैं यह काम इनाम के लिए नहीं करता, बल्कि इसलिए करता हूँ क्योंकि मुझे विश्वास है कि जिन उपकरणों पर लोग निर्भर करते हैं, वे सुरक्षित होने चाहिए। जब मुझे कुछ मिलता है, तो मैं इसे जिम्मेदारी से रिपोर्ट करता हूँ, उचित रूप से दस्तावेजीकरण करता हूँ, और ठीक होने के बाद सार्वजनिक रूप से साझा करता हूँ।

मुझे क्या मिला

osTicket के AJAX सबसिस्टम की मैन्युअल कोड समीक्षा करते समय, मैंने ajax.tickets.php में कुछ गड़बड़ देखी। viewField() फ़ंक्शन टिकट फ़ील्ड डेटा देखने के अनुरोधों को संभालता है - और यह टिकट ऑब्जेक्ट को पुनर्प्राप्त करता है और फ़ील्ड के अस्तित्व को मान्य करता है। लेकिन यह कभी जाँच नहीं करता कि अनुरोध करने वाले एजेंट के पास उस टिकट तक पहुँचने की अनुमति है या नहीं।

कोई checkStaffPerm() नहीं। कोई विभाग सत्यापन नहीं। कुछ नहीं।

इसका मतलब है कि कोई भी प्रमाणित एजेंट, यहाँ तक कि एक जो सख्ती से एक ही विभाग तक सीमित है, सिस्टम में किसी भी अन्य विभाग से टिकट फ़ील्ड पढ़ सकता है, बस ticket_id और field_id जानकर या अनुमान लगाकर। ये क्रमिक पूर्णांक हैं। गणना करना आसान है।

जो चीज़ इसे विशेष रूप से स्पष्ट बनाती है, वह है उसी फ़ाइल में ठीक ऊपर स्थित सहोदर फ़ंक्शन editField() के साथ तुलना। editField() सही ढंग से $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT) कॉल करता है और उल्लंघन पर HTTP 403 लौटाता है। फिक्स पहले से ही लिखने के लिए लागू किया गया था — इसे पढ़ने के लिए कभी लागू नहीं किया गया।

अवधारणा का प्रमाण: लाइव डेमो

मैंने एक नियंत्रित प्रयोगशाला वातावरण में शोषण का पूरा एंड-टू-एंड प्रदर्शन रिकॉर्ड किया:

वीडियो दिखाता है:

• दो पृथक विभागों (Dept-A और Dept-B) के साथ प्रयोगशाला सेटअप
• एजेंट agent_a केवल Dept-A तक पहुँच प्रतिबंधित के साथ प्रमाणित
• Dept-B के गोपनीय टिकट को लक्षित करने वाला अनधिकृत अनुरोध तैयार करना
• सर्वर द्वारा HTTP 200 लौटाना जिसमें प्रतिबंधित टिकट फ़ील्ड डेटा उजागर होता है
• पैच के बाद पुनरावृत्ति HTTP 403 — अनुमति अस्वीकृत दिखाती है

इस रिपॉजिटरी में exploit.py स्क्रिप्ट पूरी श्रृंखला (प्रमाणीकरण → गणना → अनधिकृत फ़ील्ड एक्सेस) को स्वचालित करती है और इसका उपयोग मूल्यांकन के दौरान यह पुष्टि करने के लिए किया गया था कि समस्या मैन्युअल परीक्षण से परे फैलती है।

प्रभाव

• संवेदनशील डेटा प्रकटीकरण - कोई भी एजेंट सभी विभागों में गोपनीय टिकट फ़ील्ड पढ़ सकता है
• क्षैतिज विशेषाधिकार वृद्धि - विभागीय सीमाएँ पूरी तरह से बाईपास हो जाती हैं
• सामूहिक गणना - क्रमिक ticket_id / field_id पूर्णांक बल्क स्क्रैपिंग को तुच्छ बनाते हैं
• बहु-किरायेदार गोपनीयता उल्लंघन - osTicket के विभाग पृथक्करण मॉडल के मूल डिज़ाइन सिद्धांत को विफल करता है

फिक्स

viewField() में एक पंक्ति का सम्मिलन, टिकट ऑब्जेक्ट प्राप्त होने के तुरंत बाद - बिल्कुल वैसा ही जैसा editField() पहले से सही ढंग से करता है। पूर्ण तकनीकी विवरण, डिफ़ और CVSS ब्रेकडाउन संलग्न रिपोर्ट में हैं।

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ आधिकारिक पैच (osTicket टीम द्वारा पुष्टि)

osTicket ने रिपोर्ट की पुष्टि की और अनुरोधित फ़ील्ड को हल/प्रस्तुत करने से पहले $ticket->checkStaffPerm($thisstaff) जोड़कर शमन लागू किया - यह जाँच पहले से ही editField() में मौजूद है। कर्मचारियों के पास अब फ़ील्ड डेटा देखने से पहले मूल टिकट तक पहुँच होनी चाहिए।

osTicket एक संक्षिप्त अपग्रेड बफर की सिफारिश करता है इससे पहले कि एक्सप्लॉइट चरणों को सार्वजनिक रूप से साझा किया जाए। यह रिपॉजिटरी उस मार्गदर्शन का पालन करता है - नीचे प्रकटीकरण समयरेखा देखें।

प्रकटीकरण समयरेखा

इस रिपॉजिटरी में फ़ाइलें

जिम्मेदार प्रकटीकरण

मैंने इसे प्रकाशित करने से पहले osTicket सुरक्षा टीम को निजी रूप से रिपोर्ट किया। यह रिपॉजिटरी केवल जिम्मेदार प्रकटीकरण विंडो के बाद सार्वजनिक की गई थी, और अब जब आधिकारिक पैच जारी हो चुका है, तो पूरा विवरण उपलब्ध है। यदि आप osTicket के रखरखावकर्ता हैं और आपके कोई प्रश्न हैं, तो सीधे GitHub के माध्यम से संपर्क करने में संकोच न करें।

द्वारा खोजा गया @JF0x0r · ओपन सोर्स सुरक्षा मायने रखती है।