Kerentanan yang Memungkinkan Akses ke Browser Arc Tanpa Mengunjungi Situs Web

 (kibty.town)
2 poin oleh GN⁺ 2024-09-20 | 1 komentar | Bagikan ke WhatsApp
  • Masalah pada Boosts Arc dan aturan Firestore saling berkaitan, sehingga penyerang dapat menautkan Boost berisi JavaScript arbitrer ke akun korban
  • Penggunaan Firebase Authentication dan Firestore dikonfirmasi melalui hooking Frida, yang mengungkap alur akses ke koleksi preferences, users, user_referrals, dan boosts
  • Kerentanan muncul karena target penerapan Boost ditentukan berdasarkan creatorID, sementara penyerang dapat mengubah creatorID pada dokumen Boost miliknya menjadi ID pengguna lain
  • ID korban dapat diperoleh dari user_referrals, boostSnapshots pada Boost publik, dan Easels yang dibagikan, lalu Boost berbahaya dapat dijalankan saat korban mengunjungi situs target
  • The Browser Company memberikan hadiah $2,000 bersama patch, dan setelah penetapan CVE-2024-45489 berencana mengurangi penggunaan Firebase, melakukan audit keamanan, serta menjalankan program bug bounty

Fitur cloud Arc dan penggunaan Firestore

  • Arc memerlukan akun untuk digunakan, dan terkonfirmasi memakai Firebase Authentication dalam proses pendaftaran
  • Pada pengamatan jaringan awal tidak terlihat permintaan lain, tetapi saat meneliti fitur berbagi Easels muncul indikasi penggunaan Firestore
  • Easels adalah antarmuka bergaya papan tulis yang dapat dilihat di web ketika dibagikan ke orang lain
  • Firestore adalah layanan database-as-a-backend yang memungkinkan pembuatan fitur tanpa backend terpisah, lewat aturan keamanan database dan akses langsung dari klien
  • Sebagai contoh lama aturan keamanan Firestore yang lemah, artikel ini merujuk ke Firewreck

Cara memverifikasi panggilan Firebase

  • Karena Swift SDK Firebase cenderung tidak mengikuti pengaturan proksi sistem, panggilan terkait dibuang dengan skrip Frida alih-alih mitmproxy
  • Skrip tersebut melakukan hooking pada panggilan Firestore di kelas Objective-C
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • metode eksekusi seperti getDocuments, addSnapshotListener:, getDocument
    • metode penulisan dokumen keluarga updateData, setData
  • Saat Arc berjalan, jenis path dan kueri Firestore berikut teramati
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • kueri inviter_id == {userID} di user_referrals
    • kueri creatorID == {userID} di boosts
  • Dalam struktur ini, Arc menyimpan sebagian pengaturan, objek pengguna dasar, informasi referral, dan Boosts di Firestore

Mengapa Boosts menjadi jalur serangan

  • Arc Boosts adalah fitur untuk mengustomisasi situs web
    • memblokir elemen
    • mengubah font
    • mengubah warna
    • CSS kustom
    • JavaScript kustom
  • Boosts disimpan di Firestore, dan browser Arc menentukan Boost mana yang harus diterapkan dengan melakukan kueri berdasarkan field creatorID
  • Penyerang membuat Boost untuk Google.com di akunnya sendiri lalu menguji dengan mengubah sebagian parameter dokumen Firestore
  • Karena kueri berdasarkan creatorID, Boost milik pengguna lain tidak bisa diambil langsung, tetapi penyerang dapat mengubah creatorID pada dokumen Boost miliknya sendiri menjadi ID pengguna akun lain
  • Saat diuji dengan akun lain, Boost buatan penyerang diterapkan di komputer korban ketika mengakses Google.com

Rantai serangan dan memperoleh ID pengguna

  • Alur serangan akhirnya adalah sebagai berikut
    • memperoleh ID pengguna korban
    • membuat Boost berbahaya berisi payload yang diinginkan di akun penyerang
    • mengubah field creatorID pada dokumen Boost menjadi ID korban
    • saat korban mengunjungi situs web target, Boost berbahaya dijalankan
  • Kerentanan ini terjadi karena Arc Boosts dapat memuat JavaScript arbitrer, disimpan di Firestore, dan target penerapannya ditentukan oleh field creatorID
  • Ada beberapa jalur untuk mendapatkan ID pengguna korban
    • user_referrals: bila seseorang mengundang atau direferensikan ke Arc, ID pengguna pihak lain bisa diperoleh dari tabel user_referrals
    • Boost publik: Boost tanpa JavaScript dapat dibagikan, dan boostSnapshots di situs publik Arc Boosts memuat ID pengguna pembuatnya
    • Easels: ID pengguna juga bisa didapat lewat fitur papan tulis yang dapat dibagikan ini

Patch dan jadwal pengungkapan

  • The Browser Company biasanya tidak menjalankan bug bounty, tetapi untuk kerentanan ini membayar $2,000 USD
  • Linimasa kerentanan adalah sebagai berikut
    • 25 Agustus 5:48pm: kontak pertama melalui Signal dengan Hursh, salah satu pendiri Arc
    • 25 Agustus 6:02pm: PoC kerentanan dijalankan pada akun Arc milik Hursh
    • 25 Agustus 6:13pm: detail dibagikan dalam format terenkripsi lalu ditambahkan ke kanal Slack
    • 26 Agustus 9:41pm: kerentanan ditambal dan hadiah dibayarkan
    • 6 September 7:49pm: CVE-2024-45489 ditetapkan
  • Setelah itu Arc memublikasikan tulisan mereka sendiri tentang masalah ini, CVE-2024-45489 incident response

Eksekusi pada halaman berprivileg dan benturan dengan privasi

  • Meski Boosts tidak dapat dibuat dari klien, Boosts tetap bisa dijalankan pada protokol lain
  • Jika Boost dibuat untuk halaman settings, ia dapat berjalan di chrome://settings dan berujung pada eskalasi hak akses
  • Saat mengunjungi situs, kueri Firestore berikut terjadi
    • melakukan kueri ke koleksi boosts dengan kondisi creatorID == {userID} dan hostPattern == "www.google.com";
  • Di sini hostPattern berarti situs yang dikunjungi, yang bertentangan dengan kebijakan privasi Arc yang menyatakan bahwa Arc tidak mengetahui situs apa yang dikunjungi pengguna

Tindak lanjut Arc

  • Arc, dengan mempertimbangkan kerentanan ini dan pengenalan fitur baru, beralih ke arah meninggalkan Firebase
  • Ringkasan internal Arc mencakup langkah-langkah berikut
    • verifikasi perbaikan masalah
    • menambahkan fitur untuk menonaktifkan Boosts dari sisi klien
    • audit internal atas aturan ACL Firebase saat ini
    • menyusun protokol penanganan isu keamanan
  • Langkah tambahan yang dibagikan dalam diskusi internal Arc adalah sebagai berikut
    • memperbaiki masalah privasi pada pembaruan v1.61.1
    • menghentikan penggunaan Firebase pada fitur dan produk baru
    • audit keamanan eksternal untuk versi tersebut
    • memulai program bug bounty untuk kerentanan di masa mendatang

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-20
Pendapat di Hacker News

  • Saya Hursh, salah satu pendiri sekaligus CTO The Browser Company yang membuat Arc. Tidak ada pengguna yang benar-benar terdampak dan kami langsung menambalnya, tetapi menurut saya tingkat keparahan potensial dari kerentanan ini sulit diterima
    Detail teknis, rencana perbaikan ke depan, rencana untuk beralih dari Firebase, serta menyiapkan program bug bounty resmi telah kami rangkum di sini: https://arc.net/blog/CVE-2024-45489-incident-response
    Kami benar-benar minta maaf, baik atas kerentanan itu sendiri maupun komunikasi yang terlambat. Masukan kalian—termasuk kekecewaan, kemarahan, dan dukungan—membuat kami merasa bertanggung jawab untuk menjadi lebih baik

    • Saya bertanya-tanya apakah tulisan ini memang hanya ditujukan untuk pengguna HN. Tulisan ini tidak terlihat di daftar blog (https://arc.net/blog) dan juga tidak diunggah ke Twitter
      Seluruh responsnya terlihat seperti baru bereaksi setelah masalahnya cukup ramai
    • Beberapa teman saya menyukai Arc sehingga saya sempat mempertimbangkan untuk pindah, tetapi sekarang saya tidak berniat memakainya. Bukan karena kerentanannya itu sendiri, melainkan karena mereka hanya membayar bug bounty $2k untuk bug yang bisa mengambil alih semua pengguna secara berbahaya
      Saya tidak ingin memakai browser buatan perusahaan yang memandang keamanan pengguna seringan ini. Saya tidak yakin, tetapi untuk tingkat keparahan seperti ini, kemungkinan besar nilainya jauh lebih mahal di pasar gelap
    • Ada kekhawatiran di komentar-komentar di bawah bahwa setiap kali halaman dimuat, URL dan ID pengguna yang dapat diidentifikasi dikirim ke TBC. Orang yang memakai browser selain Chrome umumnya kemungkinan juga cukup sensitif terhadap privasi, jadi sebaiknya bagian ini dijawab
      Kerentanan bisa saja terjadi, tetapi mengirim data penjelajahan tampak seperti pilihan desain yang disengaja
    • Setelah melihat kejadian ini, rasanya tidak ada cara untuk meyakinkan orang bahwa tim ini memiliki keahlian untuk memelihara sebuah browser. Terlepas dari fakta bahwa mereka telah memperbaikinya, baik sekarang maupun ke depan mereka tampak tidak punya kemampuan untuk membuat browser yang aman
      Menurut saya ini perkara yang seharusnya membuat CTO mengundurkan diri
    • Saya penasaran apakah ada rencana untuk menaikkan nilai bug bounty. $2.000 adalah jumlah yang sangat kecil dibanding nilai bug ini, dan saya berharap penemunya diberi imbalan yang layak
      Mereka pada dasarnya mendapat kesempatan emas untuk mengambil arah yang benar

  • Banyak komentar di sini menyalahkan Firebase, tetapi kelihatannya mereka hanya mengulang hal yang sebenarnya tidak terlalu mereka pahami. Saya tidak memakai Firebase, tetapi dari pengalaman pernah memakainya dulu, ini bukan kasus pinggiran dan bukan masalah yang sulit diselesaikan, melainkan hal yang paling mendasar
    Masalah sebenarnya adalah API dibuat untuk mempercayai nilai yang dikirim klien untuk memberi tahu “siapa saya”. Pada akhirnya ini kesalahan amatir, dan kemungkinan besar bisa diperbaiki dengan perubahan satu baris. Dari dokumentasinya saja, di https://firebase.google.com/docs/rules/rules-and-auth#cloud-..., request.auth memberikan ID pengguna yang diperlukan (request.auth.uid)

    • Sebagai orang yang mengoperasikan aplikasi yang dibuat dengan Firebase, saya setuju. Seperti yang ditunjukkan penulis, salah konfigurasi memang sangat mudah terjadi, tetapi praktik keamanan dasar seperti ini ditekankan dengan peringatan yang tebal dan mencolok di dokumentasi Firebase
      Aturan keamanan harus ditangani dengan serius, dan pada dasarnya merupakan satu-satunya garis pertahanan
    • Menarik melihat software engineer dulu membuat autentikasi sendiri, lalu bergerak ke arah tidak membuatnya sendiri, dan sekarang bahkan tidak menyadari masalah keamanan yang sejelas ini
      Entah membuat autentikasi sendiri atau tidak, intinya satu: jangan pernah percaya klien
    • Kalau “pada akhirnya ini kesalahan amatir”, itu malah masih mending. Rekan-rekan kerja saya juga beberapa kali melakukan kesalahan yang sama persis di aplikasi frontend internal
    • Rencana keamanan yang bergantung pada asumsi bahwa siapa pun tidak akan pernah melakukan kesalahan amatir itu sendiri adalah kesalahan amatir
    • Kalau saya memahaminya dengan benar, perbaikan untuk masalah ini kira-kira hanya memasukkan aturan berikut ke dalam pernyataan match di firestore.rules. Ini persis materi yang muncul di dokumentasi tingkat pengantar keamanan Firebase Firestore 
      
// 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

  • Saya sangat menyukai kucing pixel art kecil yang berlari ke tempat yang diklik. Itu adalah fitur kecil yang seru dan unik, yang sekarang jarang terlihat, dan terasa seperti pengingat bahwa internet juga bisa menjadi ruang menyenangkan seperti itu jika kita menginginkannya

    • Di sisi saya tidak terlihat, sepertinya pengembang menghormati prefers-reduced-motion sehingga tidak menampilkannya jika pengaturan itu aktif. Penanganan yang bagus: memberi kesenangan bagi yang menginginkannya dan mencegah gangguan bagi yang tidak suka
    • Untuk kucing berusia 35 tahun, gerakannya masih sangat bagus
      https://en.wikipedia.org/wiki/Neko_(software)
    • Di Debian, Anda bisa memasang dan menjalankan kucing dengan perintah berikut
      sudo apt install oneko
      oneko &
      Cocok sebagai hadiah di komputer rekan kerja yang sedang meninggalkan mejanya
    • Memang lucu, tetapi karena saya tahu kucing itu akan bergerak setiap kali saya menggerakkan mouse atau menggulir, saya jadi tidak bisa fokus membaca tulisannya. Saya membuka konsol dan menghapusnya. Maaf, kucing
    • Di ponsel, kucing itu terus menutupi teks sehingga saya mencari cara untuk menghilangkannya. Mode baca Firefox menyelesaikannya

  • Menurut tulisan ini, Arc mewajibkan akun, dan mengirim nama host dari setiap halaman yang dikunjungi beserta ID pengguna ke Google Firebase. Kalau begitu, bukankah Arc bisa dibilang menjadi browser dengan privasi paling lemah di antara browser yang dipakai saat ini?

    • Begitu tahu bahwa akun wajib tepat setelah instalasi, saya langsung menghapus Arc. Itu terlihat konyol seperti sikat gigi yang membutuhkan Wi-Fi, tetapi sekarang tampaknya lebih serius
    • Sepertinya gelar itu akan jatuh ke OperaGX
    • Saya juga penasaran seberapa rusaknya Arc kalau Firebase down
    • Saat mengunduhnya beberapa bulan lalu, saya melihat perlu akun untuk menggunakannya, dan insting saya mengatakan lebih baik tetap memakai Firefox saja
    • Apakah data yang dikirim ke Firebase tidak dienkripsi? Kalau itu data sensitif, Google pun pasti menyarankan untuk melakukannya

  • Bug yang benar-benar keren. Aturan keamanan layanan backend seperti Firebase punya default aneh yang sulit dijelaskan. Kalau membuat API sendiri, userId pada record seperti boost dalam kasus ini tidak akan diterima dari payload request, melainkan disetel ke ID pengguna dari sesi
    Developer pada level tertentu biasanya bahkan tidak terpikir untuk membuat rute API terlindungi yang membiarkan klien mengirim nilai yang diklaim sebagai userId miliknya sendiri. Sebaliknya, dalam aturan keamanan, kita harus membayangkan semua cara sistem bisa disalahgunakan, terlepas dari cara penggunaan yang benar-benar diprogram

    • Kalau pendekatannya seperti itu, jujur saja itu keliru. Mulai dari deny by default, maka yang perlu dibayangkan hanya cara penggunaan yang sah
    • Untuk insert memang benar, tetapi pada update saya sering melihat seluruh request langsung dimasukkan ke ORM atau document store. Mudah berpikir bahwa “pemilik boleh memperbarui dokumen”, tetapi mudah juga terlewat bahwa beberapa field yang tidak disetel oleh klien resmi—misalnya pemilik atau waktu pembuatan—tidak boleh berubah
      Solusi yang benar mungkin adalah memberi izin deny by default untuk semua field. Dengan begitu, setidaknya field pemilik harus secara eksplisit dibuat bisa ditulis, dan kita juga akan memikirkan dampak memindahkan objek ini ke pengguna lain

  • Saya terkejut betapa konyol dan bodohnya kerentanan ini. Untuk melakukan eksekusi kode arbitrer, secara harfiah cukup mengirim ID pengguna orang lain, dan ID itu juga cukup mudah didapat
    Saya bukan bekerja di FAANG, dan saya bekerja di perusahaan yang membuat produk buruk yang sebenarnya tidak diperlukan, tetapi bahkan saya tidak akan membuat bug seperti ini. Lalu orang-orang ini mau membuat browser, sekaligus menanggung keahlian keamanan dan tanggung jawab moral yang menyertainya?

    • Bisa jelaskan bagaimana cara mendapatkan ID pengguna orang lain? Saya tahu ini kerentanan besar, tetapi ingin memahami bagaimana bagian itu bisa terjadi

  • Akan lebih baik jika judul postingan memasukkan Arc, supaya orang yang memakai Arc atau punya kenalan pengguna Arc bisa lebih mudah mengenalinya

    • Sangat setuju. Saat pertama kali melihatnya kemarin, saya tidak menyadari ini relevan bagi saya, dan baru mengklik setelah judulnya diubah
      Jujur saja, saya sangat merasa judulnya seharusnya seperti “Bug fundamental pada browser Arc (CVE 123-4567)”

  • Di dunia ini ada banyak kerentanan keamanan serius yang dibuat dengan alasan yang masih bisa dipahami, dan bisa dimaafkan jika ditangani serta diperbaiki secara bertanggung jawab
    Namun ini bukan kasus seperti itu. Secara pribadi, ini menunjukkan ketidakmampuan yang cukup untuk merusak reputasi, sampai membuat saya memutuskan tidak akan pernah memakai Arc lagi

    • Di sisi lain, kecepatan responsnya sendiri cukup mengesankan
      aug 25 5:48pm: Kontak awal dengan Hursh, salah satu pendiri Arc, melalui kanal terenkripsi Signal
      aug 25 6:02pm: Proof of concept kerentanan dijalankan pada akun Arc milik Hursh
      aug 25 6:13pm: Detail diungkap dalam bentuk terenkripsi lalu ditambahkan ke kanal Slack
      aug 26 9:41pm: Kerentanan ditambal, bounty dibayarkan
      sep 6 7:49pm: CVE diberikan (CVE-2024-45489)
      Empat jam dari kontak awal yang mendadak sampai perbaikan dirilis itu cukup bagus, meski mempertimbangkan kemungkinan perbaikannya sederhana. Koreksi: karena tanggalnya berganti, sebenarnya 28 jam. Tetap lumayan, dan respons “masuklah ke kanal Slack kami” hanya 30 menit setelah kontak awal itu sangat cepat
    • Fakta bahwa bahkan untuk mencoba Arc sekali pun diperlukan akun wajib sudah menjadi tanda bahaya besar sejak awal, jadi saya sama sekali tidak mencobanya. Sekarang saya senang tidak memakainya
    • Jujur saja, saya selalu melihat Arc seperti serigala berbulu domba, terutama dari sisi privasi
      Untuk produk sepenting dan sepersonal browser, mendapatkan dana tunai 50–60 juta dolar dan valuasi 500 juta dolar tetapi tidak punya model bisnis adalah tanda bahaya besar. Ini bukan kegiatan amal, jadi seseorang pada akhirnya akan membayar biayanya dengan satu cara atau lainnya
    • Kalau sebuah perusahaan mendistribusikan browser, orang cenderung mengira mereka akan sedikit lebih memperhatikan aturan keamanan
      Sayang juga Firebase tidak bisa membuat ini lebih idiot-proof. Dan sungguh hanya $2,500? Secara harfiah semua pengguna Arc bisa diambil alih; kalau NSA, mereka pasti menambahkan beberapa nol lagi
    • Ditambah lagi Firebase, serius? Perusahaan yang bahkan mempekerjakan engineer perangkat lunak level rendah memakai backend CRUD kotak jadi. Mungkin efisien dari sisi biaya, tetapi kalau saya merancang hal seperti ini, Firebase bahkan tidak akan masuk daftar panjang kandidat backend
      Apalagi pesaing fungsional seperti Supabase membungkus DBMS umum dan model autentikasi

  • Terima kasih sudah membagikan. Saya sudah memakai Arc sejak minggu pertama beta
    Namun fakta bahwa bug dan perbaikannya tidak disebutkan di mana pun di media sosial cukup mengkhawatirkan. Saya menikmati waktu memakai Arc, tetapi melihat cara penanganan seperti ini, rasanya saya tidak bisa terus menggunakannya

    • Bukankah mengakui masalahnya dan memperbaikinya dalam 28 jam sudah cukup? Dengan respons seperti itu, saya malah merasa masih bisa terus memakai Arc

  • $2,000 untuk kerentanan sebesar ini adalah jumlah yang menghina

    • Dari tulisan-tulisan blog di HN, tampaknya kerentanan seperti ini sering kali tidak mendapat imbalan sama sekali atau hanya menerima jumlah yang sangat kecil. Sampai-sampai terlihat seperti perusahaan memohon agar hacker menjual exploit-nya
      Mungkin karena mereka tidak dihukum regulator atas insiden pelanggaran
    • Benar, itu juga reaksi pertama saya. Saya benar-benar terkejut mereka bisa sepelit itu
    • Perlu hati nurani yang cukup kuat untuk tidak menjualnya ke pihak jahat yang bersedia membayar 20–50 kali lipat dari jumlah ini