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, iż 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, iż 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ć, iż podstawowy certyfikat SSL (bez wpisanej nazwy organizacji) zapewnia nas jedynie, iż łą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 dzięki 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 iż przeznaczeniem wspomnianego narzędzia jest dokonywanie kontrolowanych testów penetracyjnych, należy mieć świadomość iż 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ę dzięki 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ć, iż klasycznie stosowane formy uwierzytelniania dwuskładnikowego przez cały czas 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 dzięki przeglądarki, która nie jest ustawiona w systemie jako domyślna (stąd wskazówka dotycząca manualnego kopiowania linku w e-mailu).
Niestety, tego typu modyfikacja nie byłaby zbyt praktyczna w przypadku SMSów (wymagane manualne 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 dzięki 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, iż dochodzi do ataku MITM. Należy mieć na uwadze, iż operator phishingowego proxy (atakujący) może skontrować tę technikę, wycinając skrypt z oryginalnej odpowiedzi serwera np. dzięki wyrażeń regularnych.
Przykładowy skrypt, który sprawdza czy strona została załadowana w prawidłowej domenie i o ile 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 dzięki 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, iż 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 dzięki 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 systemu 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ć, o ile połączy sie ją np. z opisywaną wcześniej detekcją fałszywych domen dzięki 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.
