1 puan yazan GN⁺ 2024-09-04 | 1 yorum | WhatsApp'ta paylaş
  • Güvenli öğeler güçlü kimlik doğrulamanın güven temeli olarak kullanılırken, EUCLEAK; Infineon'un ECDSA uygulamasından gizli anahtarı çıkaran ve YubiKey 5Ci üzerinde gösterilen bir yan kanal saldırısıdır
  • Temel zafiyet, Infineon kripto kütüphanesindeki sabit zamanlı olmayan modüler ters alma işlemidir ve bu durum 14 yıl boyunca yaklaşık 80 kez en yüksek seviye Common Criteria sertifikasyon değerlendirmesinden geçti
  • Saldırganın güvenli öğeye fiziksel erişimi olması gerekir; ayrıca birkaç yerel elektromanyetik ölçüm, pahalı ekipman, özel yazılım ve teknik yetkinlik gerekir, ancak ölçümlerin kendisi yalnızca birkaç dakika sürer
  • Etki alanı; firmware 5.7'nin altındaki YubiKey 5 Series ile Infineon kripto kütüphanesini çalıştıran güvenli mikrodenetleyicileri kapsar ve buna TPM'ler de dahildir
  • FIDO'da ECDSA gizli anahtarının çıkarılması cihaz kopyalamayı mümkün kılsa da, kimlik avına karşı koruma açısından etkilenen ürünleri kullanmak yine de hiç kullanmamaktan daha güvenlidir

EUCLEAK saldırısının hedef aldığı nokta

  • Güvenli öğe (secure element), gizli değerleri üreten ve saklayan, ayrıca kriptografik işlemler gerçekleştiren küçük bir mikrodenetleyicidir; çoğu zaman Common Criteria'nın en yüksek seviyeli güvenlik değerlendirmesini alır
  • FIDO donanım token'ları, web hizmetlerinde oturum açmak için kullanılan güçlü kimlik doğrulama araçlarıdır ve FIDO protokolü temel kriptografik yapı taşı olarak ECDSA kullanır
  • YubiKey 5 Series, yaygın kullanılan bir FIDO donanım token'ıdır ve güvenli öğe olarak Infineon SLE78 kullanır
  • NinjaLab, Infineon SLE78 tabanlı benzer bir JavaCard açık platformu olan Feitian A22 üzerinde Infineon ECDSA uygulamasını analiz etti ve yan kanal zafiyetini kullanan gerçek bir saldırı tasarladı
    • Saldırı YubiKey 5Ci üzerinde gösterildi
    • Zafiyet daha yeni ürünler olan Infineon Optiga Trust M ve Infineon Optiga TPM güvenli mikrodenetleyicilerine de uzanıyor
  • Zafiyetin nedeni, Infineon Technologies kripto kütüphanesindeki sabit zamanlı olmayan modüler ters alma işlemidir ve bu durum 14 yıl ile yaklaşık 80 en yüksek seviye Common Criteria sertifikasyon değerlendirmesi boyunca fark edilmedi
  • Ayrıntılı teknik doküman Download the Writeup bağlantısında sunuluyor

Etkilenen ürünler ve saldırı koşulları

  • Saldırganın güvenli öğeye fiziksel olarak erişmesi gerekir ve birkaç yerel elektromanyetik yan kanal ölçümüyle ECDSA gizli anahtarı çıkarılabilir
    • FIDO protokolünde bu, FIDO cihazı kopyalamayı mümkün kılar
    • Saldırı için pahalı ekipman, özel yazılım ve teknik beceri gerekir
  • Etkilenen ürünler şunlardır
    • Infineon kripto kütüphanesini içeren tüm Infineon güvenli mikrodenetleyicilerinin mevcut sürümleri
    • Mevcut Infineon TPM sürümleri
    • Firmware 5.7'nin altındaki tüm YubiKey 5 Series
  • Söz konusu güvenli mikrodenetleyiciler; elektronik pasaportlar, kripto para donanım cüzdanları, akıllı kartlar, akıllı ev sistemleri gibi ECDSA'ya dayanan çeşitli güvenlik sistemlerinde yer alıyor, ancak EUCLEAK'in bu ürünlere pratikte uygulanıp uygulanmadığı henüz doğrulanmadı
  • Feitian A22 JavaCard, araştırmada kullanılan eski bir üründür ve artık satılmıyor
    • Şu anda Feitian web mağazasında satılan, Infineon güvenli mikrodenetleyicisi tabanlı ürünler Feitian'ın kendi kripto kütüphanesini kullanıyor ve NinjaLab'in bildiği kadarıyla bu araştırmadan etkilenmiyor

Azaltım ve resmi bilgiler

  • YubiKey firmware 5.7, 6 Mayıs 2024 güncellemesiyle Infineon kripto kütüphanesi yerine Yubico'nun yeni kripto kütüphanesine geçti
    • NinjaLab'in bildiği kadarıyla bu yeni kütüphane EUCLEAK'ten etkilenmiyor
  • Infineon'un kripto kütüphanesi için bir yaması zaten var, ancak NinjaLab'in bildiği kadarıyla henüz Common Criteria sertifikasyon değerlendirmesinden geçmedi
  • CVE talebi reddedildi ve MITRE bunun yerine CVE-2024-45678 numarasını kullanıyor
    • Açıklama güncelleme talebi beklemede
  • Resmi açıklamalar şu belgelerde yer alıyor

1 yorum

 
GN⁺ 2024-09-04
Hacker News yorumları
  • Ars Technica makalesine göre, saldırganın kullanıcı adı ve parolanın yanı sıra anahtara fiziksel erişime de ihtiyacı var; ayrıca cihazı söktükten sonra geri vermek için yeniden monte etmesi gerektiğinden bu kesinlikle önemsiz bir saldırı değil
    Plastik birleşim yerlerine biraz oje sürmek, kurcalanıp kurcalanmadığını gösteren bir kanarya olarak işe yarayabilir
    Ancak FIDO token’larının zayıf yönlerini de ortaya çıkarıyor. Nerelere kaydedildiğinin listesini bizzat tutmanız, token’ı kaybederseniz veya çaldırırsanız kayıtlı olduğu tüm yerlerde tek tek iptal etmeniz gerekiyor

    • Bu yalnızca YubiKey’e özgü bir sorun değil
      NinjaLab’e göre Infineon kriptografi kütüphanesini çalıştıran tüm Infineon güvenlik mikrodenetleyicileri, bilinen mevcut tüm sürümlerinde bu saldırıya karşı savunmasız
      Buna ABD, Çin, Hindistan, Brezilya ve çeşitli Avrupa ile Asya ülkelerinin elektronik pasaport çipleri; Samsung ve OnePlus telefonlardaki güvenli bölgeler; Ledger ve Trezor gibi kripto para donanım cüzdanları; SIM kartlar; Lenovo, Dell ve HP dizüstülerdeki TPM’ler; kredi ve banka kartlarındaki EMV çipleri dahil
    • KeePassXC’yi parola yöneticisi olarak kullanırken donanım anahtarı kullanan her hesaba etiket koyuyorum
      Böylece anahtarı kaybedersem, çaldırırsam veya anahtar bozulursa kaldırmam gereken sitelerin listesini hızlıca çıkarabiliyorum
      Her zaman 2 anahtar kaydedip fiziksel olarak ayrı yerlerde saklıyorum; böylece birini kaybetsem bile giriş yapabiliyorum
    • Bu saldırının önemsiz olmadığına katılıyorum, ama YubiKey zaman zaman çok yüksek riskli ortamlarda kullanılıyor
      Buna yalnızca kripto para varlıklarına erişim değil, savunma sanayii şirketleri gibi daha ciddi durumlar da dahil
      Bu tür durumlarda saldırganın kaynakları da bol, motivasyonu da güçlü olur; zaten YubiKey tam da bu tür saldırıları engellesin diye kullanılır
      Dolayısıyla anahtar hâlâ kimlik avına dayanıklı kimlik doğrulama sağlıyor, ancak bazı güvenlik beklentilerinin boşa çıktığını kabul etmek gerekir
    • Yeterli kaynağa sahip bir saldırgan, aynı ECDSA anahtarını içeren arka kapılı bir yedek anahtar da üretebilir
    • Bireyler için çözüm, bu cihazı yalnızca kritik servislerde kullanıp geri kalanında iyi parola hijyenine güvenmek şeklinde sınırlandırmak olabilir
  • En sinir bozucu kısım, YubiKey’i öylece değiştiremiyor olmanız
    Passkey kullansanız da keşfedilemeyen anahtar kullansanız da, bu anahtarı kullanımdan kaldırmadan önce her hesabı tek tek dolaşıp savunmasız olmayan yeni bir anahtarla değiştirmeniz gerekiyor
    Keşfedilemeyen olması da sorun; geçmişte YubiKey’i nerelerde kullandığımı hatırlamıyorum
    Ars makalesinde [0] PIN’den de bahsediliyor, ancak bu YubiKey’e özgü bir özellik değil, bir FIDO özelliği
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • Bir başka açıdan, keşfedilemeyen FIDO anahtarlarının başlıca kullanım alanı olan iki adımlı doğrulama nedeniyle hesabın dışında kalmaktan daha çok endişeleniyorum
      Geçmişte ABD gümrüğü YubiKey dahil elektronik cihazları alıkoyduğunda bunu gerçekten yaşadım
      Sonradan e-postayı iki adımlı doğrulama ya da nihai doğrulama aracı olarak kabul eden birçok hesabı kurtardım, ancak AWS dahil bazıları için bu mümkün olmadı
      Birçok web sitesi, alternatif doğrulama yöntemlerini ve erişimi kaybetmenin sonuçlarını açıkça anlatmadan iki adımlı doğrulama kaydını teşvik ediyor
    • Parola yöneticisinde takip ediyorum
      YubiKey’in kayıtlı olduğu hesaplara "YubiKey (FIDO)" etiketi koyuyorum
    • GitHub gibi yerleşik WebAuthn token’ı kullanan siteler, anahtarda bilinen sitelerin listesini gösterebilir
      Ancak bu akışın genel kullanıcı deneyimi hâlâ beklenen düzeyde değil
    • Kişisel YubiKey’in klonlanamaması veya yedeklenememesi hep hoşuma gitmedi; bu yüzden her yerde kullanmaktan kaçındım
    • FIDO cihazı kaydederken başka bir iki adımlı doğrulama biçimi ayarlamayı istemeyen bir siteye henüz rastlamadım
      Benim durumumda, uygulamada tuttuğum TOTP’yi de yanında bulunduruyorum
  • “Firmware’i 5.7’nin altında olan tüm YubiKey 5 Series cihazlar etkileniyor” denince, fiziksel donanım token’ının firmware’ini güncellemenin yeterli olacağını sanmıştım
    Ama YubiKey firmware’i yükseltilemiyor deniyor
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    O zaman Yubico ücretsiz değişim sunuyordur, değil mi? Elimde bu YubiKey’lerden birkaç tane var…

    • YubiKey, kimlik avını engellemek amacıyla tasarlandı ve bu saldırı fiziksel erişim gerektiriyor
      Yani gerçek hayatta doğrudan hedef alınacak kadar değerliyseniz zaten YubiKey kullanmamalısınız
      Birisi yedek anahtarı değiştirebilir ve çok geç olana kadar bunu fark etmeyebilirsiniz
    • 5.4.3 5C Nano kullanıyorum; ücretsiz değişim yok, yalnızca azaltıcı önlemler var
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • Infineon çipinde parolayı kıran bir hata son kez ortaya çıktığında Estonya vatandaşları yeni kimlik kartlarını ücretsiz aldı
      Buna karşılık, piyasaya çıkalı iki ay bile olmamış YubiKey 4’üm donanım onaylı PIV akıllı kart olarak çalışamaz hâle geldi
  • “Sabit zamanda olmayan modüler ters hesaplamasından kaynaklanıyor” denmesi, ince elektromanyetik yayılım gibi hassas bir yan kanal anlamına gelmiyor
    Gizli veriye bağlı olarak sürenin değişip değişmediği, yan kanal denetiminde ilk kontrol edilmesi gereken maddelerden birine yakındır
    Tüm işlemlerin veriden bağımsız olarak her zaman aynı sayıda saat döngüsü kullanıp kullanmadığını doğrulamak yeterlidir; hatalar da veriden bağımsız olarak sabit sayıda saat döngüsünden sonra oluşmalıdır
    Denetçilerin bunu nasıl kaçırdığı merak konusu

    • Tam olarak söylemek gerekirse bu tür bir yayılım yan kanalına daha yakın görünüyor
      Makaleyi doğru anladıysam sabit zamanda olmayan şey algoritmanın çalışmasının kendisi değil, dışarıdan gözlemlenebilen RF yan kanalının duty cycle’ı
      Çalışma süresi gerçekten sabit olmasaydı, en kötü durumda saldırı yalnızca USB ile bile mümkün olurdu; ancak Infineon uygulaması saf zamanlama saldırılarına karşı savunmasız görünmüyor
      nonce blinding de uygulanmış, fakat sorun eliptik eğri boyutundan çok daha küçük bir çarpma maskesi kullanılması ve bunun kaba kuvvetle denenebilir hale gelmesi
    • ECDSA kod incelemesinde ilk bakılan şeylerden biri olduğu için, Infineon açısından utandırıcı bir hata
    • Katılıyorum. Gerçekten ileri düzey bir saldırı bekliyordum; bu, şık bir prob takılmış standart zamanlama saldırısına daha yakın
      Yine de probun kendisi şık
  • Fiziksel olarak YubiKey’e erişmeye çalışacak noktadaysanız, benzer şekilde yıpranmış ve benzer görünen bir anahtarla değiştirmeniz yeterli
    Böylece kurban ya kendi YubiKey’inin bozulduğuna inanır ya da saldırgan YubiKey’i kullanmak için yeterli zaman kazanır
    Örneğin bende iki YubiKey varsa ve biri eve gizlice girip yedek anahtarı değiştirirse, yedek anahtarı kullanana kadar fark etmem
    Sonuçta bu saldırı ancak hedef doğrudan hedef alınmaya değecek kadar değerliyse anlamlı; böyle bir hedef de muhtemelen YubiKey’den biraz daha güvenli bir şey kullanır

    • ykman list ile YubiKey’in kimlik bilgileri kontrol edilebildiğinden, anahtarın bozulup bozulmadığını ya da gerçekten değiştirilip değiştirilmediğini denetlemek için kolayca bir prosedür konabilir
      Güvenlik gereksinimi yüksekse düzenli olarak kontrol edilebilir veya yedek anahtarın fiziksel konumu ayrıca korunabilir
      Donanım kimlik doğrulayıcılar arasında YubiKey’den daha güvenli olanın ne olduğunu da merak ediyorum
    • Erişim izniniz varsa anahtarı bozup çalışan bir yedek anahtarla değiştirmek gerçekten kolay
    • Gerçekte YubiKey’in zincirin en zayıf halkası haline gelmesi çok nadir olur
      Saldırgan cihazı hedef alabilir, iletişimi araya girip yakalayabilir ya da verileri barındıran hizmete mahkeme emri uygulatabilir veya gizlice sızabilir
  • EUCLEAK açıklama PDF’i: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Yubico blog yazısı: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • NinjaLab’in araştırması mükemmel
    Yubico duyurusunda özellikle ilginç olan kısım, bu yerel klonlamanın WebAuthn protokolünün attestation’ını [1] da etkisiz hale getirmesi
    Protokol bu yerel klonlama saldırısına daha iyi dayanacak şekilde tasarlanabilir miydi?
    “Saldırgan, kurtardığı attestation anahtarını kullanarak sahte bir YubiKey oluşturabilir. Bu durumda make credential sırasında geçerli bir FIDO attestation ifadesi üretilir ve etkilenen YubiKey sürümleri için kuruluşun kimlik doğrulayıcı modeli tercih denetimi aşılabilir.”

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • Saldırganın istek imzalamada kullanılan gizli değeri kopyaladığı bir durumda, o gizli değere sahip olduğu sürece kopya ile özgün cihazı ayırt etmenin bir yolu yok gibi görünüyor
      Güvenli öğenin tüm güvenlik modeli anahtar çıkarılmasını engellemeye dayanıyor; bu mümkün hale gelirse anahtarı bilgisayarda bir dosyada saklamaktan daha iyi bir yanı kalmaz
      Elbette anahtarı elde etmek için cihazı fiziksel olarak açmak gerektiğinden, biri gerçekten anahtarı almadığı sürece bilgisayarda saklamaktan daha güvenli
    • Ne yazık ki pratikte zor. Attestation neredeyse her zaman, bir tür güvenli donanımın ihraç edenin onayladığı bir sırrı koruyup güvenen tarafa kendini doğrulaması ve türetilmiş/saklanan sırlarla güveni sürdürmesi yapısına dayanır
      Bu attestation sırrı herhangi bir şekilde çıkarılabiliyorsa, saldırganın gerçekten öyle davranmadan sahte attestation üreten sahte bir kimlik doğrulayıcı oluşturmasını engellemek mümkün değildir
      Teoride dolaylı attestation veya kimlik doğrulayıcıya özgü benzersiz attestation anahtarları kullanarak tek bir attestation sırrının sızmasının etkisi azaltılabilir
      Bu, YubiKey gibi yüz binlerce kimlik doğrulayıcının paylaştığı attestation anahtarı yerine kullanılabilecek bir yöntemdir; yine de muhtemelen yalnızca olasılıksal bir hafifletme olarak kalır
  • Yubico web sitesinde 5.7 ve üzerinin etkilenmediği yazıyor
    Başka bir Yubico yazısına [1] göre 5.7 sürümünün özelliklerinden biri, RSA ve ECC’nin temel kriptografik işlemlerini yapan Yubico’nun kendi kriptografi kütüphanesine geçiş
    Umarım birçok kişi incelemiştir. Açık ve kapalı kaynak bu kadar çok uygulamanın olduğu günümüzde neden kendi kriptografi kütüphanelerini kullanmak istediklerini pek bilmiyorum
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • Bunun nedeni, tedarikçi kaynaklı güvenlik sorununun ikinci kez yaşanması ve öncekinin daha ciddi olması
      Tüm şirket kriptografi üzerine kuruluysa, yeterli sayıda uygulamalı kriptograf istihdam edip kendi kaderini doğrudan kontrol etmek gerçekten mantıklı
    • Gömülü platformlarda mevcut kütüphaneler taşınmamış olabilir veya platform çok farklı olduğundan taşıma pratik olmayabilir
      Başka nedenler de olabilir; kapalı kaynakta ekonomik değerlendirmeler de büyüktür
      Özellikle önceki kapalı kaynaklı, muhtemelen kaynak kodu sağlanan tedarikçi uygulamasından kurum içi uygulamaya geçiş söz konusuysa bu daha da geçerli
    • 5.7 ne zaman yayımlandı?
  • Infineon yine yaptı yapacağını. 7 yıl önce de böyle bir şey olmuştu: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • “Infineon’da kriptografi kitaplığı için zaten bir yama var, ancak bildiğim kadarıyla henüz Common Criteria sertifikasyon değerlendirmesinden geçmedi” deniyor; açıkçası bu hiç önemli değil

    • Saldırının kendisinden bağımsız bakıldığında ilginç bir deney ve yayımlanmaya değer, ancak pratikte kâğıt üzerinde savunmasız görünen cihazlarda bile gerçek dünyadaki etkisi pek büyük görünmüyor