Paweł Goleń, blog

Na początek groźnie brzmiące zdanie:

Tym razem obiektem zainteresowania cyberoszustów stali się klienci banku PKO BP. Firma G DATA ostrzega, że mechanizm ataku jest bardzo wyrafinowany i tylko częściowo przypomina standardowe ataki phishingowe.

Brzmi ciekawie, cóż takiego nowego jest w tym ataku? Mechanizm opisany jest w sposób następujący:

Użytkownik zachęcany jest do wizyty na zainfekowanej stronie WWW, która proponuje mu aktualizację oprogramowania Flash Player. Instalator Flasha pobierany z witryny jest w rzeczywistości trojanem, modyfikującym plik host, co pozwala przekierować użytkownika na dowolną stronę w Sieci. Po podaniu adresu URL w polu przeglądarki zamiast na stronę banku użytkownik trafia na spreparowaną witrynę, stworzoną przez przestępców, a imitującą serwis bankowy.

Podstawienie trojana pod Flash Player nie jest nową koncepcją, już w kwietniu 2008 roku właśnie jako Flash Player maskował się złośliwy kod wykorzystywany przy ataku na nasza-klasa.pl. Nadpisywanie pliku hosts też jest działaniem standardowym. Bardziej wyrafinowane "rozwiązania" instalują różnego rodzaju BHO. Tak więc sposób działania jest standardowy. Ciekawy jestem tylko, czy w pliku hosts wprowadzana zmiana dotycząca PKO BP jest jedyna. Malware często atakują jednocześnie wiele banków, wówczas jest większa szansa, że ich ofiara z jakiegoś skorzysta. Tego typu "multiataki" istniały już w sieci w okolicach 2006 roku (to wiem na pewno), a i być może wcześniej (ale tego nie wiem). Ciekawy jestem również, czy modyfikacja pliku hosts jest jedyną wprowadzaną zmianą. Gdybym to ja pisał takiego trojana, to dodałbym jeszcze certyfikat swojego własnego CA do zaufanych, tak, by certyfikaty serwera, który podstawię ze sfałszowanymi stronami prawidłowo się weryfikowały. I znów tutaj nie jestem oryginalny, malware, które wprowadzają tego typu zmiany istnieją "w naturze".

Dochodzimy jednak do fragmentu opisującego nowatorstwo nowego malware:

"Jednak w tym miejscu kończą się podobieństwa do klasycznego ataku phishingowego, ponieważ przestępcy dodali kolejny krok - po "zalogowaniu się" do banku otwiera się kolejna strona, na której użytkownik proszony jest o podanie pięciu kolejnych haseł jednorazowych" - czytamy w przygotowanym przez G DATA alercie.

Domyślam się, że nowatorski ma być ten "drugi krok". Problem w tym, że nie jest. Autoryzacja transakcji w bankowości elektronicznej służy właśnie temu, by atakujący po zdobyciu nazwy użytkownika i hasła nie mógł wykonać żadnych operacji (w praktyce w zależności od implementacji pewne "zaufane" operacje wykonać może). W czasach, gdy powszechnie wykorzystywane były listy haseł jednorazowych wystarczyło, by na podstawionych stronach pojawiła się prośba o podanie 5 kolejnych haseł jednorazowych (tak, właśnie 5 kolejnych haseł jednorazowych, zadziwiająca zbieżność, prawda?) z jakimś sprawiające wrażenie sensownego uzasadnieniem. Takie ataki miały miejsce, dlatego coraz większa część banków przechodzi na metody autoryzacji transakcji uniemożliwiające takie ataki (na przykład kod jednorazowy przesyłany SMS dla konkretnej transakcji). Niektóre banki jednak wciąż stosują (przynajmniej częściowo) listy haseł jednorazowych i to one (a właściwie ich klienci) mogą stać się ofiarami tego typu ataków.

Dochodzimy jednak do sekcji jak się chronić:

W trakcie odwiedzania serwisu bankowości elektronicznej zawsze sprawdzaj, czy adres URL strony rozpoczyna się od https:// i czy adres strony jest prawidłowy. Zwracaj uwagę, jak zakończony jest adres (domena główna). "Początek adresu strony jest bardzo łatwo sfałszować" - ostrzega G DATA.

No pięknie... Przypominam, że plik hosts został zmieniony, więc nie trzeba fałszować adresu strony!. Informacja, że adres zaczyna się od https:// również nic nie daje bez jednoczesnego zweryfikowania certyfikatu. Być może został dopisany nowy zaufany certyfikat, więc poleganie na tym, że przeglądarka nie zgłasza uwag co do ważności certyfikatu również jest niewystarczające. Zresztą weryfikacja certyfikatu przez użytkowników jest poważnym problemem. Nawet wprowadzenie certyfikatów SSL EV niewiele w tym zakresie zmieniło. Tak więc informacje w sekcji jak się chronić są może zgodne ze standardową litanią (choć niepełną - brak informacji o weryfikacji certyfikatu), ale takie trochę nieprzystające do opisywanego przypadku.