Chrome'daki Passkey Güvenlik Açıkları: Kriptografi Sağlam, Ama Uygulama Hatalı
Google Password Manager'da saklanan bir passkey, standart kullanıcı yetkisine sahip bir malware tarafından—biyometrik doğrulama istemi, ekran bildirimi veya kullanıcı etkileşimi tetiklenmeden—çalınabiliyor ve hesaplara giriş yapılabiliyor. Palo Alto Networks Unit 42 araştırmacıları, Chrome'un Windows üzerinde çalışan senkronize passkey sistemine karşı üç farklı saldırı vektörü yayınladı: Pass-ta-key, Silver Pass-ta-key ve Golden Pass-ta-key. Hiçbiri passkey'lerin altında yatan kriptografiyi kırmıyor; bunun yerine cihaz kaydı, doğrulama bayrağı denetimi ve bulut senkronizasyonu için kullanılan master anahtarın bellek içi tutulma şeklindeki uygulama zayıflıklarını hedef alıyor.
Saldırıların üçü de lokal cihaz erişimi ve Windows TPM gereksinimi ile sınırlı. Ancak bu koşullar sağlandığında, malware kullanıcının hiçbir şeyden haberdar olmadan passkey korumalı sitelere giriş yapabiliyor. eBay ve GitHub gibi büyük platformlar test edildi; eBay sorumlu açıklama sonrası güvenlik açığını kapattı. Google henüz bu vektörlerden kaçının tamamen düzeltildiğini resmi olarak açıklamadı ve 3 Ağustos 2026 itibarıyla CVE numarası atanmış değil.
Chrome Senkronize Passkey Sistemi Nasıl Çalışıyor?
Google, passkey'leri tek bir cihaza bağlı tutmak yerine kullanıcının tüm cihazlarına senkronize eden bir sistem kullanıyor. Bu sistemin merkezinde Security Domain Secret (SDS) adı verilen 32 baytlık bir master anahtar var. SDS, kullanıcının Google hesabına bağlı tüm passkey'leri şifrelemek ve şifresini çözmek için kullanılıyor.
Bir kullanıcı yeni bir cihazda Google Password Manager'ı ilk kez ayarlarken, Chrome bu SDS'yi buluttan indiriyor ve yerel TPM'ye (Trusted Platform Module) sarılı bir kimlik anahtarı ile koruyor. Sarılı anahtar, teorik olarak TPM'nin dışına çıkarılamaz ve yalnızca o cihazda çözülebilir şekilde tasarlandı.
Ancak bu koruma yalnızca anahtarın depolandığı katmanda geçerli. SDS, kullanım sırasında Chrome'un işlem belleğinde düz metin olarak tutuluyor. Araştırmacılar ayrıca SDS'nin Chrome'un chrome://device-log/FIDO sayfasında daha önce loglandığını tespit etti. Google bu logu temizledi, ancak bellek içi tutulan anahtarın korunması sorunu devam ediyor.
Google şu an kullanıcılara SDS'yi rotate etme veya iptal etme seçeneği sunmuyor. Bir kez çalınırsa, saldırgan hem mevcut hem de gelecekte oluşturulacak tüm senkronize passkey'lere erişebilir.
Üç Saldırı Vektörü: Pass-ta-key, Silver ve Golden
Pass-ta-key: Sarılı Anahtarı Çalmak
İlk saldırı yöntemi, cihazda kayıtlı olan sarılı kimlik anahtarını hedef alıyor. Bu anahtar Chrome'un yerel profil klasöründe depolanıyor ve standart kullanıcı yetkisi olan bir malware tarafından kopyalanabiliyor.
Sarılı anahtar TPM'ye bağlı olduğundan, saldırgan bunu kendi cihazına taşıyamaz. Ancak aynı cihazda çalışan malware, bu anahtarı kullanarak Google'ın Cloud Authenticator servisine kimlik doğrulama istekleri gönderebilir—kullanıcının yüzünü taratmasına veya PIN girmesine gerek kalmadan. Passkey, TPM'nin cihazı unlock ettiği varsayımına dayanarak serbest bırakılıyor.
Bu saldırı cihazın fiziksel kontrolü gerektiriyor, ancak kullanıcıdan görünür bir etkileşim istemiyor.
Silver Pass-ta-key: Cihazı Yeniden Kaydetmek
İkinci vektör, cihaz kaydının yenilenmesini zorluyor. Saldırgan, mevcut cihaz kimliğini silerek Chrome'u yeniden kayıt sürecine itiyor. Yeniden kayıt sırasında sistemin uv_key_pending (user verification key bekliyor) adı verilen bir durumu var. Bu durumda Google Cloud Authenticator, yeni kaydedilen kimlik anahtarının attestation (güvenilir kaynak doğrulama) bilgisini kontrol etmiyor.
Saldırgan, bu aşamada kendi kontrol ettiği bir UV anahtarı kaydedebiliyor. User Verification bayrağı daha sonra o anahtarın doğrulama yaptığını belirtiyor, ancak relying party (passkey'i kabul eden site) bu bayrağın gerçekten güvenilir bir cihaz tarafından üretildiğini denetlemiyorsa, saldırgan kullanıcı doğrulaması olmadan giriş yapabiliyor.
Golden Pass-ta-key: Master Anahtarı Çalmak
Üçüncü ve en güçlü saldırı, SDS'nin kendisini hedefliyor. Malware, Chrome işlem belleğini tarayarak 32 baytlık SDS'yi düz metin olarak yakalayabiliyor. Bu anahtarı ele geçiren bir saldırgan:
- Kullanıcının tüm mevcut passkey'lerinin şifresini çözebilir - Gelecekte oluşturulacak tüm passkey'leri otomatik olarak okuyabilir - Kurbanın cihazına canlı erişim olmadan kendi ortamından giriş yapabilir - Bu erişimi, Google'ın rotasyon veya iptal mekanizması olmadığından, süresiz sürdürebilir
Golden Pass-ta-key, saldırganın bir kerelik bellek erişimi ile kalıcı, sınırsız passkey erişimi elde etmesine olanak tanıyor.
Uygulama Zayıflıkları: UV Bayrağı ve Cihaz Kaydı
Passkey standardı (WebAuthn / FIDO2), kimlik doğrulama verisi içinde tek bir bit olan User Verified (UV) bayrağını tanımlıyor. Bu bayrak, kullanıcının biyometrik veya PIN doğrulaması yaptığını belirtir. Ancak bayrak, imzalı veri içinde taşındığı için kurcalanamaz kabul ediliyor—passkey'in altındaki kriptografi bayrakla birlikte tüm paketi imzalıyor.
Sorun, bazı relying party'lerin bu bayrağı sunucu tarafında doğrulamaması. Bir site, passkey'i kabul ederken userVerification: required ayarı yapsa bile, yanıt içindeki UV bayrağını kontrol etmezse, malware tarafından manipüle edilmiş bir cihaz kaydından gelen "doğrulanmış" bir imzayı kabul edebilir.
eBay bu açığa sahipti. Site passkey ile giriş yaparken UV bayrağını kontrol etmiyordu, bu da Pass-ta-key saldırısı ile kullanıcı doğrulaması yapılmadan hesaba erişim sağlanabilmesine izin veriyordu. eBay, Unit 42'nin sorumlu açıklamasından sonra problemi düzeltti.
GitHub da test edilen siteler arasındaydı. Diğer büyük platformların kaçının aynı hatayı yaptığı bilinmiyor.
Google'ın Cloud Authenticator servisi, yeniden kayıt sırasında attestation doğrulaması yapmıyor. Bu, Silver Pass-ta-key saldırısının mümkün olmasını sağlayan ikinci bir tasarım zayıflığı.
Relying Party Sorumluluğunun Sınırları
eBay örneği, saldırının yalnızca Google'a değil, passkey'i kabul eden platformlara da bağlı olduğunu gösteriyor. WebAuthn standardı, UV bayrağı doğrulamasını relying party'nin sorumluluğuna bırakıyor. Google, bu doğrulamayı otomatik olarak zorlayamaz. Passkey'in güvenliği yalnızca kimlik sağlayıcıya değil, aynı zamanda her bir sitenin kendi implementasyonuna da bağlı.
Eksenize, passkey'lerin merkezi olmayan güvenlik modelinde bir durum ortaya çıkıyor: Standart güçlü, ancak her bir relying party'nin kendi validation layer'ını doğru yapması gerekiyor. Tek bir doğrulama hatası, kullanıcıyı biyometrik doğrulama olmadan hesap erişimine açık hale getirebiliyor.
Windows TPM Gereksinimi ve Lokal Malware Kısıtlaması
Üç saldırı da önemli bir ön koşula bağlı: Saldırgan, kurbanın Windows cihazına zaten malware yüklemiş olmalı. Malware standart kullanıcı yetkisiyle çalışabilir, ancak lokal cihazda aktif olmalı ve TPM'ye erişim sağlamalı.
Bu kısıtlama, saldırının uzaktan veya phishing yoluyla gerçekleştirilemeyeceği anlamına geliyor. Ancak infostealer'lar, trojan'lar ve keylogger'lar tarayıcı şifrelerini, çerezleri ve session token'larını hedef alıyor. Bu saldırı vektörleri, aynı tehdit aktörlerinin araç setine yeni bir katman ekliyor.
Saldırı macOS veya Linux üzerinde test edilmedi. Google Password Manager Android ve iOS'ta farklı bir mimari kullanıyor; bu araştırmanın kapsamı dışında.
TPM gereksinimi bir engel, ama tam bir savunma değil. Bir saldırganın fiziksel cihaza erişimi varsa veya uzaktan erişim trojan'ı (RAT) yüklüyse, TPM sarılı anahtarlar bile bir koruma katmanı sunmuyor. Çünkü malware, cihazın açık ve unlock durumunda olduğu anlarda anahtarı kullanabiliyor.
Passkey Güvenliğine İlişkin Yanlış Anlaşılmalar
Passkey teknolojisi, phishing'e karşı dayanıklılığı ve kullanıcı kolaylığı nedeniyle yaygın olarak "şifrelerden daha güvenli" olarak tanıtılıyor. Bu ifade, phishing ve uzaktan credential çalma saldırıları için doğru. Passkey, kullanıcıdan hiçbir sır paylaşmayı gerektirmediğinden, sahte web sitelerine karşı doğal bir koruma sağlıyor.
Ancak bu araştırma, passkey'lerin lokal cihaz güvenliğine tamamen bağlı olduğunu gösteriyor. Eğer cihazda malware varsa, passkey'in sağladığı anti-phishing koruması bir anlam ifade etmiyor. Kullanıcı hiçbir etkileşimde bulunmasa bile hesap ele geçirilebiliyor.
Bu, passkey'in başarısız olduğu anlamına gelmiyor. Ancak güvenliğin yalnızca kriptografik protokollerle değil, cihaz hijyeni, güncel yazılım ve TPM-sarmalı depolama gibi tamamlayıcı katmanlarla sağlanabileceğini gösteriyor.
Şu an için şifre + 2FA (TOTP veya SMS) kullanan bir kullanıcı, phishing'e açık. Passkey kullanan ancak cihazında malware olan bir kullanıcı, lokal saldırıya açık. İki model de farklı tehdit vektörlerini hedef alıyor.
Somut Koruma Adımları: Neler Yapılabilir
Google'ın yapması gereken adımlar açık: SDS'nin bellek içinde tutulma süresini kısaltmak, process belleğinin dışında tutulabilirse tutmak, ve en önemlisi kullanıcılara SDS'yi rotate etme ve iptal etme yeteneği sunmak. Eğer bir cihaz ele geçirilirse veya SDS çalınırsa, kullanıcı mevcut SDS'yi iptal edip yeni bir tane oluşturabilmelidir. Bu, çalınan anahtarın değerini sıfırlayacaktır.
Relying party'ler için gerekli olan, UV bayrağını ve attestation bilgisini sunucu tarafında zorunlu olarak doğrulamak. Passkey'i "gerekli" olarak ayarlayan siteler, bunun sadece cihaz tarafında değil, authentication response döndüğünde sunucu tarafında da kontrol edilmesi gerektiğini bilmelidir.
Kullanıcılar için, hiçbir teknoloji lokal cihaz güvenliğinin yerini tutamaz. Passkey'in anti-phishing avantajını almak için, cihazın malware'den temiz tutulması gerekir. Bu, güncel işletim sistemi, güncel tarayıcı, ve zararlı yazılım taraması anlamına geliyor. Passkey, uzaktan saldırılara karşı güvendir; lokal hijyen ise kullanıcının sorumluluğudur.
