Dziś znowu w nawiązaniu do Niebezpiecznika: Zaufany Profil ePUAP nie jest bezpieczny — twierdzi jego autor. I konkretne stwierdzenie:
Atak na profil zaufany ogranicza się do przejęcia kontroli nad skrzynką poczty elektronicznej użytkownika, co umożliwia całkowite przejęcie wykorzystania profilu zaufanego przez atakującego.
Chodzi oczywiście o funkcję "przypominania" hasła. ePUAP nie jest ani pierwszą, ani jedyną aplikacją, w której mechanizm ten został zaimplementowany źle.
W OWASP ASVS (sekcja V2 - Authentication Verification Requirements) znajdują się następujące wymagania:
V2.7 Verify that the strength of any authentication credentials are sufficient to withstand attacks that are typical of the threats in the deployed environment.
V2.8 Verify that all account management functions are at least as resistant to attack as the primary authentication mechanism.
V2.9 Verify that users can safely change their credentials using a mechanism that is at least as resistant to attack as the primary authentication mechanism.
Zmiana zapomnianego hasła może być traktowana jako account management function (V2.8) i na pewno jest sposobem, w którym users can safely change their credentials (V2.9).
Jeśli jestem atakującym i chcę przejąć tożsamość użytkownika, wówczas mogę między innymi:
- próbować odgadnąć jego hasło,
- zmienić jego hasło na nowe,
Niestety, często okazuje się, że łatwiejszym celem dla atakującego jest ta druga możliwość - nadużycie mechanizmu resetu hasła dostępnego w aplikacji. Częstym problemem są tak zwane security questions, na które atakujący może bez problemu odpowiedź znaleźć (ach te serwisy społecznościowe), lub zgadnąć (np. pytanie o ulubiony kolor). Innym dość często stosowanym rozwiązaniem jest wysyłanie linka z losowym tokenem, który użytkownik może użyć w celu resetu hasła.
W takim przypadku założenie jest proste - tylko uprawniony użytkownik ma dostęp do wysłanego linka. Oznacza to, że:
- treść wiadomości jest szyfrowana w trakcie transmisji,
- tylko uprawniony użytkownik ma dostęp do swojej skrzynki pocztowej,
Zwróćmy dodatkowo uwagę, że token do resetu hasła jest niczym innym, jak nowym credentialem, czyli jak najbardziej podpada pod wymaganie any authentication credentials are sufficient to withstand attacks (...) (V2.7).
Pierwsza sprawa - wiadomość nie jest szyfrowana w trakcie transmisji, a przynajmniej nie możemy mieć pewności, że jest. Nie ma gwarancji, że połączenie między serwerem nadawcy a serwerem odbiorcy jest szyfrowane. Nawet jeśli jest, atakujący może próbować wykonać atak typu man-in-the-middle na transmisję w celu przejęcia takiej wiadomości.
Druga sprawa - nie ma gwarancji, że skrzynka odbiorcy jest wystarczająco dobrze chroniona. Prawdopodobnie również i tutaj jest jakiś mechanizm resetu hasła. Być może znowu security questions, być może link przesyłany na inne konto. Nagle okazuje się, że bezpieczeństwo naszego mechanizmu resetu hasła staje się zależne od mechanizmu resetu hasła w jednym z systemów, z których korzysta nasz użytkownik.
Może się również okazać tak, że w pewnym miejscu wykorzystany jest stary adres e-mail, który już nie istnieje. Ktoś mógł przestać opłacać domenę albo przestać korzystać z darmowego konta e-mail, które w rezultacie zostało "zwolnione". W efekcie atakujący rejestrując na nowo starą domenę lub zakładając na nowo stary adres e-mail może również uzyskać dostęp do nowych danych uwierzytelniających (linka z resetem hasła).
Warto zwrócić uwagę na to, jak bardzo zmniejsza się zaufanie do zaufanego profilu. Na początku przy jego zakładaniu trzeba go "potwierdzić". W trakcie tej operacji potwierdzana jest tożsamość użytkownika (pomijam tutaj opcję samozaufania, w której użytkownik sam potwierdza swój profil z wykorzystaniem certyfikatu kwalifikowanego - tożsamość użytkownika została zweryfikowana w trakcie wystawiania certyfikatu).
Czy jednak później można mieć pewność, że osoba, która korzysta z profilu zaufanego jest tą samą osobą, która go zakładała, i której tożsamość została zweryfikowana? Moim zdaniem nie. Kravietz kiedyś wspominał o zróżnicowanych poziomach uwierzytelnienia (Zróżnicowane poziomy uwierzytelnienia), gdzie pewność potwierdzenia tożsamości uwierzytelniającego się użytkownika jest różna, w zależności od istotności aplikacji. Metoda uwierzytelnienia oparta o hasło daje ograniczoną pewność w tym zakresie. W zasadzie już w chwili potwierdzania profilu, profil może być pod kontrolą zupełnie innej osoby.
Hasło mogło zostać odgadnięte, podsłuchane, lub zmienione z wykorzystaniem słabego mechanizmu resetu hasła. Nie wiem jaka jest aktualnie liczba użytkowników systemu ePUAP. Gdyby jednak ten system był wykorzystywany powszechnie, to nie widzę powodów, dla których hasła wybierane przez użytkowników tego systemu miałyby być istotnie różne od tych, które użytkownicy wybierają zwykle. No i jeszcze ten problem z wykorzystaniem jednego hasła w wielu miejscach...
Z drugiej strony ePUAP nie powstał bez powodu. Gdyby w tym systemie wymuszone zostało uwierzytelnienie dwuskładnikowe, to mam dziwne przeczucie, że byłby on równie (nie)popularny, jak podpis cyfrowy. Zresztą wspominał o tym Kravietz.
Kolejnym sposobem pozwalającym na podszycie się pod innego użytkownika (obywatela) jest przejęcie sesji. Nie wiem jak dokładnie działa ePUAP, ciekawy jestem na przykład, czy spełnione jest to wymaganie ASVS:
V2.10 Verify that re-authentication is required before any application-specific sensitive operations are permitted.
Na koniec odsyłam do dwóch materiałów odnośnie funkcji resetu zapomnianego hasła:
To, że jakieś rozwiązanie sprawdza się w jakimś innym kraju wcale nie znaczy, że będzie się sprawdzać i u nas.