तात्कालिक: OwnID पासवर्ड रहित लॉगिन (<= 1.3.4) — प्रमाणीकरण बायपास (CVE-2025-10294)

सलाह और शमन मार्गदर्शन — 15 अक्टूबर 2025 को प्रकाशित। एक हांगकांग सुरक्षा विशेषज्ञ के दृष्टिकोण से लिखा गया: सीधा, व्यावहारिक, और नियंत्रण और पुनर्प्राप्ति पर केंद्रित।.

कार्यकारी सारांश

• CVE-2025-10294 OwnID पासवर्ड रहित लॉगिन (≤ 1.3.4) में एक प्रमाणीकरण बायपास है।.
• बिना प्रमाणीकरण वाले हमलावरों द्वारा शोषण योग्य — पूर्व पहुंच की आवश्यकता नहीं है।.
• प्रभाव: उपयोगकर्ताओं का अनुकरण (प्रशासकों सहित), पूर्ण साइट अधिग्रहण, स्थायी बैकडोर, डेटा चोरी।.
• प्रकाशन के समय कोई विक्रेता पैच उपलब्ध नहीं है — तत्काल शमन की आवश्यकता है।.
• प्राथमिक क्रियाएँ: प्लगइन को निष्क्रिय करें या इसके एंडपॉइंट्स को ब्लॉक करें, आभासी पैच या सर्वर नियम लागू करें, प्रमाणीकरण नमक और संवेदनशील क्रेडेंशियल्स को घुमाएँ, खातों और फ़ाइलों का ऑडिट करें, और यदि समझौता किया गया है तो स्वच्छ बैकअप से पुनर्स्थापित करें।.

समस्या क्या है (तकनीकी, सरल)

पासवर्ड रहित लॉगिन प्रवाह प्रमाणीकरण प्रमाणों (जादुई लिंक, WebAuthn प्रतिक्रियाएँ, हस्ताक्षरित कॉलबैक) के सावधानीपूर्वक सर्वर-साइड सत्यापन पर निर्भर करते हैं। यहाँ कमजोरियाँ OwnID के प्रमाणीकरण कॉलबैक हैंडलरों में एक तर्क/सत्यापन विफलता है: कुछ एंडपॉइंट्स या कोड पथ प्रमाण को बनाने से पहले पर्याप्त रूप से सत्यापित नहीं करते हैं। परिणामस्वरूप, तैयार किए गए अनुरोधों को वैध के रूप में स्वीकार किया जा सकता है और WordPress अनुरोधकर्ता को लक्षित उपयोगकर्ता के रूप में मानता है।.

प्रमुख विशेषताएँ:

• हमलावर का विशेषाधिकार: बिना प्रमाणीकरण।.
• हमले का वेक्टर: प्लगइन REST/AJAX/callback एंडपॉइंट्स के लिए HTTP अनुरोध।.
• प्रभाव: पूर्ण खाता अनुकरण, संभावित प्रशासक अधिग्रहण, साइट समझौता।.

हमलावर इसको कैसे शोषण करने की संभावना रखते हैं

1. प्लगइन संपत्तियों, ज्ञात REST नामस्थान, या विशेष हेडर के लिए स्कैनिंग के माध्यम से कमजोर प्लगइन चलाने वाली साइटों का पता लगाएँ।.
2. OwnID-संबंधित एंडपॉइंट्स की जांच करें ताकि व्यवहार का निर्धारण किया जा सके।.
3. दोषपूर्ण मान्यता तर्क को सक्रिय करने वाले तैयार किए गए पेलोड भेजें, जिससे लक्षित उपयोगकर्ता (अक्सर एक प्रशासक) के लिए सत्र निर्माण या कुकी सेटिंग होती है।.
4. प्रशासनिक खातों को बनाने, वेबशेल अपलोड करने, सामग्री को संशोधित करने और डेटा को निकालने के लिए पहुंच का उपयोग करें।.

शोषण को स्वचालित करना सीधा है; सामूहिक स्कैनिंग और शोषण तेजी से, व्यापक समझौतों का परिणाम बन सकता है।.

आपकी साइट के लिए तत्काल जोखिम

यदि आपकी सार्वजनिक रूप से सामने आने वाली वर्डप्रेस साइट OwnID Passwordless Login ≤ 1.3.4 चलाती है, तो उच्च जोखिम मानें। स्वचालित हमलावर पहले प्रशासनिक खातों को लक्षित करेंगे। आधिकारिक प्लगइन अपडेट की प्रतीक्षा न करें - अभी कार्रवाई करें।.

पहचान - संकेत कि आपकी साइट पहले से ही समझौता की गई हो सकती है

इन संकेतकों की तुरंत जांच करें:

• डेटाबेस में नए प्रशासनिक खाते। उदाहरण क्वेरी:

  SELECT ID, user_login, user_email, user_registered
  FROM wp_users
  WHERE ID IN (
    SELECT user_id
    FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
  )
  ORDER BY user_registered DESC;

• वेब सर्वर लॉग जो ownid-संबंधित REST/AJAX एंडपॉइंट्स पर बार-बार POST दिखा रहे हैं या “ownid”, “passwordless”, “magic-link” आदि को शामिल करने वाले असामान्य क्वेरी स्ट्रिंग्स।.
• प्लगइन एंडपॉइंट्स पर अनुरोधों के बाद सत्र या प्राधिकरण कुकी सेट की जा रही हैं।.
• wp_options, wp_posts, प्लगइन या थीम फ़ाइलों में अप्रत्याशित संशोधन।.
• अपलोड या अन्य गैर-कोड निर्देशिकाओं में PHP फ़ाइलें।.
• PHP प्रक्रियाओं द्वारा अपरिचित डोमेन के लिए प्रारंभ की गई आउटबाउंड कनेक्शन।.
• wp_options में अप्रत्याशित अनुसूचित क्रोन नौकरियां।.

यदि आप उपरोक्त में से कोई भी देखते हैं, तो साइट को संभावित रूप से समझौता किया गया मानें और तुरंत सीमांकन और फोरेंसिक कदम उठाएं।.

तत्काल सीमांकन कदम (प्राथमिकता के अनुसार)

1. तुरंत प्लगइन को निष्क्रिय करें।.
   • यदि आपके पास WP Admin पहुंच है: प्लगइन्स स्क्रीन के माध्यम से OwnID Passwordless Login को निष्क्रिय करें।.
   • यदि WP Admin उपलब्ध नहीं है: SFTP/SSH के माध्यम से प्लगइन फ़ोल्डर का नाम बदलें या हटा दें (जैसे, नाम बदलें wp-content/plugins/ownid जोड़कर ownid.disabled), जो कमजोर कोड को चलने से रोकता है।.
2. वेब सर्वर स्तर पर या WAF के माध्यम से प्लगइन एंडपॉइंट्स को ब्लॉक करें।.

   यदि आप उपलब्धता कारणों से प्लगइन को अक्षम नहीं कर सकते हैं, तो तुरंत प्लगइन के REST/AJAX/callback एंडपॉइंट्स के लिए HTTP पहुंच को ब्लॉक करें। नीचे नियम के उदाहरण देखें।.

3. प्रमाणीकरण नमक और कुंजी को घुमाएं।.

   AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY और NONCE_KEY के नए मान उत्पन्न करें wp-config.php (WordPress.org गुप्त-कुंजी जनरेटर का उपयोग करें)। यह मौजूदा कुकीज़ को अमान्य करता है और पुनः प्रमाणीकरण को मजबूर करता है।.

4. पासवर्ड रीसेट करने और महत्वपूर्ण क्रेडेंशियल्स को घुमाने के लिए मजबूर करें।.
   • सभी व्यवस्थापक खातों के लिए पासवर्ड रीसेट करें।.
   • सर्वर पर संग्रहीत सेवा क्रेडेंशियल्स, API कुंजी और OAuth टोकन को घुमाएं।.
5. अज्ञात खातों का ऑडिट करें और हटाएं।. सभी उपयोगकर्ता खातों की सावधानीपूर्वक समीक्षा करें और अनधिकृत व्यवस्थापकों को हटाएं। जांच के लिए उपयोगकर्ता आईडी और संबंधित कलाकृतियों को रिकॉर्ड करें।.
6. मैलवेयर और बैकडोर के लिए स्कैन करें।. संशोधित कोर/प्लगइन/थीम फ़ाइलों और अपलोड में PHP फ़ाइलों को खोजने के लिए फ़ाइल-इंटीग्रिटी स्कैनर और एक प्रतिष्ठित मैलवेयर स्कैनर का उपयोग करें।.
7. फोरेंसिक स्नैपशॉट लें।. जहां संभव हो, विनाशकारी परिवर्तनों को करने से पहले फ़ाइल सिस्टम और डेटाबेस का स्नैपशॉट लें। यदि तत्काल कार्रवाई की आवश्यकता है, तो कंटेनमेंट को प्राथमिकता दें और बाद में विश्लेषण के लिए समय और लॉग के नोट्स बनाएं।.
8. यदि समझौता पुष्टि हो गया है - एक साफ बैकअप से पुनर्स्थापित करें।. समझौते से पहले लिए गए बैकअप से पुनर्स्थापित करें। पुनर्स्थापना के बाद, कंटेनमेंट चरणों को फिर से लागू करें और रहस्यों को घुमाएं।.
9. अपने होस्ट को सूचित करें और लॉगिंग बढ़ाएं।. विस्तृत एक्सेस लॉग और प्रक्रिया निगरानी सक्षम करें। अपने होस्टिंग प्रदाता को सूचित करें ताकि वे आपत्तिजनक IPs और नेटवर्क स्तर के कंटेनमेंट को ब्लॉक करने में सहायता कर सकें।.

अनुशंसित वर्चुअल-पैच / WAF नियम (अब लागू करें)

वर्चुअल पैचिंग (किनारे पर कमजोर अंत बिंदुओं को ब्लॉक करना) एक आधिकारिक प्लगइन सुधार जारी होने तक सबसे तेज़ समाधान है। वैध ट्रैफ़िक को तोड़ने से बचने के लिए पहले स्टेजिंग में नियमों का परीक्षण करें।.

OwnID REST नामस्थान को ब्लॉक करने के लिए उदाहरण Nginx नियम:

# OwnID REST नामस्थान के लिए अनुरोधों को अस्वीकार करें

उदाहरण Apache/.htaccess नियम:

# OwnID REST अंत बिंदुओं को ब्लॉक करें

उदाहरण ModSecurity (SecRule) स्निपेट:

SecRule REQUEST_URI "@rx ^/wp-json/(ownid|ownid-.*)"

ज्ञात AJAX क्रियाओं को ब्लॉक करें (यदि प्लगइन admin-ajax.php क्रिया पैरामीटर का उपयोग करता है):

# उदाहरण: उन admin-ajax अनुरोधों को ब्लॉक करें जिनमें ownid क्रियाएँ शामिल हैं

किनारे या सर्वर स्तर पर लागू करने के लिए अन्य सुरक्षा उपाय:

• प्लगइन-विशिष्ट अंत बिंदुओं और प्रशासन लॉगिन पथों के लिए अनुरोधों की दर-सीमा निर्धारित करें।.
• उन अनुरोधों को ब्लॉक करें जिनमें अपेक्षित nonce या हस्ताक्षर हेडर की कमी है।.
• जहां लागू हो, प्लगइन अंत बिंदुओं के लिए POST पहुंच को ज्ञात IP रेंज तक सीमित करें।.
• संदिग्ध पेलोड (खाली टोकन, बड़े पैरामीटर, या शोषण प्रयासों के अनुरूप पैटर्न) वाले अनुरोधों को अस्वीकार करें।.
• ownid/passwordless से संबंधित पथों पर अनुरोधों में वृद्धि की निगरानी करें और अलर्ट करें।.

व्यावहारिक सर्वर-स्तरीय प्रतिकूल उपाय (त्वरित नियम जिन्हें आप अब जोड़ सकते हैं)

• पहुंच को प्रतिबंधित करें wp-login.php 8. और /wp-admin जहां संभव हो, IP द्वारा।.
• प्लगइन के REST नामस्थान (ownid, passwordless, आदि) से संबंधित स्ट्रिंग्स वाले अनुरोधों को अस्वीकार करने के लिए एक वेब सर्वर नियम जोड़ें।.
• संदिग्ध अंत बिंदुओं के लिए अनुरोधों को अस्वीकार करने वाले एक हल्के mu-plugin का उपयोग करके असत्यापित REST API पहुंच को अस्थायी रूप से निष्क्रिय करें (वैध API उपभोक्ताओं को तोड़ने से बचने के लिए सावधानी से परीक्षण करें)।.

सामान्य ownid REST कॉल को ब्लॉक करने के लिए उदाहरण mu-plugin (अस्थायी समाधान):

<?php;

नोट: उत्पादन से पहले किसी भी mu-plugin का परीक्षण स्टेजिंग में करें। आधिकारिक प्लगइन के पैच होने के बाद और आपने व्यवहार को मान्य किया है, mu-plugin को हटा दें।.

यह कैसे सत्यापित करें कि आपकी साइट साफ है (संक्रमण के बाद)

प्लगइन को अक्षम करने और एज/सर्वर ब्लॉक्स लागू करने के बाद, इन जांचों को चलाएं:

1. अज्ञात प्रशासनिक खातों की खोज करें और उन्हें हटा दें।.
2. पुष्टि करें wp-config.php salts/keys को अपडेट किया गया है।.
3. हाल ही में बदले गए फ़ाइलों के लिए फ़ाइल सिस्टम को स्कैन करें (उपयोग करें खोजें उचित -mtime पैरामीटर)।.
4. अपलोड में PHP फ़ाइलें खोजें: find wp-content/uploads -type f -name "*.php"
5. अप्रत्याशित अनुसूचित कार्यों की जांच करें (WP Admin क्रोन UI या 11. संदिग्ध सामग्री के साथ। क्रोन प्रविष्टि की जांच करें)।.
6. संदिग्ध विकल्पों, बागी विजेट्स, या इंजेक्टेड सामग्री के लिए डेटाबेस की जांच करें।.
7. ownid एंडपॉइंट्स से जुड़े निरंतर POSTs या असामान्य उपयोगकर्ता एजेंटों के लिए वेब सर्वर लॉग की समीक्षा करें।.
8. एक विश्वसनीय मैलवेयर स्कैनर के साथ फिर से स्कैन करें और फ़ाइल अखंडता जांचें।.

यदि आप बैकडोर या स्थिरता के सबूत पाते हैं, तो ज्ञात-साफ बैकअप से पुनर्स्थापना सबसे विश्वसनीय पुनर्प्राप्ति दृष्टिकोण है। पुनर्स्थापना के बाद, containment को फिर से लागू करें और सभी रहस्यों को घुमाएं।.

पुनर्प्राप्ति कदम और दीर्घकालिक कठिनाई

• यदि समझौता पुष्टि हो जाता है तो एक साफ बैकअप से पुनर्स्थापित करें।.
• पुनर्प्राप्ति के बाद, विक्रेता पैच उपलब्ध और सत्यापित होने तक कमजोर प्लगइन को तुरंत अक्षम रखें।.
• सभी क्रेडेंशियल्स को घुमाएँ और नए ऑथ सॉल्ट्स उत्पन्न करें wp-config.php.
• सभी प्रशासनिक खातों के लिए दो-कारक प्रमाणीकरण (2FA) की आवश्यकता करें।.
• न्यूनतम विशेषाधिकार प्रशासन नीतियों को लागू करें और प्रशासनिक खातों की संख्या सीमित करें।.
• फ़ाइल परिवर्तन निगरानी और नियमित मैलवेयर स्कैन सक्षम करें।.
• स्वचालित ऑफसाइट बैकअप का उपयोग करें और नियमित रूप से बैकअप की अखंडता को मान्य करें।.
• घटना के बाद कम से कम 30 दिनों तक लॉग और उपयोगकर्ता गतिविधि की निगरानी करें पुनः-संक्रमण के संकेतों के लिए।.

डेवलपर मार्गदर्शन (प्लगइन/थीम लेखकों और एकीकृत करने वालों के लिए)

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

समझौते के संकेतों की चेकलिस्ट (त्वरित स्कैन)

• पिछले 30 दिनों में बनाए गए अप्रत्याशित प्रशासनिक स्तर के उपयोगकर्ता।.
• सक्रिय थीम/प्लगइन फ़ाइलों पर हालिया संशोधन टाइमस्टैम्प जो आपने अपेक्षित नहीं किए थे।.
• PHP फ़ाइलें 16. WP क्रॉन में अप्रत्याशित अनुसूचित घटनाएँ जो अपरिचित कोड को निष्पादित करती हैं। या अन्य गैर-कोड निर्देशिकाएँ।.
• PHP प्रक्रियाओं से अज्ञात होस्टों के लिए आउटबाउंड नेटवर्क कनेक्शन।.
• नए निर्धारित क्रॉन नौकरियाँ जिन्हें आपने कॉन्फ़िगर नहीं किया।.
• REST API एंडपॉइंट्स पर अनुरोधों में वृद्धि जो ownid-संबंधित पथों से मेल खाती हैं।.

अंतिम प्राथमिकता वाली चेकलिस्ट

1. यदि OwnID पासवर्ड रहित लॉगिन स्थापित है: इसे तुरंत निष्क्रिय या हटा दें.
2. यदि आप इसे बंद नहीं कर सकते हैं: इसके REST/AJAX एंडपॉइंट्स को ब्लॉक करें वेब सर्वर या एज नियमों के माध्यम से।.
3. WordPress कुंजी/नमक को घुमाएँ wp-config.php सत्रों को अमान्य करने के लिए।.
4. प्रशासकों के लिए पासवर्ड रीसेट करने के लिए मजबूर करें और महत्वपूर्ण क्रेडेंशियल्स को घुमाएँ।.
5. उपयोगकर्ताओं, प्लगइन्स, थीम और कोर फ़ाइलों का ऑडिट करें ताकि छेड़छाड़ का पता चल सके।.
6. स्कैन करें और, यदि आवश्यक हो, तो ज्ञात-साफ बैकअप से पुनर्स्थापित करें।.
7. एज/सर्वर नियम लागू करें और निरंतर निगरानी और फ़ाइल अखंडता जांच सक्षम करें।.
8. प्रशासनिक पहुंच को मजबूत करें: 2FA, न्यूनतम विशेषाधिकार, नियमित बैकअप और निगरानी।.

समापन विचार

प्लगइन्स में प्रमाणीकरण बाईपास जो लॉगिन प्रवाह को फिर से काम करते हैं, WordPress साइटों के लिए सबसे गंभीर जोखिमों में से हैं - वे प्रमाणीकरण कोड को सीधे पहुंच वेक्टर में परिवर्तित करते हैं। वर्तमान खतरे के माहौल में, त्वरित containment (बंद या ब्लॉक) और फोरेंसिक सत्यापन आवश्यक हैं। उच्च-मूल्य वाली साइटों (ईकॉमर्स, उच्च ट्रैफ़िक) को पहले प्राथमिकता दें। जब संदेह हो, तो समझें कि समझौता हुआ है और containment, सफाई, और पुनर्प्राप्ति प्रक्रियाओं का पालन करें।.

यदि आप ऊपर दिए गए containment कदमों को लागू करने में सहायता की आवश्यकता है, तो घटना प्रतिक्रिया संसाधनों या नेटवर्क-स्तरीय ब्लॉकों और फोरेंसिक समर्थन के लिए अपने होस्टिंग प्रदाता से संपर्क करें।.