स्थानीय फ़ाइल समावेश (LFI) क्या है?

स्थानीय फ़ाइल समावेश (LFI) एक वेब एप्लिकेशन भेद्यता वर्ग है जहाँ एक हमलावर एक सर्वर-साइड स्क्रिप्ट को स्थानीय फ़ाइल सिस्टम से फ़ाइलें शामिल करने और मूल्यांकन करने के लिए मजबूर कर सकता है। वर्डप्रेस थीम जैसे PHP अनुप्रयोगों में, यह आमतौर पर include(), require(), या समान कार्यों के असुरक्षित उपयोग से उत्पन्न होता है जहाँ एक उपयोगकर्ता-नियंत्रित पैरामीटर एक फ़ाइल का चयन करता है। सफल शोषण संवेदनशील फ़ाइलों (wp-config.php, .env, बैकअप) को प्रकट कर सकता है, क्रेडेंशियल्स का खुलासा कर सकता है, और कुछ कॉन्फ़िगरेशन में कोड निष्पादन की ओर ले जा सकता है।.

LFI दूरस्थ फ़ाइल समावेश (RFI) से भिन्न है — आधुनिक PHP अक्सर दूरस्थ समावेशों को निष्क्रिय कर देता है, इसलिए LFI एक अधिक सामान्य वास्तविक-विश्व जोखिम है। स्थानीय फ़ाइलें अक्सर रहस्यों और कॉन्फ़िगरेशन को शामिल करती हैं, जिससे LFI हमलावरों के लिए अत्यधिक मूल्यवान हो जाता है।.

एसी सेवाएँ थीम भेद्यता: त्वरित तथ्य

• प्रभावित उत्पाद: “एसी सेवाएँ | एचवीएसी, एयर कंडीशनिंग और हीटिंग कंपनी” वर्डप्रेस थीम (थीम परिवार: विंडो / एसी सेवाएँ)
• संवेदनशील संस्करण: ≤ 1.2.5
• सुरक्षा कमजोरी का प्रकार: स्थानीय फ़ाइल समावेश (LFI)
• CVE: CVE-2026-27326
• रिपोर्ट किया गया: स्वतंत्र शोधकर्ता (सार्वजनिक प्रकटीकरण तिथि 2026-03-04)
• आवश्यक विशेषाधिकार: कोई नहीं — बिना प्रमाणीकरण
• प्रभाव: स्थानीय फ़ाइलों का प्रकटीकरण (जिसमें wp-config.php शामिल है), संभावित डेटाबेस क्रेडेंशियल लीक, सर्वर कॉन्फ़िगरेशन और लिखने योग्य अपलोड निर्देशिकाओं के आधार पर साइट पर कब्जा संभव
• पैच स्थिति: सक्रिय साइटों को जोखिम में मानें जब तक विक्रेता एक पुष्टि की गई फ़िक्स प्रकाशित नहीं करता और आप इसे लागू नहीं करते।.

यह भेद्यता वर्डप्रेस साइटों के लिए क्यों खतरनाक है

इस LFI को गंभीर बनाने वाले प्रमुख गुण:

1. बिना प्रमाणीकरण का शोषण — हमलावर बिना खाते के जांच और शोषण कर सकते हैं।.
2. संवेदनशील स्थानीय फ़ाइलें — वर्डप्रेस इंस्टॉलेशन आमतौर पर wp-config.php, लॉग, बैकअप और अन्य फ़ाइलें होती हैं जो क्रेडेंशियल और रहस्यों को रखती हैं।.
3. स्वचालित सामूहिक स्कैनिंग — हमलावर प्रकटीकरण के तुरंत बाद कमजोर विषयों को खोजने और शोषण करने के लिए बॉट तैनात करते हैं।.
4. पूर्ण समझौते की ओर बढ़ना — उजागर DB क्रेडेंशियल सामग्री हेरफेर, व्यवस्थापक निर्माण, या स्थायी बैकडोर की ओर ले जा सकते हैं।.
5. आपूर्ति श्रृंखला जोखिम — कई ग्राहक साइटों पर तैनात खरीदे गए विषयों के कारण व्यापक जोखिम हो सकता है।.

इन कारकों को देखते हुए, तुरंत स्तरित शमन लागू करें: शोषण प्रयासों को ब्लॉक करें, पिछले शोषण का पता लगाएं, और मूल कारण का पैच करें।.

हमलावर LFI का दुरुपयोग कैसे कर सकते हैं (और अक्सर करेंगे)

हमलावर आमतौर पर इस प्लेबुक का पालन करते हैं:

1. फिंगरप्रिंटिंग — कमजोर विषय और संस्करण का उपयोग करने वाली साइटों की पहचान करें।.
2. जांच — ज्ञात कमजोर एंडपॉइंट्स पर तैयार किए गए अनुरोध भेजें, अक्सर निर्देशिका ट्रैवर्सल अनुक्रमों के साथ (../ या एन्कोडेड समकक्ष)।.
3. डेटा निष्कर्षण — wp-config.php और अन्य फ़ाइलें प्राप्त करें जिनमें क्रेडेंशियल्स या सॉल्ट्स होते हैं।.
4. क्रेडेंशियल का उपयोग या वृद्धि — डेटा को बदलने, व्यवस्थापक उपयोगकर्ता बनाने, या आगे की पहुंच प्राप्त करने के लिए उजागर DB क्रेडेंशियल्स का उपयोग करें।.
5. स्थिरता और सफाई — बैकडोर/वेबशेल्स स्थापित करें और निशान छिपाने के लिए लॉग हटा दें।.

LFI प्रयासों को जल्दी रोकना जोखिम को कम करने और कई स्वचालित हमलों को रोकने का एक प्रभावी तरीका है।.

समझौते के संकेत (IoCs) और पहचान मार्गदर्शन

लॉग और फ़ाइल सिस्टम पर इन संकेतों की तलाश करें — LFI शोषण प्रयासों के लिए सामान्य IoCs:

• HTTP requests to theme endpoints with query parameters containing traversal payloads (“../” or “..%2F”).
• ऐसे अनुरोध जिनमें पैरामीटर जैसे फ़ाइल=, पृष्ठ=, टेम्पलेट=, शामिल=, शामिल करें=, पथ=, दृश्य=, आदि, विशेष रूप से यदि वे थीम कोड से मैप करते हैं।.
• 404/403 लौटाने वाले अनुरोधों के लिए बार-बार 200 प्रतिक्रियाएँ।.
• wp-config.php, .env, या बैकअप फ़ाइलों तक वेब पहुंच के प्रमाण।.
• अपलोड, wp-content, या थीम निर्देशिकाओं में नए या संशोधित PHP फ़ाइलें (संभावित वेबशेल्स)।.
• अप्रत्याशित डेटाबेस परिवर्तन (नए व्यवस्थापक उपयोगकर्ता, मैलवेयर के साथ संशोधित पोस्ट)।.
• फ़ाइल सामग्री या स्टैक ट्रेस प्रकट करने वाले उच्च स्तर की त्रुटि लॉग।.
• वेब सर्वर से अप्रत्याशित आउटबाउंड कनेक्शन।.

ऐसे पहचान कार्य जो आप अभी कर सकते हैं:

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

तत्काल उपाय जो आप अभी लागू कर सकते हैं (कोई थीम अपडेट आवश्यक नहीं)

यदि आप प्रभावित थीम चला रहे हैं और तुरंत इसे अपडेट नहीं कर सकते, तो इन व्यावहारिक कदमों को लागू करें:

1. किनारे पर LFI पैटर्न को अवरुद्ध करें (वर्चुअल पैचिंग)
   सर्वर या फ़ायरवॉल नियम लागू करें जो निर्देशिका यात्रा को अवरुद्ध करते हैं (../ और एन्कोडेड रूपों), शून्य बाइट्स, और रैपर योजनाएँ (php://, रैपर और फ़िल्टर को अस्वीकार करें:, file:). जहां संभव हो, थीम शामिल अंत बिंदुओं तक पहुंच को विश्वसनीय मूल स्रोतों तक सीमित करें।.
2. संवेदनशील फ़ाइलों तक सीधे पहुँच को सीमित करें
   अनुरोधों को अस्वीकार करने के लिए वेब सर्वर नियम जोड़ें wp-config.php, .env, .git और अन्य ज्ञात संवेदनशील नामों के लिए।.
3. थीम फ़ाइलों को लॉक करें
   संदिग्ध एंट्री-पॉइंट फ़ाइलों को अस्थायी रूप से हटा दें या नाम बदलें जो untrusted input के साथ include() को कॉल करते हैं। यदि किसी कमजोर फ़ाइल की सार्वजनिक कार्यक्षमता के लिए आवश्यकता नहीं है, तो इसे वेब रूट से हटा दें।.
4. फ़ाइल अनुमतियों और PHP निष्पादन को मजबूत करें
   सुनिश्चित करें कि अपलोड निर्देशिकाएँ PHP को निष्पादित नहीं करती हैं। न्यूनतम विशेषाधिकार अनुमतियाँ लागू करें (फ़ाइलें 644, निर्देशिकाएँ 755) और सत्यापित करें कि वेब सर्वर उपयोगकर्ता को कोर थीम या प्लगइन निर्देशिकाओं में लिखने की अनुमति नहीं है।.
5. यदि आप प्रकटीकरण के सबूत पाते हैं तो कुंजी और क्रेडेंशियल्स को घुमाएँ
   यदि wp-config.php या अन्य रहस्यों तक पहुँच गई है, तो तुरंत डेटाबेस क्रेडेंशियल्स और किसी भी उजागर API कुंजी को घुमाएँ, और इसके अनुसार कॉन्फ़िगरेशन अपडेट करें।.
6. संदिग्ध होस्ट की निगरानी करें और अलग करें
   जब आप जांच कर रहे हों तो हमलावर IP को अवरुद्ध करें। यदि कोई स्थायी बैकडोर या शेल मौजूद है, तो आगे के नुकसान को रोकने के लिए होस्ट को अलग करने पर विचार करें।.
7. सुधार से पहले बैकअप लें
   साक्ष्य को संरक्षित करने और पुनर्प्राप्ति बिंदु प्रदान करने के लिए पूर्ण फ़ाइल सिस्टम और डेटाबेस बैकअप बनाएं।.

इन नियंत्रणों को तुरंत लागू करें - ये तत्काल जोखिम को कम करते हैं और पूर्ण सुधार करने के लिए समय प्रदान करते हैं।.

सुरक्षित कोड सुधार और डेवलपर मार्गदर्शन

यदि आप थीम बनाए रखते हैं या किसी डेवलपर के साथ काम करते हैं, तो शामिल/आवश्यक संचालन के लिए अप्रमाणित, उपयोगकर्ता-नियंत्रित इनपुट के उपयोग को समाप्त करके मूल कारण को ठीक करें। सबसे मजबूत नियंत्रण श्वेतसूची बनाना है।.

अनुशंसित सुरक्षित पैटर्न

1. अनुमत टेम्पलेट या फ़ाइलों की एक श्वेतसूची का उपयोग करें। तार्किक नामों को वास्तविक फ़ाइलों से मैप करें:

// अनुमत टेम्पलेट मैपिंग

2. कभी भी कच्चा इनपुट शामिल/आवश्यक में न भेजें। श्वेतसूची सबसे मजबूत नियंत्रण है; basename()/realpath() केवल आंशिक शमन हैं।.

3. यदि पथ में इनपुट का अनुवाद अनिवार्य है, तो इसे मानकीकरण करें और सुनिश्चित करें कि फ़ाइल एक सुरक्षित आधार निर्देशिका के भीतर है:

$base = realpath( get_template_directory() . '/templates' );

4. गतिशील कोड मूल्यांकन (eval(), create_function, आदि) से बचें और फ़ाइल सामग्री को डेटा के रूप में मानें, न कि निष्पादन योग्य कोड के रूप में।.

5. सुनिश्चित करें कि वेब सर्वर प्रक्रिया के पास फ़ाइल संचालन के लिए न्यूनतम विशेषाधिकार हैं और यह मनमाने ढंग से थीम कोड को संशोधित नहीं कर सकती।.

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

पूर्ण सुधार चेकलिस्ट (प्राथमिकता के अनुसार)

इन चरणों का पालन करें जो तात्कालिकता के क्रम में हैं:

तात्कालिक (घंटों के भीतर)

• LFI पैटर्न और ज्ञात कमजोर अंत बिंदुओं को लक्षित करने वाले अनुरोधों को अवरुद्ध करने के लिए एज/सर्वर नियम लागू करें।.
• nginx/apache नियमों के माध्यम से संवेदनशील फ़ाइलों तक सीधी पहुंच को अस्वीकार करें।.
• परिवर्तनों से पहले पूर्ण बैकअप (फ़ाइल सिस्टम + DB) बनाएं।.

अल्पकालिक (24–72 घंटे)

• यदि विक्रेता पैच उपलब्ध है, तो सभी साइटों पर थीम को अपडेट करें (पहले स्टेजिंग पर परीक्षण करें)।.
• यदि कोई पैच मौजूद नहीं है, तो उत्पादन पर कमजोर थीम को अक्षम या बदलें; सुधार करते समय एक डिफ़ॉल्ट या ज्ञात-अच्छी थीम पर स्विच करें।.
• यदि समझौता होने का संदेह है, तो डेटाबेस और API क्रेडेंशियल्स को घुमाएं।.

मध्यावधि (1–2 सप्ताह)

• संशोधित या दुर्भावनापूर्ण फ़ाइलों को सत्यापित स्रोतों या बैकअप से स्वच्छ प्रतियों के साथ बदलें।.
• दुर्भावनापूर्ण उपयोगकर्ताओं, निर्धारित कार्यों और अप्रत्याशित आउटबाउंड कनेक्शनों के लिए ऑडिट करें।.
• पूर्ण मैलवेयर स्कैन और फ़ाइल अखंडता जांच चलाएँ।.

दीर्घकालिक (चल रहा)

• फ़ाइल अनुमतियों को मजबूत करें और अपलोड में PHP निष्पादन को अक्षम करें।.
• विसंगतियों के लिए लॉगिंग और निगरानी लागू करें; सिस्टम को पैच रखें।.
• अपडेट के लिए स्टेजिंग का उपयोग करें और एक घटना प्रतिक्रिया योजना बनाए रखें।.

वर्डप्रेस होस्ट और साइट मालिकों के लिए हार्डनिंग सिफारिशें

• पूर्ण साइट बैकअप और पुनर्स्थापन प्रक्रियाओं को बनाए रखें और परीक्षण करें।.
• फ़ाइल प्रणाली और डेटाबेस खातों पर न्यूनतम विशेषाधिकार लागू करें।.
• मजबूत रहस्यों को लागू करें और उन्हें समय-समय पर घुमाएँ (DB पासवर्ड, साल्ट, API कुंजी)।.
• व्यवस्थापक इंटरफ़ेस के माध्यम से फ़ाइल संपादन अक्षम करें: define('DISALLOW_FILE_EDIT', true);
• समय-समय पर भेद्यता स्कैन और फ़ाइल अखंडता जांच चलाएँ।.
• वेब सर्वर को एक्सेस अस्वीकार करने के लिए कॉन्फ़िगर करें .git, .env और बैकअप फ़ाइलें।.
• जहाँ संभव हो, अनावश्यक आउटबाउंड सर्वर कनेक्शनों को प्रतिबंधित करें।.
• व्यवस्थापक खातों के लिए दो-कारक प्रमाणीकरण सक्षम करें और लॉगिन प्रयासों की निगरानी करें।.

घटना प्रतिक्रिया: यदि आपको संदेह है कि आपकी साइट से समझौता किया गया है तो क्या करें

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

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

पेशेवर मदद और सेवाएँ प्राप्त करना

यदि आपको शमन लागू करने, फोरेंसिक विश्लेषण करने, या कई ग्राहकों के बीच साइटों को पुनर्स्थापित करने में सहायता की आवश्यकता है, तो एक विश्वसनीय सुरक्षा सलाहकार या घटना प्रतिक्रिया प्रदाता की तलाश करें। संभावित प्रदाताओं से पूछें:

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

सुरक्षा टीमों के लिए सुरक्षित परीक्षण मार्गदर्शन और नोट्स।

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

सार्वजनिक शोषण कोड और सामूहिक स्कैनर प्रकटीकरण के बाद जल्दी दिखाई देते हैं; शमन को तुरंत लागू करें।.

परिशिष्ट - उदाहरण सर्वर नियम (उच्च स्तर, उपयोग से पहले परीक्षण करें)

उच्च-स्तरीय उदाहरण जिन्हें आप अपने वातावरण में अनुकूलित कर सकते हैं:

• सीधे पहुंच को अवरुद्ध करें wp-config.php (Nginx स्निपेट): स्थान ~* wp-config.php { सभी को अस्वीकार करें; }
• यात्रा अनुक्रमों को शामिल करने वाले अनुरोधों को अस्वीकार करें: अनुरोधों को अस्वीकार करें जिनमें ../ या एन्कोडेड वेरिएंट जहां आपका सर्वर अनुरोध मिलान का समर्थन करता है।.
• संदिग्ध.wrapper योजनाओं को ब्लॉक करें: अनुरोधों को अस्वीकार करें जिनमें php://, रैपर और फ़िल्टर को अस्वीकार करें:, अपेक्षा:, आदि।.

ये नियम जानबूझकर सामान्य हैं - उत्पादन में तैनात करने से पहले स्टेजिंग में सावधानी से अनुकूलित और परीक्षण करें।.