Dwuczynnikowe uwierzytelnienie od dawna jest standardem w sytuacjach wymagających wyższego poziomu bezpieczeństwa. Kiedyś oparte głównie na tokenach sprzętowych, wraz z rozwojem smartfonów ewoluuje w stronę tokenów programowych. A wraz z ewolucją pojawiają się też nowe zagrożenia.
Szacuje się, że w użyciu znajduje się ok. 40 milionów tokenów RSA. Używane są do zabezpieczania najważniejszych tajemnic w wielu korporacjach oraz instytucjach rządowych czy wojskowych. Jednym z podstawowych aspektów ich bezpieczeństwa, oprócz zapewnienia drugiego czynnika w dwuczynnikowym procesie uwierzytelnienia, jest zapewnienie braku możliwości łatwego skopiowania urządzenia. Behrang Fouladi, badacz pracujący dla firmy SensePost, udowodnił, że ta zaleta nie dotyczy jednak tokenów programowych.
Sklonowany token w działaniu (źródło: SensePost)
Fouladi poddał inżynierii wstecznej oprogramowanie symulujące token RSA SecurID w środowisku MS Windows i odkrył, iż posiadając dostęp do komputera, na którym zainstalowane jest to oprogramowanie, można sklonować wszystkie jego parametry tak, by otrzymać w pełni funkcjonalną kopię, podającą te same hasła jednorazowe w tych samych przedziałach czasowych.
Zabezpieczenia i metoda ich pokonania
Pierwszym zabezpieczeniem tokenów programowych jest ich skojarzenie tylko z jednym fizycznym urządzeniem poprzez wygenerowanie i zapisanie w oprogramowaniu odpowiedniego numeru seryjnego urządzenia. Fouladi odkrył jednak, iż ten numer seryjny obliczany jest na podstawie nazwy systemowej hosta (łatwej do ustalenia poprzez zapytanie DNS lub RPC) oraz identyfikatora SID aktualnego użytkownika (w większości konfiguracji łatwo dostępnego w rejestrze Windows). Numer seryjny urządzenia tokena programowego to pierwsze 10 bajtów funkcji skrótu SHA1 wykonanej na 3 połączonych ciągach: nazwie domenowej, identyfikatorze SID oraz ciągu „RSA Copyright 2008”.
Obliczanie identyfikatora urządzenia (źródło: SensePost)
Drugim zabezpieczeniem, znacznie solidniejszym, jest zabezpieczenie przed kopiowaniem bazy danych tokena, zawierającej przede wszystkim wartość ziarna (seed), w oparciu o które obliczane są hasła jednorazowe. Sama baza w formacie SQLite jest zwykłym plikiem, jednak takie wartości jak ziarno, klucz bazy przypisujący ją do konta użytkownika czy suma kontrolna są zaszyfrowane przy użyciu mechanizmu Data Protection API. Dzięki istnieniu takich narzędzi jak DPAPIck mamy możliwość odszyfrowania tych danych poza oryginalnym środowiskiem. Niezbędne jest do tego jednak skopiowanie odpowiednich kluczy szyfrujących z oryginalnego systemu. Kolejne kroki, niezbędne do sklonowania tokena, wyglądają następująco:
- skopiowanie pliku bazy danych RSASecurIDStorage
- skopiowanie głównego klucza użytkownika z %PROFILEDIR%\Application Data\Microsoft\Protect\%SID%
- skopiowanie głównego klucza systemu z %WINDIR%\system32\Microsoft\Protect\ wraz z hashami LSA (przy uzyciu np. lsadump)
- wgranie wszystkich parametrów do nowego środowiska Windows oraz ustawienie tych samych wartości SID
Jeśli wszystkie kroki zostały wykonane prawidłowo, uruchomiony w nowym systemie token programowy RSA SecureID powinien zacząć podawać te same wartości haseł jednorazowych, co token oryginalny.
Zrzut klucza DPAPI z LSA (źródło: SensePost)
Ograniczenia ataku
Podstawowym ograniczeniem możliwości przeprowadzenia tego ataku jest dostęp do urządzenia, na którym działa oryginalny token. Pewnym ułatwieniem może być fakt, iż atak możliwy jest do przeprowadzenia w formie zdalnej – przy założeniu dostępu na poziomie administratora systemu.
Opisany powyżej przykład ataku dotyczy jedynie platformy Windows i nie jest wykluczone, że platformy mobilne, na których dostępny jest token programowy (Android, iPhone, BlackBerry, Nokia) są lepiej zabezpieczone przed sklonowaniem systemu szyfrowania. Należy też pamiętać, że ilość tokenów programowych na urządzeniach mobilnych rośnie, podobnie jak rośnie liczba zgubionych smartfonów, co sprawia, że rośnie prawdopodobieństwo opracowania podobnego ataku również i na inne platformy. W przypadku smartfonów głównym ograniczeniem w przypadku ataków zdalnych może być konieczność wcześniejszego uzyskania uprawnień roota.
Jak żyć?
Biorąc pod uwagę relatywną łatwość przeprowadzenia ataku sklonowania tokena programowego RSA SecureID i potencjalną wagę zabezpieczanych nim informacji rekomendujemy pozostanie przy tokenach sprzętowych. I szybkie zgłaszanie ich utraty właściwym Działom Bezpieczeństwa.
