iLeakage: Serangan Eksekusi Spekulatif Berbasis Browser Tanpa Timer terhadap Perangkat Apple

 (ileakage.com)
1 poin oleh GN⁺ 2023-10-26 | 1 komentar | Bagikan ke WhatsApp
  • Meskipun mitigasi Spectre telah berlanjut selama sekitar 6 tahun, iLeakage menunjukkan bahwa side channel eksekusi spekulatif masih dapat dieksploitasi di Safari pada Mac, iPad, dan iPhone
  • Penyerang dapat membujuk pengguna agar mengunjungi dan mengeklik halaman web berbahaya, lalu menggunakan JavaScript dan WebAssembly untuk membuat Safari merender halaman web arbitrer dan memulihkan informasi sensitif
  • Demonstrasi mencakup pemulihan judul pesan terbaru Gmail, kredensial autofill Instagram, riwayat tontonan YouTube, serta kata sandi Facebook dan token SMS 2FA pada MacBook Pro berbasis Apple M3
  • Cakupan dampaknya meliputi perangkat macOS dan iOS yang menggunakan CPU A-series dan M-series milik Apple, dan telah dimitigasi pada iOS 17.2 serta macOS 14.2 yang menyertakan Safari 17.2
  • Lockdown Mode atau menonaktifkan JavaScript juga dapat mencegahnya, tetapi ada keterbatasan fungsi, dan karena berjalan di dalam Safari serta tidak meninggalkan jejak di log sistem, pendeteksiannya sangat sulit

Risiko Spectre kembali muncul pada perangkat Apple

  • iLeakage adalah serangan side channel eksekusi spekulatif yang menargetkan browser web Safari
  • Targetnya adalah perangkat macOS dan iOS yang menggunakan CPU A-series atau M-series milik Apple
    • Termasuk iPhone dan iPad terbaru
    • Juga termasuk laptop dan desktop Apple sejak 2020
  • Pada dasarnya, kode dalam satu tab browser seharusnya tidak bisa menyimpulkan isi tab lain, tetapi iLeakage dapat membaca isi halaman web target milik pengguna yang telah mengunjungi dan mengeklik halaman milik penyerang
  • Informasi yang dapat dipulihkan dapat mencakup data pribadi, kata sandi, dan informasi kartu kredit
  • Tim peneliti mengungkapkan temuan ini kepada Apple pada 12 September 2022, yaitu 408 hari sebelum rilis publik

Data sensitif yang benar-benar berhasil dipulihkan

  • Tim peneliti mendemonstrasikan pemulihan informasi bernilai tinggi dari layanan-layanan populer

  • Kredensial Instagram

    • Menggunakan skenario pengguna masuk ke Instagram di Safari macOS dengan LastPass sebagai pengelola kredensial autofill

  • Kotak masuk Gmail

    • Di Safari iOS, dengan asumsi pengguna sedang login ke Google, mereka memulihkan judul pesan terbaru dari akun Gmail pada iPad

  • Riwayat tontonan YouTube

    • Memulihkan riwayat tontonan YouTube di Chrome untuk iOS
    • Chrome untuk iOS berfungsi sebagai shell di atas mesin perambanan Safari karena kebijakan Apple App Store

  • Kata sandi Facebook dan token 2FA

    • Mula-mula memulihkan kata sandi Facebook pada MacBook Pro dengan chip Apple M3, macOS 14.1.1, dan Safari 17.1
    • Setelah itu, mereka memulihkan token SMS 2FA yang dikirim ke ponsel Android melalui Google Messages

Cara kerja Spectre dan side channel

  • Sebagian besar CPU modern menggunakan eksekusi spekulatif, yaitu memprediksi jalur eksekusi dan memproses instruksi pada jalur tersebut lebih dulu ketika hasil percabangan belum langsung tersedia
  • Jika prediksinya salah, CPU membatalkan perubahan status, tetapi jejak dapat tetap tertinggal pada status mikroarsitektur seperti cache
  • Spectre adalah kerentanan perangkat keras yang memanfaatkan jejak ini untuk membaca data yang semestinya tidak dapat diakses menurut semantik program
  • Side channel dapat mengeksploitasi karakteristik implementasi sistem bahkan ketika program menjalankan algoritme yang aman
    • Contohnya termasuk suara, radiasi elektromagnetik, thermal throttling, dan berbagi sumber daya mikroarsitektur CPU
  • Jika penyerang dan target berjalan pada CPU yang sama, mereka berbagi sumber daya seperti core, cache, dan buffer internal, dan persaingan ini dapat diukur secara tidak langsung melalui variabel seperti waktu atau konsumsi daya

Rangkaian serangan tanpa timer yang melewati pertahanan Safari

  • Vendor browser telah memperkuat pertahanan terhadap serangan eksekusi spekulatif dan eksekusi sementara sejak Spectre
  • Pertahanan Safari mencakup 35-bit addressing, value poisoning, kebijakan isolasi proses per tab, dan timer beresolusi rendah
  • iLeakage adalah demonstrasi pertama serangan eksekusi spekulatif terhadap CPU Apple Silicon dan Safari
  • Serangan dimulai dengan memulihkan secara empiris konfigurasi cache yang tidak dipublikasikan dari CPU Apple
    • Setelah itu, peneliti membuat gadget berbasis spekulasi yang dapat membedakan cache hit dan miss hanya dengan timer beresolusi rendah
    • Mereka juga mendemonstrasikan varian yang memanfaatkan race condition tanpa timer
  • Gadget ini digunakan baik untuk pengujian pembuatan eviction set maupun untuk covert channel
  • Setelah tekniknya dipindahkan ke Safari, CPU dibuat menjalankan, selama eksekusi spekulatif, kode untuk tipe data tertentu pada objek bertipe salah yang dibuat penyerang
  • Hasil akhirnya adalah kemampuan melakukan out-of-bounds read di mana saja dalam ruang alamat proses rendering Safari
  • Dikombinasikan dengan metode baru untuk menggabungkan situs web dari domain berbeda ke dalam ruang alamat yang sama, serangan ini menjalankan speculative type confusion untuk membocorkan informasi sensitif

Mitigasi, kesulitan deteksi, dan dampak per browser

  • iLeakage telah dimitigasi di Safari 17.2, yang disertakan dalam iOS 17.2 dan macOS 14.2
    • Tindakan yang disarankan adalah memperbarui perangkat Apple ke versi OS terbaru
  • Lockdown Mode memitigasi iLeakage dengan menonaktifkan kompilasi JIT di Safari
    • Kompilasi JIT adalah fitur performa yang digunakan iLeakage untuk membangun primitif serangan
    • Lockdown Mode dapat mengubah perilaku perangkat, misalnya memblokir sebagian lampiran pesan dan panggilan FaceTime dari nomor yang tidak dikenal
    • Daftar lengkapnya ada di dokumentasi Lockdown Mode milik Apple
  • Menonaktifkan JavaScript juga mencegah iLeakage, tetapi Safari dapat merender sebagian situs secara salah atau tidak lengkap, dan fitur web tingkat lanjut seperti pembayaran online mungkin tidak berfungsi
  • Karena iLeakage berjalan di dalam Safari dan tidak meninggalkan jejak di file log sistem, pendeteksiannya sangat sulit
    • Namun, jejak kunjungan ke halaman web penyerang dapat tertinggal di cache browser untuk halaman yang baru dikunjungi
  • Tidak ada bukti eksploitasi nyata
    • Rangkaian serangan end-to-end sangat sulit dilakukan dan memerlukan pengetahuan tingkat lanjut tentang serangan side channel berbasis browser dan implementasi Safari
  • Pengelola kredensial tetap disarankan untuk terus digunakan
    • iLeakage dapat memulihkan kredensial yang di-autofill ke halaman web
    • Banyak platform mewajibkan interaksi pengguna agar autofill terjadi
  • Chrome, Firefox, dan Microsoft Edge di macOS menggunakan mesin JavaScript yang berbeda, sehingga iLeakage yang mengeksploitasi kekhususan mesin JavaScript Safari tidak berfungsi di sana
  • Di iOS, karena kebijakan Apple App Store dan sandboxing, aplikasi browser lain juga menggunakan mesin JavaScript Safari
    • Chrome, Firefox, dan Edge untuk iOS adalah wrapper di atas Safari yang menyediakan fungsi tambahan seperti sinkronisasi bookmark dan pengaturan
    • Hampir semua aplikasi browser di App Store rentan terhadap iLeakage
  • Makalah akademiknya tersedia sebagai makalah iLeakage dan dipublikasikan di 2023 ACM Conference on Computer and Communications Security

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-26
Komentar Hacker News

  • Sepertinya ada yang terlewat di FAQ ini: saya penasaran apakah ini kerentanan WebKit atau kerentanan Safari, apakah di Safari mobile—yang tidak punya pengaturan developer tersebut—ini bisa dimitigasi dengan mengaktifkan Lockdown Mode, dan kapan hal ini diungkapkan ke Apple
    Setelah itu halamannya diperbarui sehingga pertanyaan terakhir sudah terjawab; para peneliti mengatakan mereka mengungkapkan temuan ini kepada Apple pada 12 September 2022, yaitu 408 hari sebelum rilis publik

    • Secara teknis ini bisa dianggap sebagai Hacker News Favorite Processor, yaitu kerentanan M1/M2, tetapi semua CPU relevan yang ada di pasar saat ini memiliki kelemahan yang sama, sehingga ini sudah seperti fitur yang harus dirancang agar dimitigasi oleh perangkat lunak
      Menghapus semua gadget Spectre yang mungkin dari WebKit tidak realistis, jadi browser harus memanfaatkan mitigasi Spectre dari sistem operasi dengan cara mengisolasi situs web yang berbeda ke proses yang berbeda
      Karena FAQ mengatakan “pada akhirnya, ini mencapai pembacaan di luar batas di mana pun dalam ruang alamat proses rendering Safari”, secara pribadi saya melihatnya sebagai kerentanan akibat implementasi site isolation Safari yang keliru
    • Pertanyaan terakhir sudah dijawab di FAQ: para peneliti mengungkapkan hasilnya kepada Apple pada 12 September 2022, dan itu 408 hari sebelum rilis publik
    • Ini tampak seperti kerentanan arsitektur yang memungkinkan pemanfaatan side channel speculative execution mirip Spectre di dalam Safari atau browser lain
      Dalam lingkungan apa ia bisa dieksploitasi bergantung pada detail implementasi gadget berbasis JavaScript yang memicu dan mengukur side channel ini, dan mungkin ada di makalah yang belum saya baca
    • Sekarang FAQ sudah memuat jawabannya: ini adalah kerentanan Safari, dan disebutkan bahwa “iLeakage mengeksploitasi karakteristik mesin JavaScript Safari”
      Lockdown Mode memitigasinya karena menonaktifkan kompilasi JIT di Safari, sehingga memblokir fitur performa yang digunakan iLeakage untuk membuat primitive serangan

  • Untuk pertanyaan “apakah berbahaya memakai credential manager?”, sebagian besar jawabannya tidak, tetapi kalau ada sesuatu yang bocor dari memori, bukankah itu seharusnya berdampak pada semua memori di dalam ruang proses Safari?
    Saya tidak terlalu familier dengan bidang ini, jadi saya kurang paham mengapa penggunaan credential manager menjadi kondisi pengecualian

    • Pada dasarnya sepertinya yang mereka katakan begini: serangan spesifik ini tidak memberikan keamanan tambahan, tetapi memakai password manager secara umum lebih aman, dan juga tidak membuat Anda lebih rentan terhadap serangan ini
      Sepertinya mereka ingin menghindari orang kembali memakai pola seperti “newpassword2”, dan akan lebih aman jika mematikan autofill lalu mengisi lewat pintasan keyboard atau interaksi pengguna lain
    • Salah satu demonya memulihkan kombinasi ID/password untuk situs pihak ketiga seperti Instagram, karena password manager mengisi otomatis kolom sehingga datanya berada di memori
      Bisa saja dibaca seolah-olah Anda kebal jika tidak memakai password manager, tidak menyimpannya di browser, dan mengetiknya sendiri setiap kali, tetapi itu sanggahan yang buruk karena berbagai alasan
      Password manager bermanfaat karena banyak alasan lain, dan kalau sebuah password dicuri pun setidaknya hanya satu situs web yang terdampak
      Teknik ini mungkin juga bisa mencuri token sesi, yang meski tidak separah pencurian password tetap saja buruk
      Jika password manager diatur agar hanya mengisi setelah diklik, serangan ini juga bisa dicegah
    • Maksudnya tampaknya penggunaan password manager tidak membuat Anda lebih rentan
      Password yang diisi otomatis di halaman dapat dipulihkan seperti password yang diketik manual, tetapi semua password yang tersimpan di dalam password manager tidak bisa dibaca langsung
    • Saya memahami kerentanan ini hanya mengizinkan akses ke memori proses Safari/WebKit terkait, khususnya situs-situs yang dibuka melalui panggilan window.open
      Password yang tersimpan di aplikasi password manager terpisah tidak dapat diakses kecuali aplikasi itu mengisi otomatis ke jendela atau proses Safari yang sudah dikompromikan
    • Saya memahami bahwa Safari biasanya menempatkan origin dan ekstensi yang berbeda di ruang alamat yang berbeda, sehingga tidak rentan terhadap serangan speculative execution
      Serangan kali ini menemukan cara membuat dua origin berbeda berbagi ruang alamat yang sama, dan menurut saya tidak berlaku untuk ekstensi
      Makalahnya menyatakan, “kami menunjukkan teknik baru yang mengeksploitasi kebijakan site isolation Safari, sehingga halaman penyerang cukup membuka halaman korban mana pun dengan API JavaScript window.open untuk membuat keduanya berbagi ruang alamat”

  • Saya bingung apakah framing bahwa ini khusus WebKit benar-benar tepat. Penyalahgunaan cache itu sendiri tampak umum, dan kutipannya juga mengatakan bahwa akurasinya hampir sempurna di Safari, Firefox, dan Tor secara luas
    Selain itu, saya penasaran apakah serangan melalui window.open() benar-benar khusus WebKit, atau hanya karena penelitian ini mendalami WebKit saja
    window.open() mengisyaratkan konteks bersama, karena jendela pemanggil mendapat referensi ke jendela baru, dan jendela baru punya referensi balik melalui window.opener; saya juga bertanya-tanya apakah engine browser lain benar-benar mencapai isolasi penuh

    • Chromium dan Firefox menerapkan site isolation di browser desktop, sehingga halaman yang bukan dari situs yang sama seharusnya tidak dimuat dalam proses yang sama
      Di browser mobile, site isolation Chromium terbatas, dan Firefox belum selesai mengimplementasikannya
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • Membingungkan. Ini terlihat seperti isu dengan tingkat keparahan tinggi, tetapi perbaikannya ada di balik menu debug. Saya tidak mengerti kenapa ini dipublikasikan sebelum benar-benar diterapkan di semua tempat
    Ini juga menunjukkan bahwa mitigasi side-channel pada dasarnya tidak berguna dan kita tidak boleh berpura-pura serangan seperti ini sudah diperbaiki
    Pada host yang menjalankan beberapa aplikasi di CPU modern, menjalankan kode yang tidak tepercaya itu tidak aman, seketat apa pun sandbox-nya

    • Sepertinya Apple punya waktu lebih dari 400 hari untuk memperbaikinya, dan itu sudah lebih lama daripada waktu yang akan saya berikan
      Menurut saya jauh lebih baik memberi tahu pengguna Apple tentang risikonya daripada membiarkan mereka tidak tahu bahaya selama lebih dari setahun lagi
      Saya setuju perusahaan perlu diberi waktu untuk memperbaiki bug, tetapi pada titik tertentu, tidak memberi tahu orang-orang yang terdampak justru menjadi lebih tidak bertanggung jawab
    • Status mitigasinya juga membingungkan bagi saya, tetapi makalahnya lebih jelas daripada situs webnya
      Makalah tersebut menjelaskan bahwa speculative JavaScript sandbox escape masih mungkin dilakukan, tetapi penyerang dibatasi hanya bisa membaca ruang alamat dan data miliknya sendiri
      Disebutkan bahwa pada saat penulisan, patch Apple sudah tersedia untuk publik dan diimplementasikan di Safari Technology Preview 173 atau lebih baru, dan [57] adalah https://github.com/WebKit/WebKit/pull/10169
      Di bagian bawahnya, engineer terus menautkan patch hardening tambahan terkait window.open() dan isolasi proses
    • Saya kira di Safari 17.0 standar di Ventura, Swap Processes on Cross-Site Window Open sudah aktif dan ditandai Stable
      Saya tidak mengaktifkannya sendiri, jadi sempat berpikir mungkin Apple sudah mengaktifkannya dan deskripsinya sudah usang, tetapi belakangan saya sadar yang saya lihat adalah Swap Processes on Cross-Site Navigation yang namanya mirip, dan sepertinya saat ini belum aktif secara default
    • Itu karena Apple, yang disebut sebagai “benteng terakhir privasi dan keamanan”, menahan ini selama lebih dari 400 hari tetapi tetap tidak memperbaikinya
      Yang harus disalahkan bukan para peneliti yang mempublikasikannya sebelum perbaikan dirilis, melainkan Apple yang berdiam diri selama itu
    • Perbaikan ini kemungkinan masih berada di balik menu debug karena harus mengubah model proses WebKit, jadi masih dalam pengujian sebelum diluncurkan sepenuhnya
      Tidak semua serangan side-channel telah diperbaiki, tetapi mengatakan mitigasi side-channel tidak berguna itu tidak tepat
      Seperti halnya orang masih bisa meninggal dalam kecelakaan mobil meski memakai sabuk pengaman, bukan berarti sabuk pengaman tidak berguna; mitigasi sangat meningkatkan tingkat kesulitan eksploitasi

  • Katanya, “para peneliti mengungkapkan hasilnya kepada Apple pada 12 September 2022”, jadi saya benar-benar penasaran kenapa Apple hampir membiarkannya begitu saja selama lebih dari setahun

    • Karena mereka bisa
      Apple adalah salah satu penguasa CVE, jadi mereka bisa menolak penerbitan CVE untuk produk mereka sendiri, dan kalau punya kekuatan seperti itu, mereka bisa bergerak selambat yang mereka mau

  • Saya merasa pernah melihat teks terkait perbaikan di situs web iLeakage, tetapi sekarang hilang. Saya kira saya salah ingat, tetapi ternyata situs webnya memang berubah dalam satu jam terakhir
    Ada teks yang berbunyi “Apple baru saja merilis iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1, jadi perbarui perangkat Anda”, dan sekarang sudah dikembalikan
    https://github.com/ileakage-authors/ileakage-authors.github....

    • Sepertinya salah satu penulis makalah membaca thread ini
      Setelah saya menunjukkan bahwa tidak ada jadwal publikasi di situsnya, sebuah bagian singkat ditambahkan ke FAQ, dan karena situasi apakah perbaikan sudah dirilis atau belum memang membingungkan, tampaknya para peneliti juga ikut bingung
    • Aneh. Setelah memperbarui ke iOS 17.1, di Settings -> Safari -> Advanced -> Feature Flags ada Swap Processes on Cross-Site Navigation dan itu aktif secara default
      Saya penasaran apakah ini berbeda dari Swap Processes on Cross-Site Window Open di macOS

  • Kalimat “iLeakage adalah serangan yang cukup sulit dijalankan sampai tuntas, dan membutuhkan pengetahuan tingkat lanjut tentang serangan side-channel berbasis browser serta implementasi Safari” mungkin menjadi alasan Apple tidak terlalu memedulikannya

    • Kelihatannya maksudnya serangan ini terlalu sulit dijalankan sehingga secara realistis mustahil, dan pada dasarnya risikonya mendekati 0%
      Memberinya julukan menakutkan dan bahkan nama domain lagi juga tidak terlihat profesional maupun dapat dipercaya

  • Jika yang terdampak adalah perangkat macOS atau iOS dengan CPU Apple seri A atau seri M, yaitu iPhone/iPad terbaru serta laptop dan desktop Apple sejak 2020, maka sebagai pengguna Intel Mac yang langka, sepertinya saya tidak terdampak

    • Kemungkinan besar tetap terdampak
      Hanya struktur hierarki cache-nya yang sedikit berbeda, dan proof of concept mungkin perlu sedikit perubahan
    • Kalau di macOS, cukup jangan gunakan Safari
      Kalau di iOS, harus memakai Lockdown Mode, dan itu satu-satunya cara memakai iPhone dengan aman
      Benchmark yang dilakukan tanpa Lockdown Mode harus dianggap sama tidak bergunanya seperti menjalankan benchmark CPU dengan mitigations=off

  • Ini satu lagi alasan bagus untuk mengizinkan engine browser lain di perangkat iOS

    • Regulasi UE mungkin akhirnya akan memaksa Apple

  • Jika muncul error saat menjalankan perintah di bawah, berikan Full Disk Access ke Terminal lalu coba lagi
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1