Zacznijmy od tego (ostrzegam - dość żenującego) artykułu: Polskie banki ostrzegają: wirus Banatrix podmienia numer konta w zupełnie nowy sposób. Następnie proponuję przenieść się do źródła: VBKlip 2.0: bez schowka, za to z efektami specjalnymi. Przy czym raczej polecałbym przeczytać angielską wersję, bo to "zadanie okresowe" mnie kopie - w polskiej wersji Scheduled Tasks są tłumaczone (chyba) na Zaplanowane Zadania.
Przede wszystkim nie jestem zaskoczony istnieniem takiego wirusa, a nawet na swój specyficzny sposób cieszę się, że się pojawił. Dlaczego? Dlatego, że być może bzdurne "zabezpieczenie" polegające na wyłączeniu możliwości kopiowania numeru konta nie będzie implementowane/zalecane. Tak naprawdę możliwość podmiany rachunku wpisanego przez użytkownika malware ma od dawna. W dodatku "możliwość" należy tutaj rozumieć nie jako jakieś techniczne "supermoce", tylko jako zaimplementowaną/dostępną standardowo funkcję.
Druga sprawa - Scheduled Tasks już dawno były wykorzystywane przez malware jako persistence mechanisms co jest opisane choćby tutaj: Windows Forensic Analysis Toolkit: Advanced Analysis Techniques for Windows 8.
Po trzecie - ten malware cały czas jest prymitywny. Dlaczego? Dlatego, że go widać. Dobry malware powinien podmieniać numer rachunku wysyłany do serwera, ale jednocześnie ukrywać ten fakt przed użytkownikiem - prezentować oryginalny numer rachunku w GUI. Malware ma taką (techniczną) możliwość.
W tym kontekście bardzo dobrze pasuje ta prezentacja: Evaluation of Transactional Controls in e-Banking Systems (slajd 13).
Przy okazji - jest dokładnie tak, jak mówiłem ostatnio na WHEEL Eventing #006 - warto wyjść od dwóch elementów:
- co atakujący ma;
- co atakujący może (mając to, co mu "daliśmy").
Jeśli atakującemu "dajemy" malware zainstalowane na stacji ofiary, to tak trywialne rzeczy jak podmiana rachunku i ukrywanie tego faktu przed użytkownikiem atakujący po prostu może.
Co do podmieniania numeru rachunku "bez zastanowienia się czym on jest" - to akurat mam tu pewną wątpliwość. Przypominam, że przelew zawiera informację o koncie źródłowym i docelowym. Rachunek źródłowy w różnych bankach jest prezentowany różnie (identyfikator, bezpośrednio numer). Podmienianie wszystkiego co wygląda na numer rachunku może spowodować, że przelew się nie wykona, bo numer rachunku źródłowego będzie nieprawidłowy.
Akurat z tego, co widzę, w mBank nie ma tego "problemu", numer rachunku źródłowego nie jest tam podawany "wprost". Z drugiej strony jednak grzebanie bezpośrednio po pamięci i podmiana "jak leci" nie jest bardzo uniwersalna.
Pozwolić kopiować numer rachunku można, tylko trzeba to zrobić z głową - np. tak by bezwzględnie uruchomić weryfikację choćby części numeru przez Klienta + suma kontrolna numerów rachunków (przynajmniej w przelewach krajowych) rozwiąże problem w znakomitej większości przypadków banaptera.
Podchodząc do elementów: co atakujący może i co ma - ma to moim zdaniem sens jeśli opisując "co może" wskazujemy co "może zrobić" dzisiaj, przy tym co już widujemy. Podstawą w planowaniu defensywnych elementów bezpieczeństwa jest przewidywanie, jak można złamać nasze zabezpieczenie i jakie warunki trzeba spełnić by to zrobić. Widząc możliwe rozwiązania na rynku oraz te zrobione w wew. fabrykach jestem przekonany, że można obejść każde ze stosowanych metod obrony z tym, że nie wszystkie "teraz", bo nie został ten atak jeszcze zaimplementowany (czyt. ujawniony) LUB nie jest powszechny.
Nie można się skupiać na "schowku" jeśli wiadomo, że możliwa (i czasami wykorzystywana) jest modyfikacja rachunku, który przez schowek nie przechodzi.
Co do skupiania się na "schowku" - pełna zgoda, ale przecież te inne miejsca, gdzie podmieniany jest przez malware numer rachunku to już wszyscy zabezpieczyli, right?
Wcześniej miałem na myśli to, że ci co wiedzą o tym, iż malware może w locie podmieniać numer rachunku beneficjenta, powinni się przed tym już zabezpieczyć - nie licząc tylko na to, że Klient zauważy w opisie kodu autoryzacyjnego, że ma podpisać nie tą transakcję/operację, którą chciał wykonać.
Oczywiście możesz implementować różnego rodzaju "zabezpieczenia", ale dla atakującego dysponującego malware na stacji ofiary wszystkie te zabezpieczenia są możliwe do obejścia. To, co ewentualnie może Cię przez pewien czas bronić to ta stara zasada o uciekaniu przed niedźwiedziem - musisz biec szybciej, niż najwolniejsza osoba z grupy.
Może kiedyś będzie okazja do prezentacji jak w "nie idealny" sposób skutecznie rozwiązywać/oddalać niebezpieczeństwo związane z malware i dlaczego większość czeka na to "idealne" rozwiązanie, a do tego czasu wydaje się, że "jest OK - nie ma idealnego rozwiązania, więc cóż... malware na stacji może obejść wszystko". Jestem pod wielkim wrażeniem "bezradności/pasywności" bezpieczników w takich sytuacjach - chcą wszystko albo nic, pomijam sytuację kiedy chcą "certyfikat" lub "papier", który ma być ich tarczą ratunkową, że coś zrobili i to nie ich wina.
Administrator (root - (e)uid-0) w Linuksie też może wszystko, a czy nie po to stosujemy nie idealne rozwiązania jak SELinux (choćby jego podsystem auditd), kontenery, etc. by zmniejszyć ryzyko? Pojawia się znana i powszechna podatność w SELinuksie to i zmienia się SELinuks. Bezpieczeństwo to proces...bla bla bla.
Moim zdaniem walka z malware to walka z ich ekosystemem, jeśli nie całym to jego fragmentami tam gdzie jest dźwignia do sukcesu - obrony środków klientów banków i gdzie sięgają "ręce". To wszystko wymaga zmiany myślenia, trzeba pozbyć się dogmatu: "na stacji malware może wszystko" - otóż może to co jest zaimplementowane i system na to pozwala. Czasem malware trzeba oszukać, a nie zablokować czy ograniczyć. Trzeba zmieniać taktykę na taką, której się nie spodziewają. Czy to są skuteczne metody? - TAK, pogadać możemy jak się spotkamy znów na mieście lub przy innej okazji, bloga pewnie czytają również ci "źli"
Nie znaczy to, że trzeba rezygnować z rozwiązań tymczasowych jeśli są efektywne/opłacalne. Trzeba tylko pamiętać, że są one krótkotrwałe. A jeśli chodzi o koszty rozwiązań - to jest to nie tylko koszt ich wprowadzenia, ale również choćby stopień niewygody dla użytkownika. I w tym przypadku ewentualne wyłączenie możliwości wklejania rachunku jest wysoko na skali upierdliwości. Z drugiej strony nie podoba mi się komunikat typu "rachunek został wklejony, sprawdź jego poprawność", bo wraz z pojawieniem się Banatrix stracił na aktualności (wyłączenie kopiowania numeru rachunku zresztą też). Lepsza byłaby instrukcja - "zawsze sprawdź numer rachunku w SMS".
Jeśli chodzi o skuteczność ataków socjotechnicznych - trochę trudno z nimi walczyć technicznie, prawda? Inna sprawa, że mechanizmy bezpieczeństwa muszą być zrozumiałe i wygodne dla tych, którzy z nich korzystają.
A nad pozostałymi kwestiami można dyskutować długo i namiętnie
Rozwiązaniem strategicznym może i jest idealny TIV, ale on nie istnieje, prawda? - jeśli masz przykłady idealnego tzn., że odnalazłeś odpowiedź na pytanie z Twojej prezentacji i bardzo chętnie się z nim zapoznam.
Jeśli nie ma idealnej strategi - idealna to taka realizowalna, w krótkim czasie (zanim nam ukradną więcej niż klienci/firmy są w stanie przetrwać) i kosztowo efektywna
Czy inne rozwiązania są krótkotrwałe? - mam przykłady, że nie, mogą być skuteczne przez lata, trzeba je tylko rozwijać. Czy IPS raz skonfigurowany i zapomniany daje 100% jego możliwości? - nie i uważam, że w tym przypadku jest podobnie, a nawet tak samo.
Podałem SELinuksa jako podobny przykład z innego świata, nie wiązałem go z malware - bankerami.
co atakujący ma,może i umie