900 site, 125 milyon hesap, 1 açık

İlk deneme

• Python ile yazılmış temel bir tarayıcı Firebase yapılandırma değişkenlerini kontrol etti.
• Bellek tüketimi sorunu nedeniyle bir saat içinde çalışmayı durdurdu.

İkinci deneme

• Go ile yeniden yazılan tarayıcıda bellek sızıntısı yoktu.
• 5 milyondan fazla alan adını taramak beklenenden daha uzun sürdü.

Tüm alan adlarını manuel doğrulama

• 550 bin satırlık metin dosyasındaki her öğe manuel olarak incelendi.
• 136 site ve 6,2 milyon kayıt doğrulandı, ancak otomatik bir yönteme ihtiyaç olduğu fark edildi.

Katalizör

• Potansiyel olarak etkilenmiş olabilecek sitelerin listesi Katalizör adlı yardımcı bir tarayıcıyla incelendi.
• Sitede veya .js paketlerinde ortak Firebase koleksiyonlarına okuma erişimi otomatik olarak kontrol edildi.
• Verinin etkisini değerlendirmek için 100 kayıtlık örnekler toplandı ve bilgi türleri doğrulandı.
• Sonuçları saklamak için Supabase (açık kaynaklı bir Firebase rakibi) seçildi.

Sayılar

• Toplam kayıt: 124 milyon 605 bin 664
• İsim: 84 milyon 221 bin 169
• E-posta: 106 milyon 260 bin 766
• Telefon numarası: 33 milyon 559 bin 863
• Parola: 20 milyon 185 bin 831
• Ödeme bilgisi: 27 milyon 487 bin 924
• Bu sayıların gerçekte olduğundan büyük olabileceğine dikkat edin.

Etkilenen sitelerin listesi

1. Silid LMS

• Öğrenciler ve öğretmenler için bir öğrenme yönetim sistemi.
• En fazla kullanıcı kaydı ifşası burada yaşandı; 27 milyon kişi etkilendi.

2. Çevrim içi kumar ağı

• Her biri farklı tasarıma sahip 9 siteden oluşuyor.
• Bazı oyunlarda kazanma olasılığı %0 olacak şekilde hile yapıldı.
• Sorunu bildirmeye çalışıldığında müşteri desteği kandırmaya çalıştı.
• En fazla banka hesabı bilgisi ifşası burada görüldü: 8 milyon.
• En fazla düz metin parola ifşası burada görüldü: 10 milyon.

3. Lead Carrot

• Soğuk arama için çevrim içi potansiyel müşteri üreticisi.
• En fazla kullanıcı bilgisinin ifşa olduğu ilk 3 siteden biri; 22 milyon kişi etkilendi.

4. MyChefTool

• Restoranlar için iş yönetimi uygulaması ve point-of-service uygulaması.
• En fazla isim ve ikinci en fazla e-posta ifşası burada görüldü; sırasıyla 14 milyon ve 13 milyon.

Sonuç

• 13 gün boyunca 842 e-posta gönderildi.
• E-postaların %85'i ulaştı.
• E-postaların %9'u geri döndü.
• Site sahiplerinin %24'ü yapılandırma hatasını düzeltti.
• Site sahiplerinin %1'i yanıt verdi.
• Site sahiplerinin %0,2'si (2 site) bug bounty sundu.

GN⁺ görüşü

• Bu araştırma, Firebase güvenlik ayarlarının yanlış yapılandırılmasının ne kadar kolay olabileceğini gösteriyor. Bu, geliştiricilere güvenlik ayarları konusunda farkındalık kazandıran önemli bir örnek.
• Güvenlik sorunu bulunduğunda site sahiplerinin tepkilerinin farklı olduğu görülüyor. Çoğu sorunu düzeltti, ancak bazıları görmezden geldi veya uygun bir ödül sunmadı.
• Bu güvenlik açıklarını bulmak için kullanılan otomasyon araçları başka güvenlik araştırmacıları için de faydalı olabilir. Benzer işlevler sunan araçlar arasında OWASP ZAP ve Burp Suite yer alıyor.
• Firebase gibi bulut hizmetleri kullanılırken güvenlik ayarlarını doğru anlamak ve uygulamak önemli. Yanlış yapılandırma büyük ölçekli veri sızıntılarına yol açabilir.
• Bu vaka, Supabase gibi açık kaynak alternatifler de dahil olmak üzere diğer hizmetler değerlendirilirken güvenlik özellikleri ile kullanım kolaylığını karşılaştırmaya yardımcı olabilir. Supabase, PostgreSQL tabanlıdır ve Firebase'e benzer işlevler sunar, ancak açık kaynaklıdır.

[GN⁺]

Hacker News yorumları

• Firebase'te uzun süre çalışmış bir kullanıcı, güvenlik kurallarıyla ilgili sorunların ürünü her zaman rahatsız ettiğini belirtiyor. Çeşitli yaklaşımlar denenmiş olsa da hâlâ birçok veritabanının güvenlik açısından zayıf olduğunu gördüğünü söylüyor. Bunun nedeni, Firebase güvenlik kurallarının yeni ve karmaşık bir kavram olması ve geliştiricilerin mevcut verilere yeni veri eklerken güvenlik kurallarını güncellememeye eğilimli olmaları. Ayrıca özel bir backend uygulaması olmadığından toplu tarama kolaylaşıyor; gerçek zamanlı veritabanında güvenlik kuralı yazmak da zor ve iyi ölçeklenmiyor. Ancak otomatik taramalar çoğu zaman yalnızca açıkta olan verileri bulduğu için bu sorun sanıldığı kadar sık yaşanmıyor. Firebase yaklaşımının kendisinde teknik bir sorun yok, ancak depolanan veriler ve güvenlik kurallarına dayanan tek backend'lerden biri olduğu için yanlış anlaşılmaya, hatalı kullanıma ve bu tür sorunlara açık.
• Bir kullanıcı, bu durumun ona ABD'deki fast-food zincirlerinin hacklenmesi vakalarını hatırlattığını söylüyor.
• Başka bir kullanıcı, gönderinin son kısmına göre bu tür zafiyetlere sahip sitelerin %75'inin hâlâ veri dökümünü beklediğine dikkat çekiyor ve bunun delilik olduğunu söylüyor. Hatta bazen bilgisayar kullanmak için lisans gerekmesi gerektiğini düşündüğünü ekliyor.
• Bir kullanıcı, ucuz ve hızlı olanı seçmenin kaçınılmaz sonucunun bu olduğunu belirtiyor; bazı müşterilerin/kullanıcıların kaygılarının konuşmada yer almadığını ve bedeli onların kişisel verilerinin ödediğini söylüyor. Burada listelenen şirketlerden yönetimi değişmemiş olanlara karşı dikkatli olunması gerektiği konusunda da uyarıyor. Çünkü birçok şirketin müşterilerini korumayı yeterince umursamadığı defalarca kanıtlandı.
• Başka bir kullanıcı, bu gönderide anılan uygulamaların çoğunun tamamen statik olarak barındırılan istemci tarafı JavaScript ile geliştirildiğini, backend'in de %100 Google tarafından barındırılan bir Firebase yapılandırması olup olmadığına dair temel bir soru soruyor. Eğer öyleyse, milyonlarca kullanıcısı olan sitelerde bu mimarinin ne kadar yaygın olduğunun farkında olmadığını söylüyor.
• Bir kullanıcı, "900 site, 125 milyon hesap, 1 zafiyet, 0 kız arkadaş" diye şaka yapıyor.
• Bir başka kullanıcı, bu tür durumlar yüzünden uzun zaman önce bir parola yöneticisi ve sanal kartlar seçmiş olmasına minnettar olduğunu ifade ediyor. Çoğu insanın web'in ne kadar kırılgan olduğunu ve kendilerinin ne kadar savunmasız olduğunu bilmediğini, bu yüzden internetin daha korkutucu hissettirdiğini söylüyor.
• Bir kullanıcı, yaklaşık 500 thread'i olan bir Python programının zamanla giderek daha fazla bellek kullandığını fark ettiğini ve bu konuda ek bilgi ya da çözüm olup olmadığını soruyor. Kendi Python scraper'ının da yüzlerce thread'e sahip olduğunu ve çok bellek kullanıyor gibi göründüğünü belirtiyor.
• Bir kullanıcı, yapılan işi övüyor ve etkilenen kullanıcı sayısının daha yüksek olduğunun nasıl tahmin edildiği sonucuna nasıl varıldığını merak ediyor. Anılan bazı sitelerin (kumar, lead carrot) sahte hesap verileriyle dolu olduğundan şüphelenildiğini söylüyor.
• Son olarak bir kullanıcı, müşteri desteğinin kendisini güldürdüğünü söyleyerek teşekkür ediyor.