Kerentanan Kebocoran Email Pengguna YouTube Mendapat Imbalan $10.000

 (brutecat.com)
1 poin oleh GN⁺ 2025-02-13 | 1 komentar | Bagikan ke WhatsApp
  • obfuscated Gaia ID, pengenal akun Google internal untuk channel YouTube, terekspos dan dapat dikaitkan dengan alamat email melalui API berbagi Pixel Recorder, sehingga menjadi masalah privasi akun Google
  • Permintaan Innertube dari menu blokir live chat mengembalikan parameter moderateLiveChatEndpoint yang berisi Gaia ID channel target, bahkan tanpa benar-benar melakukan pemblokiran
  • Dengan mengganti channel ID pada parameter permintaan, target meluas hingga Topic Channel yang tidak memiliki pesan live chat, sehingga masalah ini tidak terbatas pada peserta tertentu
  • WriteShareList milik Pixel Recorder menerima obfuscated Gaia ID dari target berbagi dan menyertakan alamat email dalam respons; pengiriman email notifikasi juga dapat dicegah dengan judul rekaman sepanjang 2,5 juta karakter
  • Google menerima laporan pada 15 September 2024, lalu mengonfirmasi perbaikan dua kerentanan pada 9 Februari 2025, dan membayar total imbalan $10.633

Gaia ID yang Terungkap dari Fitur Blokir YouTube

  • Dari dokumen discovery staging Internal People API milik Google, diketahui bahwa objek BlockedTarget menggunakan obfuscated Gaia ID dan fallbackName
    • profileId adalah obfuscated Gaia ID pengguna yang diblokir
    • fallbackName adalah nama tampilan pengguna yang diblokir
  • Bantuan akun Google menyebutkan bahwa akun dapat diblokir di YouTube, dan ketika pengguna benar-benar diblokir di live stream YouTube, pengguna tersebut muncul di myaccount.google.com/blocklist
  • Di daftar blokir, nama channel Mega Prime ditampilkan sebagai fallbackName, dan 107183641464576740691 sebagai profile ID
  • Dengan asumsi bahwa channel YouTube tidak semestinya mengekspos akun Google dasarnya, dan karena sebelumnya pernah ada bug yang mengubah Gaia ID menjadi alamat email, pencarian jalur tambahan pun dimulai

Dari Menu Live Chat ke Seluruh Channel

  • Di live chat YouTube, sekadar membuka menu tiga titik sudah memicu permintaan /youtubei/v1/live_chat/get_item_context_menu
  • Responsnya berisi moderateLiveChatEndpoint yang mengarah ke /youtubei/v1/live_chat/moderate serta nilai params
  • params tersebut adalah protobuf berenkode base64 yang umum digunakan Google, dan setelah didekode, di dalamnya terdapat Gaia ID pengguna yang akan diblokir
    • Contoh respons berisi 113907466537670370590 dan pengenal terkait channel
    • Gaia ID target dapat diperoleh tanpa benar-benar melakukan pemblokiran
  • Saat parameter permintaan get_item_context_menu didekode, di dalamnya terdapat channel ID channel yang hendak diblokir, ID video live stream, dan ID pembuat live stream
  • Hasil pengujian dengan mengganti channel ID di dalam parameter permintaan ke nilai lain menunjukkan bahwa Gaia ID 103261974221829892167 milik Topic Channel yang dibuat otomatis oleh YouTube juga dapat diperoleh

Pixel Recorder Menjadi Jalur Konversi ke Email

  • Saat mencari bug atau cacat logika pada produk Google lama yang dapat mengubah Gaia ID menjadi email, Pixel Recorder](https://recorder.google.com/) diselidiki bersama nathan
  • Setelah membuat rekaman uji di ponsel Pixel dan menyinkronkannya ke akun Google, endpoint web recorder.google.com digunakan
  • Saat membagikan rekaman ke email uji, permintaan WriteShareList menyertakan obfuscated Gaia ID dalam daftar target berbagi
  • Respons PlaybackService/WriteShareList dari pixelrecorder-pa.clients6.google.com mengembalikan alamat email target berbagi tersebut
    • Respons uji berisi vrptest2@gmail.com
    • Saat memasukkan Gaia ID 107183641464576740691 yang diperoleh dari eksperimen pemblokiran YouTube, redacted@gmail.com juga dikembalikan
  • Dengan demikian, rantai serangan yang memasukkan Gaia ID dari YouTube ke API berbagi Pixel Recorder untuk mengetahui alamat email menjadi mungkin

Judul Rekaman 2,5 Juta Karakter yang Menghentikan Email Notifikasi

  • Jika rekaman di Pixel Recorder dibagikan kepada korban, korban akan menerima email notifikasi, sehingga dampak serangan dapat berkurang
  • Popup berbagi tidak memiliki opsi untuk mematikan notifikasi, dan analisis protobuf permintaan dengan req2proto juga tidak menemukan field untuk menonaktifkan notifikasi
  • Struktur WriteShareListRequest memiliki field berikut
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Email tetap dikirim meskipun pengguna ditambahkan dan dihapus secara bersamaan
  • Karena judul rekaman disertakan dalam subjek email notifikasi, diasumsikan bahwa membuat judul rekaman sangat panjang dapat menyebabkan pengiriman email gagal
  • Skrip Python dibuat untuk mengubah judul rekaman menjadi 2,5 juta karakter melalui endpoint UpdateRecordingTitle, lalu diuji; tidak ada batas panjang judul di sisi server
  • Setelah judul ditetapkan menjadi 2,5 juta karakter lalu dibagikan ke pengguna uji lain, email notifikasi tidak terkirim

PoC Akhir dan Jadwal Penanganan

  • Rantai serangan yang selesai terdiri dari tiga langkah
    • Mendapatkan obfuscated Gaia ID channel target dari endpoint YouTube Innertube /get_item_context_menu
    • Membagikan rekaman Pixel Recorder dengan judul sangat panjang kepada target untuk mengubah Gaia ID menjadi alamat email
    • Menghapus pengguna tersebut dari target berbagi rekaman Pixel Recorder untuk membersihkan jejak
  • Video PoC tersedia sebagai video YouTube

Imbalan Google dan Timeline Perbaikan

  • 2024-09-15: Laporan dikirim ke vendor
  • 2024-09-16: Vendor melakukan triage terhadap laporan dan memberi respons Nice catch!
  • 2024-10-03: Panel menandainya sebagai duplikat dari bug pelacakan yang sudah ada, dan menerapkan patch tidak lengkap untuk kebocoran awal obfuscated Gaia ID YouTube
  • 2024-10-03: Dijelaskan kembali kepada vendor bahwa Pixel Recorder sendiri juga merupakan kerentanan
    • obfuscated Gaia ID juga dapat terekspos dari reviewer Google Maps dan Google Play
    • Metode bypass untuk membocorkan kembali obfuscated Gaia ID channel YouTube juga diberikan
  • 2024-11-05: Panel membayar imbalan $3.133
    • Dasarnya adalah tingkat kemungkinan eksploitasi sedang
    • Diklasifikasikan sebagai high-impact abuse-related methodology
  • 2024-12-03: Tim produk mengirim kembali laporan ke panel untuk peninjauan imbalan tambahan, dan jadwal publikasi 2025-02-03 dikoordinasikan
  • 2024-12-12: Panel membayar imbalan tambahan $7.500
    • Dasarnya adalah tingkat kemungkinan eksploitasi tinggi
    • Diklasifikasikan sebagai high-impact abuse-related methodology
    • Karena kompleksitas rantai serangan, jumlah dasar diturunkan satu tingkat
  • 2025-01-29: Vendor meminta jadwal publikasi diperpanjang ke 2025-02-02
  • 2025-02-09: Dikonfirmasi bahwa kedua bagian rantai serangan telah diperbaiki
    • Saat itu 147 hari sejak laporan pertama
  • 2025-02-12: Laporan dipublikasikan

Bacaan terkait

1 komentar

 
GN⁺ 2025-02-13
Pendapat di Hacker News

  • Judulnya membingungkan. Untuk yang belum membaca sampai akhir: bukan berarti biaya timbul karena email yang bocor, melainkan mereka menghabiskan waktu dan kecerdikan, lalu menerima bug bounty sebesar 10.000 dolar

    • Awalnya saya kira maksudnya mereka menawarkan layanan untuk membocorkan email pengguna seharga 10.000 dolar per pengguna
    • Saya juga mengira maksudnya layanan seharga 10.000 dolar
    • Bisa jadi judulnya memang dibuat untuk memancing klik
    • Awalnya saya kira ini soal biaya komputasi untuk melakukan brute force terhadap semacam hash

  • Ada banyak riuh soal pengungkapan yang bertanggung jawab, motivasi, dan imbalan, tetapi jarang terlihat pembahasan bahwa ini adalah satu lagi argumen yang menentang identitas permanen yang tersentralisasi
    Setiap kali sebuah layanan mengklaim bahwa layanannya bekerja paling baik ketika hanya terhubung ke satu Real Identity™, saya merasa perusahaan-perusahaan itu hanya punya kepedulian abstrak untuk benar-benar melindungi pengguna, itu pun hanya sesekali
    Bayangkan siapa pun yang berinteraksi di YouTube bisa seketika beberapa langkah lebih dekat untuk melakukan doxing; menurut saya itulah dampak nyata bug ini. Syukurlah sudah diperbaiki, tetapi rasanya bug semacam ini tidak akan segera hilang. Apa yang diperlukan agar perusahaan dan korporasi besar menyadari bahwa desain seperti ini adalah ladang ranjau yang tinggal menunggu meledak?

    • Secara abstrak saya setuju. Akun seperti ini seharusnya diberi tingkat anonimitas dan kemampuan untuk dibuang tertentu. Toh pada akhirnya itu hanya satu baris di suatu database
      Namun banyak orang bertransaksi dengan perusahaan-perusahaan ini memakai uang sungguhan. Misalnya pelanggan YouTube Premium atau pembuat konten. Dalam praktiknya, di suatu tempat pada akun yang bisa dibuang itu tetap harus tersimpan pengenal identitas dunia nyata. Karena risiko penipuan dan realitas urusan perbankan, kita menyerahkan identitas dan alamat asli kepada perusahaan, dan perusahaan pun menyimpannya
      Saya tidak memberikan informasi yang dapat mengidentifikasi diri ke aplikasi atau situs web sembarangan, tetapi pihak yang bertransaksi dengan saya mau tidak mau mengetahui diri saya di dunia nyata, dan secara teori menjadi titik tempat data itu bisa bocor
    • Karena tidak ada konsekuensi hukum, mereka tidak peduli
      Kalau penyedia layanan kesehatan membocorkan data medis, mereka akan benar-benar hancur

  • Lucu juga: “Ini POC exploit yang berfungsi: video ini telah dihapus karena melanggar Ketentuan Layanan YouTube”

    • Penulis asli mengungkap alamat email pengguna yang benar-benar ada untuk bukti konsep. Pada video yang diunggah ulang, alamat emailnya diburamkan
    • Awalnya bagi saya juga terlihat begitu, tetapi ketika saya membuka tulisannya lagi, sepertinya videonya terlihat. Entah apakah baru saja dipulihkan

  • Karena setiap komentar ketiga di utas ini mengatakan bahwa Google memberi terlalu sedikit untuk bug ini, berikut pembahasan dasar tentang valuasi nilai kerentanan
    Kerentanan sisi server bernilai rendah karena para vendor tidak saling bersaing. Praktis tidak ada pasar abu-abu untuk kerentanan sisi server. Sulit bagi pihak ketiga untuk memberi harga pada bug yang bisa segera dimatikan oleh Google, yang hampir tidak punya waktu paruh sejak ditemukan, dan yang jika dieksploitasi akan menghasilkan telemetri yang dapat dipercaya di sisi target
    Sebaliknya, bug seperti full chain Android/Chrome bisa terjual ratusan ribu dolar karena Google bersaing dengan pasar abu-abu yang sudah terbentuk dengan baik. Satu vendor bisa mengambil bug itu lalu menjualnya ke beberapa lembaga di satu negara Eropa, mungkin sampai 6 pihak
    Meski begitu, bounty dan pasar abu-abu adalah perbandingan apel dan jeruk. Google hanya butuh bukti bahwa exploit bisa dibuat, bukan exploit yang sangat andal, dan tidak perlu biaya pemeliharaan, sehingga mereka membayar jauh lebih sedikit daripada pasar abu-abu. Total nilai pasar lainnya terbagi dalam beberapa tahap dan disertai syarat risiko, tetapi Google bisa menawarkan pembayaran sekali bayar yang menarik meski sudah didiskon
    Penyerang membeli kerentanan yang sesuai dengan proses bisnis yang sudah ada. Umumnya mereka tidak berspekulasi membayangkan hal-hal keren yang bisa dilakukan dengan suatu kerentanan baru dan cara menghasilkan uang darinya. Mengumpulkan informasi pembayaran, memperoleh ribuan mesin untuk botnet adalah proses bisnis yang sudah ada. Apakah pengungkapan nama asli akun Google bisa menjadi bisnis? Mungkin saja. Apakah sudah ada? Mungkin belum
    Besaran bounty biasanya bukan referendum publik tentang seberapa cerdik atau menarik sebuah bug. Namun di sini sedikit demikian juga, karena 10 ribu dolar untuk bug web sisi server terasa luar biasa tinggi
    Bagi orang yang mencari nafkah dengan menemukan bug seperti ini, strategi bisnisnya adalah menjadi mahir menemukan banyak bug. Berbeda dengan pengembangan exploit iOS yang menghabiskan berbulan-bulan untuk satu exploit yang andal
    Riset kerentanan yang saya lakukan dalam karier belakangan ini lebih mirip bidang ini dibanding banyak pekerjaan lain, jadi saya cukup yakin. Namun di HN ada orang yang mengerjakan bounty seperti ini penuh waktu, jadi saya senang jika mereka mengoreksi

    • Di sebagian besar bidang lain, orang tidak diberi imbalan berdasarkan nilai pasar gelap dari barang yang mereka buat
      Jika analisis ini diterapkan ke hal lain, batas atas harga car audio atau sepeda baru akan menjadi sekitar 100 dolar, dan harga semua barang berhak cipta akan dibatasi oleh biaya pengirimannya lewat jaringan
      Menurut saya lebih berguna membagi jumlah yang dibayar Google dengan waktu yang dihabiskan untuk pekerjaan ini serta seluruh waktu percobaan exploit yang gagal sejak bounty terakhir
      Saya menduga mayoritas orang di bidang ini menghasilkan lebih sedikit daripada upah minimum AS dibanding usaha yang dikeluarkan, sambil menanggung opportunity cost enam digit per tahun
      Angka itu menunjukkan secara akurat seberapa besar Google menghargai keamanan dan privasi pengguna akhir. Angkanya jauh lebih rendah daripada yang mereka bayarkan, beberapa orde lebih besar, kepada engineer lain untuk mencuri informasi pribadi orang-orang yang sama
    • Saya tidak suka utas HN ini sebagian besar membahas nominal bounty, tetapi itu juga wajar. Kebanyakan orang yang berkomentar di sini bekerja di industri perangkat lunak dan ingin menormalkan bounty yang sangat tinggi
      Karena bagi mereka itu adalah sumber penghasilan tambahan. Sama seperti software engineer ingin profesinya bergaji tinggi, mereka juga ingin bug bounty menjadi tinggi. Wajar bagi pekerja untuk menuntut upah yang lebih besar bagi profesinya, dan rasionalisasi apa pun tidak akan mengubah naluri itu
    • Katanya “penyerang membeli kerentanan yang sesuai dengan proses bisnis yang sudah ada”, tetapi bukankah ada pasar juga untuk hal seperti ini? Misalnya, “mari ungkap siapa orang di balik akun yang mengkritik perusahaan/pemerintah mencurigakan kita ini, lalu lumpuhkan dia”
      Ada juga insentif yang terpisah dari nilai pasar bagi penyerang. Orang kekerasan yang menguntit selebritas online mungkin bukan pelanggan yang menguntungkan di pasar exploit zero-day semacam ini, tetapi jika perusahaan secara ceroboh dapat mengekspos identitas target kepada stalker yang kejam, kerentanan itu tetap merupakan liabilitas dan risiko etis
      Secara pribadi, jika perusahaan membayar mahal para seniman performa LeetCode yang menghasilkan kode dalam jumlah sangat besar sambil memberi perhatian tidak sempurna pada keamanan, saya rasa mereka juga harus membayar dengan baik orang-orang yang membantu menemukan dan memperbaiki banyak kesalahan mereka sebelum hal buruk terjadi
    • Eksploitasi bug sisi server oleh aparat penegak hukum jauh lebih berada di area abu-abu, atau mungkin benar-benar ilegal. Sebaliknya, prosedur standar untuk mendapatkan perintah pengadilan agar bisa mengeksploitasi perangkat target tertentu, yaitu ponsel atau laptop, sudah ada bagi aparat penegak hukum maupun badan intelijen

  • Katanya “diturunkan satu tingkat dari nominal dasar karena kompleksitas rantai serangan yang diperlukan”; apakah ini umum?
    Saya hanya pernah berpartisipasi dalam beberapa program kerentanan, tetapi kebanyakan justru memberi imbalan lebih kecil untuk cacat yang sangat sederhana tetapi serius seperti email pengguna yang muncul di source halaman

    • Sebaliknya, saya memahaminya sebagai pengurangan karena ini relatif kompleks untuk ukuran kerentanan web
    • Ini terasa terbalik. Pada dasarnya ia menemukan 2 bug, jadi seharusnya dinaikkan dari nominal dasar

  • Katanya “beberapa waktu lalu, saat mencari target riset di Google, saya menggali dokumen discovery Internal People API (Staging)”; apakah ini memang boleh tersedia publik begitu saja: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Itu hanya file skema yang otomatis dikonversi dari definisi .proto internal. Google tidak bergantung pada security by obscurity, melainkan pada kriptografi yang nyata
      Selain itu, endpoint discovery didokumentasikan secara publik[0] dan dibuat untuk pengguna eksternal. Orang internal tidak membaca endpoint discovery, melainkan langsung melihat file .proto lewat pencarian kode
      Berdasarkan pengalaman bekerja di Google, untuk mengekspos API ke publik harus berurusan dengan birokrasi selama berminggu-minggu. Ini bukan seperti bucket AWS S3 yang kebetulan terbuka. Timnya tahu bahwa ini publik, dan kemungkinan telah menembus birokrasi untuk mempublikasikannya
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Jika melihat lini masa tulisan tersebut, laporan dikirim ke vendor pada 2024-09-15, lalu pada 2025-01-29 vendor meminta perpanjangan publikasi hingga 2025-02-12, pada 2025-02-09 dikonfirmasi bahwa kedua sisi eksploit sudah diperbaiki, dan pada 2025-02-12 dipublikasikan.
    Jadi bukankah selama 136 hari belum diperbaiki dan Google meminta perpanjangan? Sampai perbaikan 147 hari, sampai publikasi 150 hari.
    Jika dibandingkan dengan tenggat publikasi sebelum perbaikan yang diberikan Google Project Zero kepada perusahaan lain, mereka mengatakan, “Bug ini tunduk pada tenggat publikasi 90 hari. Jika perbaikan tersedia bagi pengguna sebelum tenggat 90 hari, laporan bug ini akan dipublikasikan 30 hari setelah perbaikan tersedia. Jika tidak, akan dipublikasikan saat tenggat.”
    “Jika patch diperkirakan akan keluar dalam 14 hari setelah tenggat berakhir, Project Zero dapat memberikan perpanjangan… Namun, masa tenggang 14 hari tumpang tindih dengan periode penerapan patch 30 hari, sehingga kerentanan yang diperbaiki dalam masa tenggang pun akan dipublikasikan selambat-lambatnya pada hari ke-120 sejak tenggat 90 hari semula.”
    “Jika dinilai perbaikan tidak akan siap dalam 14 hari, tenggat 90 hari semula digunakan sebagai waktu publikasi. Dengan kata lain, perpanjangan tenggang 14 hari hanya diberikan ketika developer berjanji akan merilis perbaikan dalam masa tenggang 14 hari.”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Saya tidak melihat perbandingan ini berguna. Ini bug Google pada software Google, sedangkan yang biasanya ditemukan Project Zero adalah bug pada software yang dipakai banyak orang, jadi saya memahami urgensi perbaikannya lebih tinggi.

  • Katanya, “params itu hanya protobuf yang di-encode dengan base64, dan itu format encoding yang umum dipakai di seluruh Google.” Kita perlu menuangkan segelas untuk developer Google yang bertanggung jawab menjejalkan format pesan biner keren yang di-encode base64 ke dalam gumpalan JSON.
    Kalau ingin melihat masa depan, bayangkan sebuah sepatu bot dengan tulisan “worse is better” di solnya menginjak wajah engineer selamanya.

    • Ini ada di mana-mana dan parah sekali. Kadang saya berpikir jangan-jangan jumlah byte protobuf yang direpresentasikan sebagai base64 di dalam JSON lebih banyak daripada byte protobuf sebenarnya yang melintas di atas jalur internet, lalu saya menuangkan segelas untuk diri sendiri.
    • Secara internal, mungkin itu adalah protobuf base64 di dalam field protobuf.
      Bagian JSON adalah konversi otomatis.
    • String JSON berisi protocol buffer yang di-encode base64; entah perusahaan mana yang melakukannya, tapi kita tahu perusahaan mana yang melakukannya.

  • Puncaknya adalah mereka merusak sistem email sehingga email tidak terkirim. Di perusahaan raksasa seperti Google yang membuat begitu banyak produk, keamanan terasa seperti pura-pura.
    Jika setiap baris kode adalah potensi kerentanan, maka pada jutaan baris kode itu bukan lagi kemungkinan, melainkan keniscayaan. Rasanya tidak ada cara selain menjaganya tetap sederhana, misalnya mematikan situs recorder, tetapi itu pun tidak mudah.

    • Ini mungkin alasan lain Google mematikan banyak produk yang memang berhasil, tetapi tidak cukup berhasil untuk terus dihidupkan dan dijaga tetap aman di keseluruhan sistem Google.
    • Sayangnya, mengingat jumlah pengguna Google, setiap penghentian akan memicu jeritan kesakitan dan penolakan semacam “saya bergantung pada tombol spasi untuk menghangatkan komputer.” Lihat https://killedbygoogle.com/.
    • Saya ingin meminta contoh keamanan yang terasa “nyata”, dan bagaimana itu membantu.
      Sebagian besar produk software bergantung pada software stack yang sangat kompleks, dan menurut saya mempercayai 100% semua library serta sistem operasi yang digunakan adalah pola pikir yang keliru. Prosesor pun pernah punya bug seperti Meltdown. Keamanan adalah pertarungan berkelanjutan; kita tidak pernah tahu apakah sudah menang, dan hanya sesekali tahu ketika kalah.
    • Pada dasarnya, Anda sedang mengusulkan semacam persamaan Drake[1] yang menghitung jumlah kerentanan keamanan berdasarkan jumlah baris kode. Faktor apa lagi yang akan masuk ke persamaan itu?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • Intinya adalah keamanan itu palsu. Tidak ada aplikasi yang benar-benar aman. Meski menghabiskan jutaan dolar untuk keamanan aplikasi, satu kesalahan dari satu pengguna manusia saja bisa menjebolnya.

  • Saya juga salah mengira judulnya berarti semacam biaya komputasi GPU 10 ribu dolar. Melihat mereka memilih satu produk Google lama lalu langsung menemukan celah, rasanya masih ada puluhan atau ratusan bug seperti ini.

    • Cara kerjanya bukan seperti “memilih satu produk Google lama lalu langsung menemukan celah.” Kemungkinan besar penulis mengulik berbagai produk selama beberapa minggu atau bulan sampai menemukan sesuatu yang bernilai.
    • Saya juga salah mengira maksudnya adalah menjual alamat email YouTuber seharga 10 ribu dolar.