MCS क्लाउड प्लेटफ़ॉर्म सुरक्षा ऑडिट

सीरलाइट द्वारा स्काईशिप डस्क

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

लेख बाहरी विशेषज्ञों के इस बहुत अलोकप्रिय लुक के बारे में है जिन्होंने Mail.ru Cloud Solutions (MCS) टीम को क्लाउड सेवा का परीक्षण करने में मदद की, और जो उन्होंने पाया, उसके बारे में। "बाहरी ताकतों" के रूप में MCS ने डिजिटल सुरक्षा को चुना, जिसे सुरक्षा समुदाय में उच्च विशेषज्ञता के लिए जाना जाता है। और इस लेख में हम कुछ दिलचस्प कमजोरियों का विश्लेषण करेंगे जो बाहरी ऑडिट के हिस्से के रूप में पाई गई थीं - ताकि जब आप अपनी क्लाउड सेवा करें तो आपको वही रेक मिलें।

उत्पाद विवरण

Mail.ru क्लाउड सॉल्यूशंस (MCS) क्लाउड में वर्चुअल इन्फ्रास्ट्रक्चर के निर्माण के लिए एक मंच है। इसमें IaaS, PaaS शामिल है, जो डेवलपर्स के लिए तैयार अनुप्रयोग छवियों का एक बाज़ार है। एमसीएस की वास्तुकला को ध्यान में रखते हुए, निम्नलिखित क्षेत्रों में उत्पाद की सुरक्षा की जांच करना आवश्यक था:

• वर्चुअलाइजेशन पर्यावरण अवसंरचना संरक्षण: हाइपरविजर, रूटिंग, फायरवॉल;
  
• ग्राहकों की वर्चुअल इन्फ्रास्ट्रक्चर की सुरक्षा: एसडीएन में नेटवर्क, निजी नेटवर्क सहित एक दूसरे से अलगाव;
  
• ओपनस्टैक और इसके खुले घटक;
  
• एस 3 खुद के विकास;
  
• IAM: एक रोल मॉडल के साथ बहु-किरायेदार परियोजनाएं;
  
• दृष्टि (मशीन दृष्टि): एपीआई और कमजोरियों जब छवियों के साथ काम करना;
  
• वेब इंटरफ़ेस और क्लासिक वेब हमले;
  
• Paa घटकों की कमजोरियाँ;
  
• सभी घटकों के एपीआई।
  

शायद, बाद के इतिहास के लिए जरूरी सब कुछ है।

किस तरह के काम किए गए और उनकी आवश्यकता क्यों है?

एक सुरक्षा ऑडिट का उद्देश्य कमजोरियों और कॉन्फ़िगरेशन त्रुटियों की पहचान करना है जो व्यक्तिगत डेटा के रिसाव, संवेदनशील जानकारी के संशोधन या सेवाओं की उपलब्धता के उल्लंघन के कारण हो सकता है।

काम के दौरान, जो औसतन 1-2 महीने तक रहता है, ऑडिटर संभावित हमलावरों की कार्रवाई को दोहराते हैं और चयनित सेवा के क्लाइंट और सर्वर भागों में कमजोरियों की तलाश करते हैं। MCS क्लाउड प्लेटफ़ॉर्म के ऑडिट के संदर्भ में, निम्नलिखित उद्देश्यों की पहचान की गई थी:

1. सेवा में प्रमाणीकरण का विश्लेषण। इस घटक में कमजोरियां तुरंत अन्य लोगों के खातों में जाने में मदद करेंगी।
   
2. रोल मॉडल और विभिन्न खातों के बीच अभिगम नियंत्रण का अध्ययन। एक हमलावर के लिए, किसी और की वर्चुअल मशीन तक पहुंचने की क्षमता एक स्वागत योग्य लक्ष्य है।
   
3. ग्राहक पक्ष की कमजोरियां। XSS / CSRF / CRLF / आदि। शायद दुर्भावनापूर्ण लिंक के माध्यम से अन्य उपयोगकर्ताओं पर हमला करना संभव है?
   
4. सर्वर साइड में कमजोरियां: आरसीई और सभी प्रकार के इंजेक्शन (एसक्यूएल / एक्सएक्सई / एसएसआरएफ और इसी तरह)। सर्वर भेद्यता आमतौर पर खोजने में अधिक मुश्किल होती है, लेकिन वे एक साथ कई उपयोगकर्ताओं के समझौते का नेतृत्व करते हैं।
   
5. उपयोगकर्ता खंडों का नेटवर्क खंड अलगाव विश्लेषण। एक हमलावर के लिए, अलगाव की कमी अन्य उपयोगकर्ताओं पर हमले की सतह को काफी बढ़ाती है।
   
6. व्यापार तर्क विश्लेषण। क्या किसी व्यवसाय को बेवकूफ बनाना और मुफ्त में वर्चुअल मशीन बनाना संभव है?
   

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

कमजोरियाँ मिलीं

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

उन स्थानों को खोजना महत्वपूर्ण है जो संदिग्ध लगते हैं या दूसरों से बहुत अलग हैं। और पहली खतरनाक भेद्यता इस तरह से पाई गई थी।

IDOR

IDOR भेद्यताएं (असुरक्षित प्रत्यक्ष वस्तु संदर्भ, वस्तुओं के लिए असुरक्षित प्रत्यक्ष संबंध) व्यापार तर्क में सबसे आम कमजोरियों में से एक हैं जो उन वस्तुओं तक पहुंच प्राप्त करने के लिए एक तरह से या किसी अन्य की अनुमति देती हैं जिन तक पहुंच की वास्तव में अनुमति नहीं है। आईडीओआर कमजोरियां उपयोगकर्ता की महत्वपूर्ण डिग्री के अलग-अलग जानकारी प्राप्त करने की संभावना पैदा करती हैं।

IDOR विकल्पों में से एक सिस्टम ऑब्जेक्ट्स (उपयोगकर्ता, बैंक खाते, टोकरी में माल) के साथ क्रिया करना है ताकि इन वस्तुओं तक पहुंच पहचानकर्ताओं में हेरफेर किया जा सके। यह सबसे अप्रत्याशित परिणाम की ओर जाता है। उदाहरण के लिए, प्रेषक के खाते के प्रतिस्थापन की संभावना, जिसके कारण आप उन्हें अन्य उपयोगकर्ताओं से चुरा सकते हैं।

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

सर्वर साइड अनुरोध क्षमा (SSRF)

OpenSource उत्पाद अच्छे हैं क्योंकि उनके पास समस्याओं के विस्तृत तकनीकी विवरण के साथ बड़ी संख्या में फ़ोरम हैं और यदि आप भाग्यशाली हैं, तो समाधान का वर्णन करें। लेकिन इस सिक्के का एक दूसरा पहलू भी है: प्रसिद्ध कमजोरियाँ भी विस्तृत हैं। उदाहरण के लिए, ओपनस्टैक फोरम में कमजोरियों [XSS] और [SSRF] का अद्भुत वर्णन है, जो किसी कारण से कोई ठीक करने की जल्दी में नहीं है।

बार-बार एप्लिकेशन की कार्यक्षमता उपयोगकर्ता को सर्वर पर एक लिंक भेजने की क्षमता है जो सर्वर पर क्लिक करता है (उदाहरण के लिए, किसी निर्दिष्ट स्रोत से छवि डाउनलोड करने के लिए)। लिंक या प्रतिक्रियाओं की अपर्याप्त सुरक्षा फ़िल्टरिंग के साथ स्वयं सर्वर से उपयोगकर्ताओं के पास लौट आए, ऐसी कार्यक्षमता का उपयोग हमलावरों द्वारा आसानी से किया जाता है।

SSRF भेद्यता हमले के विकास को बहुत आगे बढ़ा सकती है। एक हमलावर मिल सकता है:

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

ओपनस्टैक लंबे समय से अपने "ब्लाइंड" SSRF भेद्यता के लिए जाना जाता है: जब आप सर्वर का उपयोग करते हैं, तो आपको इससे प्रतिक्रिया नहीं मिलती है, लेकिन अनुरोध के परिणाम के आधार पर आपको विभिन्न प्रकार की त्रुटियां / देरी मिलती हैं। इसके आधार पर, आप सभी आगामी परिणामों के साथ, आंतरिक नेटवर्क पर मेजबानों पर बंदरगाहों को स्कैन कर सकते हैं, जिसे कम करके आंका नहीं जाना चाहिए। उदाहरण के लिए, किसी उत्पाद में बैक ऑफिस के लिए API हो सकता है, जो केवल कॉर्पोरेट नेटवर्क से उपलब्ध हो। दस्तावेज़ीकरण (अंदरूनी सूत्रों के बारे में मत भूलना), एक हमलावर SSRF का उपयोग करके आंतरिक तरीकों का उपयोग कर सकता है। उदाहरण के लिए, यदि आप किसी तरह से उपयोगी URL की अनुमानित सूची प्राप्त करने में कामयाब रहे, तो SSRF का उपयोग करके आप उनके माध्यम से जा सकते हैं और एक अनुरोध पर अमल कर सकते हैं - अपेक्षाकृत बोलने, खाते से खाते में पैसे स्थानांतरित करने या सीमाएं बदलने के लिए।

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

और HackerOne (h1) सेवा से सार्वजनिक रूप से उपलब्ध इस रिपोर्ट में, मेटाडेटा को पढ़ने की क्षमता के साथ एक गैर-अंधा SSRF का शोषण पूरे Shopify बुनियादी ढांचे के लिए रूट का उपयोग करता है।

एमसीएस में, समान कार्यक्षमता वाले दो स्थानों में, SSRF कमजोरियों की खोज की गई थी, लेकिन फ़ायरवॉल और अन्य सुरक्षा के कारण उनका दोहन करना लगभग असंभव था। एक तरह से या किसी अन्य, एमसीएस टीम ने समुदाय के लिए इंतजार किए बिना, इस समस्या को वैसे भी तय किया।

लोडिंग गोले के बजाय XSS

सैकड़ों अध्ययनों के बावजूद, साल-दर-साल XSS (क्रॉस-साइट स्क्रिप्टिंग अटैक) अभी भी सबसे आम वेब कमजोरियों (या हमले ?) है।

फ़ाइलें डाउनलोड करना किसी भी सुरक्षा शोधकर्ता के लिए एक पसंदीदा जगह है। अक्सर यह पता चलता है कि आप एक मनमाना स्क्रिप्ट (asp / jsp / php) लोड कर सकते हैं और OS कमांड्स को निष्पादित कर सकते हैं, जो कि पेंटेस्टर्स की शब्दावली में है - "लोड शेल"। लेकिन ऐसी कमजोरियों की लोकप्रियता दोनों दिशाओं में काम करती है: उन्हें याद किया जाता है और उनके खिलाफ उपकरण विकसित किए जाते हैं, इसलिए हाल ही में "शेल को लोड करने" की संभावना शून्य हो गई है।

हमलावर टीम (डिजिटल सुरक्षा द्वारा प्रतिनिधित्व) भाग्यशाली थी। ठीक है, एमसीएस में, सर्वर की तरफ, डाउनलोड की गई फ़ाइलों की सामग्री की जांच की गई थी, केवल छवियों की अनुमति थी। लेकिन एसवीजी भी एक तस्वीर है। और खतरनाक एसवीजी चित्र क्या हो सकते हैं? क्योंकि आप उन में जावास्क्रिप्ट अंश एम्बेड कर सकते हैं!

यह पता चला कि डाउनलोड की गई फाइलें एमसीएस सेवा के सभी उपयोगकर्ताओं के लिए उपलब्ध हैं - जिसका अर्थ है कि आप क्लाउड के अन्य उपयोगकर्ताओं पर हमला कर सकते हैं, अर्थात् प्रशासक।


XSS हमले का उपयोग करके फ़िशिंग लॉगिन फ़ॉर्म का उपयोग करने का एक उदाहरण

XSS हमले के शोषण के उदाहरण:

• क्यों एक सत्र चोरी करने की कोशिश (विशेष रूप से अब से हर जगह HTTP-Only कुकीज़ को js-script का उपयोग करके चोरी से सुरक्षित किया जाता है) यदि डाउनलोड की गई स्क्रिप्ट संसाधन API तक तुरंत पहुंच सकती है? इस स्थिति में, पेलोड XHR अनुरोधों के माध्यम से सर्वर कॉन्फ़िगरेशन को बदल सकता है, उदाहरण के लिए, हमलावर की सार्वजनिक SSH कुंजी जोड़ें और सर्वर तक SSH पहुंच प्राप्त करें।
  
• यदि CSP नीति (सामग्री सुरक्षा नीति) जावास्क्रिप्ट के कार्यान्वयन पर रोक लगाती है, तो एक हमलावर इसके बिना कर सकता है। शुद्ध एचटीएमएल में, साइट का फर्जी लॉगिन फ़ॉर्म तैयार करें और ऐसे उन्नत फ़िशिंग के माध्यम से व्यवस्थापक का पासवर्ड चोरी करें: उपयोगकर्ता के लिए फ़िशिंग पृष्ठ एक ही URL पर है, और उपयोगकर्ता के लिए इसका पता लगाना अधिक कठिन है।
  
• अंत में, एक हमलावर क्लाइंट DoS - 4 KB से बड़े कुकीज़ सेट कर सकता है। यह उपयोगकर्ता के लिए एक बार लिंक को खोलने के लिए पर्याप्त है और पूरी साइट दुर्गम हो जाती है जब तक कि आप विशेष रूप से ब्राउज़र को साफ करने का अनुमान नहीं लगाते हैं: अधिकांश मामलों में वेब सर्वर इस तरह के क्लाइंट को स्वीकार करने से इनकार कर देगा।
  

आइए, इस समय एक और खुलासा एक्सएसएस का उदाहरण देखें, इस बार ट्रिकियर ऑपरेशन के साथ। MCS सेवा आपको समूहों में फ़ायरवॉल सेटिंग्स को संयोजित करने की अनुमति देती है। XSS को समूह नाम में खोजा गया था। इसकी ख़ासियत यह थी कि वेक्टर तुरंत काम नहीं करता था, नियमों की सूची देखते समय नहीं, लेकिन जब समूह हटा दिया गया था:



यही है, परिदृश्य इस प्रकार था: एक हमलावर नाम में "लोड" के साथ एक फ़ायरवॉल नियम बनाता है, व्यवस्थापक इसे थोड़ी देर के बाद नोटिस करता है, हटाने की प्रक्रिया शुरू करता है। और यहां दुर्भावनापूर्ण जेएस भी पूरा करता है।

एमसीएस डेवलपर्स के लिए, डाउनलोड करने योग्य एसवीजी छवियों में एक्सएसएस से बचाने के लिए (यदि उन्हें नहीं छोड़ा जा सकता है), डिजिटल सुरक्षा टीम ने सिफारिश की:

• एक अलग डोमेन पर उपयोगकर्ताओं द्वारा अपलोड की गई फ़ाइलों को होस्ट करें जिनका "कुकी" से कोई लेना-देना नहीं है। स्क्रिप्ट को अन्य डोमेन के संदर्भ में निष्पादित किया जाएगा और एमसीएस के लिए खतरा पैदा नहीं करेगा।
  
• सर्वर की HTTP प्रतिक्रिया में, हेडर "सामग्री-स्वभाव: अनुलग्नक" दें। फिर फ़ाइलों को ब्राउज़र द्वारा डाउनलोड किया जाएगा, और निष्पादित नहीं किया जाएगा।
  

इसके अलावा, डेवलपर्स के लिए ऑपरेटिंग XSS के जोखिमों को कम करने के लिए अब कई तरीके उपलब्ध हैं:

• "केवल HTTP" झंडे का उपयोग करके, आप दुर्भावनापूर्ण जावास्क्रिप्ट को दुर्गम कुकीज़ के सत्र हेडर बना सकते हैं;
  
• एक सही ढंग से कार्यान्वित CSP नीति एक हमलावर के लिए XSS के संचालन को काफी जटिल करेगी ;
  
• आधुनिक टेम्प्लेट इंजन, जैसे कि एंगुलर या रिएक्ट, उपयोगकर्ता के ब्राउज़र में प्रदर्शित करने से पहले उपयोगकर्ता डेटा को स्वचालित रूप से साफ़ करता है।
  

दो-कारक प्रमाणीकरण कमजोरियाँ

खाता सुरक्षा बढ़ाने के लिए, उपयोगकर्ताओं को हमेशा 2FA (दो-कारक प्रमाणीकरण) सक्षम करने की सलाह दी जाती है। वास्तव में, यह एक प्रभावी तरीका है कि किसी हमलावर को सेवा तक पहुंच प्राप्त करने से रोकने के लिए यदि उपयोगकर्ता क्रेडेंशियल्स से समझौता किया गया है।

लेकिन क्या दूसरे प्रमाणीकरण कारक का उपयोग हमेशा खाते की सुरक्षा की गारंटी देता है? 2FA कार्यान्वयन में, ऐसे सुरक्षा मुद्दे हैं:

• OTP- कोड (एक बार कोड) की किसी न किसी खोज। ऑपरेशन की सादगी के बावजूद, ओटीपी ब्रूट के खिलाफ सुरक्षा की कमी के रूप में ऐसी त्रुटियां भी बड़ी कंपनियों द्वारा सामना की जाती हैं: स्लैक केस, फेसबुक केस ।
  
• कमजोर पीढ़ी का एल्गोरिथ्म, उदाहरण के लिए, निम्नलिखित कोड की भविष्यवाणी करने की क्षमता।
  
• तार्किक त्रुटियां, उदाहरण के लिए, आपके फोन पर किसी और के ओटीपी का अनुरोध करने की क्षमता, जैसा कि शोपिफाई के साथ था ।
  

MCS के मामले में, 2FA Google प्रमाणक और डुओ के आधार पर कार्यान्वित किया जाता है। प्रोटोकॉल का समय से पहले ही परीक्षण कर लिया गया है, लेकिन आवेदन पक्ष पर कोड सत्यापन का कार्यान्वयन जाँच के लायक है।

MCS 2FA का उपयोग कई स्थानों पर किया जाता है:

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

यह मानते हुए कि बैकअप कोड ओटीपी एप्लिकेशन द्वारा उत्पन्न किए गए लाइन मानों की एक ही श्रेणी में स्थित थे, कम समय में कोड लेने का मौका बहुत अधिक था।


Burp: Intruder टूल का उपयोग करके OFA को 2FA अक्षम करने के लिए चयन करने की प्रक्रिया

परिणाम

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

लेकिन यहां यह ध्यान रखना महत्वपूर्ण है कि सुरक्षा निरंतर काम है। सेवाएं स्थिर नहीं हैं, वे लगातार विकसित हो रही हैं। और कमजोरियों के बिना पूरी तरह से एक उत्पाद विकसित करना असंभव है। लेकिन आप उन्हें समय पर पा सकते हैं और उनकी पुनरावृत्ति की संभावना को कम कर सकते हैं।

अब एमसीएस में सभी उल्लिखित कमजोरियां पहले से ही तय हैं। और नए लोगों की संख्या को कम करने और अपने जीवनकाल को छोटा करने के लिए, प्लेटफ़ॉर्म टीम ऐसा करना जारी रखती है:

• बाहरी कंपनियों द्वारा नियमित ऑडिट करना;
  
• बग बाउंटी-प्रोग्राम Mail.ru ग्रुप में भागीदारी का समर्थन और विकास करने के लिए;
  
• सुरक्षा करने के लिए। :)