Serangan Pass-ta-key membolehkan malware merampas passkey Google di Windows

Yang penting, serangan ini tidak memecahkan kriptografi WebAuthn atau FIDO2. Sebaliknya, ia mengambil kesempatan daripada kelemahan dalam cara Chrome mengurus pengesah awan (cloud authenticator) serta proses pendaftaran dan pengesahan peranti .

Tiga teknik Pass-ta-key dan kelemahan yang dieksploitasi

1. Pass-ta-key: Memalsukan identiti peranti dipercayai

Dalam serangan asas ini, malware mengekstrak kunci identiti peranti yang dibalut TPM daripada fail tempatan Chrome bernama passkey_enclave_state. Kunci tersebut kemudiannya digunakan semula melalui panggilan API Windows CNG yang sah untuk menandatangani permintaan yang dikawal penyerang.

Hasilnya ialah assertion WebAuthn yang sah, walaupun tiada permintaan cap jari atau PIN dipaparkan pada skrin mangsa. Serangan ini berjaya terhadap laman web yang tidak menyemak bendera User Verified (UV) dalam data pengesah .

Kelemahan yang dieksploitasi: kepercayaan pengesah awan terhadap kunci identiti peranti yang disimpan secara tempatan, selain kegagalan sesetengah laman web menguatkuasakan pengesahan pengguna.

2. Silver Pass-ta-key: Memintas pengesahan pengguna

Silver Pass-ta-key menyasarkan laman web yang sememangnya menguatkuasakan pengesahan pengguna. Penyerang memadam atau membatalkan fail passkey_enclave_state, lalu memaksa Chrome mendaftarkan semula peranti tersebut.

Ketika proses pendaftaran semula itu, Chrome menghasilkan kunci pengesahan pengguna melalui aliran tertangguh untuk tempoh yang singkat. Penyerang boleh mendaftarkan kunci pengesahan mereka sendiri dalam ruang masa tersebut.

Pengesah awan Google tidak mengesahkan attestation bagi kunci baharu berkenaan. Oleh itu, tandatangan yang dihasilkan membawa bendera UV dengan nilai 1, sekali gus melepasi pemeriksaan laman web yang memerlukan pengesahan pengguna. Penyerang kemudiannya memperoleh akses yang boleh digunakan berulang kali dari komputer mereka sendiri — komputer mangsa tidak lagi perlu berada dalam talian .

Kelemahan yang dieksploitasi: ketiadaan pengesahan attestation ketika pendaftaran semula peranti serta kemampuan memadam fail keadaan enclave tanpa perlindungan yang mencukupi.

3. Golden Pass-ta-key: Mencuri kunci induk semua passkey

Golden Pass-ta-key menggunakan proses pendaftaran semula yang sama, sebelum membaca memori proses Chrome untuk mendapatkan Security Domain Secret (SDS).

SDS ialah kunci simetri sepanjang 32 bait yang menyulitkan setiap passkey yang disegerakkan dalam akaun Google mangsa. Dengan SDS, penyerang boleh menyahsulit semua kunci peribadi passkey sedia ada dan passkey baharu yang disegerakkan kemudian. Ini membuka jalan kepada pengambilalihan akaun secara menyeluruh bagi semua perkhidmatan yang dilindungi passkey tersebut .

Unit 42 sebelum ini mendapati Chrome merekodkan SDS dalam bentuk teks biasa di chrome://device-log/FIDO. Google telah membuang rekod tersebut selepas pendedahan itu, tetapi isu pendedahan SDS dalam memori masih wujud .

Kelemahan yang dieksploitasi: SDS berada dalam bentuk teks biasa dalam memori proses Chrome ketika proses pendaftaran peranti berlangsung.

Laman web yang terjejas

Serangan Pass-ta-key asas boleh digunakan terhadap mana-mana pihak yang bergantung pada pengesah (relying party) tetapi gagal menyemak bendera UV. Unit 42 mengenal pasti eBay sebagai salah satu laman yang tidak menguatkuasakan pemeriksaan tersebut; eBay kemudiannya telah membaikinya .

Penyelidik turut menyatakan bahawa terdapat “jumlah yang mengejutkan” laman web yang menetapkan userVerification: "required" ketika pendaftaran, tetapi tidak memeriksa bit UV yang dikembalikan semasa log masuk .

Apa berlaku jika SDS dicuri?

SDS berfungsi sebagai kunci induk kepada semua passkey yang disegerakkan dalam akaun Google pengguna. Jika ia dicuri:

• Semua kunci peribadi passkey yang telah disegerakkan boleh dinyahsulit, termasuk passkey baharu yang disegerakkan selepas itu .
• Penyerang boleh log masuk ke mana-mana akaun yang dilindungi passkey — termasuk Gmail — tanpa memerlukan tindakan lanjut daripada mangsa .
• Akses kepada Gmail boleh digunakan untuk menetapkan semula kata laluan akaun lain, menyebabkan kesannya merebak jauh melangkaui perkhidmatan yang terjejas secara langsung .
• Tiada mekanisme terbina dalam untuk menukar atau memutar ganti SDS; Google tidak menyediakan cara untuk pengguna menjana SDS baharu .

Langkah yang disyorkan

Berdasarkan penemuan Unit 42, pengguna dan pengendali perkhidmatan boleh mengambil langkah berikut:

• Daftarkan sekurang-kurangnya satu kunci keselamatan perkakasan, seperti YubiKey, selain passkey yang disegerakkan. Kelayakan yang terikat pada peranti tidak disegerakkan ke awan, tidak masuk ke dalam keadaan enclave Chrome dan tidak boleh dibaca daripada memori .
• Aktifkan Advanced Protection Program Google jika anda tergolong dalam kumpulan berisiko tinggi, seperti wartawan, eksekutif, aktivis atau pentadbir sistem. Program ini mewajibkan kunci keselamatan atau passkey yang terikat pada peranti serta memperkukuh proses pemulihan akaun .
• Semak senarai peranti dalam akaun Google sekurang-kurangnya sebulan sekali dan keluarkan sesi atau peranti yang tidak dikenali .
• Anggap jangkitan infostealer sebagai insiden yang memerlukan set semula semua kelayakan. Selepas akaun dipulihkan, pasang semula sistem pada komputer dan daftarkan semula semua passkey menggunakan peranti yang bersih .
• Pihak yang mengendalikan laman web perlu menyemak bendera UV di bahagian pelayan dan menetapkan userVerification kepada "required", bukannya "preferred", untuk operasi sensitif .

Status semasa

Pada masa laporan itu diterbitkan pada 3 Ogos 2026, tiada CVE diberikan untuk isu tersebut. Google juga belum mengesahkan secara terbuka sama ada laluan Silver atau Golden akan dibaiki secara langsung .

Kesimpulan utama penyelidikan ini ialah passkey masih bergantung pada keselamatan peranti tempat ia digunakan. Passkey boleh menghapuskan banyak risiko kata laluan, tetapi komputer Windows yang telah dijangkiti malware tetap menjadi titik serangan kritikal.