[Raport CERT OPL] Co warto wiedzieć o kluczach U2F?

Zrobiliśmy sobie chwilę przerwy od publikacji tekstów z naszego Raportu, ale to nie znaczy, że o Was nie pamiętamy! Tym razem łamy oddajemy naszemu specowi od wszelakich krypto (poza kryptowalutami 😉 ), Konradowi Kamińskiemu. Opowie Wam o kluczach U2F: co, jak, dlaczego, po co i czy warto? Oczywiście to nie jedyny tekst, który warto przeczytać! Cały raport znajdziecie tutaj.

Od pewnego czasu technologia kluczy U2F pojawia się coraz częściej w artykułach i na konferencjach. Często można z zamieszczonych tam wypowiedzi odnieść wrażenie, że klucz U2F to panaceum na wszelkie sieciowe zagrożenia. Tworzy to wśród korzystających z tego rozwiązania (fałszywe) poczucie bezpieczeństwa. Artykuł przedstawia pokrótce opis działania U2F oraz wskazuje część zagrożeń, którymi opisywane rozwiązanie się zajmuje.

U2F (Universal 2nd Factor) to otwarty standard uwierzytelnienia (głównie do aplikacji webowych), działający bez sterowników. Oczywiście system operacyjny i przeglądarki muszą obsługiwać urządzenia U2F. Sam proces użycia klucza U2F jest dwuetapowy. Pierwszy etap, wykonywany jednorazowo dla danej usługi, to rejestracja klucza w usłudze oraz jej rejestracja w kluczu. Obie strony wiążą kryptograficznie klucz z usługą (nazwą DNS) oraz indywidualnym losowym identyfikatorem. Po tym etapie następuje etap wielokrotnego uwierzytelniania. Polega on na podpisaniu przez klucz prywatny z U2F losowego ciągu wysłanego z serwera usługi wraz z zapisanym identyfikatorem. Serwer weryfikuje podpis za pomocą zapisanego w trakcie rejestracji klucza publicznego. Klucz odpowiada tylko na żądania podpisu pochodzącego od zapisanych w nim usług i unikalnego identyfikatora. Implementacja po stronie przeglądarki U2F działa w oparciu o wywołania funkcji JavaScript. Interfejsem do kluczy U2F jest USB, NFC a także Bluetooth.

Uwierzytelnienie U2F. Źródło: http://usbauth.com/

Klucze U2F działają zatem w warstwie aplikacji webowej (wywołania JavaScript), po wcześniejszym poprawnym nawiązaniu komunikacji TLS (Transport Layer Security) i uwierzytelnieniu hasłem. To już wskazuje, że przeprowadzenie ataku MITM (Man In The Middle) na sesję HTTPS (Hypertext Transfer Protocol Secure), w której wykorzystuje się logowanie dwuskładnikowe (2FA) oparte o U2F, nie różni się zasadniczo od tego, w którym nie używamy klucza U2F. Ograniczeniem dla tego ataku jest prawidłowo nawiązany kanał HTTPS (zielona kłódka), co przy instalacji w przeglądarce lub systemie zaufanego certyfikatu urzędu, np. z Burp Suite, może być spełnione. Podsumowując: U2F wprowadza dodatkowy czynnik w uwierzytelnianiu, ale nie ogranicza przechwytywania ruchu w otwartej sesji użytkownika – nie zapewnia poufności, zarówno podczas fazy uwierzytelniania do usługi webowej, jak i samego korzystania z niej.

W twierdzeniu o zabezpieczaniu połączenia w przypadku phishingu lub innych ataków typu SSLStrip, jest dużo prawdy. Wynika to z wymagań do działania w przeglądarce i wywołania funkcji JavaScript związanych z U2F. Klucz U2F powiązany jest z nazwą domenową (FQDN) hosta pytającego o uwierzytelnienie. Zatem klucz generowany podczas jednokrotnego rejestrowana (registration phase) dla accounts.google.com, będzie dostępny tylko dla uwierzytelniania (authentication phase) w tej domenie. Z przypadkowymi (typosquatting) lub celowymi literówkami stosowanymi w phishingu, klucz ten nie będzie działać, jednak nadal może nastąpić skuteczne wyłudzenie loginu/hasła. Po drugie, sesja TLS musi być nawiązana bez ostrzeżeń (zielona kłódka). Dla połączeń nieszyfrowanych (HTTP) klucz U2F nie zadziała. Powyższe zabezpieczenia ograniczają obszar ataku, jednak w przypadku komputera w przysłowiowej kawiarence internetowej lub po skłonieniu użytkownika do zainstalowania certyfikatu urzędu CA kontrolowanego przez atakującego, nie zapewnią bezpieczeństwa. Wykradzione poświadczenia będą mogły być wykorzystane w ograniczonym zakresie (nie będzie możliwe obejście weryfikacji dwuetapowej), ale jeśli to samo hasło było stosowane w innych serwisach, to problem pozostaje.

Problemem dla bezpieczeństwa rozwiązania opartego o U2F jest możliwość przeprowadzenia ataku MITM. Wydawać się może, że ataki MITM można wyeliminować przez poprawne wdrożenie mechanizmu HPKP (HTTP Public Key Pinning)[4]. Czy można jednak skutecznie ograniczyć te ataki tylko w oparciu o nagłówki HPKP? Stosowanie przypinania certyfikatów (certificate pinning) w HTTPS opartych o ten mechanizm jest niestety skuteczne tylko w pewnych przypadkach ataku MITM. Chodzi o ataki na HTTPS z wykorzystaniem wydanego niepoprawnie (nie przez właściciela domeny/serwera) certyfikatu u innego globalnie zaufanego dostawcy certyfikatów (posiadającego akredytację WebTrust i wpisanego do systemowych magazynów zaufanych certyfikatów przeglądarek/systemów) lub zgodę przez użytkownika na wykorzystanie niezaufanego certyfikatu witryny internetowej. Jednak jest to mechanizm nieskuteczny w przypadku dodania własnego certyfikatu zaufanego urzędu do osobistego magazynu certyfikatów. Specyfikacja HPKP zostawiła taką lukę [5], w celu umożliwienia inspekcji ruchu HTTPS wewnątrz organizacji przez mechanizmy bezpieczeństwa (TLS Inspection). W tym celu urządzenie brzegowe (PROXY) terminuje ruch TLS, następnie sprawdza jego zawartość i ponownie szyfruje ruch do klienta.

Wracając do kluczy U2F, droższe ich modele mają zintegrowane funkcje magazynu haseł, OTP i karty inteligentnej. W przypadku karty inteligentnej można stosować dwustronne uwierzytelnienie TLS, zapewaniające bezpieczny kanał end to end w trakcie nawiązywania połączenia, ale to już jest inny mechanizm, pracujący niezależnie od popularnych produktów FIDO i wymagający sterowników (np. do obsługi PKCS#11). Wykorzystanie tych mechanizmów wykracza poza ramy tego artykułu.

Osobną kwestię stanowi zagrożenie dla prywatności. Źle zaimplementowane klucze U2F mogą być identyfikowalne za pomocą zarówno kluczy publicznych, jak i na podstawie certyfikatów urządzenia. Przykładem takiego zagrożenia jest rejestracja tego samego klucza w kontekście różnych tożsamości, co może to ułatwić dostawcy je powiązać.

Czy warto zatem stosować klucze U2F? Tak, ale istotna jest świadomość, że nie jest to rozwiązanie zabezpieczające przed wszystkimi rodzajami ataków. Stosowanie kluczy U2F znacznie podnosi poprzeczkę w przypadku przejmowania tożsamości w danym serwisie, nie zwalnia jednak ze stosowania zaleceń bezpieczeństwa odnoszących się m.in. do niestosowania tych samych haseł w różnych serwisach, weryfikacji prawidłowości połączenia HTTPS, czy wyjątkowo sceptycznego odnoszenia się do potrzeby instalacji zaufanych certyfikatów urzędów (CA). Warto także mieć zawsze alternatywny sposób dostępu do usługi (lub drugi skonfigurowany i zarejestrowany w danej usłudze klucz U2F), który zastąpi klucz podstawowy w razie jego zagubienia.

Konrad Kamiński

Bibliografia:

1. https://fidoalliance.org/how-fido-works/
2. https://padlock.argh.in/2018/08/25/u2f-firefox-google.html
3. https://security.stackexchange.com/questions/157756/mitm-attacks-on-fido-uaf-and-u2f
4. https://kryptosfera.pl/post/http-public-key-pinningrobisz-to-zle/
5. https://tools.ietf.org/html/rfc7469#section-2.6
6. https://developer.mozilla.org/pl/docs/Web/API/Web_Authentication_API
7.https://w3c.github.io/