Bezpieczeństwo transakcji elektronicznych

Najciekawszym celem dla hakerów jest zawsze bankowość elektroniczna. Bardzo często zastanawiałem się, co jest tak naprawdę najprostszym sposobem na kradzież pieniędzy z bankowości elektronicznej. Otóż najłatwiej zaatakować najsłabszy punkt bankowości internetowej, a mianowicie klienta.

Jak myśli haker i co tak naprawdę go interesuje?

Załóżmy, że atakujący zna nazwę użytkownika oraz hasło klienta, za pomocą których loguje się do systemu bankowości elektronicznej. W wielu core-owych systemach bankowości zwykle nie istnieje takie coś jak silne uwierzytelnianie lub jest ono mylnie interpretowane, a więc osoba atakująca może bez większych problemów przejąć konto użytkownika.

Obecnie jednak większość organów kontrolujących banki w państwach Unii Europejskiej wymaga zastosowania silnego uwierzytelnia. Wynika to bezpośrednio z dokumentu o nazwie „Rekomendacje dotyczące bezpieczeństwa płatności internetowych.”, który jest dostępny na stronie Komisji Nadzoru Finansowego. Przeważnie wygląda to w ten sposób, że klient najpierw musi się uwierzytelnić i jeżeli proces przebiegnie poprawnie, klient może tylko i wyłącznie przeglądać swoje konto. Natomiast aby wykonać jakąkolwiek transakcję, klient musi dostarczyć kolejną rzecz, znaną tylko jemu – jednorazowe hasło autoryzacji transakcji.

Każdy atakujący natomiast ma zasadniczo jeden cel. Atakujący musi uzyskać jak największy zwrot z każdej swojej inwestycji. Haker musi wymyślić taki sposób ataku, który jest maksymalnie skalowalny, ponieważ tylko w ten sposób może szybko osiągnąć swój cel. Idealnym sposobem jest oczywiście atak pishingowy oraz udostępnianie złośliwego oprogramowania.

Atak pishingowy jest zwykle w pełni zautomatyzowany, a wszelkie wiadomości są wysyłane e-mailem. Większość ludzi nie jest świadoma ryzyka i otwiera wszystkie wiadomości, jakie dostanie, a liczba ofiar jest wprost proporcjonalna do liczby prób. Natomiast  złośliwy kod może być zawarty nawet w darmowym oprogramowaniu. Ludzie po prostu je pobierają i instalują. Oprogramowanie działa normalnie, a ludzie nie są świadomi ryzyka. Następnie łączą się do systemu bankowości internetowej i nagle okazuje się, że przelewy wcale nie idą na te konta, na jakie iść powinny. W trakcie ataku jest po prostu podmieniany numer NRB.

Oczywiście są to tylko dwa przykłady, ale większość banków nie potrafi sobie z nimi poradzić. Oczywiście istnieją mechanizmy detekcji ataków pishingowych oraz ataków za pomocą malware, ale systemy te mają jedną zasadniczą wadę. Problemem tutaj jest to, że wykrywają one znane ataki, ponieważ posiadają czarne listy dla pishingu oraz złośliwego oprogramowania. Ale nie da się za ich pomocą wykrywać nowych typów ataków oraz nieznanych typów ataków, ponieważ nie posiadają one żadnej heurystyki koncepcji. A więc dostępne na rynku rozwiązania pozwalają tylko częściowo zminimalizować ryzyko.

W jaki sposób klient się uwierzytelnia?

Gdy klient się uwierzytelnia, musi najpierw uzyskać dostęp do systemu bankowości. Zwykle wygląda się to tak, że klient łączy się z bankiem za pomocą protokołu SSL / TLS i jest zwykle używany protokół HTTPS zamiast HTTP i jest generowany cyfrowy certyfikat. Jeżeli certyfikat jest podpisany przez jeden z trzech organów certyfikujących, to przeglądarka nie wyświetli ostrzeżenia. Następnie klient wprowadza swój login i hasło, aby zalogować się do systemu. Zanim jednak to się stanie, każdy klient powinien sprawdzić, czy certyfikat jest rzeczywiście podpisany przez bank.

Phishing jako narzędzie do kradzieży danych klienta

Większość klientów bankowości nie rozumie w jaki sposób działają certyfikaty. A więc teoretycznie wystarczy wysłać klientom banku link do strony, która wygląda podobnie jak strona banku. Większość klientów nie zauważy różnicy, nawet jeśli wyświetli się normalne logowanie do witryny, które znajduje się poza protokołem SSL.

Teraz załóżmy, że klient jednak sprawdza, czy certyfikat jest rzeczywiście używany do komunikacji ze stroną bankową. Haker może wtedy po prostu kupić zaufany certyfikat i stworzyć stronę, która jest idealną kopią działającej. Wtedy klient bankowości elektronicznej zwykle daje się nabrać, ponieważ SSL jest na stronie i działa, a strona wygląda tak, jak rzeczywista strona banku. Gdy klient nie sprawdzi, kto tak naprawdę jest właścicielem certyfikatu, to może się okazać, że haker wykradnie dane.

W niektórych systemach bankowych, z jakimi się spotkałem, do uwierzytelniania klienta są używane także hasła maskowane. Klient jest wtedy proszony o podanie wybranych znaków z hasła. Wydaje się, że stanowi to jakiś problem dla hakera, ale tak naprawdę haker potrzebuje po prostu trochę więcej prób, aby odgadnąć hasło. A nawet jeśli jest leniwy, pozyskanie hasła nie jest dla niego problemem. Po prostu prosi wtedy klienta o podanie całego hasła. Większość ludzi zrobi oczywiście to, o co prosi atakujący, ponieważ uznają oni, że po prostu bank coś zmienił.

Idealnym rozwiązaniem dla systemów bankowości jest możliwość lub wymaganie podania zdjęcia klienta podczas podpisywania umowy. Rozwiązanie powinno być zaprojektowane w ten sposób, że jeśli klient zaloguje się do systemu bankowości internetowej, zobaczy swoje zdjęcie, co pokaże mu, że rzeczywiście komunikuje się on z systemem bankowości elektronicznej. Atakujący na pewno nie będzie wiedział, jakie zdjęcie klient przesłał do banku. W ten sposób może zostać wykryta większość prób phishingu, ponieważ klient może sprawdzić, czy pojawia się jego rzeczywiste zdjęcie. W momencie, kiedy obraz się nie pojawia, klient może zacząć podejrzewać, że padł ofiarą ataku phishingowego. Jeśli tak się stanie, powinien zadzwonić do banku lub połączyć się z prawdziwym systemem bankowości internetowej i natychmiast zmienić hasło.

Złośliwe oprogramowanie i poręczenia klienta

Teraz załóżmy, że klient zaraził się złośliwym oprogramowaniem. Wtedy nie pomoże to, że klient wie, w jaki sposób działają certyfikaty. Z punktu widzenia klienta wszystko jest w porządku. Certyfikat jest podpisany cyfrowo przez jeden z zaufanych urzędów certyfikacji, a klient sprawdził, że rzeczywiście loguje się do właściwego banku. Złośliwe oprogramowanie, które jest pisane dzisiaj, jest w stanie nauczyć się hasła, które jest podawane podczas logowania na stronie banku. Nawet zamaskowane hasła nie pomagają, ponieważ oprogramowanie się ich uczy i dyskretnie analizuje każdą próbę podania hasła.

Zdjęcie lub inne dane, jakie klient jest w stanie dostarczyć bankowi także nie pomogą. Klient loguje się na stronę banku i pojawiają się rzeczywiste dane. Natomiast na jego komputerze działa złośliwe oprogramowanie, a klient nie jest tego świadomy. Bardzo często niektóre banki wykorzystują także klawiatury ekranowe. Ale to wcale nie przeszkadza złośliwemu oprogramowaniu w nauce hasła klienta. Jako ciekawostkę chcę podać to, że złośliwe oprogramowanie jest w stanie uchwycić i wysłać zrzuty ekranowe, opierając się na pozycji kursora myszy.

Transakcje internetowe

Przerobiliśmy już atak na poręczenia klienta. Teraz zajmijmy się bardziej newralgicznymi elementami, takimi jak transakcje. Oczywiście transakcje internetowe także są zdefiniowane w dokumencie KNF. Każda transakcja internetowa powinna być silnie uwierzytelniania. Oznacza to, że musi być potwierdzona przez dwa niezależne środki komunikacji z klientem. Najczęściej stosuje się kodu jednorazowe lub wiadomości SMS. Czasami jednak także banki stosują tokeny sprzętowe. Zastanówmy się teraz, jak sobie z tym radzi złośliwe oprogramowanie.

Atak phishingowy na transakcję bankową

Załóżmy, że klient ma listę haseł jednorazowych OTP. Zwykle jest on proszony o podanie hasła z listy do autoryzacji transakcji. Kiedy hasło jest już użyte, nie ma ono wtedy żadnego sensu dla atakującego. Dlatego jest to wiele lepsze od statycznych haseł, ale nie powstrzyma atakującego na długo. W przypadku haseł jednorazowych typu OTP, nie są one w żaden sposób związane z transakcją bankową. Dlatego naczelnym celem hakera jest atak, mający na celu pozyskanie kilku haseł OTP, dzięki którym wykona dowolne czynności. Na przykład może zaistnieć taka sytuacja, że atakujący będzie wymagał od klienta podania 3-5 kodów OTP, uzasadniając to tym, że bank zmienił mechanizm zabezpieczeń i prosi użytkownika o podanie kilku haseł w celu weryfikacji tożsamości. Niektórzy ludzie zrobią oczywiście to, czego oczekuje od nich atakujący, ponieważ z ich poziomu bank po prostu zwiększa bezpieczeństwo.

Oczywiście do generowania kodów OTP może zostać zastosowany jednorazowy token. Token może posiadać swój zegar czasowy, zsynchronizowany z systemem bankowym i ważny 60 – 120 sekund. To jest zdecydowanie lepsze rozwiązanie niż generowanie i drukowanie list OTP, ponieważ gdy atakujący przejmie hasło ma ograniczone pole działań. Dodatkowo w takim przypadku atakujący nie może wykonać wielu działań, a tylko jedno. Ale to wszystko tylko niweluje ryzyko związane z pishingiem i atak jest cały czas możliwy.

Złośliwe oprogramowanie atakuje wykonywanie transakcji bankowych

Znowu musimy założyć, że maszyna klienta została zarażona malware. Klient chce przeprowadzić transakcję i jest proszony o podanie hasła autoryzacji. Musimy założyć, że hasła nie są powiązane w żaden sposób ze szczegółami transakcji. Klient wprowadza hasło i autoryzuje transakcję. Wydaje się to być bezpieczne, ale złośliwe oprogramowanie zmienia w międzyczasie numer konta bankowego. W ten sposób wygląda atak Man in the Browser.

Załóżmy, że klient banku wejdzie w szczegóły transakcji i zostanie poproszony o podanie hasła, które jest związane z daną transakcją. Autoryzacja transakcji jest wysyłana na komputer klienta wraz ze szczegółami transakcji. Nawet jeśli tak jest, atak man in the browser cały czas jest możliwy. Atakujący wie, co klient chciał wykonać i wyświetla prawidłowe dane transakcji, natomiast w pamięci przeglądarki wykonuje swoje operacje. Z punktu widzenia klienta wszystko się zgadza, więc autoryzuje transakcję.

A teraz nadszedł czas na ostatni punkt. Załóżmy, że maszyna klienta jest używana, aby uzyskać dostęp do systemu bankowości elektronicznej i używa telefonu do autoryzacji wszystkich transakcji, na przykład poprzez SMS z tokenem, jaki jest wysyłany do transakcji. To oczywiście działa dobrze tak długo, aż atakujący nie zainfekuje telefonu klienta. Załóżmy, że klient loguje się do systemu bankowości elektronicznej, a system wyświetla wiadomość, że zmieniły się zasady i bank wprowadził nowe mechanizmy bezpieczeństwa. Wtedy klient musi pobrać nowy certyfikat bezpieczeństwa dla swojego telefonu komórkowego. Oczywiście ze strony klienta wszystko wygląda w porządku. Następnie klient jest proszony o podanie swojego numeru telefonu i otrzymuje wiadomość z linkiem do certyfikatu, który następnie jest instalowany na telefonie klienta. Teraz atakujący posiada kontrolę nad komputerem i telefonem komórkowym klienta. Klient banku chce przelać pieniądze, dostaje potwierdzenie SMS wraz z tokenem, ale szczegóły transakcji zostały już zmienione przez złośliwe oprogramowanie i według klienta wszystko jest w porządku. Dodatkowo klient bankowości internetowej bardzo często korzysta z aplikacji mobilnych, dających dostęp do bankowości elektronicznej oraz umożliwiającą przeprowadzenie transakcji. To w zupełności wystarczy, ab zagrozić bezpieczeństwu transakcji internetowych.

Podsumowanie artykułu

Banki stosują zwykle dwa niezależne kanały autoryzacji transakcji, aby zmniejszyć ryzyko kradzieży pieniędzy klienta. Nawet jeśli atakującemu uda się przejąć poświadczenia klienta, zwykle potrzebuje danych z drugiego kanału uwierzytelniania, aby wykonać transakcję elektroniczną.

Wszystkie generowane tokeny nie powinny być w żaden sposób powiązane z danymi transakcji. Kiedy tak jest rzeczywiście, atakujący, nawet jeśli przejmie token, nie może wykonać dowolnych operacji, ale tylko i wyłącznie jedną operację. I nagle atak phishingowy staje się bezużyteczny dla atakującego. Problemem pozostaje złośliwe oprogramowanie. Jeśli do wykonywania transakcji jest używana tylko jedna maszyna lub  tylko jeden kanał autoryzacji transakcji, to wtedy każda transakcja bankowa ma bardzo wysoki stopień ryzyka. Potwierdzenie transakcji wiadomością SMS wydaje się oczywiście dobrym pomysłem, aczkolwiek występują tutaj takie same problemy, jak w przypadku zwykłych komputerów.

Dlatego zwykle klientom bankowym proponuje się używanie dedykowanego urządzenia do weryfikacji transakcji. Idealnym rozwiązaniem na chwilę obecną jest posiadanie przez klienta dedykowanego urządzenia, które pokazuje szczegóły transakcji klienta. Ale zwykle dla takich rozwiązań jest niezbędne dodatkowe łącze internetowe lub gniazdko sieciowe. Tego typu rozwiązania pozwalają bardzo szybko wychwytywać ataki man in the browser, ale pojawia się problem użyteczności. Klient musi wprowadzić podwójnie wszystkie swoje akceptacje.

Rozwiązaniem problemu może być dedykowane urządzenie z wbudowanym aparatem, który będzie służył do skanowania kodów QR, wyświetlanych na ekranie komputera. Kod QR będzie zawierał wszystkie dane transakcji oraz będzie od razu dostępny dla klienta. Dzięki temu po zeskanowaniu kodu QR klient będzie mógł od razu sprawdzić szczegóły transakcji oraz pozostałe informacje. Klucz szyfrowania powinien być wspólny dla banku oraz dedykowanego urządzenia, co zapewni pełne bezpieczeństwo transakcji elektronicznej.

Read it in english version: http://www.businessmantoday.us/security-of-elec…nic-transactions/