Zespół CERT Polska zaobserwował interesującą technikę phishingową zastosowaną wobec użytkowników popularnego polskiego agregatora treści. W sieci zrobiło się również głośno za sprawą pojawienia się nowego narzędzia Modlishka służącego do automatyzacji tego typu ataków. Artykuł opisuje mechanizm ataku oraz przedstawia nasze rekomendacje dla twórców stron internetowych.

 

Mechanizm ataku

Zaobserwowany atak polega na skierowaniu użytkownika na fałszywą domenę, która często nazywa się bardzo podobnie do prawdziwej usługi. Odmiennie od obserwowanych wcześniej technik phishingowych, fałszywy serwer nie przesyła użytkownikowi podrobionej wersji strony, tylko pośredniczy w komunikacji z prawdziwą usługą.

Użytkownik łączy się z fake-google.pl, a ten serwer przesyła żądania dalej do prawdziwej usługi pod adresem google.pl, jednocześnie przechwytując wszystkie informacje (loginy, hasła, kody 2FA, dane kart płatniczych).

 

Dodatkowym elementem uwiarygodniającym tego typu phishing jest to, że strona w domenie phishingowej będzie wyglądała i zachowywała się dokładnie tak samo, jak oryginalny serwis internetowy pod który się podszywa. To znaczy, że ofiara może w niezakłócony sposób korzystać z usługi, jednocześnie pozwalając atakującemu na przechwytywanie całej aktywności.

Fałszywa strona może też posiadać prawidłowy certyfikat SSL (typu DV), więc przeglądarka będzie prezentowała charakterystyczną ikonkę kłódki. Warto pamiętać, że podstawowy certyfikat SSL (bez wpisanej nazwy organizacji) zapewnia nas jedynie, że łączymy się z serwerem należącym do prawowitego właściciela domeny. Atakujący nie ma problemu z pozyskaniem certyfikatu, ponieważ jest faktycznym właścicielem swojej domeny phishingowej (np. fake-google.pl). Uzyskanie podstawowego certyfikatu możliwe jest nieodpłatnie za pomocą usług LetsEncrypt czy CloudFlare.

 

Implementacja ataku

Na portalu GitHub został udostępniony projekt drk1wi/Modlishka, który stanowi praktyczną implementację ataku z użyciem serwera MITM. Narzędzie pozwala na automatyczne przechwytywanie danych logowania użytkowników, ciasteczek sesyjnych, usuwanie wszystkich nagłówków związanych z bezpieczeństwem (Cross-origin resource sharing, Content Security Policy) oraz wstrzykiwanie dodatkowego kodu JavaScript w treść oryginalnej strony.

Pomimo że przeznaczeniem wspomnianego narzędzia jest dokonywanie kontrolowanych testów penetracyjnych, należy mieć świadomość że może ono również zostać wykorzystane do przeprowadzania nielegalnych ataków phishingowych. Ponadto, atakujący mogą dysponować innymi narzędziami tego typu o różnym stopniu zaawansowania.

 

Sposoby ochrony

Obecnie rekomendujemy twórcom stron internetowych trzy sposoby ochrony przed omówionym wcześniej atakiem. Każdy ze sposobów różni się stopniem zaawansowania oraz wymaganym nakładem manualnych działań ze strony administratora.

 

Wprowadzenie uwierzytelniania dwuskładnikowego U2F

Warto rozważyć implementację Web Authentication API i umożliwić użytkownikom logowanie się za pomocą tzw. sprzętowych tokenów U2F. Uwierzytelnianie takim tokenem realizowane jest na poziomie przeglądarki internetowej, a nie w obrębie aplikacji.

Diagram sekwencyjny uwierzytelniania z użyciem tokenów U2F, gdzie “relying party” to strona internetowa, “client” to użytkownik, a “U2F Device” to sprzętowy token USB. Kolorem zielonym zaznaczono elementy ochrony przed phishingiem. Źródło: https://developers.yubico.com/U2F/Protocol_details/Overview.html

 

Ponieważ do każdego żądania uwierzytelniania przekazanego do tokena U2F przeglądarka dołącza m. in. informację na temat domeny żądającego serwisu (“origin”), użycie omawianej techniki phishingowej z wykorzystaniem proxy spowoduje negatywną weryfikację podpisu cyfrowego w ostatnim etapie. W związku z tym, phishing nie będzie skuteczny, a ponadto strona internetowa będzie mogła zablokować konto zaatakowanego użytkownika i powiadomić go o próbie oszustwa.

 

Modyfikacja schematu uwierzytelniania e-mailem

Należy podkreślić, że klasycznie stosowane formy uwierzytelniania dwuskładnikowego nadal są podatne na atak omawiany w tym artykule. Ponieważ atakujący zwyczajnie zestawia proxy pomiędzy użytkownikiem, a prawdziwym serwerem, wszystkie metody oparte na „przepisywaniu kodu” nie stanowią w tym przypadku żadnej dodatkowej ochrony. Pomocna może być jednak modyfikacja istniejących schematów w taki sposób, aby użytkownik zamiast przepisywać kod musiał kliknąć w link przesłany e-mailem.

 

Przykładowy e-mail z linkiem do logowania.

W celu dodatkowego zabezpieczenia użytkownika, po otwarciu linku powinno nastąpić sprawdzenie ciasteczka sesyjnego w celu zweryfikowania, czy użytkownik faktycznie zainicjował logowanie w tej samej przeglądarce w której kliknął w link przesłany e-mailem. Korzystanie z takiej metody może jednak stwarzać problemy niektórym użytkownikom, którzy używają programu pocztowego, jednocześnie surfując po Internecie w trybie incognito lub za pomocą przeglądarki, która nie jest ustawiona w systemie jako domyślna (stąd wskazówka dotycząca ręcznego kopiowania linku w e-mailu).

Niestety, tego typu modyfikacja nie byłaby zbyt praktyczna w przypadku SMSów (wymagane ręczne przepisywanie linku do przeglądarki albo zawsze aktywnego połączenia internetowego w telefonie), ani Authenticatora (wymagane przerobienie aplikacji w taki sposób, aby wyświetlała powiadomienie o logowaniu i samodzielnie wysyłała kod 2FA na serwer w przypadku zatwierdzenia przez użytkownika).

 

Detekcja MITM za pomocą JavaScriptu

Opisywany atak można skontrować poprzez dodanie do strony internetowej dodatkowego skryptu, który sprawdzi nazwę hosta zawartą w window.location.host i poinformuje autora oryginalnej strony, że dochodzi do ataku MITM. Należy mieć na uwadze, że operator phishingowego proxy (atakujący) może skontrować tę technikę, wycinając skrypt z oryginalnej odpowiedzi serwera np. za pomocą wyrażeń regularnych.

 

Przykładowy skrypt, który sprawdza czy strona została załadowana w prawidłowej domenie i jeżeli nie – tworzy niewidzialny obrazek, który wyśle zapytanie na oryginalny serwer, przekazując nazwę domeny phishingowej w parametrze. Nadmiarowe operacje łączenia ciągów znaków służą zmyleniu narzędzi do uruchamiania phishingowych proxy, które automatycznie wyszukują oryginalną domenę i próbują ją podmieniać.

 

Technikę detekcji za pomocą JavaScript można rozwijać na zasadzie “wyścigu zbrojeń” z atakującymi. Przykładowo, dopisać powyższy kod do jednego ze skryptów już wykorzystywanych na stronie – najlepiej takiego, który jest niezbędny do funkcjonowania strony, ale nie jest biblioteką. Następnie, zastosować obfuskację całego pliku .js za pomocą jednego z ogólnodostępnych narzędzi (np. obfuscator.io), albo według własnych pomysłów. Atakujący wciąż będzie mógł ominąć zabezpieczenie, ale w tym celu będzie musiał ponieść zdecydowanie większy wysiłek niż jedynie pobranie odpowiedniego narzędzia do uruchamiania proxy phishingowych i jego skonfigurowanie.

W repozytorium CERT-Polska/anti-modlishka na GitHubie prezentujemy proof-of-concept bardziej zaawansowanej mitygacji, która wykorzystuje zobfuskowany JavaScript w celu wykrycia i zablokowania proxy takich jak Modlishka, czy Evilginx. Należy mieć na uwadze, że z założenia możliwe jest obejście tego zabezpieczenia. Warto jednak rozważyć samodzielną implementację podobnego (nie identycznego) mechanizmu

 

Blokowanie istniejących proxy za pomocą podstrony-pułapki

W przypadku wystąpienia incydentu związanego z phishingiem MITM, administrator strony internetowej może zablokować znane proxy wpuszczając je w “pułapkę”.

Wdrożenie tej techniki należy rozpocząć od stworzenia nowej podstrony (np. pod adresem /trap/<losowy_ciąg_znaków>) i oprogramowania jej w taki sposób, aby każde wejście na nią powodowało czasowe zablokowanie IP odwiedzającego. Następnie należy wejść na tę podstronę w domenach phishingowych proxy. Oryginalny serwis jako adresy IP odwiedzających odnotuje adresy należące do serwerów atakującego, a to pozwoli na unieszkodliwienie danego, konkretnego serwera proxy. Podstrona pułapka nie powinna być w żaden sposób widoczna dla użytkowników, a jej adres powinien być nieprzewidywalny i zmieniać się co jakiś czas.

W przypadku zdecydowania się na użycie takiego sposobu obrony należy również uważać, aby nie ujawnić swojego prawdziwego adresu IP samemu atakującemu, który może na swoim serwerze proxy dysponować dziennikiem dostępu (access log) – w tym przypadku pomocny może być TOR lub inne usługi VPN. W przypadku dużej skali ataku, technikę tę można zautomatyzować, jeżeli połączy sie ją np. z opisywaną wcześniej detekcją fałszywych domen za pomocą skryptów JavaScript.

 

Podsumowanie

Artykuł zaprezentował technikę phishingową opartą na wykorzystaniu serwera man-in-the-middle. Na chwilę obecną w Polsce odnotowaliśmy przypadki użycia podobnych technik w stosunku do banków (nazywanych lokalnie “webfake” lub “redirect”), podmioty z sektora finansowego posiadają jednak zaawansowane systemy autyfraudowe które są w stanie wykryć przypadki tego typu ataków. W pozostałych sektorach nie obserwujemy wykorzystania opisywanej techniki na szeroką skalę. Niemniej jednak, jest to stosunkowo prawdopodobny kierunek rozwoju bieżących zagrożeń, warto więc przeprowadzić stosowne analizy ryzyka i rozważyć implementację mechanizmów zabezpieczających.