Janusz Nawrat, Raiffeisen Bank Polska

Statystyki dotyczące liczby ataków, określanych ogólnie jako ataki phishingowe wykazują w ostatnim czasie tendencję wzrostową. Rośnie też poziom złożoności mechanizmów tych ataków. Obecnie stosowane mechanizmy polegają na zastosowaniu przez agresorów groźnych wirusów, które nie tylko potrafią wyłudzić od użytkownika dane, ale nawet podmienić „w locie” konto beneficjenta czy kwotę zlecanego przelewu na dowolne dane podstawione przez agresorów – mówi Janusz Nawrat, dyrektor Biura Bezpieczeństwa Informacji i Systemów Informatycznych w Raiffeisen Bank Polska.

Coraz więcej Polaków korzysta z bankowości internetowej. Czy w ślad za tym rośnie liczba ataków przeprowadzanych na klientów korzystających z tego kanału dostępu? Jakie obecnie są najczęstsze zagrożenia? Czy jest się czego obawiać?

Statystyki dotyczące liczby ataków, określanych ogólnie jako ataki phishingowe niestety wykazują w ostatnim czasie tendencję wzrostową. Rośnie też poziom złożoności mechanizmów tych ataków. Niegdyś, typowy phishing, czyli kradzież tożsamości, polegał na wyłudzeniu od klienta identyfikatora jego konta i hasła w systemie bankowości poprzez fałszywe strony banków, do których odsyłacze propagowane były zazwyczaj w odpowiednio przygotowanych przez agresora wiadomościach e-mail. Obecnie stosowane, można rzec „modne” mechanizmy ataków polegają na zastosowaniu przez agresorów groźnych wirusów, które nie tylko potrafią wyłudzić od użytkownika dane niezbędne do zalogowania się do bankowości internetowej, ale dodatkowo rejestrują aktywność klawiatury zainfekowanego komputera, rejestrują też co pewien czas zrzuty ekranu, a nawet potrafią „w locie” podmienić konto beneficjenta czy kwotę zlecanego przelewu na dowolne dane podstawione przez agresorów.

Wirusy z grupy tzw. trojanów phishingowych, bo o nich tutaj mowa, nie działają na ogół jako byty samoistne, lecz dołączają zainfekowaną stację do nieraz ogromnych rozmiarów sieci zwanych botnetami. Botnet może liczyć od kilku tysięcy do kilkuset tysięcy zainfekowanych stacji (tzw. komputerów zombie lub botów). Wszystkie boty sterowane są z poziomu stacji zarządzającej botnetem, zwanej serwerem C&C (command and control). To serwer C&C odpowiada za „zasilanie” botów najświeższą konfiguracją i instrukcjami do wykonania przez bota. Agresor posiadający kontrolę nad botnetem może z poziomu serwera C&C prawie dosłownie „dyrygować” zainfekowanymi stacjami. W ramach kontroli nad botami serwer C&C może nakazać im na przykład rejestrowanie naciśnięć klawiszy klawiatury (keylogging), a tym samym spowodować ujawnienie wszystkich haseł logowania nie tylko do bankowości internetowej, wysłanie skradzionych haseł na serwer kontrolowany przez agresorów, podmianę całych stron lub elementów stron banku internetowego (tzw. fałszowanie treści czyli z ang. content spoofing), przekierowania połączeń do fałszywych serwerów banków internetowych, pobieranie dowolnych plików z zainfekowanego komputera, zapisywanie dowolnych plików na dyskach zainfekowanego komputera, „zabijanie” dowolnych procesów, w tym procesów odpowiedzialnych za bezpieczeństwo komputera, np. procesów osobistego firewalla czy skanera antywirusowego, niekorzystną rekonfigurację lub wyłączanie mechanizmów zabezpieczeń, osłabianie bezpieczeństwa przeglądarki czy wreszcie uszkadzanie systemu operacyjnego zainfekowanego komputera.

Infekcja komputera klienta wspomnianymi wirusami następuje na ogół wtedy, kiedy ten odwiedza strony internetowe propagujące oprogramowanie złośliwe, otwiera załączniki do wiadomości poczty z niezaufanych źródeł czy pobiera niezaufane lub nielegalne oprogramowanie z sieci peeer-to-peer albo z serwerów plików w Internecie.

Ofiarami ataków padają zazwyczaj użytkownicy nie stosujący w codziennej praktyce podstawowych zasad bezpieczeństwa, publikowanych na stronach banków.

Reasumując – bankowość internetowa może być i jest bezpieczna pod warunkiem, że użytkownicy sami zadbają także o bezpieczeństwo swoich komputerów.

Raiffeisen Bank wdrożył kolejną wersję bankowości mobilnej. Konsekwentnie wybieracie aplikacje instalowane na komórce. Inteligo i Alior wybrały lekkie wersje stron transakcyjnych. Jak wygląda bezpieczeństwo tych wszystkich rozwiązań? Czy można korzystać z bankowości mobilnej bez obaw?

Fakty wynikające z porównań rozwiązań bankowości mobilnej stosowanej przez Raiffeisen Bank oraz inne banki konkurencyjne są – przyznam – dość wymowne.

Mianowicie, samodzielna aplikacja oferowana przez Raiffeisen Bank, instalowana na telefonie komórkowym ma szereg niezaprzeczalnych zalet, jeśli brać pod uwagę jej bezpieczeństwo.
Jedną z nich jest możliwość łatwego i wiarygodnego uwierzytelnienia źródła pochodzenia, czyli autentyczności aplikacji i dostarczenia użytkownikowi gwarancji jej integralności (niemodyfikowalności kodu). Aplikacja jest elektronicznie podpisana przez jej dostawcę czyli bank. Zatem nikt, pozostając niewykrytym przez stosowane mechanizmy zabezpieczeń, nie może podszyć się pod bank i prezentować w niej fałszywych treści takich jak na przykład formularze z zapytaniami o hasła, kody autoryzacyjne oraz numery kart kredytowych klientów. Dodać trzeba, że ryzyko wyłudzeń tak ważnych danych od klienta jest istotnie większe w przypadku aplikacji uruchamianej poprzez przeglądarkę internetową zainstalowaną na telefonie komórkowym. Większa odporność samodzielnej aplikacji na ataki przez podmianę treści czy przekierowania połączeń wynika w prostej linii z jej niezależności od przeglądarki. Zatem aplikacja, będąc niezależną od przeglądarki internetowej, nie dziedziczy jej błędów i luk w bezpieczeństwie, które są na ogół wykorzystywane przez agresorów do przeprowadzania udanych ataków przełamywania systemów zabezpieczeń komputerów czy też urządzeń mobilnych, z takimi tego konsekwencjami jak instalacja na zaatakowanym urządzeniu oprogramowania złośliwego, włącznie z przekazaniem agresorom pełnej kontroli nad urządzeniem.  
Luki w bezpieczeństwie przeglądarek, o których tutaj mowa, wynikają zazwyczaj z błędów w kodzie, a błędów tych jest sporo; są też krytyczne błędy ”niełatane” przez dostawców przeglądarek od lat, ale spora ich część może wynikać także ze słabości konfiguracji przeglądarki.

Dedykowana, niezależna aplikacja pozostaje odporna na typowe, na ogół groźne w skutkach ataki charakterystyczne dla komunikacji webowej (ataki z kategorii client site attack), takie jak Cross-Site Scripting, Cross-Site Request Forgery, przekierowania do stron fałszywych banków internetowych czy podmiany elementów treści strony (np. atak IFRAME). W tej sytuacji ryzyko udanego ataku phishingowego wspomnianego typu na bankowość mobilną Raiffeisen Bank praktycznie nie istnieje.

Koniecznie dodać trzeba, że w przypadku rozwiązania oferowanego przez Raiffeisen Bank informacja pozostaje zaszyfrowana na całej ścieżce jej przesyłania (end-to-end) – od aplikacji na telefonie do serwerów w banku. Brak na tej ścieżce wszelkiego rodzaju serwerów pośredniczących oznacza w praktyce brak ryzyka „podsłuchu”, ataków man-in-the-middle, ujawnienia czy przestępczego wykorzystania przechwyconej tożsamości użytkownika.

Niestety przeglądarka Opera Mini rekomendowana przez niektóre banki działa w oparciu o serwery pośredniczące, na których wszystkie dane wymieniane pomiędzy użytkownikiem a bankiem, w tym krytyczne dane o tożsamości użytkownika (hasła, PIN-y itp.), pojawiają się w postaci jawnej (odszyfrowywane na serwerach pośredniczących potrzeby przeformatowania treści, by można ją było w odpowiedni sposób prezentować na telefonie). Jak widać w tym przypadku, bezpieczeństwo komunikacji użytkownika z bankiem bazuje na wątpliwym założeniu, że serwery pośredniczące Opery są zawsze całkowicie odporne na wszelkie możliwe formy ataków naruszenia poufności danych.  
Wobec przedstawionych faktów, konieczność instalacji dedykowanej aplikacji na telefonie komórkowym, przedstawiana jako jedna z głównych wad proponowanego przez Raiffeisen Bank sposobu dostępu do bankowości mobilnej, jawi się jako niewiele znacząca, drobna niedogodność, którą warto pokonać, bo w nagrodę użytkownik otrzymuje dużo większe bezpieczeństwo niż w przypadku dostępu poprzez interfejs przeglądarki internetowej w telefonie.

Jak wygląda kwestia autoryzacji zleceń w kanale mobilnym? Tradycyjne hasła jednorazowe mają swoje wady, a SMS-y przesyłane na ten sam telefon, to chyba niezbyt dobre rozwiązanie. Jakie są możliwości rozwiązania tego problemu?

Najlepszym rozwiązaniem byłyby tokeny typu challenge-response. Działają one na takiej zasadzie, że aplikacja wysyła do użytkownika tekst (zwykle kilkucyfrowy kod) stanowiący wyzwanie (z ang. challenge). Użytkownik wprowadza go przy pomocy klawiaturki do tokena. Token, uruchamiając zaprogramowaną w nim, unikalną i znaną jedynie jemu i serwerowi banku funkcję kryptograficzną zależną od klucza przypisanego do tokena, wylicza kod odpowiedzi (ang. response).. Użytkownik w dalszej kolejności wprowadza do aplikacji odpowiedź, która następnie podlega weryfikacji po stronie serwera. Identyczność kodu odpowiedzi dostarczonej przez użytkownika i wyliczonej przez serwer decyduje o sukcesie procesu autoryzacji zleconej przez niego transakcji.

Wadą sprzętowych tokenów typu challenge-response jest oczywiście ich koszt.

W bankowości mobilnej Raiffeisen Bank stosowane są aktualnie statyczne kody jednorazowe, które przy oferowanym przez bank rozwiązaniu opartym o dedykowaną aplikację stanowią bezpieczny sposób autoryzacji transakcji.

Bank będzie jednak w przyszłości wyposażał swoich klientów w inne, mniej kłopotliwe i jeszcze bardziej bezpieczne, możliwości autoryzacji transakcji. Nie jest wykluczone, że będą to właśnie tokeny typu challenge-response.  

Pozostając przy SMS-ach. Coraz więcej banków wybiera właśnie ten sposób zabezpieczenia. Problem w tym, że nowe komórki coraz bardziej przypominają komputery, a co za tym idzie coraz realniejszy jest scenariusz, że takie wiadomości tekstowe mogą być podmieniane przez przestępców. Czy to nie tworzy jakiegoś niebezpieczeństwa? Przecież mało kto dokładnie czyta SMS-a z informacją co autoryzuje…

Kody SMS pozostają wciąż jednym z najbezpieczniejszych sposobów autoryzacji.

Ryzyko przechwycenia kodu oczywiście nie jest zerowe, ale bezpieczeństwo zastosowania kodów SMS do celów autoryzacji transakcji opiera się na założeniu, że serwer musi otrzymać niezależnym kanałem (telefon komórkowy i komputer użytkownika stanowią dwa niezależne kanały) jeden, jedyny dla danej transakcji kod, którego się spodziewa od użytkownika. Jeśli dojdzie do podmiany kodu, to będzie to automatycznie oznaczało błąd w procesie autoryzacji.

Atakujący, chcąc z powodzeniem dokonać wyprowadzenia środków z rachunku klienta musiałby wcześniej podmienić takie elementy transakcji jak numer konta beneficjenta przelewu i ewentualnie jego kwotę, potem wysłać podmienione dane do serwera i uzyskać dla nich prawidłowy SMS-owy kod autoryzacyjny.

Jednakże z każdym kodem autoryzacyjnym w wiadomościach SMS przesyłane są przez bank także informacje na temat operacji, którą użytkownik ma zamiar zautoryzować. Jeśli użytkownik stwierdzi rozbieżność tych danych (to co widać w aplikacji i to co zostało przesłane SMS-em), to oczywiście nie przeprowadzi autoryzacji podejrzanego przelewu i powiadomi o tym fakcie bank.

Czytanie komunikatów o autoryzowanych transakcjach jest absolutnie niezbędne dla zachowania bezpieczeństwa odkąd pojawił się w Internecie groźny wirus o nazwie ZBOT, Zeus lub SilentBanker. Specyfiką działania tego wirusa jest między śledzenie dialogu użytkownika z bankiem i wychwytywanie stamtąd wszelkich zleceń przelewów, dla których podmieniane są w sposób niezauważalny dla użytkownika numery kont beneficjentów i kwoty.

Jedynym sposobem uniknięcia problemu jest czytanie przez klientów komunikatów otrzymywanych wraz z kodami autoryzacyjnymi i staranne sprawdzanie, czy opisują one planowany przelew.  

W jakim kierunku będzie rozwijały się systemy zabezpieczeń bankowości elektronicznej w najbliższych latach? Czy kryzys finansowy może mieć jakiś wpływ na wdrażanie nowych rozwiązań?

Zabezpieczenia bankowości on-line prawdopodobnie pójdą w kierunku integracji z systemami wykrywania e-fraudów, zastosowania systemów adaptatywnej autoryzacji, wirtualizacji środowisk uruchamiania aplikacji po stronie użytkownika, zastosowania rozwiązań typu Admission Control oraz oczywiście dalszej edukacji użytkownika.

Systemy wykrywania e-fraudów (FDS – Fraud Detection Systems) analizują połączenia z bankowością on-line oraz zachowania użytkowników w ramach sesji i wychwytują wszelkie nieprawidłowości, mogące świadczyć na przykład o próbie dokonania przestępczych przelewów z rachunku klienta. Powiadamiają o tym fakcie odpowiednie służby w Banku lub rzadziej podejmują automatycznie zaprogramowaną akcję.

Systemy adaptatywnej autoryzacji pozwalają na dynamiczne podejmowanie decyzji odnośnie metod autoryzacji, bazując na ocenie  ryzyka operacji zlecanych przez użytkownika. Na ogół takie systemy potrafią uczyć się typowych zachowań użytkownika (w sensie sposobu korzystania z aplikacji), „profilować” je, a wszystkie zachowania nie pasujące do dynamicznie tworzonego profilu traktować jako zachowania podwyższonego ryzyka.  
Na przykład, podstawowym sposobem autoryzacji może być kod SMS i jest on stosowany zawsze, w przypadku kiedy użytkownik zleca operacje „niskiego ryzyka”. Załóżmy, że użytkownik dotąd logował się do systemu bankowości internetowej z Polski, używał przeglądarki Firefox  i wykonywał przelewy na kwoty nie przekraczające 2000 złotych. Teraz system stwierdza, że logowanie ma miejsce z innego kraju, a kwota przelewu wynosi 5000 zł, na dodatek przeglądarka użytkownika to Internet Explorer w wersji 6 z masą zainstalowanych rozszerzeń w postaci obiektów BHO (niektóre z nich mogą być oprogramowaniem złośliwym). Wtedy system może zadecydować na przykład o konieczności zastosowania dodatkowej autoryzacji w postaci telefonicznego kontaktu z klientem w celu potwierdzenia autentyczności transakcji.

Wirtualizacja środowiska uruchamiania aplikacji polega na stosowaniu takich rozwiązań technicznych, które wykreują na komputerze użytkownika rodzaj piaskownicy (ang. sandbox) – odseparowanego, bezpiecznego środowiska uruchamiania aplikacji z wirtualnym pulpitem oraz bezpiecznie skonfigurowaną, zaserwowaną przez bank przeglądarką internetową, z szyfrowanym buforem (tzw. cache) oraz możliwością sprawdzenia, czy komputer użytkownika spełnia minimalne wymagania bezpieczeństwa odnośnie na przykład zainstalowanych poprawek bezpieczeństwa systemu operacyjnego, skanera antywirusowego i aktualności baz sygnatur wirusów czy braku obecności keyloggerów.

Z wirtualizacją środowiska uruchamiania aplikacji wiąże się także badanie stanu bezpieczeństwa komputera użytkownika zanim system pozwoli mu się połączyć z bankowością internetową (Admission Control). Jak wspomniano wcześniej, kryteria weryfikacji mogą być różne. Różne także mogą być podejmowane reakcje w odpowiedzi na stwierdzenie stanu niezgodności komputera użytkownika ze zdefiniowanym przez bank wzorcem bezpieczeństwa – od blokowania dostępu do kierowania użytkownika do odpowiednich serwerów oferujących możliwość pobrania poprawek i instalacji oprogramowania zabezpieczającego.

Kryzys gospodarczy na pewno spowoduje jeszcze większą aktywność przestępców, dlatego myślenie o ograniczaniu środków na budowę systemów zabezpieczeń może być ścieżką donikąd.

Artykuł pochodzi z archiwalnego numeru Przeglądu Finansowego Bankier.pl. Chcesz otrzymywać aktualne informacje, nowe wywiady oraz podsumowanie najważniejszych wydarzeń mijającego tygodnia ze świata finansów? Zapisz się na bezpłatną subskrypcję Przeglądu Finansowego Bankier.pl, by w każdy poniedziałek otrzymywać najnowszy numer naszego tygodnika. Zapraszamy na http://www.bankier.pl/przeglad/!

Źródło: Bankier.pl