Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Można klonować klucze Yubikey 5. Podatne są klucze z firmware < 5.7. Wymagany fizyczny dostęp.
Piekło zamarzło, Yubikey’e zhackowane – tak moglibyśmy opisać wczorajszy komunikat wydany przez Yubico, czyli producenta najpopularniejszych na świecie fizycznych kluczy bezpieczeństwa. Moglibyśmy, ale pomimo że jest w tym nieco prawdy, to nie ma powodu do paniki, przynajmniej dla większości użytkowników popularnych yubikey’ów. Dlaczego nie ma? Zacznijmy od teorii.
Badacze z firmy NinjaLab właśnie opublikowali wynik badań oraz opis podatności, którą nazwali EUCLEAK. Nazwa jest nieprzypadkowa – wadliwą okazała się implementacja rozszerzonego algorytmu Euklidesa (ang. Extended Euclidean algorithm, EEA) a podatność umożliwia wyciek (leak) prywatnego klucza kryptograficznego urządzenia. EEA używany jest jako część algorytmu krzywych eliptycznych (ang. Elliptic Curve Digital Signature Algorithm, ECDSA).
Badacze najpierw odkryli podatność typu side channel w dość wiekowym mikrokontrolerze Infineon SLE78, następnie potwierdzili istnienie tego samego błędu w nowszych układach Infineona: Optiga Trust M oraz Optiga TPM. Przy okazji wyszło na jaw, że podatność istnieje w układach Infineona od ponad 14 lat. Warto tutaj nadmienić, że Infineon jest jednym z największych na świecie producentów mikrokontrolerów bezpieczeństwa – poza kluczami bezpieczeństwa i klasycznymi komputerami znajdziemy je m.in. w elektronicznych paszportach, fizycznych portfelach kryptowalut, systemach zabezpieczeń domów czy samochodach.
In fact all Infineon security microcontrollers (including TPMs) that run the Infineon cryptographic library (as far as we know, any existing version) are vulnerable to the attack. [źródło]
Źródłem problemu jest wspomniana wyżej błędna implementacja EEA w bibliotece kryptograficznej Infineona. Ale skoro klucze działają – bo przecież używamy ich na co dzień – to czy algorytm może być zaimplementowany równocześnie prawidłowo i błędnie? Odpowiedź brzmi: tak, tutaj właśnie leżą źródła ataków klasy side channel. Z punktu widzenia matematycznej poprawności funkcje w w/w bibliotece działają prawidłowo, ale obserwując poboczne kanały (stąd side channel) działającego urządzenia, takie jak zużycie prądu czy czas wykonywania operacji, można wywnioskować pewne szczegóły na temat jego wewnętrznej aktywności czy przetwarzanych danych. Dokładnie to zrobili badacze z NinjaLab – obserwując działanie klucza YubiKey 5Ci byli w stanie odtworzyć prywatny klucz ECDSA używany m.in. w protokole FIDO, co efektywnie prowadzi do możliwości sklonowania urządzenia. Zainteresowanych szczegółami technicznymi odsyłamy do bardzo obszernego opisu podatności.
Yubico zostało poinformowane o problemie już w kwietniu tego roku, po czym potwierdziło istnienie podatności w kluczach:
- Serie Yubikey 5, YubiKey 5 FIPS, YubiKey 5 CSPN, Security key z firmware < 5.7
- Seria YubiKey Bio z firmware < 5.7.2
- YubiHSM 2, YubiHSM 2 FIPS z firmware < 2.4
Wersja firmware pełni tu kluczową rolę. Producent załatał lukę wprowadzając własną implementację problematycznej biblioteki:
As part of ongoing improvements in Yubico products and to reduce exposure to our supply chain, the dependency on Infineon’s cryptographic library has been removed in favor of Yubico’s own cryptographic library. [źródło]
Wersję firmware posiadanego klucza możemy sprawdzić np. za pomocą graficznej wersji YubiKey Manager:
Lub jej konsolowego odpowiednika:
Obydwa klucze użyte na powyższych zrzutach ekranu to YubiKey 5 z firmware w wersji 5.4.3, czyli podatnym na atak. Wypada tutaj wspomnieć, że firmware w kluczach Yubico nie da się zaktualizować, więc te klucze już zawsze będą „wadliwe”. Czy to poważny problem i powód do natychmiastowego wyrejestrowania ich ze wszystkich serwisów, utylizacji i kupienia nowych? Niekoniecznie, gdyż wykorzystanie luki nie jest trywialne, co poniekąd potwierdza oszacowanie jej na zaledwie 4.9 w skali CVSS.
Skuteczne przeprowadzenie ataku wymaga przede wszystkim fizycznego dostępu do klucza, poza tym zaawansowanej wiedzy z zakresu elektroniki i kryptografii oraz kosztownego (około $11 000) sprzętu; dodatkowo mogą być potrzebne informacje o użytkowniku klucza:
Depending on the use case, the attacker may also require additional knowledge including username, PIN, account password, or authentication key [źródło]
Decyzja o wymianie lub dalszym używaniu podatnych kluczy powinna zależeć od przyjętego przez nas modelu ryzyka. Jeśli podejrzewamy, że możemy być celem instytucji dysponującej tak znaczącymi zasobami i środkami, prawdopodobnie należy rozważyć wymianę kluczy na te z nowszym firmware. W przeciwnym przypadku nie mamy się czym przejmować i możemy używać „starych” kluczy tak, jak robiliśmy to do tej pory. Yubico sugeruje też kilka sposobów na wyeliminowanie problemu bez wymiany kluczy, jednak są one mocno uzależnione od konkretnego przypadku użycia.
Pamiętajmy, że fizyczne klucze bezpieczeństwa wciąż pozostają jedną z najlepszych metod ochrony przed m.in. phishingiem – również te od Yubico.
~kz
Należy też podkreślić że atak zakłada że da się rozebrać Yubi Key i potem niepostrzeżenie złożyć go z powrotem, co w przypadku Yubi jest raczej trudne, bo Yubi jest zaprojektowany tak aby nie dało się tego zrobić. Badacze sami stwierdzają w raporcie że nie próbowali złożyć Yubi ponownie i nie wiedzą na ile to jest wykonalne.
Atakujący wcale nie musi składać z powrotem oryginalnego klucza. Po prostu w jego miejsce podrzuci jedną z wykonanych kopii.
Tyle, że ta kopia będzie na płytce prototypowej, a nie w kształcie Yubikeya. Aczkolwiek pewnie dałoby się zrobić identyczną kopię – kwestia kasy.
Można użytkownikowi oddać klona :D
To praktycznie niewykonalne. Żeby wykonać klona całego Yubi trzeba by odzyskać klucze wszystkich kont, co oznacza konieczność znajomości poświadczeń do tych wszystkich kont i dużo więcej pracy.
YubiKey nie przechowuje kluczy bezpośrednio na sobie dla U2F, a jedynie masterkey, którym deszyfruje handle zawarte w serwisie
Tymczasem silne hasła z 194+ bitami entropii wciąż mają zero podatności. Hasła > passkeys.
chyba, że ktoś przechowuje je w plaintext po stronie serwerowej ;) lub np. ma podatność SQL injection na ekranie logowania, albo w ogóle problemy z uwierzytelnianiem/autoryzacją w swojej appce/systemie. W skrócie – nic nie jest w 100% bezpieczne…
Zależy czym to hasło się generowało. Niektóre pseudolosowe hasła są mniej losowsze od innych.
Bazę keepass-a też można ukraść i to zupełnie niezauważenie.
Hasła mają trzy podstawowe wady:
1) Stosunkowo łatwo jest je przechwycić infekując komputer ofiary (na przykład jakimś keylogerem).
2) Jest stałe – za każdym razem przesyła się te same 194+ bitów informacji, więc wystarczy je przechwycić tylko raz.
3) Nie zabezpieczają przed phishingiem i innymi tego typu atakami
Z drugiej stronu samo U2F czy FIDO też mają zero podatności – podatność jest w konkretnym modelu klucza (równie dobrze można powiedzieć, że są podatności w klawiaturach bezprzewodowych pozwalające na przechwycenie wpisanych haseł drogą radiową „przez ścianę” :D).
Klucze U2F/FIDO mają przede wszystkim wadliwą architekturę która umożliwia istnienie takich podatności. Nie pierwszy raz takie znaleziono taką podatność. W przeszłości klonowano klucze Google Titan M i wyciągano klucze SSH z Yubikey NEO. Zabezpieczenia tych kluczy nie są oparte na kryptografii, tylko na obscurity. Na początku hierarchii kluczy jest główny sekret zapisany w kluczu w plain tekście, nie jest szyfrowany hasłem użytkownika, a „niemożliwość” wydobycia go z klucza ma opierać się na zabezpieczeniach sprzętowych i braku interfejsu do odczytania go.
To tak jakby zabezpieczać swoje dane ekranem logowania do windowsa, lol. Albo jak twierdzić, że posty na facebooku sa prywatne i szyfrowane bo są wysyłane po https.
A co do haseł:
1. Jeśli atakujący jest w stanie zainstalować jakiś spyware, to równie dobrze może ukraść ciasteczka i yubikey cię przed tym nie ochroni. Jeśli ma dostęp do zalogowanego systemu to koniec.
2, 3. Dlatego stosuje się 2FA, np. TOTP. Seed w TOTP można zaszyfrować, w przeciwieństwie do głównego klucza w FIDO. Do ochrony przed phishingiem są rozszerzenia menedżerów haseł do przeglądarek które tak samo jak U2F weryfikują nazwę domeny.
No bez przesady, są klucze zabezpieczone PIN-em (wprowadzanym na klawiaturze klucza) lub „hashem” z odcisku palca i w nich klucze kryptograficzne nie są przechowywane jako plaintext – w dodatku potrafią mieć nawet otwartoźródłowe firmware (na przykład OnlyKey) i tam „security by obscurity” nie ma. A YubiKeye to produkt dla zwykłego użytkownika, który chce mieć wygodne i proste w użyciu zabezpieczenie na USB, dodatkowo działające ze smartfonem po NFC i nawet nie ma pojęcia co to jest SSH, RSA itp.
Ciekawe, jakie jeszcze kluczyki i HSM używają scalaków Optiga. Pewnie producenci jakoś się pochwalą.
Z ciekawostek w necie, znalazłem takie info:
It’s not just YubiKey.
NinjaLab: „All Infineon security microcontrollers (including TPMs) that run the Infineon cryptographic library (as far as we know, any existing version) are vulnerable to the attack.”
– Chips in e-passports from the US, China, India, Brazil and numerous European and Asian nations
– Secure enclaves in Samsung and OnePlus phones
– Cryptocurrency hardware wallets like Ledger and Trezor
– SIM cards
– TPMs in laptops from Lenovo, Dell, and HP
– EMV chips in credit and debit cards
Co ciekawe yubikey wcale nieśpieszno do wymiany tokenów użytkowników którzy się zgłoszą z reklamacją. Co ciekawe, klucze yubikey mają FIPSa 2 i certyfikacja nie zabezpieczyła świata przed błędem.
Co w tym niezrozumiałego? FIPS 2 to przecież tamper evident, czyli widać jak ktoś go otworzył, to nie jest FIPS 3, który ma zapewnić bezpieczeństwo przed otwarciem
Banki będą miały dobry argument, by nie implementować U2F – w trosce o bezpieczeństwo użytkowników.
Czy teraz bedziemy mieć promocję na już wyprodukowane kluczy Yubi z tą podatnością?
Raczej nie, to jest atak typu niemalże „niemożliwego”
Niemalże “niemożliwego” dopóki Ethan Hunt nie zabierze się za ten problem w 10 części mission impossible 😂.