Web sitesini ziyaret etmeden Arc tarayıcısına erişim sağlayan açık

 (kibty.town)
2 puan yazan GN⁺ 2024-09-20 | 1 yorum | WhatsApp'ta paylaş
  • Arc tarayıcısındaki Boosts özelliği ile Firestore kuralları sorunu birleşince, saldırganın kurban hesabına rastgele JavaScript içeren bir Boost bağlayabilmesi mümkün oldu
  • Firebase kimlik doğrulaması ve Firestore kullanımı Frida hooking ile doğrulandı; preferences, users, user_referrals, boosts koleksiyonlarına erişim akışı ortaya çıkarıldı
  • Açık, Boost uygulanacak hedefin creatorID ile belirlenmesine rağmen saldırganın kendi Boost belgesindeki creatorID değerini başka bir kullanıcının kimliğiyle değiştirebilmesinden kaynaklandı
  • Kurban kimliği user_referrals, herkese açık Boost'ların boostSnapshots verileri, paylaşılan Easels gibi kaynaklardan elde edilebiliyordu; kurban hedef siteyi ziyaret ettiğinde kötü amaçlı Boost çalışabiliyordu
  • The Browser Company, yama ile birlikte $2,000 ödül verdi ve CVE-2024-45489 atandıktan sonra Firebase kullanımını azaltma, güvenlik denetimi ve bug bounty programı başlatma planlarını duyurdu

Arc'ın bulut özellikleri ve Firestore kullanımı

  • Arc, kullanım için bir hesap gerektiriyordu ve kayıt sürecinde Firebase kimlik doğrulamasının kullanıldığı doğrulandı
  • İlk ağ gözlemlerinde başka istekler görünmese de, Easels paylaşım özelliği incelenirken Firestore kullanım ihtimali ortaya çıktı
  • Easels, başkalarıyla paylaşıldığında web üzerinden görüntülenebilen beyaz tahta benzeri bir arayüzdür
  • Firestore, ayrı bir backend olmadan veritabanı güvenlik kuralları ve istemcinin doğrudan erişimiyle özellikler geliştirmeyi sağlayan bir database-as-a-backend hizmetidir
  • Firestore güvenlik kurallarının zayıf olduğu önceki bir örnek olarak Firewreck gösteriliyor

Firebase çağrılarının nasıl doğrulandığı

  • Firebase'in Swift SDK'sı sistem proxy ayarlarını izlememe eğiliminde olduğundan, mitmproxy yerine ilgili çağrıları dökmek için Frida script'i kullanıldı
  • Script, Objective-C sınıflarındaki Firestore çağrılarını hook'luyordu
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • getDocuments, addSnapshotListener:, getDocument gibi yürütme metotları
    • updateData, setData ailesindeki belge yazma metotları
  • Arc çalışırken aşağıdaki türlerde Firestore yolları ve sorguları gözlemlendi
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • user_referrals içinde inviter_id == {userID} sorgusu
    • boosts içinde creatorID == {userID} sorgusu
  • Bu yapıda Arc, bazı ortam ayarlarını, temel kullanıcı nesnesini, yönlendirme bilgilerini ve Boosts verilerini Firestore'da saklıyordu

Boosts'un saldırı yolu haline gelmesinin nedeni

  • Arc Boosts, kullanıcıların web sitelerini özelleştirmesini sağlayan bir özelliktir
    • öğe engelleme
    • yazı tipi değiştirme
    • renk değiştirme
    • özel CSS
    • özel JavaScript
  • Boosts, Firestore'da saklanıyordu ve Arc tarayıcısı hangi Boost'un uygulanacağını creatorID alanına göre sorguluyordu
  • Saldırgan, kendi hesabında Google.com için bir Boost oluşturduktan sonra Firestore belgesindeki bazı parametreleri değiştirerek test yaptı
  • creatorID temelli sorgu nedeniyle başka kullanıcıların Boost'ları doğrudan sorgulanamıyordu; ancak kendi Boost belgesindeki creatorID alanını başka bir hesabın kullanıcı kimliğiyle değiştirmek mümkündü
  • Başka bir hesapla yapılan testte, kurbanın bilgisayarında Google.com açıldığında saldırganın oluşturduğu Boost'un uygulandığı görüldü

Saldırı zinciri ve kullanıcı kimliğinin elde edilmesi

  • Nihai saldırı akışı şu şekildeydi
    • kurbanın kullanıcı kimliği elde edilir
    • saldırgan hesabında istenen payload'u içeren kötü amaçlı bir Boost oluşturulur
    • Boost belgesindeki creatorID alanı kurbanın kimliğiyle değiştirilir
    • kurban hedef web sitesini ziyaret ettiğinde kötü amaçlı Boost çalışır
  • Bu açık; Arc Boosts'un rastgele JavaScript içerebilmesi, Firestore'da saklanması ve uygulanacak hedefin creatorID alanıyla belirlenmesi nedeniyle mümkün oldu
  • Kurbanın kullanıcı kimliğini elde etmenin birden fazla yolu vardı
    • user_referrals: Birine Arc daveti gönderildiğinde veya birinden davet alındığında user_referrals tablosundan karşı tarafın kullanıcı kimliği alınabiliyordu
    • herkese açık Boosts: JavaScript içermeyen Boost'lar paylaşılabiliyordu ve Arc Boosts herkese açık sitesi içindeki boostSnapshots verileri oluşturucunun kullanıcı kimliğini içeriyordu
    • Easels: Paylaşılabilir beyaz tahta özelliği üzerinden de kullanıcı kimliği elde edilebiliyordu

Yama ve açıklama takvimi

  • The Browser Company normalde bug bounty uygulamasa da bu açık için $2,000 USD ödedi
  • Açığın zaman çizelgesi şöyleydi
    • 25 Ağustos 5:48pm: Arc kurucu ortağı Hursh ile Signal üzerinden ilk temas
    • 25 Ağustos 6:02pm: Hursh'un Arc hesabında açığın PoC'si çalıştırıldı
    • 25 Ağustos 6:13pm: Ayrıntılar şifreli biçimde paylaşıldıktan sonra Slack kanalına eklendi
    • 26 Ağustos 9:41pm: Açık yamandı ve ödül ödendi
    • 6 Eylül 7:49pm: CVE-2024-45489 atandı
  • Ardından Arc, konuyla ilgili kendi yazısını CVE-2024-45489 incident response başlığıyla yayımladı

Yetkili sayfalarda çalıştırma ve gizlilik çelişkisi

  • Boosts, istemci içinde oluşturulamasa bile başka protokollerde çalıştırılabiliyordu
  • settings sayfasını hedefleyen bir Boost oluşturulursa chrome://settings üzerinde çalışabiliyor ve bu da yetki yükseltmeye yol açabiliyordu
  • Bir site ziyaret edildiğinde şu Firestore sorgusu gerçekleşiyordu
    • boosts koleksiyonunda creatorID == {userID} ve hostPattern == "www.google.com"; koşullarıyla sorgu yapılıyordu
  • Burada hostPattern ziyaret edilen siteyi ifade ediyor; bu da Arc'ın hangi sitelerin ziyaret edildiğini bilmediğini söyleyen Arc gizlilik politikası ile çelişiyor

Arc'ın sonraki adımları

  • Arc, bu açık ve yeni özelliklerin devreye alınmasıyla birlikte Firebase'den uzaklaşma yönünde bir geçiş başlattı
  • Arc'ın kendi özetinde şu adımlar yer aldı
    • sorunun düzeltildiğinin doğrulanması
    • istemci tarafında Boosts'u devre dışı bırakma özelliğinin eklenmesi
    • mevcut Firebase ACL kuralları için iç denetim
    • güvenlik sorunlarına müdahale protokolünün oluşturulması
  • Arc içi tartışmalarda paylaşılan ek adımlar ise şunlardı
    • v1.61.1 güncellemesinde gizlilik sorununun düzeltilmesi
    • yeni özellik ve ürünlerde Firebase kullanımının bırakılması
    • ilgili sürüm için harici güvenlik denetimi
    • gelecekteki açıklar için bir bug bounty programının başlatılması

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-20
Hacker News yorumları

  • Arc’ı geliştiren The Browser Company’nin kurucu ortağı ve CTO’su Hursh ben. Gerçekten etkilenen kullanıcı olmadı ve hemen yama yaptık, ancak bu açığın potansiyel ciddiyetinin kabul edilemez olduğunu düşünüyorum.
    Teknik ayrıntıları, bundan sonra yapacağımız iyileştirme planlarını, Firebase’den uzaklaşmayı ve resmi bir bug bounty programı oluşturmayı burada özetledik: https://arc.net/blog/CVE-2024-45489-incident-response
    Hem açığın kendisi hem de geciken iletişim için gerçekten özür dilerim; hayal kırıklığı, öfke ve destek dâhil geri bildirimleriniz sayesinde daha iyisini yapmak için sorumluluk hissediyoruz.

    • Bu yazının yalnızca HN kullanıcıları görsün diye mi yazıldığını merak ediyorum. Blog listesinde (https://arc.net/blog) görünmüyor, Twitter’da da paylaşılmamış.
      Tüm müdahale, ancak yeterince gürültü kopunca tepki verme şeklinde görünüyor.
    • Birkaç arkadaşım Arc’ı sevdiği için ben de geçmeyi düşünüyordum, ama artık kullanmayı düşünmüyorum. Açığın kendisinden çok, tüm kullanıcıları tehlikeli biçimde ele geçirebilecek bir bug için sadece $2k bounty ödenmiş olması nedeniyle.
      Kullanıcı güvenliğini bu kadar hafife alan bir şirketin yaptığı tarayıcıyı kullanmak istemem. Emin değilim ama bu ciddiyette bir açığın karaborsada çok daha pahalıya satılmış olma ihtimali yüksek.
    • Aşağıdaki yorumlarda, her sayfa yüklemesinde URL’nin ve tanımlanabilir kullanıcı ID’sinin TBC’ye gönderilip gönderilmediğine dair endişeler var. Chrome dışı tarayıcı kullanan kişiler genelde gizliliğe de duyarlı olma eğilimindedir; bu konuya yanıt vermeniz iyi olur.
      Güvenlik açıkları ortaya çıkabilir, ama gezinme verilerini göndermek kasıtlı bir tasarım tercihi gibi görünüyor.
    • Bu olaydan sonra ekibin bir tarayıcıyı bakımını yapacak uzmanlığa sahip olduğuna ikna etmenin bir yolu yok gibi. Düzeltmiş olmalarından bağımsız olarak, şimdi de gelecekte de güvenli bir tarayıcı yapabilecek kapasitede görünmüyorlar.
      CTO’nun istifa etmesi gereken bir konu olduğunu düşünüyorum.
    • Bug bounty ödeme tutarını artırma planınız olup olmadığını merak ediyorum. $2,000, bu bug’ın değerine kıyasla çok küçük bir miktar; bulan kişiye düzgün bir ödül verilmesini umuyorum.
      Doğru yöne dönmek için elinize mükemmel bir fırsat geçmiş durumda.

  • Buradaki yorumlarda Firebase çok suçlanıyor, ama insanlar aslında pek bilmedikleri bir şeyi tekrar ediyor gibi görünüyor. Firebase kullanmıyorum ama geçmişte kullanmış biri olarak bu ne uç bir durum ne de çözmesi zor bir sorun; en temel konulardan biri.
    Asıl sorun, API’nin istemcinin “ben kimim” diye bildirdiği değere güvenecek şekilde yapılmış olması. Sonuçta amatörce bir hata ve muhtemelen tek satırlık bir değişiklikle düzeltilebilirdi. Sadece dokümantasyona bakınca bile https://firebase.google.com/docs/rules/rules-and-auth#cloud-... içinde request.auth gerekli kullanıcı ID’sini (request.auth.uid) veriyor.

    • Firebase ile yapılmış bir uygulama işleten biri olarak katılıyorum. Yazarın doğru belirttiği gibi yapılandırma hatası yapmak çok kolay, ama bu tür temel güvenlik uygulamaları Firebase dokümantasyonunda kalın ve göze çarpan uyarılarla vurgulanıyor.
      Güvenlik kuralları ciddiye alınmalı; fiilen tek savunma hattı onlar.
    • Yazılım mühendislerinin önce kimlik doğrulamayı kendileri yapıp, sonra kendileri yapmamaya yönelip, şimdi de bu kadar bariz güvenlik sorunlarını bile fark edememesi ilginç.
      Kimlik doğrulamayı kendiniz yapsanız da yapmasanız da temel nokta tek: istemciye asla güvenmeyin.
    • “Sonuçta amatörce bir hata” ise keşke öyle olsa. Benim iş arkadaşlarım da şirket içi frontend uygulamalarında aynı hatayı defalarca yaptı.
    • Herhangi bir kişinin asla amatörce hata yapmayacağı varsayımına dayanan güvenlik planının kendisi amatörce bir hatadır.
    • Doğru anladıysam bu sorunun düzeltmesi, firestore.rules içindeki match ifadesine aşağıdaki kuralları koymaktan ibaretti. Firebase Firestore güvenliğine giriş düzeyindeki dokümanlarda aynen çıkan şey. 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • Tıklanan yere koşup gelen küçük piksel art kediyi gerçekten sevdim. Bugünlerde pek sık görülmeyen eğlenceli ve yaratıcı küçük bir dokunuştu; istersek internetin böyle keyifli bir yer olabileceğini hatırlatan bir şey gibiydi.

    • Bende görünmedi; geliştirici prefers-reduced-motion ayarına saygı gösterip bu ayar açıksa göstermiyor gibi. İsteyene keyif veren, istemeyene de rahatsızlık çıkarmayan harika bir yaklaşım.
    • 35 yaşındaki bir kediye göre gayet iyi hareket ediyor.
      https://en.wikipedia.org/wiki/Neko_(software)
    • Debian’da kediyi şu şekilde kurup çalıştırabilirsiniz:
      sudo apt install oneko
      oneko &
      Yerinde olmayan bir iş arkadaşının bilgisayarına hediye etmek için iyi olur.
    • Sevimli ama fareyi her hareket ettirdiğimde veya kaydırma yaptığımda kedinin hareket edeceğini bildiğim için yazıya odaklanamadım. Konsolu açıp sildim. Üzgünüm, kedi.
    • Telefonda sürekli metnin üstünü kapatıyordu; kaldırmanın bir yolunu arıyordum. Firefox okuma modu çözdü.

  • Bu yazıya göre Arc’ta hesap zorunlu ve ziyaret edilen her sayfanın ana makine adını ve kullanıcı ID’sini Google Firebase’e gönderiyor. Öyleyse Arc, şu anda kullanılan tarayıcılar arasında gizliliği en zayıf tarayıcı olmuyor mu diye düşünüyorum

    • Kurulumdan hemen sonra hesap zorunlu olduğunu öğrenince Arc’ı anında sildim. Wi-Fi gerektiren bir diş fırçası kadar saçma görünmüştü; şimdi bakınca daha da ciddiymiş
    • O ödülü OperaGX alacak gibi
    • Firebase çökerse Arc’ın ne kadar bozulacağını da merak ediyorum
    • Birkaç ay önce indirip kullanmak için hesap gerektiğini görünce, Firefox kullanmaya devam etmenin daha iyi olacağına dair içime bir his doğmuştu
    • Firebase’e gönderilen verileri şifrelemiyorlar mı? Hassas veriyse Google da bunu yapmalarını önerir herhâlde

  • Gerçekten harika bir bug. Firebase gibi backend servislerinin güvenlik kurallarında açıklaması zor, tuhaf varsayılanlar var. Kendi API’mi yazsaydım, bu örnekteki boost gibi bir kaydın userId değerini istek payload’ından almaz, oturumdaki kullanıcı ID’si olarak ayarlardım
    Belli bir seviyenin üzerindeki geliştiriciler, korumalı bir API yoluna istemcinin kendi userId’si olduğunu iddia ettiği bir değeri geçirmeyi zaten pek düşünmez. Buna karşılık güvenlik kurallarında, sistemin gerçekten programlandığı kullanım biçiminden bağımsız olarak, kötüye kullanılabileceği her yolu hayal etmek gerekiyor

    • Böyle yaklaşıyorsanız açıkçası yanlış yapıyorsunuz. Varsayılan reddetme ile başlarsanız yalnızca meşru kullanım biçimlerini hayal etmeniz yeterli olur
    • Ekleme işlemlerinde doğru ama güncellemelerde tüm isteğin olduğu gibi ORM’e ya da belge deposuna verildiğini sık görüyorum. “Sahip belgeyi güncelleyebilir” diye düşünmek kolay; fakat resmi istemcinin ayarlamadığı bazı alanların, örneğin sahip ya da oluşturulma zamanının değişmemesi gerektiğini gözden kaçırmak kolay
      Doğru çözüm muhtemelen tüm alanlar için varsayılan reddetme yetkisi koymak. Böylece en azından sahip alanını yazılabilir olarak açıkça belirtmeniz gerekir ve bu nesneyi başka bir kullanıcıya devretmenin etkilerini de düşünürsünüz

  • Bu açığın ne kadar akıl almaz derecede aptalca olduğuna şaşırıyorum. Rastgele kod çalıştırmak için kelimenin tam anlamıyla başka birinin kullanıcı ID’sini göndermek yeterli; o ID’yi elde etmek de epey kolay
    FAANG’de çalışmıyorum; gerçekten ihtiyaç duyulmayan, berbat bir ürün yapan bir şirkette çalışıyorum ama ben bile böyle bir bug yapmazdım. Bu insanların tarayıcı yapmaya kalkıp bunun gerektirdiği güvenlik uzmanlığını ve ahlaki sorumluluğu da üstleneceklerini düşünmek zor

    • Başka birinin kullanıcı ID’sinin nasıl elde edilebileceğini açıklayabilir misin? Büyük bir açık olduğunu anlıyorum ama o kısmın nasıl gerçekleştiğini anlamak istiyorum

  • Arc kullananların ya da Arc kullanan tanıdığı olanların daha kolay fark etmesi için gönderi başlığında Arc geçse iyi olurdu

    • Kesinlikle katılıyorum. Dün ilk gördüğümde bunun beni ilgilendirdiğini fark etmemiştim; ancak başlık değiştikten sonra tıkladım
      Açıkçası başlığın “Arc tarayıcısında temel bug (CVE 123-4567)” gibi bir şey olması gerektiğini güçlü biçimde düşünüyorum

  • Dünyada anlaşılabilir nedenlerle ortaya çıkmış pek çok ciddi güvenlik açığı var; sorumlu biçimde ele alınıp düzeltilirse affedilebilir
    Ama bu onlardan biri değil. Kişisel olarak itibarı mahvedecek düzeyde bir beceriksizlik gösteriyor ve Arc’ı bir daha kullanmamaya karar verdirecek kadar ciddi

    • Öte yandan yanıt verme hızı kendi başına oldukça etkileyici
      aug 25 5:48pm: Signal şifreli kanalı üzerinden Arc kurucu ortağı Hursh ile ilk temas
      aug 25 6:02pm: Hursh’ün Arc hesabında güvenlik açığı kavram kanıtının çalıştırılması
      aug 25 6:13pm: Ayrıntılar şifreli biçimde paylaşıldıktan sonra Slack kanalına eklenme
      aug 26 9:41pm: Açığın yamalanması, ödülün ödenmesi
      sep 6 7:49pm: CVE atanması (CVE-2024-45489)
      Ani ilk temastan düzeltmenin dağıtılmasına kadar 4 saat; düzeltmenin basit olma ihtimali düşünülse bile oldukça iyi. Düzeltme: Tarih değişmiş, yani aslında 28 saatmiş. Yine de fena değil; ilk temastan 30 dakika sonra “Slack kanalımıza gel” yanıtı çok hızlı
    • Arc’ı bir kez denemek için bile zorunlu hesap gerekmesi baştan büyük bir uyarı işaretiydi; bu yüzden hiç denemedim. Şimdi kullanmadığıma seviniyorum
    • Açıkçası Arc’ı özellikle gizlilik açısından hep kuzu postuna bürünmüş kurt gibi gördüm
      Tarayıcı kadar önemli ve kişisel bir üründe, 50–60 milyon dolar nakit ve 500 milyon dolar değerleme almışken iş modelinin olmaması büyük bir uyarı işareti. Bu bir hayır işi değil; birileri bir şekilde bedelini ödeyecek
    • Tarayıcı dağıtan bir şirketin güvenlik kurallarına biraz daha dikkat edeceğini düşünür insan
      Firebase’in de bunu biraz daha aptal-proof hâle getirememiş olması üzücü. Ve gerçekten sadece $2,500 mü? Kelimenin tam anlamıyla Arc’ın tüm kullanıcıları ele geçirilebilirdi; NSA olsaydı birkaç sıfır daha eklerdi
    • Üstelik Firebase mi, gerçekten? Düşük seviye yazılım mühendisleri bile işe alan bir şirket, kutudan çıkan bir CRUD backend’i kullanıyor. Maliyet açısından verimli olmuş olabilir ama ben böyle bir şey tasarlıyor olsaydım Firebase’i backend adaylarının uzun listesine bile koymazdım
      Özellikle Supabase gibi işlevsel rakipler normal DBMS ve kimlik doğrulama modelini sarmalayan bir yaklaşımken

  • Paylaştığın için teşekkürler. Beta’nın ilk haftasından beri Arc kullanıyordum
    Ama bu bug’dan ve düzeltmeden sosyal medyanın hiçbir yerinde bahsetmemiş olmaları epey endişe verici. Arc kullanırken keyif aldım ama bu şekilde ele alışlarını görünce kullanmaya devam edebileceğimi sanmıyorum

    • Sorunu kabul edip 28 saat içinde düzeltmeleri yeterli değil mi? Böyle bir yanıt, Arc kullanmaya devam edilebileceğini düşündürüyor

  • Böyle büyük bir açık için $2,000 hakaret gibi bir miktar

    • HN’deki blog yazılarına bakınca, bu tür açıkların çoğu zaman hiç ödüllendirilmediği ya da çok düşük tutarlar aldığı görülüyor. Şirketler hacker’lara exploit’i satmaları için yalvarıyor gibi görünüyor
      Muhtemelen ihlal olayları için düzenleyicilerden ceza almadıkları içindir
    • Evet, benim de ilk tepkim buydu. Bu kadar cimri davranmalarına gerçekten şaşırdım
    • Bu tutarın 20–50 katını verecek kötü niyetli bir tarafa satmamak için oldukça sağlam bir vicdan gerekir