900 site, 125 milyon hesap, 1 güvenlik açığı
(env.fail)- Yanlış yapılandırılmış tek bir Firebase güvenlik kuralı, yüzlerce sitede kullanıcı verilerinin açığa çıkmasına yol açtı; doğrulanan ölçek tek başına yaklaşık 124,6 milyon kayıt düzeyinde
- İnceleme, web sitelerinde ve yüklenen JavaScript bundle’larında Firebase yapılandırma değişkenlerini arayarak başladı; Python tarayıcısındaki bellek sorunları nedeniyle Go ile yeniden yazıldı
- Yardımcı tarayıcı Catalyst, Firebase koleksiyonlarının okunabilir olup olmadığını otomatik olarak kontrol ediyor ve örnek verilere dayanarak açığa çıkan bilgi türlerini ve ölçeğini tahmin ediyor
- Toplam açığa çıkan öğeler arasında 84.221.169 ad, 106.266.766 e-posta, 33.559.863 telefon numarası, 20.185.831 düz metin parola ve 27.487.924 ödeme bilgisi yer alıyor
- Araştırmacılar 13 gün boyunca 842 bildirim e-postası gönderdi; ancak yapılandırmayı düzelten site sahiplerinin oranı %24, yanıt verenlerin oranı %1 oldu, bug bounty teklif edenler ise yalnızca 2 siteyle sınırlı kaldı
İnternet ölçeğinde Firebase sızıntı taraması
- Chattr.ai ihlali sonrasında, yanlış yapılandırılmış Firebase instance’ları üzerinden açığa çıkan PII’leri bulmak için internet genelinde bir tarama başlatıldı
- İlk Python tarayıcısı, web sitelerinde veya yüklenen
.jsbundle’larında Firebase yapılandırma değişkenlerini kontrol ediyordu; ancak yaklaşık 500 thread ile çalışırken bellek kullanımı arttı ve 1 saat içinde OOM oluştu - Daha sonra Go ile yeniden yazılan tarayıcı 5,5 milyon domain üzerinde çalıştırıldı ve başlangıçta tahmin edilen yaklaşık 11 günden daha uzun, 2–3 hafta sürdü
- İlk manuel incelemeyle bile 136 site ve 6,2 milyon kayıt bulundu; ancak aday listesinin çok büyümesiyle tam otomasyon gerekli hale geldi
Catalyst ve sızıntı ölçeğinin hesaplanması
- Catalyst, aday siteleri veya JavaScript bundle’larını girdi olarak alıp, yaygın Firebase koleksiyonlarının ve JavaScript içinde doğrudan adı geçen koleksiyonların okuma erişimine açık olup olmadığını otomatik olarak kontrol ediyor
- Okunabilir bir koleksiyon bulduğunda 100 kayıtlık örnek topluyor, içerdiği bilgi türlerini belirliyor ve bunu koleksiyonun toplam boyutuyla çarparak etkiyi tahmin ediyor
- Sonuç deposu olarak PostgreSQL tabanlı açık kaynak Firebase rakibi Supabase seçildi; temizlenen veriler özel veritabanı tablolarına yüklendi
- Toplam rakamlar aşağıdaki gibi; gerçek sızıntı ölçeğinin gösterilen sayılardan daha büyük olma ihtimali devam ediyor
- Toplam kayıt: 124.605.664
- Ad: 84.221.169
- E-posta: 106.266.766
- Telefon numarası: 33.559.863
- Parola: 20.185.831
- Ödeme bilgisi: banka bilgileri, faturalar vb. 27.487.924
Etkisi büyük olan siteler
-
Silid LMS
- Öğrenciler ve öğretmenler için öğrenme yönetim sistemi
- Ad, e-posta ve telefon numarası dahil 27 milyon kullanıcı kaydı açığa çıkarak en büyük ölçeği oluşturdu
-
Çevrimiçi kumar ağı
- Birbirinin reskin’i olan 9 siteden oluşuyor
- Bazı spin’ler kazanma olasılığı %0 olacak şekilde manipüle edilmiş
- Banka hesabı detay giriş bilgileri 8 milyon ile en yüksek sayıda açığa çıkan veri oldu
- Düz metin parolalar da 10 milyon ile etkilenen siteler arasında en büyük ölçekteydi
- Sorunu bildirmeye çalışırken müşteri desteği sohbet sırasında flörtöz mesajlar gönderdi
-
Lead Carrot
- Cold call için çevrimiçi lead üretim servisi
- Açığa çıkan kullanıcı bilgisi ölçeğinde ilk 3’te yer alıyor ve 22 milyon kişiyi etkiliyor
-
MyChefTool
- Restoranlara yönelik iş yönetimi uygulaması ve POS uygulaması
- Açığa çıkan ad sayısında 1., e-posta sayısında 2. sırada; sırasıyla 14 milyon ve 13 milyon veri açığa çıktı
Bildirim sonrasındaki tepkiler
- Araştırmacılar 13 gün boyunca 842 e-posta gönderdi
- %85’i iletildi, %9’u geri döndü
- Site sahiplerinin %24’ü hatalı yapılandırmayı düzeltti
- Yanıt veren site sahipleri yalnızca %1’de kaldı
- %0,2’ye karşılık gelen 2 site sahibi bug bounty teklif etti
1 yorum
Hacker News yorumları
Firebase’de uzun süre çalıştım; güvenlik kuralları sorunu ürünü sürekli zorlamaya devam etti.
Otomatik süresi dolan varsayılan kurallar, eğitimi güçlendirme gibi çeşitli yaklaşımlar denedik, ama sonunda hâlâ güvenli olmayan çok sayıda veritabanı görüyoruz.
Nedenleri karmaşık; Firebase tarzı güvenlik kuralları hâlâ yabancı bir kavram ve mevcut bir konuma veri ekleyen yeni geliştiriciler çoğu zaman verinin gizlilik gereksinimlerindeki değişime uygun olarak kuralları da düzeltmiyor.
Ayrıca herkesin kendi yazdığı backend’in sağladığı “belirsizlikten gelen güvenlik” ortadan kalktığı için büyük ölçekli taramalar kolaylaşıyor.
Özellikle Realtime Database kurallarını yazmak zor ve ölçeklenebilirliği de iyi değil; ancak otomatik taramalar genelde yalnızca açık veriyi aradığından,
read write truedurumundan biraz daha iyi olmak bile bunları engelleyebiliyordu.Teknik olarak Firebase yaklaşımının kendisi yanlış değil, ancak saklanan veri ve güvenlik kuralları merkezli modeli kullanan neredeyse tek backend olduğu için yanlış anlaşılmaya, yanlış kullanıma ve bu tür kazalara daha açık.
Backend’de doğrulama ve güvenlik kuralları spesifikasyonun bir parçası gibi görünür; Firebase güvenlik kuralları ise ayrı bir süreç olduğundan kolayca unutuluyor ve her yeni özellik geliştirildiğinde yeniden değerlendirilmesi gerekiyor.
Proje sahiplerini bilgilendirebilecek birinin dikkatini çekmek için Firebase içinde epey üst seviyelere eskale etmek gerekirdi gibi görünüyor.
Örneğin yazıdaki “yalnızca içerik sahibi erişebilir” ya da “öznitelik tabanlı/rol tabanlı erişim” gibi şablonların çoğu uygulamanın kalıplarını kapsayıp kapsayamayacağı, yoksa gerçekten çok sayıda özel kurala ihtiyaç olup olmadığı soru işareti.
Güvenlik kuralı yazmanın büyük sorunu, neredeyse her hatanın bir güvenlik sorununa dönüşmesi; bu yüzden gerekmedikçe dokunmak istemiyorsunuz.
Kurallar fazla kapalıysa uygulama çalışmaz ve hemen belli olur; ama fazla açıksa aşırı erişimi bizzat denemeden kolay kolay ortaya çıkmaz.
Bununla bağlantılı olarak, her güvenlik kuralı için geliştiricinin erişim reddi örnek test vakaları yazmasını zorunlu kılmak da düşünülebilir.
fireplanadlı kural transpiler’ı, tüm özelliklere varsayılan"$other": {".read": false, ".write": false}kuralını ekliyor.Bu sayede yeni alanların açıkça eklenmesi gerekiyor; yeni bir değerin mevcut kuralları farkında olmadan “devralması” neredeyse imkânsız hale geliyor.
Firebase’i 10 yılı aşkın süredir kullandığımız için güncel kural araçları da bunu böyle yapıyor mu bilmiyorum.
Asıl faydalı olacak şeyler; kontrol edilmesi zor birden fazla istemci sürümünün bulunduğu durumlarda alan adı değişikliklerini veya veri yapısı değişikliklerini varsayılan olarak desteklemek, veritabanını ayağa kaldırmadan kuralları hafifçe test edebilmek ve üretim ortamında kural başarısız olduğunda daha iyi hata ayıklama bilgisi vermek olurdu.
Her başarısızlıkta, kuralın eriştiği tüm değerler de birlikte kaydedilmeli ki değişen veriler yüzünden oluşan geçici hatalar ayıklanabilsin.
Bu, yeterince açıklanmamış bir kavramsal model.
Projelerde her koleksiyonun herkese açık, kullanıcı verisi, yalnızca kimliği doğrulanmış kullanıcılara açık, yalnızca yöneticilere özel gibi güvenlik profilleri olması gerektiğini söylüyor; her koleksiyon için özel koşullar yazmak yerine bu kategorileri güvenlik kuralı fonksiyonlarıyla zorunlu kılacak şekilde yaklaşıyoruz.
Güvenliği alan düzeyinde değil koleksiyon düzeyinde düşünürseniz, tek bir belge içinde farklı güvenlik amaçlarının karışmasını azaltabilirsiniz.
Bir koleksiyon herkese açıksa, herkese açık olmayan alanlar içermemeli; gerekirse Firestore tetikleyicileriyle hassas bağlamdan herkese açık bağlama veri kopyalanabilir, ama tersi yapılmamalı.
Sorun, kuralların niyetini kuralların dışında ayrıca belgelemek zorunda kalmanız ve bunun yanlış uygulanmasının kolay olması; eskiden test yazmak da sancılıydı, ama şimdi çok daha iyi.
“How I pwned half of America’s fast food chains, simultaneously.” aklıma geliyor: https://mrbruh.com/chattr/
HN: https://news.ycombinator.com/item?id=38933999
After the initial buzz of [pwning Chattr.ai] had settled down, […]Yanlış görmüyorsam, yazının sonu itibarıyla bu zafiyete sahip sitelerin %75’inin hâlâ olduğu gibi açık ve dump alınabilir durumda olduğu anlamına gelmiyor mu?
Delilik bu.
Bazı günler bilgisayara dokunmak için ehliyet gerekmesi gerektiğini düşünüyorum.
Web sitesi yapan ajanslara dış kaynak kullanıyorlar; ajanslar da geliştiricileri sürekli değiştiriyor, başta iyi geliştiriciler atayıp sonra şirket şikâyet etmediği sürece sözleşmeyi daha az deneyimli geliştiricilere bırakıyor.
Zafiyet e-postaları muhtemelen spam diye yok sayıldı, iletilip kenarda kaldı ya da PM’in toplantı takvimi kuyruğuna girip müşteriye mümkün olduğunca fatura edilerek düzeltilecek bir kalem hâline geldi.
Profesyonel lisansın zorunlu olduğu alanlarda da beceriksiz lisans sahipleri çok.
Doktorların da eğitim ve lisans gereksinimleri muazzam, ama şarlatan doktorlar ve lisanslı alternatif tıp uygulayıcıları hiç eksik değil.
Her siteye etkilenen içerik, nasıl düzeltileceği ve iletişim yöntemiyle ilgili özel e-postalar göndererek elimizden geleni yaptık.
Bu, PM’in cheap-fast-good üçgeninde ucuz ve hızlı seçeneği tercih etmesinin kaçınılmaz sonucu
Ne yazık ki bazı müşterilerin ve kullanıcıların endişeleri tartışmanın dışında kaldı; bedel de onların kişisel verileri oldu
Burada listelenen şirketler arasında böyle bir karar alıp da liderliği değişmeyenlere karşı temkinli olurum
Birçok şirketin müşterilerini koruyacak kadar umursamadığı defalarca kanıtlandı; tarih tekerrür ediyor
Firebase hakkında çok temel bir sorum var: Bu yazıdaki uygulamaların çoğu, özel sunucu kodu olmadan yalnızca statik olarak barındırılan istemci tarafı JavaScript ile mi uygulanmış?
Backend’in %100 Google’ın barındırdığı Firebase yapılandırması olduğu anlamına mı geliyor, merak ediyorum
Öyleyse milyonlarca kullanıcısı olan sitelerde böyle bir mimarinin bu kadar yaygınlaştığını bilmiyordum
API’de varsayılan izin ver güvenlik modeli olursa kaçınılmaz olarak böyle olur
Ne yazık ki JavaScript geliştiricilerini hedefleyen kütüphanelerde güvenli olmayan varsayılanlar yaygın; GraphQL de bu tür sorunların çıkabileceği bir alan gibi görünüyor
Firebase’de buluttan çağrılabilen fonksiyonlar olan Firebase Functions da var ve o kod herkese açık değil
Ancak Firestore ya da Firebase Realtime Database’de güvenlik kurallarını kullanıcıların ayarlaması gerekir; aksi halde herkes tüm verileri okuyabilir
Önemli olan, backend’de uygun yetkilendirme kurallarını kolayca yazılabilir hale getirmek
Böyle şeyleri görünce, uzun zaman önce parola yöneticisi ve sanal kartları seçmiş olmaktan memnun oluyorum
Yine de internet daha korkutucu hale geliyor
Çoğu insan web’in ne kadar kırılgan olduğunu ve kendilerinin ne kadar açıkta olduğunu hiç bilmiyor
Yapay zeka ajanları güvenlik açıklarını botlardan çok daha verimli bulacak; tuhaf bir gelecek bekliyor gibi
Kaydolduğunuz her servis için benzersiz e-posta adresi kullanmalısınız
Bir olay olduğunda zararı sınırlar ve başka servislerle karşılaştırılarak açık kaynak istihbaratı toplanmasını da engeller
Bazen o benzersiz adrese kötü amaçlı e-posta gelirse, ihlali site işletmecisinden önce fark edebilirsiniz
“Yaklaşık 500 thread’i olan Python programı zamanla bellek yemeye başlar” kısmı hakkında daha fazla bilgisi olan var mı?
Benim de Python’da yüzlerce thread’li bir scraper’ım var ve çok bellek tüketiyor gibi
Bir geçici çözüm var mı, yoksa başka bir dilde yeniden yazmak tek çözüm mü, merak ediyorum
Şahsen thread’ler yerine süreçleri tercih ediyorum; paylaşımlı bellek yerine de worker havuzu ve mesaj veri yolu kullanıyorum
Bu çözümün de eksileri ve biraz ek yükü var, ama bellek sorunları hakkında çok daha az endişelenmeniz gerekir
Crawler’da süreç sayısı görece sabit ve her sürecin işi bağımsız olduğundan süreç modeli daha uygun görünüyor
import multiprocessing as threadingYeniden yazmak pratikte tek çözüme yakın
Çok iyi uyan bir kullanım senaryosu
İyi iş
Etkilenen kullanıcı sayısının gerçekte daha yüksek olma olasılığı olduğu sonucuna nasıl vardığınızı merak ediyorum
Görünüşe göre kumar siteleri veya Lead Carrot gibi bazı sitelerde çok sayıda sahte hesap verisi karışmış olabilir
Yalnızca İngilizce sitelerde iyi çalışan bir yöntem
Daha fazla olabilir dememin nedeni, tarama listesinde olmayan başka servislerin de savunmasız olma olasılığı