Pod koniec 2013 roku do zespołu CERT Polska dotarły potwierdzone informacje o pojawianiu się komunikatów sugerujących modyfikację stron bankowych przez złośliwe oprogramowanie na… urządzeniach iPhone. Użytkownicy takich urządzeń oglądali komunikat o zmianie numeru konta bankowego, która powinna zostać potwierdzona kodem jednorazowym. Sam scenariusz był nam dobrze znany jako jedna z wersji injectów wykorzystywanych przez trojany bankowe. Skąd jednak taki trojan na iPhonie? Ponieważ byłby to pierwszy przypadek tego typu ataku na tę platformę, w dodatku ukierunkowany na polskich klientów systemów bankowych, zwrócił on naszą szczególną uwagę. W wyniku analizy zostało ustalone wiele możliwych scenariuszy przeprowadzenia ataku, włącznie z metodami infekcji urządzenia z systemem iOS. Niestety, z powodu braku wystarczających szczegółów dotyczących infekcji nie byliśmy w stanie jednoznacznie określić metody przeprowadzenia ataku.

Kluczem do rozwiązania zagadki okazały się ostatnie serie informacji o podatnościach w routerach domowych, umożliwiających zdalną zmianę ich konfiguracji. W wyniku wykorzystania podatności przestępcy doprowadzali do zmiany serwerów DNS. W efekcie takiej modyfikacji,przez podstawione serwery DNS obsługiwane były zapytania o nazwy domenowe wysyłane przez wszystkie urządzenia z sieci wewnętrznej – na przykład domowej sieci bezprzewodowej, do której mogą się łączyć oczywiście także telefony z dowolnym systemem operacyjnym. W rzeczywistości na telefonie (ani żadnym innym urządzeniu) nie było potrzeby instalowania jakiegokolwiek złośliwego oprogramowania. W jaki więc sposób dochodziło do umieszczania na stronie banku dodatkowych treści?

Zastanówmy się najpierw jakie są skutki przejęcia zapytań DNS przez serwer przestępców. Pierwszą konsekwencją jest naruszenie prywatności. Przestępcy są bowiem w stanie sprofilować użytkownika na podstawie domen, z którymi próbuje się łączyć. Na tym jednak problemy się nie kończą. Bardziej wyrafinowanym i groźnym dla użytkownika działaniem jest wykorzystanie DNS do przekierowania ruchu na serwery będące pod kontrolą przestępców. Wystarczy, że odpowiedzi z serwera będą nieco zmodyfikowane dla wybranych bądź wszystkich domen. Zamiast na serwer, z którym rzeczywiście planował połączyć się klient, będzie on w sposób niezauważony przekierowywany na podstawioną maszynę. W rezultacie przestępcy uzyskują nie tylko dostęp do przesyłanych danych, ale także możliwość ich modyfikacji w locie (atak man-in-the-middle).

Jak wygląda atak w opisywanym przypadku?

W kręgu zainteresowania przestępców znaleźli się przede wszystkim klienci bankowości elektronicznej. Podstawione serwery DNS fałszują odpowiedzi dla niektórych domen bankowych, nie ingerując jednocześnie w wyniki innych zapytań. W rezultacie ruch do tych domen przesyłany jest w sposób przezroczysty przez serwery przestępców, gdzie dodawana jest dodatkowa zawartość – na przykład znane wcześniej z trojanów bankowych żądanie potwierdzenia kodem jednorazowym zmiany numeru konta (w rzeczywistości w tle definiowany był nowy zdefiniowany odbiorca). W tym momencie u niektórych czytelników powinna zaświecić się czerwona lampka – czy do ochrony przed takim atakiem nie powinien wystarczyć poczciwy SSL? Oczywiście, powinien, a nawet rzeczywiście chroni, ale…

Wiele osób rozpoczyna wizytę w banku od strony informacyjnej, na której wciska przycisk „Zaloguj”, prowadzący do serwisu transakcyjnego. Problem w tym, że dopiero ta docelowa strona (z formularzem logowania) jest zabezpieczona przez SSL. Strona informacyjna już nie… Przestępcy modyfikują więc w locie odnośniki na stronach informacyjnych tak, by zamiast do serwera banku prowadziły pod specjalnie spreparowany adres, rozpoczynający się od ciągu ssl-. Połączenie takie (bez SSL) prowadzi do serwera pod kontrolą przestępców, skąd dalej (po odpowiednich modyfikacjach zawartości) w przezroczysty sposób i już z wykorzystaniem SSL jest przekierowywane do banku. Z punktu widzenia klienta w przeglądarce odbywa się normalna sesja bankowości elektronicznej, lecz pod zmienionym adresem (choć w domenie banku) i bez szyfrowania, a więc bez legendarnego symbolu kłódeczki! Powodzenie ataku zależy od czujności użytkownika, który wychwyci te różnice.

Ryc. 2. Fałszywa strona banku BGŻ, na którą przekierowywani są klienci przez złośliwe serwery DNS. Ciekawostką jest podmieniona w locie wiadomość od banku dotycząca weryfikacji adresu w pasku przeglądarki.

Podsumowując – przyczyną skutecznego ataku są podatności w routerach domowych, pozwalające na modyfikację wpisanych serwerów DNS. Efekty obejmują wszystkich użytkowników danej sieci lokalnej, niezależnie od wykorzystywanych przez nich platform i systemów operacyjnych (o ile pobierają dynamicznie ustawienia DNS z routera). W rezultacie przeprowadzany był atak man-in-the-middle, w którym podmieniana była zawartość niektórych serwisów bankowych, prowadząc do wyłudzenia danych logowania klientów i jednorazowych kodów autoryzacyjnych, a w rezultacie do kradzieży pieniędzy z konta. Ze względu na ingerencję w przesyłaną pomiędzy bankiem i klientem zawartość niemożliwe jest zachowanie integralności połączenia SSL. W związku z tym możliwe jest stwierdzenie, że ma się do czynienia z atakiem przez obserwację informacji o szyfrowaniu w przeglądarce (wskażnik kłódeczki, alarmy o certyfikacie).

Jak wykryć, czy jest się ofiarą ataku?

Problem dotyczy osób łączących się z Internetem za pośrednictwem lokalnego routera. Najpewniejszą metodą sprawdzenia, czy doszło do podmiany jego ustawień jest sprawdzenie adresów serwerów DNS w panelu konfiguracyjnym. Informacje o sposobie dostępu do panelu konfiguracyjnego routera można znaleźć w instrukcji obsługi. Jeżeli nie pamiętasz nazwy użytkownika i hasła do panelu, możesz przywrócić ustawienia fabryczne.

Prostszym, choć mniej pewnym sposobem jest sprawdzenie, czy nazwy domenowe banków są na Twoim komputerze rozwiązywane prawidłowo. Poniżej znajduje się lista domen, których adresy modyfikowane są przez przestępców wraz z prawidłowymi adresami IP (Uwaga! Lista może nie być kompletna. Przestępcy mogą w każdej chwili zmienić listę domen, do których ruch przechwytują.)

Aby sprawdzić, czy adresy rozwiązywane są prawidłowo, możemy wydać polecenie w linii poleceń Windows lub terminalu Linux: nslookup domena.pl, na przykład:

Aby uruchomić linię poleceń w systemie Windows należy wcisnąć przycisk Start i wpisać w oknie wyszukiwania: cmd, a następnie potwierdzić klawiszem Enter.

Następnie należy porównać, czy dla wybranego adresu (1) otrzymany adres IP (2) zgadza się z tabelą powyżej. Otrzymanie innego wyniku (razem z adresem IP) >>Można zgłosić TUTAJ<<.

Warto także skorzystać z narzędzia online stworzonego przez Orange Polska aby sprawdzić, czy router jest podatny na atak

Jak się zabezpieczyć?

W przypadku opisanego ataku (inaczej, niż przy użyciu złośliwego oprogramowania na komputerze klienta) do wykrycia ataku wystarcza czujność użytkownika i zwrócenie uwagi na szyfrowanie połączenia.

Zabezpieczając router przed atakiem należy przede wszystkim wyłączyć możliwość konfigurowania go „z zewnątrz”, tj z sieci Internet. Należy także bezwzględnie zmienić domyślne dane logowania do panelu konfiguracyjnego. Szczegółowy opis tych czynności powinien się znajdować w instrukcji obsługi routera.

Warto też rozważyć instalację aktualizacji oprogramowania routera, jeżeli została udostępniona przez producenta. Urządzenia nie wykonują takich aktualizacji automatycznie, co oznacza, że należy ręcznie sprawdzić dostępność łat na stronie producenta i w razie potrzeby zainstalować je zgodnie z instrukcją.

Wreszcie, na urządzeniach końcowych można skorzystać ze statycznie przypisanych serwerów DNS (dostarczanych przez operatora bądź otwartych, np należących do Google 8.8.8.8, 8.8.4.4), uniezależniając się tym samym od konfiguracji routera i ewentualnych nieautoryzowanych zmian w niej.

Co zrobić, jeśli zostałem dotknięty atakiem?

Przede wszystkim będziemy bardzo wdzięczni za kontakt z nami (http://www.cert.pl/kontakt) – informacje pomagają nam w działalności operacyjnej. Jeżeli kontakt jest niemożliwy, proponujemy przywrócić router do ustawień fabrycznych (według instrukcji producenta), a następnie postępować zgodnie ze wskazówkami w akapicie „Jak się zabezpieczyć”?