Wielkie nieszczęście dopadło jednego z klientów banku mBank. Informacja o tym incydencie szybko została „wykopana” i dotarła do sporego grona odbiorców.
Pechowy bohater tego incydentu, na skutek zainfekowanego systemu operacyjnego oraz – w tym wypadku – nieskutecznego programu antywirusowego Norton, utracił pokaźną sumę w wysokości 40 tysięcy złotych. Trochę z własnej winy, a trochę z winy oprogramowania, które powinno zabezpieczać jego komputer – przynajmniej w teorii. W praktyce ani Symantec, ani mBank nie biorą odpowiedzialności za wyrządzone przez malware straty finansowe.
A oto nagrane wideo przez tego nieszczęśnika.
System operacyjny zabezpieczony popularnym oprogramowaniem antywirusowym marki Norton został zainfekowany złośliwym kodem i na skutek działania malware’u klient stracił 40 tysięcy złotych, których prawdopodobnie nie da się już odzyskać. Jak twierdzi autor materiału filmowego, złośliwe oprogramowanie nie podmieniało skopiowanego do schowka systemowego numeru konta bankowego – w pole tekstowe na stronie banku numer rachunku był wpisywany „z palucha”. Także sam przelew nie został wysłany przez pomyłkę na inne konto, które różniłoby się jedną lub dwoma cyframi, lecz na zupełnie inny numer konta bankowego, który należał do tak zwanego słupa.
Komputer naszego bohatera nie został zainfekowany popularnym w ubiegłym roku w Polsce trojanem bankowym VBKlip, który to ewoluował do Bantrix, lecz innym groźnym wirusem, który „atakował” przeglądarkę stosując tzw. atak man-in-the-browser.
Wektor infekcji
Jak w ogóle mogło dojść do zarażenia komputera tym wirusem? Sam atak rozpoczął się dużo wcześniej, a wektorów infekcji mogło być co najmniej kilka. Najpopularniejsze z nich w ostatnim czasie to oczywiście ataki z wykorzystaniem socjotechniki i wiadomości phishingowych, które u ofiary mają wzbudzić zaufanie do nadawcy i przekonać ją do kliknięcia w „podlinkowany” adres URL (hiperłącze kieruje do innej strony niż widoczny w nazwie adres URL) lub spowodować otwarcie załącznika.
By w ogóle szkodliwe oprogramowanie mogło do przeglądarki wstrzyknąć swój złośliwy kod (payload), najpierw musi znaleźć się na komputerze ofiary. A może do zrobić na kilka sposobów, z czego najpopularniejsze z nich to ataki phishingowe na Pocztę Polską, na Adwokatów lub ataki drive-by.
Man-in-the-browser (MitB) w praktyce
Rozróżnijmy na początek dwa scenariusze zaawansowanego ataku. Pierwszy z nich z pozoru łatwiejszy do wykonania, ale bardzo skuteczny to man-in-the-middle (MitM). Jego działanie polega na przechwyceniu ruchu HTTP z komputera i przekierowanie go do złośliwego serwera przestępcy, skąd dalej trafiają do banku i z powrotem do użytkownika, ale już w zmodyfikowanej formie. Strona bankowa może wyglądać identycznie i będzie pozornie bezpieczna – wskazywać na to będzie szyfrowane połączenie w pasku adresu URL (kłódka bezpieczeństwa). W przypadku ataku MitM przestępca wykorzystując narzędzie np. SSLTrip będzie w stanie zmusić przeglądarkę do komunikacji z własnym podstawionym serwerem WWW otwartym nieszyfrowanym kanałem.
Natomiast atak man-in-the-browser (MitB) odbywa się pomiędzy użytkownikiem a mechanizmami bezpieczeństwa w przeglądarce i działa „lokalnie” – na komputerze ofiary (więc nie może być mowy o winie banku, co najwyżej antywirusa, który sromotnie poległ), z tą różnicą, że malware nie modyfikuje strony w „locie” – tak jak w przypadku ataku man-in-the-middle. Tutaj ruch sieciowy z serwera bankowego nie jest przekierowywany do serwera przestępcy, lecz trafia bezpośrednio do serwera WWW banku. W odpowiedzi, malware przechwytując informacje bezpośrednio z pamięci przeglądarki. Potrafi za pomocą tzw. techniki webinject do wyświetlonej strony internetowej wstrzyknąć kod (np. <script>…</script>) powodując wyświetlenie dodatkowych informacji:
1. Po zalogowaniu wyświetli się komunikat np. „nie możemy zweryfikować Twojego komputera, potwierdź swoją tożsamość”. Strona banku będzie oryginalna, ale z lekko zmodyfikowaną zawartością. Za pomocą webinject’u zostaną wstrzyknięte dodatkowe pola tekstowe do wypełnienia poufnych, prywatnych danych, gdzie ofiara będzie proszona o podanie np. swoich wszystkich danych osobowych, które najnormalniej w świecie nie są potrzebne bankowi, a z całą pewnością przydadzą się przestępcy do kolejnych socjotechnicznych ataków (dane osobowe, pesel, data urodzenia, numer karty debetowej/kredytowej, jej data ważności i trzy cyfrowy kod CVV wykorzystywany do potwierdzania i weryfikowania płatności).
2. I scenariusz ataku bohatera tego wpisu. Szkodliwe oprogramowywanie w momencie wysłania informacji do banku o realizacji przelewu wstawiło swój własny numer rachunku bankowego, co więcej, przy otworzeniu historii przelewów nadal podstawiało numer konta bankowego, nie „na słupa”, lecz ten, który został wpisany przez ofiarę „ręcznie”.
Poniższe wideo prezentuje próbę zalogowania się z nieistniejącego konta do banku. Strona banku zwraca informację, że klient nie istnieje.
Poniższe wideo przedstawia atak MitB na zainfekowanym komputerze. Wpisanie nawet fikcyjnych danych oraz dodatkowych informacji poufnych (malware wstrzyknęło dodatkowe pola do wypełnienia) i tak spowoduje, ze zostaną one wysłane do przestępcy, a strona banku na końcu zwróci komunikat, że konto nie istnieje.
Przelew został wykonany, ale czy na pewno na pożądany rachunek bankowy?
Niestety nie. Jak słusznie zauważył autor wideo, dopiero w wiadomości SMS od banku dociera informacja do ofiary o tym, na jakie konto zostanie wykonany przelew. Dlatego należy weryfikować, czy kilka ostatnich cyfr rachunku bankowego w wiadomości SMS pokrywa się z tym, co zostało wklejone lub wpisane jako numer rachunku odbiorcy. Można to sprawdzić w historii przelewów, ale nie na zainfekowanym komputerze. Dlaczego?
Szkodliwe oprogramowanie wykorzystuje wspomniane techniki webinject także do nadpisania informacji o wykonanym przelewie wstawiając w pole nadawcy wpisany „z palca” numer rachunku bankowego. Natomiast, ofiara pobierając potwierdzenie przelewu jako plik PDF zobaczy już informację z podstawionym na słupa rachunkiem bankowym – w tym przypadku malware nie modyfikował plików PDF (potawierdzenie przelewu). Również taka sama informacja byłaby widoczna na niezainfekowanym systemie operacyjnym – tj. na innym komputerze.
Jak się chronić?
Powstaje więc pytanie, dlaczego oprogramowanie antywirusowe nie wykryło zagrożenia? Bez dostępu do komputera owego pechowca ciężko cokolwiek więcej powiedzieć, poza tym, że malware nie było wykrywane przez sygnatury Symanteca, a ochrona w czasie rzeczywistym również nie zadziałała, co zapewne bardzo zaniepokoi obecnych klientów Symanteca. Obawy te są jak najbardziej słuszne.
Niestety, jak pokazał powyższy przykład samo oprogramowanie antywirusowe nie zawsze skutecznie chroni przed stratami finansowymi. Udowodniły to przypadki słabej detekcji pierwszych wirusów z rodziny ransomware, które blokowały dostęp do komputera wyświetlając komunikat o rzekomym rozprzestrzenianiu treści pornograficznych (popularne „wirusy Policja” z byłym prezydentem Komorowskim) – wirusy te jeszcze nie szyfrowały plików, ale żądały okupu za odzyskanie dostępu do systemu.
Aby ustrzec się przed atakami MitB, MitM, keyloggerami, trojanami i innym szkodliwym oprogramowaniem, bez programów antywirusowych nadal ciężko żyć. Pomimo, że powyższy przypadek dobitnie obnażył słabość produktu opracowanego przez firmę Symantec, to z antywirusów nie należy zupełnie rezygnować. Zaawansowane malware niekoniecznie będzie wykryte w systemie, ale mając na uwadze ilość złośliwego kodu, który codziennie powstaje, aż strach pomyśleć, co by było, gdyby niewykwalifikowanego pracownika przez kilka dni pozostawić samemu sobie bez żadnej ochrony antywirusowej.
Jak chronicie się przed wirusami? Czy stosujecie się do zasad bezpiecznego korzystania z bankowości elektronicznej? Czekamy na komentarze.
