GhostMarket.net 2009: डेटा उजागर होने का दावा

तारीख केवल वर्ष की सटीकता के साथ संग्रहीत है। डेटाबेस में दर्ज 1 जनवरी 2009 केवल वर्ष 2009 का तकनीकी निरूपण है; इससे यह दावा नहीं किया जाता कि घटना 1 जनवरी को हुई थी। आंतरिक मेटाडेटा में 2009 को “डेटा उल्लंघन की तारीख” कहा गया है, जबकि SQL एक्सपोर्ट के हेडर में उसे बनाए जाने का समय जुलाई 2009 है। डेटाबेस डंप बनाए जाने का समय यह बता सकता है कि एक्सपोर्ट कब तैयार हुआ, लेकिन उससे स्वतंत्र रूप से डेटा उजागर होने की तारीख स्थापित नहीं होती। सार्वजनिक मेटाडेटा में 2009 के उल्लेख इकाई के संचालन की अवधि की पुष्टि करते हैं, पर निजी डेटा उजागर होने की घटना को किसी विशिष्ट दिन से नहीं जोड़ते। इन्हीं कारणों से breachDatePrecision का मान year है, सटीक दिन अज्ञात है और 1 जनवरी के निरूपण की सीमा स्पष्ट की गई है। भविष्य में कोई प्राथमिक स्रोत मिलने पर तारीख की अलग से समीक्षा करना उचित हो सकता है।

स्रोत एक पूर्ण 37,28,860-बाइट का 7z आर्काइव है। इसकी SHA-256 पहचान सीलबंद रखी गई है और यह पूर्ण 7z अखंडता परीक्षण में सफल रहा। सभी चार सामान्य सदस्य फ़ाइलें निकाली गईं और प्रत्येक की पहचान को उसके आकार तथा SHA-256 से स्वतंत्र रूप से जोड़ा गया। इनमें एक सामान्य Breached_Info मेटाडेटा फ़ाइल, GhostMarket के संदर्भ और नमूनों वाली एक Info मेटाडेटा फ़ाइल, phpBB users टेबल का CSV निरूपण और आठ phpBB टेबल वाला एक MySQL डंप शामिल हैं। इसके भीतर कोई अन्य आर्काइव नहीं मिला और स्रोत के पेलोड में कोई बदलाव नहीं किया गया। व्याख्यात्मक फ़ाइलों को बड़ी मात्रा में खाता डेटा मानने के बजाय उनका आकलन PII-मुक्त गणनाओं और संरचनात्मक लेबलों के आधार पर किया गया। यह अंतर किसी सदस्य फ़ाइल के पढ़े जा सकने को उसमें मिले हर टोकन को इंपोर्ट करने के प्रामाणिक आधार के रूप में गलत ढंग से प्रस्तुत किए जाने से रोकता है।

ई-मेल मैपिंग केवल स्कीमा में स्पष्ट रूप से दिए गए प्रामाणिक आधार पर निर्भर करती है। MySQL DDL सीधे phpbb_users.user_email और phpbb_banlist.ban_email को ई-मेल फ़ील्ड के रूप में पहचानता है। नाम में “email” वाले अन्य कॉलम, जिनमें user_email_hash, user_emailtime, user_allow_viewemail और user_allow_massemail शामिल हैं, हैश, टाइमस्टैम्प या वरीयता फ़्लैग दर्शाते हैं और उन्हें ई-मेल पतों के रूप में इंपोर्ट नहीं किया जाता। अन्य जगहों पर उपयोगकर्ता नामों, संदेशों के विषयों, पोस्ट, इंस्टेंट मैसेजिंग पहचानकर्ताओं और कॉन्फ़िगरेशन मानों में बानवे ऐसे मान हैं जो पूरे फ़ील्ड के स्तर पर कैनॉनिकल ई-मेल पतों जैसे दिखते हैं। लेकिन ये फ़ील्ड खाते के ई-मेल पते नहीं दर्शाते, इसलिए उन्हें बाहर रखा गया है। मैपिंग चुनने के लिए कैटलॉग की संख्या से मिलान करने, लक्ष्य संख्या के अनुरूप समायोजन करने या बिना रोक-टोक कच्चे टोकन जुटाने का कोई तरीका इस्तेमाल नहीं किया गया। केवल DDL में घोषित ई-मेल फ़ील्ड स्वीकार किए गए।

कम्पाइल किए गए दो स्वतंत्र रीडरों ने 505 INSERT स्टेटमेंट में मौजूद सभी 34,014 SQL पंक्तियों को बिना किसी संरचनात्मक त्रुटि के पार्स किया। दोनों से 3,281 वैध ई-मेल प्रविष्टियों का वही क्रम, वही 71,823 बाइट और वही SHA-256 पहचान प्राप्त हुई। पंक्ति की चौड़ाई में बेमेल, बिना समापन वाले स्टेटमेंट, स्कैनर विफलताओं और पार्सर त्रुटियों की संख्या शून्य रही। दोहराई गई प्रविष्टियाँ हटाने और सख्त ASCII ई-मेल सत्यापन लागू करने के बाद, क्रमबद्ध रूप में 3,271 अद्वितीय कैनॉनिकल पते बचे। phpBB users CSV के स्पष्ट user_email कॉलम से स्वतंत्र रूप से 3,280 प्रविष्टियाँ और ठीक वही 3,271 पतों का कैनॉनिकल समूह प्राप्त हुआ। CSV और SQL की कैनॉनिकल फ़ाइलें बाइट-दर-बाइट समान हैं। CSV को दोबारा इंपोर्ट नहीं किया जाता; उसे समान डेटा के समतुल्य निरूपण के साक्ष्य के रूप में रखा जाता है, ताकि केवल एक ही टेबल के दो स्रोत प्रारूपों में मौजूद होने के कारण किसी खाते को दो बार दर्ज न किया जाए।

Info मेटाडेटा सदस्य फ़ाइल में ई-मेल जैसे दिखने वाले दो कच्चे टोकन हैं। उनमें से केवल एक स्पष्ट खाता ई-मेल समूह में शामिल है। दूसरा मेटाडेटा या नमूना पाठ में दिखाई देता है और उसे किसी प्रामाणिक खाता ई-मेल फ़ील्ड से नहीं जोड़ा जा सकता। इसलिए Info सदस्य फ़ाइल को ई-मेल स्रोत के रूप में नहीं चुना गया है और इसके लिए NON_AUTHORITATIVE_METADATA_SAMPLE के रूप में शेष दायित्व दर्ज किया गया है। सामान्य Breached_Info सदस्य फ़ाइल में न तो कोई ई-मेल फ़ील्ड है, न ही कोई ऐट चिह्न। CSV निरूपण को DUPLICATE_REPRESENTATION_SET_EQUAL के रूप में जोड़ा गया है। मैपिंग कवरेज जानबूझकर PARTIAL रखा गया है, क्योंकि इन वर्गीकरणों से यह दावा नहीं होता कि आर्काइव का हर पाठ या पूरी ऐतिहासिक घटना का विवरण पूर्ण है। फिर भी, स्वीकार किए गए पतों को स्पष्ट DDL और स्वतंत्र रूप से प्राप्त कैनॉनिकल समूहों की समानता का पूरा समर्थन प्राप्त है।

स्रोत में उपयोगकर्ता नाम, IP पते, पासवर्ड हैश, फ़ोरम पोस्ट और निजी संदेशों की टेबल शामिल हैं, इसलिए रिकॉर्ड के दायरे का संदर्भ देने के लिए इन श्रेणियों को सूचीबद्ध किया गया है। LeakData की यह प्रक्रिया केवल ई-मेल पते इंपोर्ट करती है। यह जॉब पासवर्ड, IP पते, उपयोगकर्ता नाम, पोस्ट की सामग्री और निजी संदेशों की सामग्री को Mongo संबंधों में नहीं लिखती। totalRecords में स्रोत की 3,331 खाता पंक्तियों की संख्या दर्ज है। canonicalEmailCount और affectedCountLowerBound का मान 3,271 है, लेकिन यह अलग-अलग व्यक्तियों की संख्या नहीं है। एक व्यक्ति कई पते नियंत्रित कर सकता है और कोई पता साझा या निष्क्रिय हो सकता है। प्रभावित व्यक्तियों की सटीक संख्या अज्ञात है, इसलिए pwnCount का मान null है। 3,271 का आँकड़ा केवल स्पष्ट ई-मेल फ़ील्ड में सत्यापित अद्वितीय कैनॉनिकल पतों की न्यूनतम सीमा है।

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