पेंटेस्टर इतिहास

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

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

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

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



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

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



तो ऐसे खतरों से खुद को कैसे बचाएं?

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

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

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

तो, किसी साइट को ज़ीरो-डे के हमले से बचाने के लिए फ़र्ज़ी या सोर्स कोड एनालिसिस का सहारा लिए बिना क्या करना होगा? मेरी राय में, कम से कम निम्नलिखित को लागू किया जाना चाहिए:
- सभी इंटरफेस (ftp, प्रशासन अनुभाग, आदि) में इस्तेमाल किए गए पहचानकर्ताओं के लिए मजबूत पासवर्ड।
- सभी प्रशासन इंटरफेस केवल विश्वसनीय आईपी पते के लिए उपलब्ध होना चाहिए; वैकल्पिक रूप से, जहाँ भी संभव हो, द्वि-कारक प्रमाणीकरण का उपयोग करना।
- सभी घटकों में विशेषाधिकारों का न्यूनीकरण।
- सही ढंग से कॉन्फ़िगर किया गया एक्सेस कंट्रोल टेबल (फाइल सिस्टम के साथ शुरू और कंटेंट मैनेजमेंट सिस्टम का उपयोग करके एक्सेस कंट्रोल के साथ समाप्त होता है, अगर यह ऐसी कार्यक्षमता प्रदान करता है)।
- वेब सर्वर और उसके वातावरण के सुरक्षित विन्यास (उदाहरण के लिए, सुरक्षित PHP कॉन्फ़िगरेशन)।
- निवारक नियंत्रण तंत्र (वेब ​​एप्लिकेशन फ़ायरवॉल) का उपयोग।
- वेब एप्लिकेशन से किसी अन्य नेटवर्क घटकों तक नेटवर्क पहुंच का प्रतिबंध; एक अलग नेटवर्क वातावरण (उर्फ व्यक्तिगत DMZ) में एक वेब सर्वर की मेजबानी।

इन तरीकों का अनुसरण करने से आपके वेब एप्लिकेशन की सुरक्षा में उल्लेखनीय वृद्धि होगी। मैं आपको लगातार दूसरी तरफ अच्छे के साथ अच्छे युद्ध में सफलता की कामना करता हूं :)