Nawet biegli, w zakresie nowych technologii, klienci instytucji finansowych nie są w stanie obronić się przed atakami cyberprzestępców i działaniem złośliwego oprogramowania. Co więcej, część metod, po które sięgają instytucje finansowe, daje jedynie iluzoryczne poczucie bezpieczeństwa.
Większość producentów natomiast unika udzielania użytkownikom gwarancji na stworzone przez siebie aplikacje. Prowadzić to może do sytuacji, w której to na kliencie końcowym ciąży ryzyko związane z korzystaniem z oferowanych przez instytucje usług finansowych. Czas najwyższy, aby część odpowiedzialności przyjęli także ich dostawcy.
Z badań wynika, że polski system bankowy jest bardzo dobrze zabezpieczony. Mowa tu o spojrzeniu z perspektywy instytucji finansowych i nadzorujących je organizacji. Klienci bankowości internetowej mogą już jednak nie czuć się tak pewnie.
„Polska miała to szczęście w nieszczęściu, że stawialiśmy nasz system bankowy w dobie rodzącego się internetu i wypływających z tego faktu zarówno korzyści, jak i zagrożeń. Zamiast więc, w ramach zabezpieczeń, bazować na systemie ubezpieczeń, jak ma to miejsce w USA, sięgnięto po narzędzia do przeciwdziałania nadużyciom.” – przypominaPatryk Brożek, CEO, WHEEL Systems- „Problem polega jednak na tym, by wynikające z tego bezpieczeństwo rozciągnąć także na klientów instytucji finansowych.”
Skuteczne zabezpieczenia dziurawe w praktyce
Wymaganie od klientów, żeby ich komputery były wolne od złośliwego oprogramowania jest utopią. Używanie oprogramowania antywirusowego nie zabezpiecza w pełni przed zainfekowaniem stacji roboczej. Użytkownicy są w tej kwestii bezbronni, więc argument, że to wina klienta, bo miał wirusa, nie powinien być przez bank w ogóle podnoszony.
„Koronnym przykładem jest tu sposób autoryzacji transakcji bankowych. Instytucje, które nadal umożliwiają klientom korzystanie z kart „zdrapek” z hasłami, powinny w moim przekonaniu brać na siebie pełną odpowiedzialność za bezpieczeństwo takich transferów. Metoda TAN, bowiem, nie wiąże hasła z podpisywaną przez nią transakcją. Klient nie jest w stanie w żaden sposób wychwycić próby oszustwa.” – zauważa Paweł Dawidek, CTO, WHEEL Systems- „Niestety, ze względów praktycznych, nawet jedna z najskuteczniejszych metod autoryzacji transakcji, czyli hasła przesyłane SMSem, nie zabezpiecza w pełni. Brak sensownej edukacji sprawia, że klienci biorą dodatkowe dane, towarzyszące kodowi, za wysyłane wyłącznie w celach informacyjnych. Zresztą, oprócz hasła wiadomość zawiera zwykle tak dużo tekstu, że nikomu nie chce się tego nawet czytać.”
Niedawny przykład klienta jednego z polskich banków, który stracił ok. 40 000 złotych w wyniku działania złośliwego oprogramowania, odsłania wady względnie bezpiecznego systemu. Każe też zastanowić się nad odpowiedzialnością instytucji finansowych, których klienci ponoszą szkody z powodu działania czynników zewnętrznych. W tym wypadku nie dość, że na komputerze poszkodowanego klienta funkcjonowało złośliwe oprogramowanie, to na dodatek, on sam nie zweryfikował należycie danych transakcji przesłanych SMSem.
„Jeśli jednak przyjrzeć się treści SMSa autoryzacyjnego przesyłanego z banku, okaże się, że adres docelowy jest ostatnią, wymienianą informacją. Wcześniej klient pozna numer realizowanej transakcji, datę zlecenia, numer źródłowego rachunku i wiele innych. Wystarczyłby natomiast komunikat o treści: „Upewnij się, że wykonujesz przelew na rachunek XX na kwotę YY”. – twierdzi Paweł Dawidek z WHEEL Systems -Im więcej danych w SMSie, tym większe ryzyko, że klient go nie przeczyta lub zweryfikuje tylko pierwsze informacje – datę i rachunek źródłowy.”
Byle szybciej, byle do przodu
Nawet, jeśli w wyniku edukacji, klient postanowi sprawdzić numer rachunku z SMSa okazuje się, że najłatwiej i najszybciej może to zrobić na stronie banku, otwartej w oczekiwaniu na kod autoryzacyjny. Na tej samej, którą złośliwe oprogramowanie świetnie zna i potrafi podmieniać na niej wszystkie informacje, włącznie z wpisami w historii konta. Budowanie w kliencie przyzwyczajenia, że prawidłowy numer rachunku znajduje się na stronie z formularzem do autoryzacji jest błędem, który niweczy całe bezpieczeństwo metody SMSowej. Jakkolwiek archaicznie to nie brzmi, jedynym bezpiecznym sposobem jest weryfikacja docelowego rachunku u źródła – z faktury, maila, czy notatnika.
Kolejnym pomysłem na przyśpieszenie operacji jest pominięcie przez bank etapu deklaracji woli ze strony użytkownika. W uważanej za jedną z najbezpieczniejszych – metodzie SMSowej, użytkownik otrzymuje dane transakcji, które powinien zweryfikować, ale razem z tymi danymi od razu przesyłane jest działające hasło do ich potwierdzenia. Nawet, jeżeli dane transakcji nie są prawidłowe, hasło już istnieje. Nie ma tutaj deklaracji woli ze strony użytkownika. Bank, de facto, nie czeka na potwierdzenie czy dane są poprawne. Hasło do autoryzacji nieprawidłowej transakcji powstające automatycznie i bez zwłoki, wysyłane jest internetem poprzez infrastrukturę banku, następnie brokera SMS, operatora, aby w końcu poprzez sieć GSM trafić na telefon klienta. Daje to cyberprzestępcom duże pole manewru.
„Nawet, jeśli opisane zaniedbania nie stanowią bezpośredniego zagrożenia, ułatwiają użytkownikom popełnianie błędów. Nie można bowiem zakładać, że każdy klient bankowości elektronicznej jest ekspertem od bezpieczeństwa IT.” – twierdzi Paweł Dawidek z WHEEL Systems.
Rozwiązania dziurawe z założenia
Doskonałym przykładem nieprzemyślanej usługi, wprowadzonej do użytku przez instytucję z branży finansowej, jest możliwość wykonywania transferów pieniężnych z poziomu bankomatu. Zaoferował ją w połowie marca 2016 roku właściciel popularnej sieci bankomatów.
Jedyne dane odbiorcy, wymagane do realizacji przekazu to numer telefonu. Mechanizm usługi jest zbliżony do przekazów typu „escrow”. W modelu idealnym odbiorca otrzymuje od operatora systemu numer PIN oraz część kodu – jego dwie ostatnie cyfry – umożliwiającego pobranie pieniędzy. Jest to dla niego sygnał, że środki zostały zablokowane na poczet płatności i że może przejść do realizacji swojej części umowy. Kiedy nadawca uzna, że została ona wypełniona w sposób należyty, przekazuje cztery pierwsze cyfry kodu – tzw. sekret. W ten sposób adresat transferu wchodzi w posiadanie całego hasła wymaganego do wypłacenia pieniędzy.
Przekazy tego typu funkcjonowały z powodzeniem już wcześniej, więc dlaczego opisywana wersja usługi okazała się porażką?
Odgadnięcie kodu-sekretu było nie tylko możliwe, co wręcz łatwe. Wystarczyło w zbliżonym czasie nadać własny transfer. Przydzielony w ten sposób kod-sekret okazywał się być czterema pierwszymi cyframi globalnego licznika transakcji, wzrastającego o 1 wraz z każdym kolejnym przekazem. Nie miał więc nic wspólnego z losowością. Nie był też wyliczany na podstawie danych nadawcy. Poznawszy cztery pierwsze cyfry, oszust miał niemal pewność, że może z powodzeniem odblokować zawieszony transfer bez wywiązywania się z umowy. Firma usunęła wadę dopiero po nagłośnieniu sprawy przez media. W oświadczeniu przyznała zaś, że rzeczywiście „w fazie mniejszego ruchu identyfikatory mogły się wydawać niewystarczająco zdywersyfikowane”.
Skomplikowane rzeczy psują się w skomplikowany sposób
Winą za błędy w oprogramowaniu obarczyć można bardzo często krótkodystansowe cele. Zamówione oprogramowanie ma być bowiem dostarczone na czas i ma działać. Jednakże nikt nie zwraca uwagi na jakość kodu. Im gorsza, a kod bardziej skomplikowany i nieczytelny, tym więcej ma błędów i są one trudniejsze do znalezienia podczas testów oraz awarii. Tu w pełni znajduje odzwierciedlenie porzekadło, że skomplikowane rzeczy psują się w skomplikowany sposób.
To też pochodna braku odpowiedzialności za błędy w oprogramowaniu. Niezależnie od zobowiązania poprawienia ewentualnych błędów, które pojawią się w trakcie użytkowania softwareu, wszyscy producenci zastrzegają sobie, że nie odpowiadają za szkody wyrządzone przez ich produkty. Dlatego też nacisk kładzie się głównie na dostarczenie żądanych funkcjonalności. Jakość kodu, czy czysta i dobrze zaprojektowana architektura rozwiązania schodzą natomiast na dalszy plan. Zjawisko to nie powinno mieć miejsca w branży IT Security.
Źródło: WHEEL Systems
