CVE-2025-56380 — Frappe / ERPNext में टाइम-आधारित ब्लाइंड SQL इंजेक्शन (frappe.client.get_value)

📌 सारांश Frappe Framework v15.72.4 में frappe.client.get_value API एंडपॉइंट में एक टाइम-आधारित ब्लाइंड SQL इंजेक्शन भेद्यता पाई गई है (और ERPNext v15.67.0 कोडबेस में मौजूद है)। reporting/client API तक पहुँच रखने वाला एक प्रमाणित उपयोगकर्ता fieldname पैरामीटर के माध्यम से SQL इंजेक्ट कर सकता है। fieldname पैरामीटर में टाइम-डिले फ़ंक्शन (जैसे, sleep(15)) डालकर, एक हमलावर मापने योग्य प्रतिक्रिया विलंबों के माध्यम से इंजेक्शन की पुष्टि कर सकता है — जिससे denial of service, सूचना प्रकटीकरण (ब्लाइंड तकनीकों के माध्यम से), और डेटा हेरफेर संभव हो जाता है।

🛠 तकनीकी विवरण

• भेद्यता प्रकार: SQL इंजेक्शन (टाइम-आधारित ब्लाइंड) (CWE‑89)

• प्रभावित उत्पाद: Frappe Framework / ERPNext

• प्रभावित संस्करण (रिपोर्ट किए गए):

  • Frappe — 15.72.4
  • ERPNext — 15.67.0 (समान कोडबेस प्रभावित)

• प्रभावित घटक: frappe.client.get_value API विधि (frappe/client.py)

• संवेदनशील एंडपॉइंट:

  root@kitploit:~

  /api/method/frappe.client.get_value
  

  संवेदनशील क्वेरी का उदाहरण:

  root@kitploit:~

  /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893
  

• संवेदनशील पैरामीटर: fieldname (अनुचित रूप से सैनिटाइज़ किया गया / SQL में संयोजित)

• हमले का प्रकार: रिमोट (प्रमाणीकरण और reporting API तक पहुँच आवश्यक)

• गंभीरता: उच्च (टाइम-आधारित ब्लाइंड SQLi डेटा एक्सफिल्ट्रेशन, DoS और हेरफेर सक्षम बनाता है)

• अनुमानित CVSS v3.1 स्कोर: 8.0 (उच्च) — अनुमान रिमोट प्रमाणीकरण-आवश्यक SQL इंजेक्शन पर आधारित है जो डेटा प्रकटीकरण और DoS सक्षम करता है; आधिकारिक स्कोरिंग असाइनर्स द्वारा की जानी चाहिए।

• स्थिति: ठीक नहीं किया गया (जैसा रिपोर्ट किया गया है)

• खोजकर्ता: मोहम्मद अलोली (GitHub: https://github.com/MoAlali)

• खोज की तिथि: रिपोर्ट में निर्दिष्ट नहीं है

• CVE ID: CVE-2025-56380

🚀 प्रूफ ऑफ कॉन्सेप्ट (PoC) — टाइम-आधारित ब्लाइंड SQLi

केवल अधिकृत / लैब वातावरण में परीक्षण करें। उन सिस्टमों पर न चलाएँ जिनके मालिक आप नहीं हैं या जिनके परीक्षण की स्पष्ट अनुमति आपके पास नहीं है।

PoC अनुरोध (उदाहरण):

GET /api/method/frappe.client.get_value?doctype=Report&fieldname=ref_doctype+%2F+sleep(15)+&filters=Profit+and+Loss+Statement&_=1752174156893

पुष्टि के चरण

1. reporting/get_value API तक पहुँच रखने वाले उपयोगकर्ता के साथ लक्षित Frappe/ERPNext इंस्टेंस में प्रमाणित करें।
2. उपरोक्त GET अनुरोध भेजें (या समकक्ष URL-एन्कोडेड पेलोड)।
3. प्रतिक्रिया समय का निरीक्षण करें; यदि प्रतिक्रिया ~15 सेकंड विलंबित होती है, तो यह सफल टाइम-आधारित इंजेक्शन का संकेत देता है।
4. पुनरुत्पादन क्षमता की पुष्टि के लिए उसी अनुरोध को दोहराएँ।
5. इंजेक्ट किए गए +%2F+sleep(15)+& पेलोड को हटाएँ और देखें कि प्रतिक्रिया तुरंत लौटती है — यह पुष्टि करता है कि इंजेक्शन समय विलंब का कारण बनता है।

नोट: DB इंजन के आधार पर sleep(15) को बैकएंड DBMS के अनुरूप अन्य समय फ़ंक्शन या समय मानों से बदलें (जैसे, PostgreSQL के लिए pg_sleep(n))। PoC टाइमिंग के माध्यम से ब्लाइंड इंजेक्शन प्रदर्शित करता है; डेटा बिट-दर-बिट निकालने के लिए अधिक जटिल पेलोड का उपयोग किया जा सकता है।

🧪 हमले के वेक्टर और प्रभाव

• हमले का वेक्टर: प्रमाणित उपयोगकर्ता SQL पेलोड (टाइम डिले फ़ंक्शन) युक्त एक दुर्भावनापूर्ण fieldname पैरामीटर के साथ /api/method/frappe.client.get_value पर GET अनुरोध तैयार करता है।

• प्रभाव:

  • सेवा अस्वीकार: सर्वर प्रतिक्रिया में जबरन विलंब (दुरुपयोग होने पर संसाधन थकावट)।
  • सूचना प्रकटीकरण: टाइम-आधारित तकनीकों के माध्यम से डेटा की ब्लाइंड निकासी (बिटवाइज़/समय-सशर्त क्वेरी)।
  • डेटा हेरफेर: यदि अन्य SQL इंजेक्शन वेक्टर उपलब्ध हैं, तो डेटाबेस स्थिति को बदलने की संभावित क्षमता।
  • अन्य: एप्लिकेशन उपयोगकर्ता के लिए उपलब्ध DB विशेषाधिकारों के आधार पर प्रभाव का विस्तार।

🔐 शमन अनुशंसाएँ

1. पैरामीटरीकृत क्वेरी / प्रीपेयर्ड स्टेटमेंट: सुनिश्चित करें कि fieldname और सभी उपयोगकर्ता-आपूर्ति इनपुट कभी भी सीधे SQL में संयोजित न हों। पैरामीटरीकृत क्वेरी या ORM API का उपयोग करें जो पैरामीटर को ठीक से बाइंड करते हैं।
2. कठोर इनपुट सत्यापन / व्हाइटलिस्टिंग: फ़ील्ड नाम या पहचानकर्ता होने वाले पैरामीटर के लिए, ज्ञात मान्य फ़ील्ड नामों की सख्त अनुमत सूची के विरुद्ध सत्यापन करें या क्लाइंट से कच्चे फ़ील्ड पहचानकर्ता स्वीकार करने के बजाय सर्वर-साइड मैपिंग का उपयोग करें।
3. पहचानकर्ताओं को सुरक्षित रूप से एस्केप करें: यदि पहचानकर्ताओं को गतिशील रूप से उपयोग करना आवश्यक है, तो सुरक्षित DB-विशिष्ट पहचानकर्ता कोटिंग/एस्केपिंग फ़ंक्शन का उपयोग करें — और फिर भी अनुमत मानों को प्रतिबंधित करें।
4. न्यूनतम विशेषाधिकार DB खाता: एप्लिकेशन को ऐसे डेटाबेस उपयोगकर्ता के साथ चलाएँ जिसके पास केवल आवश्यक विशेषाधिकार हों (reporting एंडपॉइंट के लिए जहाँ संभव हो केवल-पढ़ने योग्य)।
5. दर-सीमा और निगरानी: दर सीमाएँ लागू करें और असामान्य अनुरोध पैटर्न या बार-बार समय-विलंब परीक्षणों का पता लगाएँ; संदिग्ध ट्रैफ़िक पर अलर्ट करें।
6. ऑडिट और लॉगिंग: संवेदनशील API एंडपॉइंट्स पर अनुरोधों को लॉग करें और संदिग्ध पेलोड (जैसे, sleep, pg_sleep, benchmark, /, ;) के लिए निगरानी करें।
7. पैच और रिलीज़: Frappe/ERPNext डेवलपर्स को frappe.client.get_value और fieldname/फ़िल्टर को संभालने वाले कोड पथ का ऑडिट करना चाहिए, असुरक्षित संयोजन को सुरक्षित API से बदलना चाहिए, और एक सुरक्षा पैच जारी करना चाहिए। ऑपरेटरों को तुरंत अपडेट लागू करने चाहिए।

🔗 संदर्भ

• खोजकर्ता / रिपोर्टर: मोहम्मद अलोली — GitHub: https://github.com/MoAlali — X: https://x.com/alaliksa_ — LinkedIn: https://www.linkedin.com/in/mohammedaloli/
• Frappe / ERPNext कोडबेस (समीक्षा और पैच): https://github.com/frappe/frappe , https://github.com/frappe/erpnext
• सामान्य SQLi मार्गदर्शन: OWASP SQL इंजेक्शन चीट शीट — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 आभार

खोजकर्ता: मोहम्मद अलोली

📢 अस्वीकरण

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