Ben bir güvenlik açığı buldum. Onlar bir avukat buldu

• Dalış eğitmeni ve platform mühendisi olan yazar, bir dalış sigortacısının üye portalında ciddi bir güvenlik açığı keşfetti
• Portal, ardışık kullanıcı kimlikleri ve aynı varsayılan parolayı kullandığı için herkes basit bir kombinasyonla başka üyelerin kişisel verilerine erişebiliyordu
• Sorun aynı anda CSIRT Malta'ya ve ilgili kuruma bildirildi, ancak kurum teşekkür etmek yerine hukuki temsilcisi aracılığıyla olası cezai sorumluluk uyarısında bulundu
• Yazar, gizlilik taahhüdü (NDA) talebini reddetti ve yalnızca verilerin silindiğini doğrulayan düzeltilmiş bir beyan önerdi, ancak kurum bu kez de iftira olasılığını gerekçe göstererek yeniden tehdit etti
• Olay, sorumlu güvenlik açığı açıklama sürecinin önemini ve hukuki tehditlerin araştırmacıların korunmasını nasıl caydırdığını ortaya koyuyor

---

Güvenlik açığının keşfi

• Kosta Rika'daki Cocos Adası'na yapılan bir dalış gezisi sırasında, bir dalış sigortacısının üye portalındaki yapısal kusur fark edildi
  • Eğitmen bir öğrenciyi kaydettiğinde sistem ardışık sayısal bir kullanıcı ID'si ve değiştirilmemiş bir varsayılan parola üretiyordu
  • Çok sayıda kullanıcı parolasını değiştirmediği için diğer üyelerin tüm kişisel verilerine (ad, adres, doğum tarihi, iletişim bilgileri vb.) erişmek mümkündü
• Parola değiştirmeyi zorlama, oturum açma sınırlaması, MFA gibi temel güvenlik önlemlerinin hiçbiri yoktu
• Bazı hesaplarda reşit olmayan kişilere (14 yaş) ait bilgiler de bulunuyordu
• Yazar, sorunu en az düzeyde erişimle doğruladıktan sonra hemen durdu ve toplanan tüm verileri kalıcı olarak sildi

Doğrulama ve kanıtlama

• Python requests ile denendi, ancak oturum yapısı karmaşık olduğundan doğrulama için Selenium ile tarayıcı otomasyonu kullanıldı
  • Yalnızca kullanıcı ID'si ve varsayılan parola girilerek oturum açılabiliyordu
  • Otomasyon betiği çalışmayan örnek kod olarak yayımlandı ve gerçek tanımlayıcıların tamamı kaldırıldı
• Çıktı örneğinde ad, e-posta, adres, doğum tarihi gibi tam profil verileri yer alıyordu
• Bu süreçte birden fazla reşit olmayan kullanıcı hesabının da aynı şekilde ifşa olduğu doğrulandı

Güvenlik açığını açıklama süreci

• 28 Nisan 2025 tarihinde güvenlik açığı resmî olarak raporlandı ve 30 günlük bir düzeltme süresi tanındı
• CSIRT Malta ve ilgili kuruma aynı anda e-postayla bildirim yapıldı
  • Raporda sorun özeti, olası GDPR ihlali, ekran görüntüleri ve şifrelenmiş bir PoC bağlantısı yer aldı
  • 7 gün içinde alındı teyidi, 30 gün içinde düzeltme talep edildi
• Bu, ulusal güvenlik açığı açıklama politikası (NCVDP) ile uyumlu standart bir prosedürdü

Kurumun tepkisi

• İki gün sonra yanıt, BT ekibinden değil veri koruma sorumlusu avukattan (DPO hukuk bürosu) geldi
  • Parolaların sıfırlanması ve 2FA'nın devreye alınmasından söz edildi, ancak önce devlet kurumuna bilgi verilmiş olması sorun edildi
  • Yazarın eylemlerinin Malta ceza kanununa göre suç teşkil edebileceği belirtilerek olası hukuki sorumluluk konusunda uyarı yapıldı
• Kurum, gizlilik beyanı imzalanmasını istedi; pasaport kopyası talep etti ve aynı gün imza için süre verdi
  • Beyanda “bu beyanın içeriğini gizli tutacağım” maddesi vardı; bu da fiilen bir NDA (gizlilik sözleşmesi) niteliğindeydi
• Sonrasında “nazik hatırlatma”, “acil bildirim” gibi tekrar eden imza talepleri geldi

Araştırmacının reddi ve itirazı

• Yazar, gizlilik maddesini imzalamayı reddetti ve bunun yerine yalnızca verilerin silindiğinin teyidini içeren düzeltilmiş bir beyan önerdi
  • CSIRT Malta'ya bildirim yapılmasının resmî sürecin bir parçası olduğu ve açıklama sonrası analizlerin güvenlik sektöründe standart uygulama sayıldığı açıkça belirtildi
• Kurum, Ceza Kanunu 337E maddesini (bilgisayarın kötüye kullanımı) alıntılayarak, yurt dışında yapılan eylemlerin de Malta içinde suç sayılabileceği uyarısında bulundu
• Ayrıca blogda veya konferanslarda kurum adının anılması hâlinde iftira ve tazminat davası açılabileceği bildirildi
• Şu anda açık giderilmiş durumda ve varsayılan parolaların sıfırlanması ile 2FA'nın devreye alınması sürüyor
• Ancak GDPR 33. ve 34. maddeler uyarınca mağdurlara bildirim yapılıp yapılmadığı doğrulanmadı

Sorumluluğu kullanıcıya yükleme ve GDPR ihlali

• Kurum, “parola değiştirmek kullanıcının sorumluluğudur” iddiasında bulundu
• Oysa GDPR 5(1)(f) ve 24(1) uyarınca uygun teknik ve idari önlemleri alma yükümlülüğü veri sorumlusuna aittir
• Aynı varsayılan parola ile ardışık ID kullanımı açık biçimde yetersiz güvenlik önlemi anlamına gelir

Tekrarlanan kalıp

• Güvenlik araştırmacıları bir açığı sorumlu biçimde açıkladığında hukuki tehditle karşılaşmasına yol açan “caydırıcı etki (Chilling Effect)” hâlâ varlığını sürdürüyor
• Hukuki karşılık vermek itibarı daha da kötüleştirir; sorun güvenlik açığının kendisi değil, kurumun buna verdiği tepki biçimidir

Doğru müdahale prosedürü

• Bildirimi almak ve düzeltmek
• Araştırmacıya teşekkür etmek
• CVD (Coordinated Vulnerability Disclosure) politikası oluşturmak
• Etkilenen kullanıcılara bildirim yapmak, özellikle reşit olmayanları korumak
• NDA ile sessizlik dayatmamak

Kurumlar ve araştırmacılar için tavsiyeler

• Kurumlar, security.txt gibi açık açıklama prosedürleri hazırlamalı ve araştırmacılara teşekkür etmelidir
• Araştırmacılar, ulusal CSIRT'nin sürece dahil edilmesi, tüm kayıtların korunması, veriler silindikten sonra gizlilik dayatmasını reddetme gibi uygulamaları benimsemelidir
• NIS2 Direktifi, AB içinde sorumlu güvenlik açığı açıklamasını teşvik eder
• 2026'da bile, basit bir güvenlik açığı bildiriminiň hukuki tehdide dönüşebildiği bir gerçeklik sürüyor

[GN⁺]

Hacker News yorumları

• Başkaları da tekdüze artan kullanıcı kimliklerini bulup test ettiği için hapse giren vakalar yaşadı
  Bu şekilde test etmeye başladığınız anda CFAA ihlali riski doğar
  Kimliklerin zaten tekdüze arttığını ve varsayılan parolanın ayarlı olduğunu öğrendiyseniz, o noktada açığı hemen bildirmeliydiniz
  Testi çalıştırdığınız anda hukuku ihlal etmiş sayılabilirsiniz
  Şu an bunu yazmak fiilen itiraf etmek gibi, bu yüzden bir avukat tutup ilgili hukuku öğrenmeniz gerekir

• Hukuki uzmanlığım yok ama üç düşüncem var

  1. Yasal açıklama prosedürü fazla zorsa, sonunda açıklar ancak suçlular aracılığıyla öğrenilir
  2. Diğer sektörlerde bir mimarın bina kusuru bulduğu için dava edilmesi nasıl saçmaysa burada da benzer bir durum var. Ama siber güvenlikte fark, kusuru bilmenin kendisinin riski artırabilmesi
  3. Yoldan geçen rastgele birinin denetim yapması fazla istikrarsız. Bir web sitesi benden PII (kişisel olarak tanımlanabilir bilgi) istiyorsa, ben de o bilginin güvenliğini talep etme hakkına sahip olmalıyım
     Sigorta şirketleri gibi kurumlar için siber denetimi zorunlu kılmalı, white-hat hacker'ları korumalı ve kullanıcıların toplu dava açabilmesine izin vermeliyiz
     Böyle olursa temel açıklar ortadan kalkar ve avukatlardan daha ekonomik olan taraf yazılım mühendisleri olur
  • Diğer sektörlerde hukuki sorumluluk taşıyan profesyonel mühendislik sistemi var
    CS alanının da yapay zeka çağında bu yöne gidip gitmeyeceğini merak ediyorum
    Profesyonel mühendisler tasarım onayı ve denetimden sorumludur, güvenliği sağlamada kilit rol oynar
    Buna paralel olarak yetkileri ve sorumlulukları büyüktür, ücretleri de yüksektir
  • Diğer sektörlerde tasarımcıların sigortası ve lisansı olur
    Acemi geliştiricilerin açık kaynak faaliyetlerini engellemek istemem ama büyük ölçekli kişisel veri veya para işleyen sitelerde sertifikalı yazılım mühendisinin imzası zorunlu olmalı diye düşünüyorum
    Ancak böylece yönetimin aşırı taleplerine karşı koyacak güç doğar
    Elbette Boeing ya da Volkswagen örneklerine bakınca bunun kusursuz bir çözüm olmadığı da görülüyor
  • Bazı ülkelerde gerçek olsa bile iftira sayılabilir
    Yani yetkililere bildirmekle basına açıklamak tamamen farklı meselelerdir
    Özellikle Malta gibi yerlerde örgütlü suç ve yolsuzluk çok yaygındır; böyle şeyleri açıklayan biri “tesadüfi bir kaza” geçirebilir

• Her hizmet için farklı bir e-posta adresi kullanıyorum
  Yaklaşık 15 yıl önce diversalertnetwork adresime spam gelmeye başladı
  DAN'e ihlali bildirdiğimde, sadece parola değiştirme yönlendirmesi aldım
  Ceza davası açılmamasına şükretmem gerektiğini düşünüyorum

  • Bu ya bir hack'ti ya da şirket verileri üçüncü taraflara sattı
  • Ben de benzer bir şey yaşadım. Portekiz havayolu için kullandığım özel e-posta adresine spam gelmeye başladı ama şirket hiç yanıt vermedi

• Yazarın kuruluşun adını açıklamaktan korkması, hukuki tehdidin etkili olduğu anlamına geliyor

  • Ya da dalış topluluğunda “Malta merkezli dalgıç sigorta şirketi” ifadesi tek başına DAN Europe'u ima etmeye yetiyor olabilir
  • Yazıdaki ipuçlarına bakılırsa, uluslararası dalış sigortacıları arasında Malta'da kayıtlı olan tek şirket DAN Europe olduğu için neredeyse kesin gibi
  • Elbette onun elde ettiği bilgileri black-hat'lere satmış olma ihtimali de tamamen dışlanamaz

• “Verileri sildiğini doğrulayan belgeyi imzala” talebi karşısında neden imzaladığı sorgulanabilir
  Şirket işbirliğinden çok kontrol istiyor gibi görünüyor

  • Ama karşı tarafın benim şartlarımı kabul etmesini sağlarsanız, onların kontrol stratejisini boşa çıkarır ve bunu hukuken bağlayıcı hale getirirsiniz

• Güvenlik araştırmacılarının açık bildirdikten sonra hukuki tehditlerle karşılaşması deseni onlarca yıldır tekrarlanıyor
  Hükümetler ve şirketler siber güvenliğin öneminden söz ediyor ama pratikte araştırmacılara düşmanca davranıyor
  Bu tür haksız tepkileri engelleyecek yasal düzenlemelere ihtiyaç var
  İlgili örnekler bu bağlantıda görülebilir

• Bu olayın hedefinin DAN Europe ve iştiraki IDA Insurance Limited olup olmadığını merak ediyorum

  • Başka yorumlarda da zaten bu yönde çıkarım yapılmıştı

• Almanya'da böyle bir script çalıştırıp başkalarının verilerine erişmek yasadışıdır
  Başkasının arabasının kapısı açık diye içine girip kontağı çevirememeye benzer
  İlgili hukuki değerlendirme için şu yazıya bakılabilir

  • O zaman yasanın değişmesi gerekir. Bu düzeyde güvenlik umursamazlığı, iyi niyetli bir ihbarcı ya da büyük bir sızıntı olmadan asla düzelmez
  • Buna ben de katılıyorum. Nerede durmanız gerektiğini bilmelisiniz
    Siteyi normal kullanıcı gibi kullanırken ekran görüntüsü alıp bildirmek kabul edilebilir, ama Python script'iyle veri toplamak çizgiyi aşmaktır
    Bu, banka kapısının açık olduğunu görüp polisi aramak yerine içeri girmeye benzer
  • Umarım suçlular bu boşluğu istismar etmez

• Geçen yıl büyük bir etkinliğin bilet sisteminde bir açık buldum
  E-postayla gelen bilet bağlantısı, ardışık sipariş numarasının base64 kodlamasıydı
  Yani başkalarının biletleri de kolayca indirilebiliyordu
  Organizatörlere ve geliştirme şirketine e-posta attım ama hiç yanıt gelmedi; şu anda da hâlâ açık duruyor
  Bu yılki etkinlikte düzeltilip düzeltilmediğini izleyeceğim

• Kullanıcı kimlikleri ardışıksa ve varsayılan parola da aynıysa, asıl açık “bir güvenlik sorumlusunun var olduğu varsayımı” idi
  Bugünlerde “sorumlu açıklama” denilen şey, sonuçta sadece şirkete avukat tutması için zaman kazandırmak anlamına geliyor