संवेदनशीलता चेतावनी: “Integrate Dynamics 365 CRM” प्लगइन (<= 1.0.9) — अनुपस्थित प्राधिकरण / टूटी हुई पहुंच नियंत्रण (CVE-2025-10746)

प्रकाशित: 3 अक्टूबर 2025   |   गंभीरता: मध्यम (CVSS 6.5)   |   प्रभावित: WordPress के लिए Integrate Dynamics 365 CRM प्लगइन — संस्करण ≤ 1.0.9   |   में ठीक किया गया: 1.1.0   |   CVE: CVE-2025-10746

नोट: यह सलाह एक हांगकांग सुरक्षा प्रैक्टिशनर के दृष्टिकोण से लिखी गई है: सीधी, व्यावहारिक, और साइट मालिकों, डेवलपर्स और होस्ट के लिए त्वरित जोखिम कमी पर केंद्रित।.

सारांश

• Integrate Dynamics 365 CRM प्लगइन में अनुपस्थित प्राधिकरण (टूटी हुई पहुंच नियंत्रण) की संवेदनशीलता मौजूद है। बिना प्रमाणीकरण वाले अभिनेता ऐसी कार्यक्षमता को कॉल कर सकते हैं जिसे प्राधिकरण की आवश्यकता होनी चाहिए।.
• यह कुछ तैनाती में विशेषाधिकार प्राप्त क्रियाओं या संवेदनशील संचालन को सक्षम करता है। विक्रेता ने समस्या को हल करने के लिए संस्करण 1.1.0 जारी किया; संस्करण 1.0.9 और इससे पहले संवेदनशील हैं।.
• यह सलाह तकनीकी जोखिम, संभावित हमले के तरीके, पहचान रणनीतियाँ, तात्कालिक शमन (सर्वर-स्तरीय और WAF-शैली के आभासी पैचिंग सलाह सहित), डेवलपर्स के लिए दीर्घकालिक सुधार, और एक घटना-प्रतिक्रिया चेकलिस्ट को स्पष्ट करती है।.

यह क्यों महत्वपूर्ण है

टूटी हुई पहुंच नियंत्रण अक्सर CMS पारिस्थितिकी तंत्र में शोषित होती है। एंडपॉइंट्स या प्रशासन-जैसे कार्यों पर अनुपस्थित प्राधिकरण जांचें स्वचालित हमलावरों को सेटिंग्स बदलने, कॉन्फ़िगरेशन निकालने, या अनुवर्ती समझौता करने की अनुमति देती हैं। चूंकि यह समस्या बिना प्रमाणीकरण वाले क्लाइंट द्वारा शोषित की जा सकती है, सामूहिक स्कैनिंग और स्वचालित शोषण वास्तविक खतरे हैं। मध्यम CVSS के साथ भी, व्यावहारिक जोखिम बढ़ जाता है जब बिना प्रमाणीकरण की पहुंच संभव होती है और प्लगइन क्रेडेंशियल्स या एकीकरण एंडपॉइंट्स को संग्रहीत करता है।.

तकनीकी अवलोकन (उच्च-स्तरीय)

• प्रकार: टूटी हुई पहुंच नियंत्रण / अनुपस्थित प्राधिकरण
• वेक्टर: प्लगइन अनुरोध हैंडलर (admin-ajax, REST एंडपॉइंट्स, या सार्वजनिक फॉर्म हैंडलर) उचित क्षमता जांच, नॉनस सत्यापन, या प्रमाणीकरण गेटिंग की कमी थी, जिससे विशेषाधिकार प्राप्त व्यवहार के लिए बिना प्रमाणीकरण वाले कॉल सक्षम हो गए।.
• सामान्य मूल कारण:
  • current_user_can() या समकक्ष क्षमता प्रवर्तन की अनुपस्थिति।.
  • स्थिति-परिवर्तन AJAX हैंडलर्स पर कोई नॉनस जांच नहीं (check_admin_referer / check_ajax_referer)।.
  • बिना permission_callback प्रवर्तन क्षमताओं के सार्वजनिक रूप से पंजीकृत REST एंडपॉइंट्स।.
  • प्रशासन-केवल कार्य जो फ्रंट-एंड या बिना प्रमाणीकरण AJAX से पहुंच योग्य हुक से बंधे हैं।.
• लागू सुधार (उपधारा): प्राधिकरण जांच (क्षमताएँ/नॉनसेस/अनुमति कॉलबैक) जोड़ी गईं, और 1.1.0 में संवेदनशील क्रियाओं के सार्वजनिक प्रदर्शन को कम या मजबूत किया गया।.

वेबसाइटों पर संभावित प्रभाव

• प्लगइन कॉन्फ़िगरेशन या कनेक्शन सेटिंग्स में अनधिकृत संशोधन (संभावित रूप से CRM क्रेडेंशियल्स या कॉलबैक एंडपॉइंट्स को उजागर करना)।.
• सहमति के बिना तीसरे पक्ष की सेवाओं के लिए सिंक या आउटबाउंड ट्रांसमिशन को सक्रिय करना।.
• संग्रहीत मैपिंग या क्रेडेंशियल्स में हेरफेर करना जिससे डेटा लीक हो सकता है।.
• हमलावर को आगे की क्रियाओं को जोड़ने के लिए एक पैर जमाने का अवसर प्रदान करना (जैसे, स्थायी कॉन्फ़िगरेशन परिवर्तन, टोकन का प्रदर्शन, या दूरस्थ कोड पथों को सक्षम करना)।.

किसे चिंतित होना चाहिए

• कोई भी वर्डप्रेस साइट जो Integrate Dynamics 365 CRM प्लगइन संस्करण 1.0.9 या उससे पहले का उपयोग कर रही है।.
• साइटें जो एकीकरण क्रेडेंशियल्स को संग्रहीत करती हैं या बाहरी सिस्टम (CRMs, ERPs) को व्यवसाय-क्रिटिकल डेटा भेजती हैं।.
• एजेंसियाँ और होस्ट जो कई साइटों का प्रबंधन कर रहे हैं जहाँ कमजोर प्लगइन मौजूद हो सकता है।.

तात्कालिक क्रियाएँ — चरण-दर-चरण

1. प्लगइन संस्करणों की पुष्टि करें
   WP Admin → Plugins की जांच करें। यदि प्लगइन दिखाई नहीं देता है, तो WP-CLI या फ़ाइल प्रणाली के माध्यम से निरीक्षण करें:

   wp प्लगइन सूची

   या wp-content/plugins/integrate-dynamics-365-crm/ में प्लगइन हेडर/रीडमी में संस्करण की जांच करें।.

2. पैच किए गए संस्करण में अपडेट करें
   यदि आप सुरक्षित रूप से अपडेट कर सकते हैं, तो तुरंत Integrate Dynamics 365 CRM 1.1.0 या बाद के संस्करण में अपग्रेड करें। यह अंतिम समाधान है।.
3. यदि आप तुरंत अपडेट नहीं कर सकते हैं — अस्थायी शमन लागू करें
   – जब तक आप अपडेट लागू नहीं कर सकते, प्लगइन को निष्क्रिय करें (सबसे तेज़ जोखिम हटाना)।.
   – यदि महत्वपूर्ण व्यावसायिक कार्यप्रवाह के कारण निष्क्रिय करना असंभव है, तो सर्वर-स्तरीय नियमों या एज WAF नियमों का उपयोग करके प्लगइन एंडपॉइंट्स तक पहुंच को प्रतिबंधित करें (नीचे उदाहरण)।.
4. लॉग की समीक्षा करें
   संदिग्ध admin-ajax या REST अनुरोधों के लिए वेब सर्वर और एप्लिकेशन लॉग की जांच करें और प्लगइन सेटिंग्स या आउटबाउंड CRM कॉल में परिवर्तनों पर नज़र रखें।.
5. यदि समझौता होने का संदेह है
   इस सलाह में बाद में घटना प्रतिक्रिया चेकलिस्ट का पालन करें (अलग करना, स्नैपशॉट लेना, क्रेडेंशियल्स को घुमाना, फोरेंसिक समीक्षा)।.

पहचान और शिकार

लॉग में प्लगइन-विशिष्ट एंडपॉइंट्स या पैरामीटर के लिए खोजें जो सामान्यतः प्रशासनिक संचालन के लिए आरक्षित होते हैं:

• admin-ajax.php के लिए अनुरोध जिसमें प्लगइन क्रिया पैरामीटर होते हैं (जैसे, ?action=integrate_d365_sync)। अज्ञात आईपी से admin-ajax कॉल के लिए वेब सर्वर लॉग की खोज करें।.
• /wp-json/* के तहत प्लगइन-विशिष्ट मार्गों के लिए REST अनुरोध जो सुरक्षित होने चाहिए।.
• प्लगइन फ़ाइल पथ या फ़ॉर्म हैंडलर्स के लिए POST अनुरोध जो सेटिंग्स को बदलते हैं।.

उदाहरण लॉग खोजें:

grep -E "integrate.*dynamics|d365|integrate-dynamics" /var/log/nginx/access.log"

समझौते के संकेत (IoCs): अचानक प्लगइन कॉन्फ़िगरेशन परिवर्तन, CRM डोमेन के लिए अप्रत्याशित आउटबाउंड ट्रैफ़िक, रहस्यों को संग्रहीत करने वाली फ़ाइलों का निर्माण/संशोधन, या नए व्यवस्थापक उपयोगकर्ता।.

अस्थायी वर्चुअल पैचिंग और सर्वर-स्तरीय उपाय

जब तत्काल प्लगइन अपडेट संभव नहीं होते हैं, तो प्रभावित एंडपॉइंट्स पर प्रमाणीकरण रहित अनुरोधों को अवरुद्ध करना या रोकना जोखिम को कम करता है। नीचे सामान्य, अस्थायी सर्वर-स्तरीय उदाहरण दिए गए हैं। सावधानी से परीक्षण करें - अत्यधिक व्यापक नियम कार्यक्षमता को तोड़ सकते हैं।.

Nginx उदाहरण

# प्रमाणीकरण रहित स्रोतों द्वारा प्लगइन के AJAX एंडपॉइंट तक सीधी पहुंच को अस्वीकार करें (अस्थायी)

Apache /.htaccess उदाहरण

# अनुमत आईपी के अलावा प्लगइन php फ़ाइलों के लिए सीधे अनुरोधों को अस्थायी रूप से अस्वीकार करें

वैकल्पिक रूप से, यदि आप एक एज WAF या रिवर्स प्रॉक्सी संचालित करते हैं, तो नियम बनाएं जो:

• विशेषाधिकार प्राप्त क्रियाएँ करने वाले प्लगइन-विशिष्ट एंडपॉइंट्स पर प्रमाणीकरण रहित POST/GET अनुरोधों को अवरुद्ध करें।.
• व्यवस्थापक-जैसी क्रियाओं के लिए WordPress सत्र कुकी या कस्टम हेडर की उपस्थिति की आवश्यकता है।.
• दर सीमाएँ लागू करें और ज्ञात दुरुपयोगकर्ता एजेंटों या आईपी प्रतिष्ठा सूचियों को अवरुद्ध करें।.

अनुशंसित WordPress-स्तरीय हार्डनिंग और कोड उपाय (डेवलपर्स के लिए)

दीर्घकालिक सुधार कोड-स्तरीय है: क्षमता जांच, nonce मान्यता और अनुमति कॉलबैक जोड़ें।.

AJAX हैंडलर उदाहरण:

add_action('wp_ajax_my_plugin_action', 'my_plugin_action_handler');

REST एंडपॉइंट उदाहरण:

register_rest_route('my-plugin/v1', '/action', array(;

सर्वोत्तम प्रथाएँ:

• किसी भी स्थिति-परिवर्तन या व्यवस्थापक-स्तरीय व्यवहार के लिए स्पष्ट क्षमता जांच की आवश्यकता है।.
• AJAX और फॉर्म सबमिशन के लिए नॉनस का उपयोग करें, और नॉनस को क्षमता जांचों के साथ मिलाएं।.
• REST रूट्स के लिए permission_callback शामिल करें; प्रशासनिक एंडपॉइंट्स के सार्वजनिक प्रदर्शन से बचें।.
• सभी इनपुट को मान्य और साफ करें; मान लें कि सभी बाहरी इनपुट अविश्वसनीय हैं।.

WAF/IDS सिस्टम के लिए पहचान नियम (संकल्पनात्मक)

• उन क्लाइंट्स से admin-ajax कॉल्स पर चेतावनी दें जिनके पास wordpress_logged_in कुकीज़ नहीं हैं और जिनमें प्लगइन-विशिष्ट क्रिया पैरामीटर हैं।.
• प्रमाणित सत्र कुकीज़ की कमी वाले IPs द्वारा प्लगइन एंडपॉइंट्स तक REST रूट एक्सेस पर चेतावनी दें।.
• एकल IPs या IP रेंज से प्लगइन एंडपॉइंट्स पर कॉल्स की बड़ी संख्या को फ्लैग करें (रेट-लिमिट थ्रेशोल्ड)।.
• उन POST अनुरोधों पर चेतावनी दें जो साइट विकल्पों को बदलते हैं जहां अनुरोध का मूल एक प्रशासनिक सत्र नहीं है।.

घटना प्रतिक्रिया चेकलिस्ट (यदि आप समझौता होने का संदेह करते हैं)

1. अलग करें और स्नैपशॉट लें: फोरेंसिक विश्लेषण के लिए फ़ाइल और DB स्नैपशॉट लें। लॉग्स को संरक्षित करें।.
2. क्रेडेंशियल्स को घुमाएं: WordPress प्रशासनिक पासवर्ड, API कुंजी, और प्लगइन द्वारा उपयोग की जाने वाली किसी भी बाहरी क्रेडेंशियल को रीसेट करें (CRM टोकन)।.
3. अपडेट और पैच करें: प्लगइन अपडेट 1.1.0 को तुरंत लागू करें या यदि अपडेट सुरक्षित रूप से संभव नहीं है तो प्लगइन को निष्क्रिय करें।.
4. स्थिरता के लिए स्कैन करें: wp-content, uploads, mu-plugins, थीम में संशोधित फ़ाइलों की तलाश करें; वेबशेल्स, संदिग्ध क्रोन जॉब्स, नए प्रशासनिक उपयोगकर्ताओं, और परिवर्तित डेटाबेस प्रविष्टियों की खोज करें।.
5. यदि आवश्यक हो तो पुनर्स्थापित करें: यदि समझौता गहरा है, तो ज्ञात साफ बैकअप से पुनर्स्थापित करें और सुरक्षा उपायों को फिर से लागू करें।.
6. बाहरी रहस्यों को सूचित करें और घुमाएं: यदि CRM क्रेडेंशियल्स/टोकन प्लगइन द्वारा संग्रहीत या उपयोग किए जाते हैं तो उन्हें घुमाएं।.
7. फॉलो-अप हार्डनिंग: प्रशासनिक उपयोगकर्ताओं के लिए 2FA लागू करें, एक्सेस लॉग की समीक्षा करें, और निगरानी जारी रखें।.

प्लगइन कमजोरियों के लिए जोखिम को कम करने के लिए सर्वोत्तम प्रथाएँ

• WordPress कोर, थीम और प्लगइन्स को अद्यतित रखें। पैच की आवृत्ति महत्वपूर्ण है।.
• प्रबंधित साइटों में प्लगइन्स और संस्करणों का एक इन्वेंटरी बनाए रखें; जहां संभव हो, WP-CLI के साथ स्वचालित करें।.
• प्लगइन के उपयोग को आवश्यक, विश्वसनीय उपकरणों तक सीमित करें और अप्रयुक्त प्लगइन्स को हटा दें।.
• उपयोगकर्ता खातों और एकीकरण खातों पर न्यूनतम विशेषाधिकार सिद्धांत लागू करें।.
• प्रशासक खातों के लिए 2FA का उपयोग करें और मजबूत पासवर्ड नीतियों को लागू करें।.
• जहां संभव हो, WAF या एज फ़िल्टरिंग चलाएं और उभरती कमजोरियों के लिए आभासी पैचिंग नियम लागू करें।.
• लॉग की निगरानी करें और असामान्य admin-ajax और REST गतिविधियों के लिए अलर्ट सेट करें।.

आभासी पैचिंग का महत्व क्यों है

जब प्लगइन स्रोत में कोड परिवर्तन की आवश्यकता होती है, तो सभी साइटें तुरंत अपडेट नहीं कर सकतीं (संगतता, स्टेजिंग परीक्षण, व्यावसायिक बाधाएं)। एज पर या सर्वर नियमों के माध्यम से आभासी पैचिंग कर सकती है:

• ज्ञात शोषण पैटर्न को साइट तक पहुँचने से पहले रोकें और अवरुद्ध करें।.
• आधिकारिक सुधार की योजना बनाने और परीक्षण करते समय सामूहिक शोषण को कम करें।.
• साइट फ़ाइलों को संशोधित किए बिना जल्दी तैनात किया जा सकता है, जिससे तत्काल परिचालन जोखिम कम होता है।.

हमलावर आमतौर पर इस प्रकार के बग को कैसे खोजते और शोषण करते हैं

1. खोज: स्वचालित स्कैनर प्लगइन स्लग को सूचीबद्ध करते हैं और एंडपॉइंट्स (admin-ajax?action=X, REST रूट) की जांच करते हैं।.
2. शोषण: हमलावर ऐसे अनुरोध जारी करते हैं जो विशेषाधिकार प्राप्त व्यवहार को ट्रिगर करते हैं जब क्षमता जांच गायब होती है।.
3. स्वचालन: पैटर्न स्वचालित होते हैं और बड़े पते की जगहों में सामूहिक रूप से स्कैन किए जाते हैं।.
4. चेनिंग: सफल क्रियाओं के बाद, हमलावर स्थिरता जोड़ सकते हैं, टोकन को निकाल सकते हैं, या अन्य प्रणालियों पर स्विच कर सकते हैं।.

मेज़बानों और एजेंसियों के लिए व्यावहारिक रक्षा चेकलिस्ट

• जहां उपयुक्त हो, छोटे/पैच रिलीज़ के लिए स्वचालित अपडेट सक्षम करें और उत्पादन से पहले स्टेजिंग में महत्वपूर्ण अपडेट का परीक्षण करें।.
• साइटों में admin-ajax और REST पैटर्न की निगरानी करें और असामान्यताओं के लिए स्वचालित अलर्ट सेट करें।.
• स्कैनिंग बॉट्स से शोर को कम करने के लिए दर सीमित करने और IP प्रतिष्ठा नियंत्रण का उपयोग करें।.
• अपडेट लागू होने से पहले शोषण को रोकने के लिए प्रकटीकरण विंडो के दौरान प्रति-साइट आभासी पैचिंग नीतियों को लागू करें।.
• साइट के मालिकों को प्लगइन जीवनचक्र और समय पर अपडेट के महत्व के बारे में शिक्षित करें।.

नमूना घटना समयरेखा (अपेक्षित)

• दिन 0 (प्रकटीकरण): सलाह प्रकाशित की गई और पैच जारी किया गया। स्कैनिंग जल्दी शुरू होती है।.
• दिन 0–2: अवसरवादी अभिनेता जांच करते हैं और स्वचालित शोषण का प्रयास करते हैं।.
• दिन 2–7: यदि भेद्यता विश्वसनीय है तो बड़े पैमाने पर शोषण अक्सर बढ़ जाता है।.
• सिफारिश: प्रकटीकरण के 24–72 घंटों के भीतर अपडेट और/या आभासी पैचिंग लागू करने का लक्ष्य रखें।.

प्लगइन लेखकों के लिए सुरक्षित विकास टिप्स

• हमेशा अनुमतियों को मान्य करें: हर स्थिति-परिवर्तनकारी क्रिया के लिए विशिष्ट क्षमताओं का दावा करें।.
• फॉर्म और AJAX के लिए नॉनसेस का उपयोग करें; नॉनसेस को क्षमताओं की जांच के साथ जोड़ें न कि केवल नॉनसेस पर निर्भर रहें।.
• सुनिश्चित करें कि REST एंडपॉइंट्स में एक permission_callback शामिल है जो क्षमताओं और संदर्भ की जांच करता है।.
• एंडपॉइंट्स का दस्तावेजीकरण करें और सार्वजनिक एक्सपोजर को न्यूनतम करें; प्राधिकरण लॉजिक के लिए CI परीक्षण बनाएं।.

कानूनी और अनुपालन विचार

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

संचार मार्गदर्शन (एजेंसियों और होस्ट के लिए)

• प्रभावित साइट के मालिकों के साथ भेद्यता, सुधार की स्थिति और अनुशंसित कदमों के बारे में पारदर्शी रहें।.
• शमन और अपडेट के लिए एक स्पष्ट समयरेखा प्रदान करें।.
• यदि प्लगइन बाहरी सेवाओं के साथ एकीकृत है तो क्रेडेंशियल्स के रोटेशन और आउटबाउंड गतिविधि की निगरानी की सलाह दें।.

पोस्ट-मॉर्टम में क्या शामिल करें

• घटनाओं और पहचान बिंदुओं का समयरेखा।.
• शोषण के सबूत (लॉग, संशोधित फ़ाइलें, आउटबाउंड कॉल)।.
• उठाए गए कदम (अपडेट, क्रेडेंशियल रोटेशन, पुनर्स्थापन)।.
• मूल कारण विश्लेषण और पुनरावृत्ति को रोकने के लिए लागू किए गए परिवर्तन।.
• सीखे गए पाठ और प्रक्रियाओं या नीतियों में अपडेट।.

सुझाए गए निगरानी और चेतावनी नियम (संक्षिप्त)

• उन ग्राहकों से admin-ajax.php अनुरोधों पर चेतावनी जो wordpress_logged_in कुकीज़ के बिना प्लगइन क्रिया पैरामीटर के साथ हैं।.
• अप्रत्याशित भौगोलिक क्षेत्रों या आईपी से उत्पन्न प्लगइन अंत बिंदुओं पर POST अनुरोधों पर चेतावनी।.
• प्लगइन अंत बिंदुओं पर ट्रैफ़िक स्पाइक्स पर चेतावनी।.
• प्लगइन से संबंधित wp_options पंक्तियों में परिवर्तनों पर चेतावनी।.

एक वास्तविक दुनिया की रक्षा करने वाली प्लेबुक (छोटी टीमों के लिए)

1. साप्ताहिक प्लगइनों और संस्करणों का इन्वेंटरी (WP-CLI के साथ स्वचालित करें)।.
2. विश्वसनीय भेद्यता फ़ीड की सदस्यता लें और जिन प्लगइनों का आप उपयोग करते हैं उनके लिए चेतावनियाँ कॉन्फ़िगर करें।.
3. महत्वपूर्ण पैच जल्दी लागू करें; गैर-आवश्यक अपडेट को रखरखाव विंडो में शेड्यूल करें।.
4. यदि आप तुरंत पैच नहीं कर सकते हैं, तो किनारे पर वर्चुअल पैचिंग सक्षम करें या अस्थायी रूप से प्लगइन को निष्क्रिय करें।.
5. पैचिंग के बाद, एक पूर्ण साइट स्कैन चलाएँ और पिछले 30 दिनों के लिए संदिग्ध गतिविधियों के लिए लॉग की समीक्षा करें।.
6. प्रशासकों के लिए एक अल्पकालिक मजबूर पासवर्ड रीसेट पर विचार करें और प्लगइन द्वारा उपयोग किए जाने वाले बाहरी क्रेडेंशियल्स को घुमाएँ।.

अंतिम सिफारिशें (संक्षिप्त चेकलिस्ट)

• तुरंत Integrate Dynamics 365 CRM को 1.1.0 या बाद के संस्करण में अपडेट करें।.
• यदि तत्काल अपडेट असंभव है, तो अस्थायी रूप से प्लगइन को निष्क्रिय करें या पहुँच को प्रतिबंधित करने के लिए लक्षित सर्वर/WAF नियम लागू करें।.
• प्लगइन द्वारा उपयोग किए जाने वाले किसी भी क्रेडेंशियल्स को घुमाएँ और संदिग्ध आउटबाउंड गतिविधियों के लिए ऑडिट करें।.
• निरंतर निगरानी लागू करें और एक इन्वेंटरी/पैचिंग ताल बनाए रखें।.

सहायता की आवश्यकता है

यदि आपको मदद की आवश्यकता है, तो एक विश्वसनीय सुरक्षा सलाहकार, आपके होस्टिंग प्रदाता, या एक आंतरिक सुरक्षा टीम से संपर्क करें ताकि वे उपाय लागू कर सकें, फोरेंसिक जांच कर सकें, और सुधार और निगरानी में सहायता कर सकें।.