Make (formerly Integromat Connector) <= 1.5.10 — Authenticated Administrator Arbitrary File Upload (CVE-2025-6085)

तारीख: 2025-09-03

लेखक: हांगकांग सुरक्षा विशेषज्ञ

सारांश

CVE-2025-6085 मेक (पूर्व में इंटीग्रोमैट कनेक्टर) प्लगइन संस्करणों को 1.5.10 तक और शामिल करते हुए प्रभावित करता है। एक प्रमाणित प्रशासक प्लगइन के अपलोड एंडपॉइंट्स के माध्यम से साइट पर मनमानी फ़ाइलें अपलोड कर सकता है। हालांकि शोषण के लिए प्रशासक क्रेडेंशियल की आवश्यकता होती है, इसके परिणाम गंभीर हो सकते हैं: वेबशेल, दूरस्थ कोड निष्पादन, स्थायीता और पूर्ण साइट समझौता।.

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

साइट के मालिकों को क्यों परवाह करनी चाहिए जब प्रशासक विशेषाधिकार की आवश्यकता होती है

• प्रशासक क्रेडेंशियल आमतौर पर पुन: उपयोग, लीक या फ़िश किए जाते हैं; एक ही समझौता किया गया प्रशासक खाता सीधे शोषण की अनुमति देता है।.
• कई साइटों में कई प्रशासक (डेवलपर्स, ठेकेदार) होते हैं जो जोखिम को बढ़ाते हैं।.
• हमलावर अन्य बग (XSS, CSRF, सत्र फिक्सेशन) को जोड़ सकते हैं ताकि प्रशासक सत्र प्राप्त कर सकें और फिर इस अपलोड दोष का शोषण कर सकें।.
• एक बार जब एक हमलावर वेब रूट के तहत निष्पादन योग्य फ़ाइलें रख सकता है, तो वे कोड निष्पादित कर सकते हैं, स्थायी हो सकते हैं और वातावरण में पिवट कर सकते हैं।.

इस भेद्यता को उच्च प्राथमिकता के रूप में मानें भले ही इसके लिए प्रशासक प्रमाणीकरण की आवश्यकता हो।.

Technical breakdown (what “arbitrary file upload” means here)

मनमाना फ़ाइल अपलोड भेद्यताएँ तब होती हैं जब फ़ाइल अपलोड को पर्याप्त सर्वर-साइड सत्यापन के बिना संग्रहीत किया जाता है:

• फ़ाइल प्रकार और MIME प्रकार
• फ़ाइल एक्सटेंशन
• गंतव्य निर्देशिका
• फ़ाइल सामग्री (निष्पादन योग्य कोड को रोकने के लिए)
• फ़ाइल नाम (पथ यात्रा को रोकने के लिए)
• अपलोड एंडपॉइंट पर प्राधिकरण जांच

In Make <= 1.5.10 the upload endpoint allowed an authenticated administrator to place arbitrary files on disk. If the destination is web-accessible (uploads, plugin directory), an attacker may upload a PHP webshell and invoke it via HTTP. Alternatively, uploaded files might be included later by other application logic, leading to remote code execution.

ऐसे एक हमले के सामान्य घटक:

• एक अपलोड एंडपॉइंट जो POST के माध्यम से फ़ाइल डेटा स्वीकार करता है
• सख्त सर्वर-साइड प्रकार/एक्सटेंशन/सामग्री जांच की कमी
• अपलोड गंतव्य वेब सर्वर के लिए सुलभ
• अनुमति देने वाली फ़ाइल अनुमतियाँ या वेब सर्वर कॉन्फ़िगरेशन जो निष्पादन की अनुमति देती हैं

यथार्थवादी हमले के परिदृश्य

1. दुर्भावनापूर्ण प्रशासक या समझौता किया गया प्रशासक खाता:

   एक समझौता किया गया विक्रेता या ठेकेदार प्रशासक खाता PHP वेबशेल को प्लगइन के माध्यम से अपलोड करने के लिए उपयोग किया जाता है, फिर हमलावर आदेश निष्पादित करता है ताकि वह स्थायी और बढ़ा सके।.

2. CSRF / संग्रहीत XSS श्रृंखला:

   एक हमलावर एक प्रशासक को क्रियाएँ करने के लिए प्रेरित करता है या संग्रहीत XSS का शोषण करता है ताकि एक विशेषाधिकार प्राप्त सत्र प्राप्त किया जा सके, फिर एक पेलोड अपलोड करता है।.

3. स्थायी बैकडोर / आपूर्ति-श्रृंखला दुरुपयोग:

   अपलोड किए गए बैकडोर अपडेट को सहन करते हैं या अन्य प्लगइनों/थीमों/कोर फ़ाइलों के साथ छेड़छाड़ करने के लिए उपयोग किए जाते हैं।.

CVSS और जोखिम संदर्भ

प्रकाशित CVSS स्कोर 7.2 है। स्कोर उच्च प्रभाव (संभवतः दूरस्थ कोड निष्पादन / साइट समझौता) को दर्शाता है जबकि हमले की जटिलता प्रशासक विशेषाधिकार की आवश्यकता द्वारा नियंत्रित होती है। व्यावहारिक रूप से छोटे साइटें अक्सर कमजोर क्रेडेंशियल स्वच्छता और सीमित निगरानी के कारण उच्च जोखिम में होती हैं।.

पहचान: संकेत कि आप शोषित हो सकते हैं

• में नए या संशोधित PHP फ़ाइलें:
  • /wp-content/uploads/
  • /wp-content/plugins/make-connector/ (या प्लगइन फ़ोल्डर का नाम)
  • अन्य प्लगइन या थीम निर्देशिकाएँ
• अजीब नामों या डबल एक्सटेंशन वाले फ़ाइलें (जैसे, .php.jpg, .phtml)
• संदिग्ध व्यवस्थापक लॉगिन के साथ मेल खाने वाले टाइमस्टैम्प वाली फ़ाइलें
• अनजान व्यवस्थापक उपयोगकर्ता या हाल के भूमिका परिवर्तन
• संदिग्ध क्रोन जॉब्स या अनुसूचित कार्य
• वेब सर्वर से असामान्य आईपी या डोमेन के लिए आउटबाउंड कनेक्शन
• HTTP लॉग जो नए अपलोड की गई फ़ाइलों या प्लगइन एंडपॉइंट्स पर असामान्य POSTs तक पहुंच दिखाते हैं
• संशोधित .htaccess या सर्वर कॉन्फ़िगरेशन जो निष्पादन को सक्षम करते हैं

उपयोगी पहचान उपकरण: फ़ाइल अखंडता निगरानी, सर्वर एक्सेस/त्रुटि लॉग, मैलवेयर स्कैनर, और संदिग्ध उपयोगकर्ताओं या विकल्प परिवर्तनों के लिए डेटाबेस ऑडिट।.

प्रभावित प्लगइन चलाने पर तात्कालिक कदम (घटना वर्गीकरण)

1. अलग करें और नियंत्रित करें
   • साइट को रखरखाव मोड में डालें या हमलावरों के संचालन को सीमित करने के लिए इसे ऑफ़लाइन ले जाएं।.
   • यदि संभव हो, तो जांच करते समय फ़ायरवॉल या सर्वर पर सार्वजनिक HTTP पहुंच को ब्लॉक करें।.
2. साक्ष्य को संरक्षित करें
   • लॉग (वेब एक्सेस/त्रुटि, FTP/SFTP, SSH), डेटाबेस डंप और फ़ाइल सिस्टम लिस्टिंग को फोरेंसिक्स के लिए एक सुरक्षित स्थान पर कॉपी करें।.
   • लॉग को ओवरराइट न करें या महत्वपूर्ण सिस्टम को पुनरारंभ न करें जब तक कि containment के लिए आवश्यक न हो।.
3. संदिग्ध फ़ाइलों की पहचान करें और उन्हें हटा दें

   हाल ही में जोड़े गए PHP फ़ाइलों की खोज करें और सामग्री की जांच करें। हटाने से पहले फोरेंसिक कॉपी को सुरक्षित रखें।.

   find /var/www/html/wp-content/uploads -type f -mtime -7 -print

   वेबशेल संकेतकों की तलाश करें जैसे base64_decode, eval, preg_replace with /e, system/exec कॉल।.

4. क्रेडेंशियल बदलें
   • सभी व्यवस्थापक पासवर्ड और सेवा खातों (FTP, SSH, DB) को रीसेट करें।.
   • सभी उपयोगकर्ताओं को मजबूर लॉगआउट करें और सत्रों को समाप्त करें।.
   • साइट द्वारा उपयोग किए जाने वाले API कुंजी और टोकन को घुमाएँ।.
5. स्थिरता की जांच करें
   • wp-config.php, mu-plugins, .htaccess और थीम/प्लगइन PHP फ़ाइलों में इंजेक्टेड कोड की जांच करें।.
6. ज्ञात-अच्छे बैकअप से पुनर्स्थापित करें

   यदि उपलब्ध हो, तो समझौते से पहले लिए गए एक साफ बैकअप से पुनर्स्थापित करें। पुनर्स्थापित साइट को उत्पादन से फिर से कनेक्ट करने से पहले पैच और साफ़ करें।.

7. प्लगइन को अपडेट या हटा दें

   यदि एक पैच मौजूद है, तो इसे तुरंत लागू करें। यदि कोई सुधार उपलब्ध नहीं है और प्लगइन अनिवार्य नहीं है, तो इसे अनइंस्टॉल करें और इसकी फ़ाइलें हटा दें - केवल निष्क्रियता फ़ाइलों को डिस्क पर छोड़ सकती है।.

8. मजबूत करें और निगरानी करें
   • सर्वर-साइड हार्डनिंग लागू करें और सुधार के बाद कम से कम कई हफ्तों तक निरंतर निगरानी स्थापित करें।.

यदि आप चरणों को सुरक्षित रूप से करने में आत्मविश्वास की कमी महसूस करते हैं, तो अपने होस्टिंग प्रदाता या एक पेशेवर घटना प्रतिक्रिया टीम से संपर्क करें - अधूरी सफाई स्थायी बैकडोर छोड़ सकती है।.

व्यावहारिक उपाय जिन्हें आप तुरंत लागू कर सकते हैं (कोई कोड-स्तरीय पैच की आवश्यकता नहीं)

ये उपाय हमले की सतह को कम करते हैं और प्रभाव को सीमित करते हैं, भले ही कमजोर प्लगइन स्थापित रहे।.

ए. WAF / वेब सर्वर स्तर पर अपलोड एंडपॉइंट (ओं) को ब्लॉक करें

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

एक विशिष्ट प्लगइन अपलोड URI को अस्वीकार करने के लिए nginx नियम का उदाहरण:

location ~* /wp-admin/admin-ajax.php {

प्लगइन स्रोत की जांच करके क्रिया नामों और URIs की पुष्टि करें और पहले स्टेजिंग पर नियमों का परीक्षण करें।.

बी. अपलोड निर्देशिकाओं में PHP निष्पादन को निष्क्रिय करें

अपलोड की गई फ़ाइलों से निष्पादित PHP को रोकने के लिए वेब सर्वर को कॉन्फ़िगर करें:

Apache (.htaccess) के लिए /wp-content/uploads/:

    php_flag engine off


    Require all denied

Nginx (सर्वर ब्लॉक):

location ~* ^/wp-content/uploads/.*\.(php|php5|phtml|phar)$ {

यह सीधे निष्पादन को रोकता है भले ही एक PHP फ़ाइल अपलोड की गई हो।.

C. अपलोड हैंडलर्स पर सख्त फ़ाइल प्रकार जांच लागू करें

जहां संभव हो, स्वीकृत MIME प्रकारों और एक्सटेंशन को ज्ञात-सुरक्षित प्रकारों (छवियाँ, PDFs) तक सीमित करें। अविश्वसनीय प्लगइन्स के लिए, प्लगइन के पैच होने तक सर्वर-स्तरीय नियंत्रणों पर भरोसा करें।.

D. व्यवस्थापक पहुंच को मजबूत करें

• सभी व्यवस्थापक खातों के लिए दो-कारक प्रमाणीकरण की आवश्यकता है।.
• अप्रयुक्त व्यवस्थापक खातों को हटा दें और व्यवस्थापक की संख्या को न्यूनतम तक सीमित करें।.
• मजबूत, अद्वितीय पासवर्ड और एक पासवर्ड प्रबंधक का उपयोग करें।.
• यदि संचालनात्मक रूप से संभव हो तो IP द्वारा wp-admin पहुंच को प्रतिबंधित करें या HTTP बेसिक ऑथ का उपयोग करें।.

E. PHP प्रक्रियाओं और फ़ाइल अनुमतियों के लिए न्यूनतम विशेषाधिकार

• सुनिश्चित करें कि वेब सर्वर एक अप्रिविलेज्ड उपयोगकर्ता खाते के साथ चलता है।.
• फ़ाइल सिस्टम अनुमतियों को सेट करें ताकि wp-content केवल आवश्यक स्थानों पर लिखने योग्य हो और प्लगइन फ़ाइलें विश्व-या वेब सर्वर-लेखन योग्य न हों जब तक कि अपडेट न हो।.

F. Regular backups & immutable copies

• दैनिक ऑफसाइट बैकअप रखें और कम से कम एक अपरिवर्तनीय स्नैपशॉट जो वेब सर्वर नहीं बदल सकता।.
• समय-समय पर पुनर्स्थापनों का परीक्षण करें।.

G. Monitoring & alerting

• नए या संशोधित PHP फ़ाइलों पर चेतावनी देने के लिए फ़ाइल अखंडता निगरानी का उपयोग करें।.
• आउटबाउंड कनेक्शनों और असामान्य ट्रैफ़िक पैटर्न की निगरानी करें।.

WAF & virtual patching: what they do and why they matter here

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

इस कमजोरियों के लिए सामान्य वर्चुअल पैच रणनीतियाँ:

• विश्वसनीय प्रशासनिक IPs के अलावा विशिष्ट प्लगइन अपलोड क्रिया के लिए POST को ब्लॉक करें।.
• मल्टीपार्ट अपलोड को ब्लॉक करें जिसमें PHP ओपनिंग टैग या .php में समाप्त होने वाले फ़ाइल नाम शामिल हैं।.
• संदिग्ध मल्टीपार्ट पेलोड या अप्रत्याशित पैरामीटर के साथ अनुरोधों को ब्लॉक करें।.

वर्चुअल पैचिंग आपके पैच करने, प्लगइन हटाने, या नियंत्रित सुधार करने के दौरान अल्पकालिक सुरक्षा के लिए मूल्यवान है।.

नमूना WAF सिग्नेचर (संकल्पनात्मक पैटर्न)

ये चित्रात्मक पैटर्न हैं; गलत सकारात्मक से बचने के लिए स्टेजिंग पर सावधानी से परीक्षण करें।.

• मल्टीपार्ट अपलोड में .php में समाप्त होने वाले फ़ाइल नाम का पता लगाएं:

  Condition: multipart/form-data && filename =~ /\.php(\d+)?$/i

• PHP टैग वाले अपलोड को ब्लॉक करें:

  Condition: request_body contains “

• प्लगइन अपलोड क्रिया के लिए POST को ब्लॉक करें:

  Condition: POST && request_uri contains “/wp-admin/admin-ajax.php” && args contains “action=make_upload”

Long-term security: developer & site owner checklist

• WordPress कोर, थीम और प्लगइन्स को अपडेट रखें; तेज़ जागरूकता के लिए कमजोरियों के फीड्स की सदस्यता लें।.
• प्रशासक खातों की संख्या सीमित करें और नियमित रूप से भूमिकाओं का ऑडिट करें।.
• विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए 2FA लागू करें।.
• मजबूत, अद्वितीय पासवर्ड का उपयोग करें और संदेह होने पर क्रेडेंशियल्स को घुमाएं।.
• WP प्रशासन में फ़ाइल संपादन को निष्क्रिय करें:

  define('DISALLOW_FILE_EDIT', true);

• नियमित रूप से मैलवेयर के लिए स्कैन करें और फ़ाइल अखंडता जांचें।.
• PHP को मजबूत करें: यदि आवश्यक न हो तो खतरनाक फ़ंक्शंस (exec, shell_exec, system) को निष्क्रिय करें।.
• वेब सर्वर कॉन्फ़िगरेशन में डायरेक्टरी लिस्टिंग को निष्क्रिय करें।.
• सर्वर-साइड सुरक्षा का उपयोग करें जैसे mod_security या समकक्ष नियम सेट और सही तरीके से कॉन्फ़िगर किया गया WAF।.
• परीक्षण किए गए बैकअप और पुनर्स्थापन योजनाओं को बनाए रखें।.
• SSH/FTP पहुंच को ज्ञात IPs तक सीमित करें और कुंजी-आधारित SSH का उपयोग करें।.

घटना प्रतिक्रिया प्लेबुक (विस्तृत कार्यप्रवाह)

1. ट्रायेज (पहले 24 घंटे)
   • पुष्टि करें कि क्या साइट प्रभावित प्लगइन/संस्करण चला रही है।.
   • सर्वर और डेटाबेस के फोरेंसिक स्नैपशॉट बनाएं।.
   • प्रशासनिक पासवर्ड बदलकर और साइट को रखरखाव मोड में रखकर पहुंच को सीमित करें।.
2. सीमित करें (24–72 घंटे)
   • तुरंत शोषण पैटर्न को ब्लॉक करने के लिए फ़ायरवॉल/WAF नियम लागू करें।.
   • यदि कोई विश्वसनीय पैच मौजूद नहीं है तो प्लगइन को निष्क्रिय या अनइंस्टॉल करें।.
   • फोरेंसिक कॉपी लेने के बाद संदिग्ध फ़ाइलों को संरक्षित और हटा दें।.
   • प्रशासनिक और सिस्टम क्रेडेंशियल्स को घुमाएं।.
3. Eradicate & Recover (72 hours – weeks)
   • समझौता की गई फ़ाइलों को साफ़ या पुनर्स्थापित करें; यदि अनिश्चित हैं, तो एक साफ़ बैकअप से पुनर्स्थापित करें।.
   • सभी सॉफ़्टवेयर घटकों को पैच और अपडेट करें।.
   • यदि आवश्यक हो तो सिस्टम को फिर से बनाएं और API कुंजी और रहस्यों को फिर से जारी करें।.
4. घटना के बाद
   • यह समझने के लिए मूल कारण विश्लेषण करें कि प्रशासनिक क्रेडेंशियल्स कैसे उजागर हुए।.
   • लॉगिंग, मॉनिटरिंग और प्रशासनिक प्रशिक्षण में सुधार करें।.
   • नियमित सुरक्षा आकलनों और पेनिट्रेशन परीक्षणों पर विचार करें।.

समझौते के संकेत (IoCs) — त्वरित चेकलिस्ट

• अपलोड या प्लगइन निर्देशिकाओं में संदिग्ध नामों के साथ नए फ़ाइलें
• Webshell signatures: base64_decode, eval(base64_decode(…)), preg_replace with /e, system/exec/passthru
• HTTP लॉग जो संदिग्ध फ़ाइलों या प्लगइन एंडपॉइंट्स पर POSTs तक पहुंच दिखाते हैं
• PHP प्रक्रियाओं से अप्रत्याशित आउटबाउंड कनेक्शन
• अनजान प्रशासनिक उपयोगकर्ता या भूमिका परिवर्तन

उदाहरण हार्डनिंग स्निप्पेट्स (सावधानी से उपयोग करें)

यदि आवश्यक नहीं है तो XML-RPC को निष्क्रिय करें:

add_filter('xmlrpc_enabled', '__return_false');

wp-config.php में प्लगइन/थीम फ़ाइल संपादन को निष्क्रिय करें:

define('DISALLOW_FILE_EDIT', true);

यदि आप तुरंत पैच नहीं कर सकते हैं — अस्थायी रक्षा विकल्प

• यदि यह गैर-आवश्यक है तो प्लगइन को पूरी तरह से अनइंस्टॉल और हटा दें।.
• बचे हुए कोड से बचने के लिए निष्क्रिय करने के बाद प्लगइन फ़ाइलें हटा दें।.
• वेब सर्वर या WAF स्तर पर प्लगइन के प्रशासनिक एंडपॉइंट्स को ब्लॉक करें।.
• wp-admin को ज्ञात IPs तक सीमित करें या wp-admin के सामने HTTP बेसिक ऑथ रखें।.
• शोषण संकेतों की निरंतर निगरानी करें।.

हांगकांग के सुरक्षा विशेषज्ञ से समापन सलाह

कोड पथ जो फ़ाइलें स्वीकार करते हैं और वेब रूट के तहत लिखते हैं, उन्हें उच्चतम सावधानी के साथ संभाला जाना चाहिए। प्रशासनिक स्तर की कमजोरियाँ अक्सर जल्दी से पूर्ण समझौते की ओर ले जाती हैं क्योंकि वे हमलावरों को स्थायी निष्पादन योग्य कोड रखने की अनुमति देती हैं। यदि आप प्रभावित प्लगइन चला रहे हैं और तुरंत अपडेट नहीं कर सकते हैं, तो सतर्क कदम उठाएं: प्लगइन को निष्क्रिय या हटा दें, सर्वर-स्तरीय प्रतिबंध लागू करें, 2FA और अन्य प्रशासनिक हार्डनिंग को लागू करें, और साबित होने तक समझौते का अनुमान लगाएं।.

जब संदेह हो, तो अपने होस्टिंग प्रदाता या एक विश्वसनीय घटना प्रतिक्रिया टीम को शामिल करें ताकि एक व्यापक और पेशेवर सफाई सुनिश्चित हो सके।.

अंतिम चेकलिस्ट - अब करने के लिए त्वरित क्रियाएँ

1. Verify plugin version: if <= 1.5.10, act immediately.
2. यदि एक पैच किया गया संस्करण उपलब्ध है, तो बिना देरी के अपडेट करें।.
3. यदि कोई पैच मौजूद नहीं है, तो प्लगइन फ़ाइलों को अनइंस्टॉल और हटाएँ।.
4. सभी प्रशासनिक खातों के लिए 2FA और मजबूत पासवर्ड लागू करें।.
5. अपलोड में PHP निष्पादन को अक्षम करें और सर्वर/WAF स्तर पर प्लगइन अपलोड एंडपॉइंट्स को ब्लॉक करें।.
6. संदिग्ध फ़ाइलों के लिए स्कैन करें और फोरेंसिक्स के लिए सबूत सुरक्षित रखें।.
7. सफाई के बाद सभी क्रेडेंशियल्स और API कुंजियों को बदलें।.
8. निगरानी सक्षम करें: फ़ाइल अखंडता, आउटबाउंड ट्रैफ़िक और एक्सेस लॉग।.

संदर्भ और आगे की पढ़ाई

• CVE-2025-6085 (सार्वजनिक सलाह)
• वर्डप्रेस सुरक्षा सख्ती दिशानिर्देश (आधिकारिक दस्तावेज़)
• PHP और वेब सर्वर सख्ती के सर्वोत्तम अभ्यास