नीचे कोई ऑडियो प्लेयर नहीं है? सुनना सीधे साउंडक्लाउड पर।

डौग  पासवर्ड प्रबंधक दरारें, लॉगिन बग, और क्वीन एलिजाबेथ I बनाम मैरी क्वीन ऑफ़ स्कॉट्स ... बिल्कुल!

वह सब, और बहुत कुछ, नग्न सुरक्षा पॉडकास्ट पर।

[संगीत मोडेम]

पॉडकास्ट में आपका स्वागत है, सब लोग।

मैं डौग आमोत हूँ; वह पॉल डकलिन है।

पॉल, आप कैसे हैं?

बत्तख।  वाह!

16वीं शताब्दी की सूचना प्रौद्योगिकी स्कलडगरी, नेकेड सिक्योरिटी पॉडकास्ट, डगलस से मिलती है।

मैं इंतजार नहीं कर सकता!

डौग  जाहिर है, हां... हम उस पर जल्द ही पहुंचेंगे।

लेकिन पहले, हमेशा की तरह, टेक इतिहास के इस सप्ताह में, 28 मई 1987 को, ऑनलाइन सेवा प्रदाता CompuServe ने ग्राफ़िक्स इंटरचेंज फ़ॉर्मेट, या GIF [HARD G] नामक एक छोटी सी चीज़ जारी की।

यह CompuServe के एक इंजीनियर स्वर्गीय स्टीव विल्हाइट द्वारा विकसित किया गया था (जो, वैसे, इसे ऊपर और नीचे "जिफ" कहा गया था) सीमित बैंडविड्थ और प्रारंभिक कंप्यूटर नेटवर्क की भंडारण क्षमताओं पर रंगीन छवियों का समर्थन करने के साधन के रूप में विकसित किया गया था।

प्रारंभिक संस्करण, GIF 87a, अधिकतम 256 रंगों का समर्थन करता है; सरल एनिमेशन प्रदर्शित करने की क्षमता और विभिन्न कंप्यूटर सिस्टम में इसके व्यापक समर्थन के कारण इसने तेजी से लोकप्रियता हासिल की।

धन्यवाद, मिस्टर विल्हाइट।

बत्तख।  और इसने हमें क्या छोड़ा है, डगलस?

वेब एनिमेशन, और इस बात पर विवाद कि क्या शब्द का उच्चारण "ग्राफिक्स" [हार्ड जी] या "जिराफिक्स" [सॉफ्ट जी] है।

डौग  बिल्कुल। [हंसते हैं]

बत्तख।  मैं इसे "giff" [हार्ड जी] नहीं कह सकता।

डौग  वही!

चलिए उस पर मुहर लगाते हैं, और अपनी रोमांचक कहानी की ओर बढ़ते हैं...

…क्वीन एलिजाबेथ I, स्कॉट्स की मैरी क्वीन और एक आदमी के बारे में दोनों तरफ खेल रहा है रैनसमवेयर बदमाश और उसके नियोक्ता पॉल के बीच।

रैंसमवेयर की दास्तां: द मिटएम अटैक जिसमें वास्तव में बीच में एक आदमी था

बत्तख।  [हंसते हैं] चलिए कहानी के अंत से शुरू करते हैं।

मूल रूप से, यह इंग्लैंड में ऑक्सफ़ोर्डशायर की एक प्रौद्योगिकी कंपनी के खिलाफ रैनसमवेयर हमला था।

(यह वाली नहीं... यह ऑक्सफोर्ड की एक कंपनी थी, एबिंगडन-ऑन-टेम्स से नदी के 15 किमी ऊपर, जहां सोफोस स्थित है।)

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

और, उस कहानी की तरह हमारे पास एक था कुछ हफ़्ते पहले, उनकी अपनी रक्षात्मक टीम में से एक, जिसे इससे निपटने में मदद करनी थी, ने सोचा, "मैं एक एमआईटीएम चलाने जा रहा हूं", एक मैन-इन-द-मिडिल हमला।

मुझे पता है कि, लैंगिक भाषा से बचने के लिए और इस तथ्य को प्रतिबिंबित करने के लिए कि यह हमेशा एक व्यक्ति नहीं होता है (यह अक्सर बीच में एक कंप्यूटर होता है) ...

... नग्न सुरक्षा पर, अब मैं "मैनिपुलेटर-इन-द-मिडिल" लिखता हूं।

लेकिन यह सचमुच बीच का आदमी था।

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

उसने धागे को हाईजैक कर लिया, और ऐतिहासिक ईमेल ट्रेस में बिटकॉइन पता बदल दिया, क्योंकि उसके पास वरिष्ठ अधिकारियों के ईमेल खातों तक पहुंच थी ...

... और वह मूल रूप से एक बीच के आदमी के रूप में बातचीत करना शुरू कर दिया।

तो, आप कल्पना करते हैं कि वह अब बदमाश के साथ व्यक्तिगत रूप से बातचीत कर रहा है, और फिर वह उस बातचीत को अपने नियोक्ता को सौंप रहा है।

हम नहीं जानते कि क्या वह पूरे इनाम के साथ भाग जाने की उम्मीद कर रहा था और फिर बस अपने नियोक्ता से कहता है, "अरे, अनुमान लगाओ, बदमाशों ने हमें धोखा दिया", या क्या वह अपने अंत में बदमाशों से बातचीत करना चाहता था, और दूसरे छोर पर उसका नियोक्ता।

क्योंकि वह कंपनी के अंदर भय और आतंक को बढ़ाने के लिए सही/गलत बातें बोलना जानता था।

इसलिए, उनका लक्ष्य मूल रूप से रैंसमवेयर भुगतान को हाईजैक करना था।

खैर, डौग, यह सब थोड़ा नाशपाती के आकार का हो गया क्योंकि, दुर्भाग्य से उसके लिए और सौभाग्य से उसके नियोक्ता और कानून प्रवर्तन के लिए, कंपनी ने भुगतान नहीं करने का फैसला किया।

डौग  [हंसते हैं] हम्मम्म!

बत्तख।  इसलिए उसके पास चोरी करने और फिर कट-एंड-रन करने के लिए कोई बिटकॉइन नहीं था।

इसके अलावा, ऐसा लगता है कि उसने अपने निशानों को बहुत अच्छी तरह से नहीं छुपाया, और ईमेल लॉग्स तक उसकी गैरकानूनी पहुंच तब धुल गई।

वह स्पष्ट रूप से जानता था कि पुलिस उसके पीछे पड़ रही थी, क्योंकि उसने घर पर अपने कंप्यूटर और फोन से दुष्ट डेटा मिटाने की कोशिश की थी।

लेकिन उन्हें जब्त कर लिया गया और डेटा बरामद कर लिया गया।

किसी तरह मामला पांच साल तक खिंचता रहा, और अंत में, जैसे ही वह परीक्षण के लिए जाने वाला था, उसने स्पष्ट रूप से फैसला किया कि उसके पास खड़े होने के लिए वास्तव में एक पैर नहीं था और उसने दोषी होने का अनुरोध किया।

तो, यह लो, डौग।

एक शाब्दिक मैन-इन-द-बीच हमला!

डौग  ठीक है, तो यह सब ठीक है और 2023 में अच्छा है …

…लेकिन हमें ले लो 1580 के दशक में वापस, पॉल.

मैरी, स्कॉट्स की रानी और महारानी एलिजाबेथ प्रथम के बारे में क्या?

बत्तख।  ठीक है, ईमानदार होने के लिए, मैंने सोचा कि उन सभी वर्षों में वापस जाकर एक आदमी के मध्य हमले को समझाने का यह एक शानदार तरीका था।

क्योंकि, प्रसिद्ध रूप से, महारानी एलिजाबेथ और उनकी चचेरी बहन मैरी, स्कॉट्स की रानी धार्मिक और राजनीतिक दुश्मन थीं।

एलिजाबेथ इंग्लैंड की रानी थी; मैरी सिंहासन की दावेदार थी।

इसलिए, मैरी को प्रभावी रूप से हाउस अरेस्ट के तहत हिरासत में लिया गया था।

मैरी कुछ विलासिता में रह रही थी, लेकिन एक महल तक ही सीमित थी, और वास्तव में अपने चचेरे भाई के खिलाफ साजिश रच रही थी, लेकिन वे इसे साबित नहीं कर सके।

और मैरी महल में पहुंचाए जाने वाले बीयर बैरल के पुंजों में भरकर संदेश भेज रही थी और प्राप्त कर रही थी।

जाहिरा तौर पर, इस मामले में, बीच का आदमी एक आज्ञाकारी बीयर आपूर्तिकर्ता था जो मैरी के मिलने से पहले संदेशों को हटा देगा, ताकि उन्हें कॉपी किया जा सके।

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

इसलिए उसने न केवल अन्य षड्यंत्रकारियों के नाम बताए, बल्कि यह भी संकेत दिया कि उसने महारानी एलिजाबेथ की हत्या की साजिश को मंजूरी दी है।

वे तब कठिन समय थे ... और इंग्लैंड में निश्चित रूप से उन दिनों मृत्युदंड था, और मैरी पर मुकदमा चलाया गया और उन्हें मार दिया गया।

इतिहास से शीर्ष 10 टूटे हुए सिफरटेक्स्ट

डौग  ठीक है, इसलिए सुनने वाले किसी भी व्यक्ति के लिए, इस पॉडकास्ट के लिए एलीवेटर पिच है, "साइबर सुरक्षा समाचार और सलाह, और इतिहास का थोड़ा छिड़काव"।

वर्तमान दिन में हमारे बीच-बीच में वापस।

हमने इस बारे में बात की एक और अंदरूनी खतरा अभी कुछ समय पहले ऐसा ही हुआ है।

तो यह देखना दिलचस्प होगा कि क्या यह एक पैटर्न है, या यह सिर्फ एक संयोग है।

लेकिन हमने कुछ ऐसी चीजों के बारे में बात की है जो आप इस प्रकार के हमलों से खुद को बचाने के लिए कर सकते हैं, तो आइए जल्दी से उन पर दोबारा गौर करें।

के साथ शुरू: विभाजन और जीत, जिसका मूल रूप से अर्थ है, "कंपनी में एक व्यक्ति को हर चीज तक असीमित पहुंच न दें," पॉल।

बत्तख।  हां.

डौग  और फिर हमारे पास है: अपरिवर्तनीय लॉग रखें, जो ऐसा लग रहा था कि इस मामले में हुआ है, है ना?

बत्तख।  हां.

ऐसा लगता है कि इस मामले में साक्ष्य का एक प्रमुख तत्व यह तथ्य था कि वह वरिष्ठ अधिकारियों के ईमेल में खुदाई कर रहा था और उन्हें बदल रहा था, और वह उसे छिपाने में असमर्थ था।

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

डौग  ठीक है, अंत में: हमेशा मापें, कभी न मानें।

बत्तख।  वास्तव में!

डौग  अंतत: अच्छे लोगों की जीत हुई... पांच साल लग गए, लेकिन हमने कर दिखाया।

चलिए अपनी अगली कहानी की ओर बढ़ते हैं।

वेब सुरक्षा कंपनी को ऐप-बिल्डिंग टूलकिट में लॉगिन बग का पता चलता है।

बग को जल्दी और पारदर्शी तरीके से ठीक किया गया है, तो यह अच्छा है... लेकिन कुछ है कहानी के लिए और अधिकबेशक, पॉल।

गंभीर सुरक्षा: सत्यापन महत्वपूर्ण है - OAUTH लॉगिन बग की जाँच करना

बत्तख।  हां.

यह एक वेब कोडिंग सुरक्षा विश्लेषण कंपनी है (मुझे उम्मीद है कि मैंने वहां सही शब्दावली चुनी है) जिसे SALT कहा जाता है, और उन्हें एक्सपो नामक ऐप-बिल्डिंग टूलकिट में प्रमाणीकरण भेद्यता मिली।

और, उनके दिल को आशीर्वाद दें, एक्सपो OAUTH नामक चीज़ का समर्थन करें प्राधिकरण खोलें प्रणाली।

यह उस प्रकार की प्रणाली है जिसका उपयोग तब किया जाता है जब आप किसी वेबसाइट पर जाते हैं जिसने निर्णय लिया है, "आप जानते हैं कि, हम अपने लिए पासवर्ड सुरक्षा कैसे करें सीखने की कोशिश करने की परेशानी नहीं चाहते हैं। हम क्या करने जा रहे हैं, हम कहने जा रहे हैं, 'Google से लॉगिन करें, Facebook से लॉगिन करें'," ऐसा ही कुछ।

और विचार यह है कि, शिथिल रूप से बोलते हुए, आप फेसबुक, या Google, या जो भी मुख्यधारा की सेवा है, से संपर्क करें और आप कहें, "अरे, मैं देना चाहता हूं example.com एक्स करने की अनुमति।"

तो, फेसबुक, या Google, या जो कुछ भी, आपको प्रमाणित करता है और फिर कहता है, "ठीक है, यह एक जादुई कोड है जो आप दूसरे छोर को दे सकते हैं जो कहता है, 'हमने आपको चेक आउट कर दिया है; आपने हमारे साथ प्रमाणित किया है, और यह आपका प्रमाणीकरण टोकन है।"

फिर, दूसरा छोर स्वतंत्र रूप से फेसबुक, या Google, या जो कुछ भी यह सुनिश्चित करने के लिए जांच कर सकता है कि वह टोकन आपकी ओर से जारी किया गया था।

तो इसका मतलब यह है कि आपको कभी भी साइट को कोई पासवर्ड सौंपने की आवश्यकता नहीं है... आप चाहें तो अपने लिए वास्तविक प्रमाणीकरण भाग करने के लिए Facebook या Google का सह-चयन कर सकते हैं।

यह एक अच्छा विचार है यदि आप एक बुटीक वेबसाइट हैं और आप सोचते हैं, "मैं अपनी खुद की क्रिप्टोग्राफी बुनने वाला नहीं हूं।"

तो, यह OAUTH में बग नहीं है।

यह सिर्फ एक निरीक्षण है; कुछ ऐसा जिसे एक्सपो के OAUTH प्रक्रिया के कार्यान्वयन में भुला दिया गया था।

और, ढीले ढंग से बोलना, डौग, यह इस तरह से चलता है।

एक्सपो कोड एक विशाल यूआरएल बनाता है जिसमें फेसबुक के साथ प्रमाणीकरण के लिए आवश्यक सभी पैरामीटर शामिल होते हैं, और फिर यह तय करते हैं कि अंतिम मैजिक एक्सेस टोकन कहां भेजा जाना चाहिए।

इसलिए, सिद्धांत रूप में, यदि आपने अपना स्वयं का URL बनाया है या आप URL को संशोधित करने में सक्षम थे, तो आप उस स्थान को बदल सकते हैं जहाँ यह मैजिक ऑथेंटिकेशन टोकन अंततः भेजा गया था।

लेकिन आप उपयोगकर्ता को धोखा देने में सक्षम नहीं होंगे, क्योंकि एक संवाद प्रकट होता है जो कहता है, "एप्लिकेशन पर URL-here आपसे आपके Facebook खाते में साइन इन करने के लिए कह रहा है. क्या आप इस पर पूरा भरोसा करते हैं और इसे ऐसा करने देना चाहते हैं? हां या नहीं?"

हालाँकि, जब फेसबुक, या Google, या जो भी हो, से प्राधिकरण कोड प्राप्त करने और इसे "वापसी URL" पर पास करने की बात आई, तो एक्सपो कोड यह जाँच नहीं करेगा कि आपने वास्तव में क्लिक किया था Yes अनुमोदन संवाद पर।

यदि आपने सक्रिय रूप से संवाद देखा और क्लिक किया No, तो आप हमले को होने से रोकेंगे।

लेकिन, अनिवार्य रूप से, यह "विफल खुला"।

यदि आपने कभी संवाद नहीं देखा, तो आपको यह भी पता नहीं चलेगा कि क्लिक करने के लिए कुछ था और आपने कुछ भी नहीं किया, और फिर हमलावरों ने अगली यूआरएल विज़िट को और अधिक जावास्क्रिप्ट के साथ स्वयं ही ट्रिगर किया ...

…तो सिस्टम काम करेगा।

और इसके काम करने का कारण यह है कि मैजिक "रिटर्न URL", वह स्थान जहां सुपर-सीक्रेट ऑथराइजेशन कोड भेजा जाना था, एक्सपो के लिए एक वेब कुकी में सेट किया गया था ताकि बाद में आपके द्वारा क्लिक करने से पहले इसका उपयोग किया जा सके। Yes डायलॉग पर*.

बाद में, उस "वापसी यूआरएल" कुकी का अस्तित्व अनिवार्य रूप से लिया गया था, यदि आप चाहें, सबूत के तौर पर आपने संवाद देखा होगा, और आपने आगे बढ़ने का फैसला किया होगा।

जबकि असल में ऐसा नहीं था.

तो यह एक बड़ी स्लिप 'ट्विक्सट कप और लिप, डगलस थी।

डौग  ठीक है, हमारे पास कुछ सुझाव हैं, जो निम्न से शुरू होते हैं: जब इस बग की रिपोर्ट करने और खुलासा करने की बात आई, तो यह पाठ्यपुस्तक का मामला था।

यह लगभग ठीक है कि आपको इसे कैसे करना चाहिए, पॉल।

सब कुछ ठीक वैसे ही काम करता है जैसे इसे करना चाहिए, इसलिए यह एक बेहतरीन उदाहरण है कि इसे सर्वोत्तम तरीके से कैसे किया जाए।

बत्तख।  और यही एक मुख्य कारण है कि मैं इसे नग्न सुरक्षा पर क्यों लिखना चाहता था।

SALT, जिन लोगों को बग मिला...

..उन्होंने इसे पाया; उन्होंने इसे जिम्मेदारी से प्रकट किया; उन्होंने एक्सपो के साथ काम किया, जिन्होंने इसे घंटों के भीतर ठीक कर दिया।

इसलिए, भले ही यह एक बग था, भले ही यह एक कोडिंग गलती थी, इसने SALT को यह कहते हुए प्रेरित किया, "आप जानते हैं कि, एक्सपो के लोगों के साथ काम करना एक परम आनंद था।"

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

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

डौग  और फिर बेशक, हमने इसके बारे में थोड़ी बात की: सुनिश्चित करें कि आपकी प्रमाणीकरण जांच विफल हो गई है.

सुनिश्चित करें कि अगर कोई इसे अनदेखा करता है या रद्द करता है तो यह केवल काम नहीं करता है।

लेकिन यहाँ बड़ा मुद्दा यह है: यह कभी न मानें कि आपका अपना क्लाइंट साइड कोड सत्यापन प्रक्रिया को नियंत्रित करेगा।

बत्तख।  यदि आपने इस OAUTH प्रक्रिया के माध्यम से आपको ले जाने के लिए एक्सपो द्वारा प्रदान किए गए जावास्क्रिप्ट कोड की सटीक प्रक्रिया का पालन किया होता, तो आप ठीक होते।

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

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

डौग  ठीक है, अंतिम लेकिन कम से कम नहीं: जब आप सक्रिय रूप से उनका उपयोग नहीं कर रहे हों तो वेब खातों से लॉग आउट करें।

यह अच्छी सलाह है।

बत्तख।  हम इसे हर समय नग्न सुरक्षा पॉडकास्ट पर कहते हैं, और हमारे पास है कई साल.

ऑनलाइन सुरक्षा के लिए 3 सरल कदम

यह अलोकप्रिय सलाह है, क्योंकि यह बल्कि असुविधाजनक है, उसी तरह जैसे लोगों को यह बताना, "अरे, बाहर निकलने पर सभी कुकीज़ को साफ़ करने के लिए अपने ब्राउज़र को क्यों सेट नहीं करना चाहिए?"

यदि आप इसके बारे में सोचते हैं, तो इस विशेष मामले में... मान लें कि लॉगिन आपके Facebook खाते के माध्यम से हो रहा था; फेसबुक के माध्यम से OAUTH।

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

तो आप हमेशा और अपरिहार्य रूप से उस बिंदु पर फेसबुक लॉगिन पॉप अप देखेंगे: "आपको अभी लॉग इन करने की आवश्यकता है।"

और वह छल को तुरंत दूर कर देगा।

डौग  ठीक है बहुत अच्छा।

और हमारी दिन की आखिरी कहानी: घबराएं नहीं, लेकिन जाहिर तौर पर ओपन-सोर्स पासवर्ड मैनेजर कीपास के लिए मास्टर पासवर्ड को क्रैक करने का एक तरीका है।

लेकिन, फिर से, घबराएं नहीं, क्योंकि यह एक बहुत अधिक जटिल जितना लगता है, पॉल।

आपको वास्तव में किसी की मशीन पर नियंत्रण रखना होगा।

गंभीर सुरक्षा: वह कीपास "मास्टर पासवर्ड क्रैक", और हम इससे क्या सीख सकते हैं

बत्तख।  तुम करो।

यदि आप इसे ट्रैक करना चाहते हैं, तो यह CVE-2023-32784 है।

यह एक आकर्षक बग है, और मैंने एक तरह का लिखा है प्रसिद्ध रचना इसके बारे में नग्न सुरक्षा पर शैली लेख, हकदार: वह कीपास 'मास्टर पासवर्ड क्रैक' और हम इससे क्या सीख सकते हैं।

इसलिए मैं उस लेख को खराब नहीं करूंगा, जो सी-टाइप मेमोरी एलोकेशन, स्क्रिप्टिंग लैंग्वेज-टाइप मेमोरी एलोकेशन, और अंत में C# या .NET मैनेज्ड स्ट्रिंग्स... सिस्टम द्वारा मैनेज्ड मेमोरी एलोकेशन में जाता है।

मैं केवल वर्णन करूंगा कि इस मामले में शोधकर्ता ने क्या खोजा।

उन्होंने क्या किया है ... वे KeePass कोड और KeePass मेमोरी डंप में देख रहे थे, इस बात के सबूत के लिए कि मास्टर पासवर्ड को मेमोरी में खोजना कितना आसान हो सकता है, भले ही अस्थायी रूप से।

क्या होगा अगर यह मिनट, घंटे या दिन बाद हो?

क्या होगा यदि मास्टर पासवर्ड अभी भी डिस्क पर आपकी स्वैप फ़ाइल में हो सकता है, भले ही आपने अपने कंप्यूटर को रीबूट कर दिया हो?

इसलिए मैंने कीपास की स्थापना की, और मैंने खुद को एक 16-वर्ण, पूर्ण-अपरकेस पासवर्ड दिया ताकि अगर मुझे यह स्मृति में मिले तो इसे पहचानना आसान हो।

और, देखो और निहारना, किसी भी बिंदु पर मुझे कभी भी अपना मास्टर पासवर्ड स्मृति में पड़ा हुआ नहीं मिला: ASCII स्ट्रिंग के रूप में नहीं; Windows वाइडचर (UTF-16)) स्ट्रिंग के रूप में नहीं।

महान!

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

इसलिए, जब आप अपने पासवर्ड में टाइप करते हैं, तो आप स्ट्रिंग ब्लॉब [●], ब्लॉब-ब्लॉब [●●], ब्लॉब-ब्लॉब-ब्लॉब [●●●] देखते हैं, और मेरे मामले में, 16 ब्लब्स तक सब कुछ दिखाई देता है।

ठीक है, उन बूँद तारों को ऐसा नहीं लगता कि वे एक सुरक्षा जोखिम होंगे, इसलिए हो सकता है कि उन्हें "प्रबंधित स्ट्रिंग्स" के रूप में प्रबंधित करने के लिए .NET रनटाइम पर छोड़ दिया जा रहा हो, जहां वे बाद में मेमोरी में पड़े रह सकते हैं ...

…और सफाई न कराएं क्योंकि, "अरे, वे तो बस बूँदें हैं।"

यह पता चला है कि यदि आप KeePass का मेमोरी डंप करते हैं, जो आपको 250MB का सामान देता है, और आप ब्लॉब-ब्लॉब, ब्लॉब-ब्लॉब-ब्लॉब, और इसी तरह (किसी भी संख्या में ब्लॉब्स) की तलाश में जाते हैं, तो वहाँ है मेमोरी डंप का एक हिस्सा जहां आप दो बूँद देखेंगे, फिर तीन बूँद, फिर चार बूँद, फिर पाँच बूँद ... और मेरे मामले में, सभी तरह से 16 बूँदें।

और फिर यदि आप चाहें तो आपको "गलती से होने वाले बूँद पात्रों" का यह यादृच्छिक संग्रह मिल जाएगा।

दूसरे शब्दों में, केवल उन ब्लॉब स्ट्रिंग्स की तलाश करना, भले ही वे आपका वास्तविक पासवर्ड न दें, आपके पासवर्ड की लंबाई को लीक कर देगा।

हालाँकि, यह और भी दिलचस्प हो जाता है, क्योंकि इस शोधकर्ता ने जो सोचा वह यह है, "क्या होगा यदि मेमोरी में उन ब्लॉब स्ट्रिंग्स के पास का डेटा किसी तरह से आपके द्वारा पासवर्ड में टाइप किए गए अलग-अलग वर्णों से बंधा हो?"

तो, क्या होगा यदि आप मेमोरी डंप फ़ाइल के माध्यम से जाते हैं, और केवल दो ब्लॉब्स, तीन ब्लॉब्स/चार ब्लॉब्स, और अधिक खोजने के बजाय ...

…आप ब्लब्स की एक स्ट्रिंग की खोज करते हैं जिसके बाद एक वर्ण होता है जो आपको लगता है कि पासवर्ड में है?

इसलिए, मेरे मामले में, मैं सिर्फ अक्षर A से Z तक खोज रहा था, क्योंकि मुझे पता था कि पासवर्ड में यही है।

मैं ब्लब्स की किसी भी स्ट्रिंग की खोज कर रहा हूं, उसके बाद एक एएससीआईआई चरित्र।

लगता है क्या हुआ, डौग?

मुझे अपने पासवर्ड के तीसरे अक्षर के बाद दो ब्लब्स मिलते हैं; मेरे पासवर्ड के चौथे अक्षर के बाद तीन बूँदें; मेरे पासवर्ड में 15वें वर्ण के तुरंत बाद 16 ब्लब्स तक।

डौग  हाँ, इस लेख में यह एक जंगली दृश्य है!

मैं साथ चल रहा था ... यह थोड़ा तकनीकी हो रहा था, और अचानक मैं देखता हूं, "वाह! यह एक पासवर्ड जैसा दिखता है!

बत्तख।  यह मूल रूप से ऐसा है जैसे कि आपके पासवर्ड के अलग-अलग अक्षर स्मृति के माध्यम से उदारतापूर्वक बिखरे हुए हैं, लेकिन वे जो ASCII वर्णों का प्रतिनिधित्व करते हैं जो वास्तव में आपके पासवर्ड का हिस्सा थे जैसे आपने इसे टाइप किया था ...

...ऐसा लगता है कि उनके साथ ल्यूमिनसेंट डाई जुड़ी हुई है।

तो, ब्लब्स के ये तार अनजाने में आपके पासवर्ड में वर्णों को फ़्लैग करने के लिए एक टैगिंग तंत्र के रूप में कार्य करते हैं।

और, वास्तव में, कहानी का नैतिक यह है कि चीजें स्मृति में उन तरीकों से लीक हो सकती हैं जिनकी आपने कभी उम्मीद नहीं की थी, और यहां तक ​​​​कि एक अच्छी तरह से सूचित कोड समीक्षक भी ध्यान नहीं दे सकता।

तो यह एक आकर्षक पठन है, और यह एक महान अनुस्मारक है कि सुरक्षित कोड लिखना आपके विचार से कहीं अधिक कठिन हो सकता है।

और इससे भी महत्वपूर्ण बात, समीक्षा करना, और गुणवत्ता-सुनिश्चित करना, और सुरक्षित कोड का परीक्षण करना अभी भी कठिन हो सकता है ...

... क्योंकि आपको अपने सिर के आगे, पीछे, और किनारों पर आँखें रखनी होंगी, और आपको वास्तव में एक हमलावर की तरह सोचना होगा और हर जगह आप कर सकते हैं लीक से हटकर रहस्यों की तलाश करने की कोशिश करनी होगी।

डौग  ठीक है, इसे बाहर की जाँच, यह makedsecurity.sophos.com पर है।

और, जैसे ही सूरज हमारे शो पर सेट होना शुरू होता है, यह हमारे पाठकों में से एक को सुनने का समय है।

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

वहाँ। मैं इसे पूरा कर दिया है। लगभग दो वर्षों के द्वि घातुमान सुनने के बाद, मैंने नग्न सुरक्षा पॉडकास्ट के सभी एपिसोड सुनना समाप्त कर दिया। मैं सब फंस गया हूँ।

मैंने शुरुआत से ही इसका आनंद लिया, लंबे समय तक चलने वाले चेट चैट के साथ; फिर ब्रिटेन के चालक दल के लिए; "ओह तेरी! इट्स किम” अगला था; फिर मैं अंत में आज के "तकनीकी इतिहास में इस सप्ताह" पर पहुंच गया।

कमाल की राइड!

धन्यवाद, चांग!

मैं विश्वास नहीं कर सकता कि आपने सभी एपिसोड बिंज किए हैं, लेकिन हम सभी करते हैं (मुझे आशा है कि मैं बारी से बाहर नहीं बोल रहा हूं) इसकी बहुत सराहना करते हैं।

बत्तख।  वास्तव में, डौग!

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

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

डौग  ठीक ठीक!

खैर, एक बार फिर बहुत बहुत धन्यवाद, चांग, ​​इसे भेजने के लिए।

हम वास्तव में इसकी बहुत सराहना करते हैं।

और अगर आपके पास कोई दिलचस्प कहानी, टिप्पणी या सवाल है जिसे आप सबमिट करना चाहते हैं, तो हम इसे पॉडकास्ट पर पढ़ना पसंद करते हैं।

आप tips@sophos.com पर ईमेल कर सकते हैं, आप हमारे किसी भी लेख पर टिप्पणी कर सकते हैं, या आप हमें सामाजिक: @nakedsecurity पर संपर्क कर सकते हैं।

आज के लिए यही हमारा शो है; सुनने के लिए बहुत बहुत धन्यवाद।

पॉल डकलिन के लिए, मैं डौग आमोथ हूं, अगली बार तक, आपको याद दिला रहा हूं ...

दोनों को।  सुरक्षित रहें!

[संगीत मोडेम]