Już kiedyś pisałem o tym, że błędna wiedza może być bardziej niebezpieczna niż sam brak takowej wiedzy. Ostatnimi laty coraz więcej serwisów umożliwia dwuskładnikowe uwierzytelnianie. Korzystają przy tym ze standardowego pierwszego składnika (coś, co wiemy) – loginu i hasła oraz drugiego składnika (coś, co mamy) – kodu sms/tokenu. Oczywiście poprawia to bezpieczeństwo kont użytkowników, jednakże wraz z tymi zmianami narodził się niebezpieczny mit.
Wielu przeciętnych zjadaczy chleba, ale i grono specjalistów od bezpieczeństwa ma błędne przekonanie, że zabezpieczenie konta przez drugi składnik uwierzytelnienia w postaci kodu sms, tokenu z aplikacji czy też metody „passwordless” (potwierdzanie chęci zalogowania w dedykowanej aplikacji) chroni przed atakami phishingowymi. Bezpieczeństwo ich kont zostało oczywiście podniesione. Niemniej ochrona ta polega przed scenariuszem gdzie ich login i hasło wycieknie albo zostanie wykradzione. Dobrze przygotowany phishing nadal spowoduje przejęcie ich kont np. poprzez wykradnięcie ciasteczka sesyjnego.
Phishing z przechwyceniem ciasteczka sesyjnego
Taki atak można przeprowadzić, korzystając z proxy pośredniczącego pomiędzy ofiarą a prawdziwą stroną. Wygląda on podobnie jak man in the middle i polega na przechwyceniu ruchu pomiędzy użytkownikiem danej strony internetowej a stroną internetową. W tym celu można wykorzystać gotowy framework Evilginx stworzony przez Kube Gretzky. Bazuje on na funkcjonalności proxypass w nginxie i umożliwia rozszyfrowywanie i ponowne szyfrowanie pakietów w locie. Pozwala to na przechwycenie loginu, hasła i ciasteczka sesyjnego użytkownika złapanego na stronę phishingową. Okazuje się, że większość znanych nam serwisów (prawdopodobnie z powodów, lepszego „user expierience”) nie wiąże tokenu sesyjnego z danym adresem ip. Tym samym przechwycone ciastko można użyć w innej przeglądarce, na innym komputerze i z innym adresem IP.
Prześledźmy ten proces na przykładzie przejęcia konta ofiary do Office365:
- Atakujący rejestruje domenę podobną do oryginalnej strony i podsyła ją ofierze. Jako że Evilginx działa jak proxy to strona, na którą wchodzi ofiara, wygląda identycznie do prawdziwej. Witryna posiada „zieloną kłódeczkę”, ponieważ posiada prawidłowy certyfikat SSL i jest oznaczona jako bezpieczna.
- Ofiara podaje swój korporacyjny adres mailowy.
- Ofiara zostaje przekierowana na brandowaną, korporacyjną wersję ekranu logowania gdzie podaje swoje hasło. Nadal znajduje się na fałszywej domenie i serwerze Evilginxa.
- Ofiara korzysta z mechanizmu „passwordless” i zostaje poproszona o potwierdzenie logowania w aplikacji na telefonie.
- Po zatwierdzeniu ofiara jest prawidłowo zalogowana do swojego konta i może z niego w pełni korzystać. Nadal jednak znajduje się na fałszywej domenie i serwerze Evilginxa.
- Evilginx przechwycił login i hasło ofiary oraz co ważniejsze ciasteczko sesyjne.
- Atakujący może teraz takowe ciasteczko zaimportować u siebie w przeglądarce.
- Po zaimportowaniu ciasteczka, atakujący jest zalogowany na koncie ofiary. Może nim dowolnie zarządzać oraz usługami powiązanymi z tym kontem.
Co zrobić jak żyć?
Żeby uchronić się przed skutkami phishingu, najlepiej byłoby być mega czujnym użytkownikiem Internetu i nigdy nie dać się oszukać. Niemniej istnieje też rozwiązanie techniczne, które może wspomóc naszą paranoidalność. Jest nim klucz U2F (universal second factor) np. YubiKey. Nawet jeśli nie zorientujesz się, że korzystasz z fałszywej strony i użyjesz klucza U2F to dzięki kryptografii asymetrycznej taka próba logowania nie powiedzie się. Upraszczając taki klucz rozpozna, że znajduje się na fałszywej domenie i po prostu nie zadziała.
Klucze U2F fajnie przedstawił Piotrek z Niebezpiecznika:
Warto wspomnieć, że menadżery haseł, które oferują integrację z przeglądarką i powiązują hasło z daną stroną też chronią przed phishingiem.
Powiedziałbym, że pomagają, ale nie chronią. Podpowiedzą, że dany adres strony jest nieznany (nie w scenariuszu ataków na DNS), ale nadal będziesz mógł podać swoje dane logowania i przejść przez proces uwierzytelnienia. U2F uniemożliwi Ci zalogowanie na fałszywej stronie.
HTTPS chroni przed MITM (nwm o jaki rodzaj ataku DNS Ci chodzi, ale nie słyszałem o żadnych nowych ostatnio).
Oczywiście, użytkownik może ręcznie przekleić hasło z menadżera na prawdziwej stronie, ale taki użytkownik, który zignoruje poważne ostrzeżenie pewnie też uruchomi malware, który dostanie w załączniku albo zainstaluje aplikację do zdalnego pulpitu na prośbę oszusta.
Z DNSem nadal ktoś może zignorować ostrzeżenie certyfikatu selfsigned i U2F uchroni go przed stratą konta.
Jako uzupełnienie polecam poniższy artykuł:
Cybercriminals crave cookies, not passwords
https://cybernews.com/security/cybercriminals-crave-cookies-not-passwords/