GhostMarket.net 2009 Veri Kümesi İddiası
Bu kayıt, GhostMarket.net alan adıyla ilişkilendirilen ve 2009 yılına atfedilen bir forum veri kümesini temkinli biçimde açıklar.
Bu sınıflandırma doğrulanmış alt sınıra dayanır; gerçek etki ve önem seviyesi daha yüksek olabilir.
Sızan Veri Türleri
6- E-posta Adresleri
- Kullanıcı Adları
- IP Adresleri
- Parolalar
- Forum Gönderileri
- Özel Mesajlar
Bu Kayıt Hakkında
İncelenen arşivin iç metadata dosyası kuruluş adını GhostMarket ve GhostMarket.net biçimlerinde tekrarlar, kaynak kapsamını 3.331 hesap kaydı olarak bildirir ve olay yılı alanında yalnız 2009 değerini verir. Kamuya açık Guardian arşiv metadata kontrolü de GhostMarket adıyla ilişkilendirilen çevrim içi suç forumunun 2009 dönemindeki faaliyet bağlamını destekler. Bununla birlikte kamu kaynağı bu özel arşivin tam olarak hangi gün elde edildiğini, GhostMarket.net işletmecisinin bu veri kümesini doğruladığını veya arşivdeki her kaydın aynı olaydan geldiğini kanıtlamaz. Bu nedenle kayıt doğrulanmış bir birincil ihlal duyurusu olarak sunulmaz. isVerified false tutulur; açıklamalar, arşiv kanıtı ile kamu bağlamının sınırlarını özellikle ayırır.
Tarih alanı yıl hassasiyetindedir. Veritabanında kullanılan 1 Ocak 2009 değeri yalnızca 2009 yılını teknik olarak temsil eder; olayın 1 Ocak günü gerçekleştiği iddia edilmez. İç metadata “date of breach” etiketinde 2009 yazar, SQL dışa aktarım başlığı ise Temmuz 2009 üretim zamanı taşır. SQL üretim zamanı bir veritabanı dökümünün hazırlanma zamanını gösterebilir ve tek başına olay günü sayılmaz. Kamu kaynağındaki 2009 bağlamı kuruluş kimliğini destekler, fakat özel veri açığa çıkmasının tarihini gün düzeyinde sabitlemez. Bu ayrım nedeniyle breachDatePrecision year olarak kaydedilir, exact gün null kabul edilir ve açıklamada 1 Ocak değerinin teknik gösterim olduğu açıkça belirtilir. Daha kesin bir birincil kaynak bulunursa tarih daha sonra ayrı bir incelemeyle güncellenebilir.
Kaynak, 3.728.860 baytlık eksiksiz bir 7z arşividir. Arşiv SHA-256 kimliği mühürlenmiş, tam 7z bütünlük testi başarıyla geçmiştir. Dört düzenli üyenin tamamı açılmış, boyutları ve SHA-256 değerleri ayrı ayrı doğrulanmıştır. Üyeler genel bir Breached_Info metadata dosyası, GhostMarket hakkında açıklama ve örnekler içeren Info metadata dosyası, phpBB kullanıcı tablosunun CSV temsili ve sekiz phpBB tablosunu içeren MySQL SQL dökümüdür. İç içe arşiv bulunmamıştır. Kaynak payload değiştirilmemiştir. Açıklama dosyaları kullanıcı verisi olarak topluca taranmamış; içerikler PII göstermeyen sayaçlar ve alan yapısı üzerinden değerlendirilmiştir. Böylece arşivin okunabilir olması ile her metin parçasının e-posta import yetkisi vermesi birbirine karıştırılmamıştır.
E-posta eşlemesi yalnız açık şema otoritesine dayanır. MySQL DDL içinde phpbb_users.user_email ve phpbb_banlist.ban_email alanları doğrudan e-posta semantiği taşır. Diğer adlarında “email” geçen user_email_hash, user_emailtime, user_allow_viewemail ve user_allow_massemail sütunları hash, zaman veya tercih göstergeleridir; e-posta adresi olarak içeri alınmaz. Kullanıcı adı, mesaj konusu, forum gönderisi, anlık mesajlaşma tanımlayıcısı ve yapılandırma değeri gibi e-posta biçimine benzeyebilen toplam 92 açık alan dışı değer de seçilmemiştir. Katalog sayısına uydurma, rastgele token toplama veya kayıt sayısını hedefleyerek alan seçme uygulanmamıştır. Yalnız açık DDL e-posta alanları kabul edilmiştir.
İki bağımsız derlenmiş okuyucu SQL kaynağının 34.014 satır kaydını ve 505 INSERT ifadesini hatasız ayrıştırmıştır. Her iki okuyucu 3.281 geçerli e-posta occurrence dizisi, 71.823 bayt ve aynı SHA-256 kimliğini üretmiştir. Satır genişliği uyuşmazlığı, yarım ifade, tarayıcı hatası ve ayrıştırma hatası sıfırdır. Yinelenen occurrence değerleri kaldırılıp katı ASCII e-posta doğrulaması uygulandığında 3.271 sıralı benzersiz kanonik adres kalır. phpBB kullanıcı CSV dosyasındaki açık user_email alanı da bağımsız olarak 3.280 occurrence ve aynı 3.271 adreslik kanonik seti üretir. CSV ve SQL setleri byte düzeyinde eşittir. Bu ikinci temsil tekrar import edilmez; yalnız eşitlik kanıtı olarak tutulur ve böylece aynı hesabın iki dosya yüzünden iki kez yazılması önlenir.
Info metadata dosyasında iki ham e-posta benzeri token görülmüştür. Bunlardan yalnız biri açık hesap e-posta setinde vardır; diğeri metadata veya örnek metni içindedir ve hesap tablosundaki yetkili e-posta alanıyla bağlanamaz. Bu nedenle Info dosyası bir e-posta kaynağı olarak seçilmez ve açık bir NON_AUTHORITATIVE_METADATA_SAMPLE borcuyla kayıt altına alınır. Genel Breached_Info dosyasında e-posta alanı veya at işareti yoktur. SQL dışındaki CSV temsili ise DUPLICATE_REPRESENTATION_SET_EQUAL olarak bağlanır. Mapping kapsamı bu sebeple bilinçli olarak PARTIAL kalır; sistem bütün arşivdeki her metnin veya bütün olayın eksiksiz temsil edildiğini ileri sürmez. Buna rağmen içeri alınacak adreslerin tamamı açık DDL alanları ve bağımsız kanonik eşitlik tarafından doğrulanır.
Kaynakta kullanıcı adları, IP adresleri, parola hashleri, forum gönderileri ve özel mesaj tabloları bulunduğu için bu sınıflar kayıt açıklamasında kapsam bilgisi olarak gösterilir. LeakData import hattı bu çalışmada yalnız e-posta adreslerini işler; parola, IP, kullanıcı adı, gönderi veya mesaj verisi Mongo ilişkilerine yazılmaz. totalRecords 3.331 kaynak hesap satırını belirtir. canonicalEmailCount ve affectedCountLowerBound 3.271 olarak saklanır, fakat bu sayı benzersiz kişi sayısı değildir. Bir kişinin birden fazla adresi olabilir veya bazı adresler paylaşılmış olabilir. Bu nedenle kesin etkilenen kişi sayısı bilinmiyor durumundadır ve pwnCount null bırakılır. 3.271 sayısı yalnız açık e-posta alanlarında doğrulanan benzersiz kanonik adres alt sınırıdır.
Kullanıcılar bu kaydı okurken üç ayrımı gözetmelidir. Birincisi, GhostMarket adı ve 2009 bağlamı kamu metadata ile desteklenirken bu özel veri kümesinin birincil olay doğrulaması mevcut değildir. İkincisi, arşiv bütünlüğünün geçmesi içerikteki her iddianın doğrulandığı anlamına gelmez. Üçüncüsü, e-posta adresinin kanonik sette bulunması o kişinin bütün diğer arşiv alanlarıyla kesin olarak ilişkilendirildiğini veya kişinin hesabı aktif kullandığını kanıtlamaz. Kayıt hassas olarak işaretlenir, doğrulanmamış statüsü korunur ve yalnız e-posta alanı fail-closed kurallarla işlenir. Sonraki kanıtlar tarih, kapsam veya kuruluş kimliği hakkında daha güçlü otorite sağlarsa metadata ayrı bir incelemeyle güncellenmelidir.
Doğrulama ve editoryal yöntem
LeakData; olay adı, tarih, etkilenen kayıt sayısı ve veri türlerini erişilebilir kaynaklarla karşılaştırır. Doğrulanamayan alanlar kesin bilgi olarak sunulmaz ve kayıtlar yeni kanıt bulunduğunda güncellenir.
Eksik veya hatalı bilgi bildirin