Konieczna nowa rubież obrony

Większość banków i ośrodków e-commerce jest zaprawiona w walce z trojanami kradnącymi referencje, tworząc bardziej złożone schematy uwierzytelniania, implementujące rozwiązania dwuskładnikowe. Dzisiaj banki często wymagają, aby użytkownik klikał na widniejącej na ekranie klawiaturze, wprowadzając losowo znaki hasła, lub wprowadzał informacje generowane przez kryptograficzne układy sprzętowe wielkości breloczka. Żadne z tych rozwiązań nie zabezpiecza jednak przed nowymi trojanami obchodzącymi SSL.

Nie jest to więc problem uwierzytelniania, ale autoryzacji transakcji. Nie ma tu znaczenia, jak skomplikowane i trudne do złamania jest wstępne uwierzytelnianie: trojan wyczekuje do momentu, aż uwierzytelnianie zostanie wykonane i dopiero wtedy manipuluje transakcją. Po wypełnieniu przez użytkownika dyspozycji przelewu, może zmienić docelowe konto na bank "na Kajmanach".

Rzeczywisty problem tkwi w tym, że dopuszczamy komputer do wykonania decyzji transakcyjnych w naszym imieniu, a komputer w rzeczywistości "nie wie" czy są one prawidłowe, czy nie.

Użytkownik może nie mieć możliwości wglądu w rzeczywistą transakcję, aby ewentualnie zatrzymać automatyczną aprobatę autoryzacji, a bank może nie mieć sposobu na dowiedzenie się, czy to trojan podejmuje decyzję, czy użytkownik.

Banki i instytucje finansowe nie zawsze doceniają wagę nowych zagrożeń. Większość banków rekomenduje co prawda używanie dwuskładnikowego uwierzytelniania, ale prawie wszystkie zwracają uwagę na kłopoty, jakie te schematy sprawiają użytkownikom. Takie dodatkowe uwierzytelnianie, oferowane w reakcji na nowe zagrożenia, jest jednak rozwiązaniem niewystarczającym.

Problemem w bankach są ponadto długie procedury wdrażania nowych zabezpieczeń, co może stawiać te instytucje w pozycji mocno defensywnej z eskalującymi atakami.

Kontrola transakcji

Nadające się do zastosowania rozwiązania problemu trojanów omijających SSL niekoniecznie są bardziej niedogodne niż uwierzytelnianie dwuskładnikowe. Skupiają się one na innych elementach: autoryzacjach transakcji. Dostawcy takich rozwiązań muszą wziąć pod uwagę, że dowolny mechanizm uwierzytelniania może być ominięty i trzeba problem rozwiązywać na innych etapach wykonywania transakcji.

Niektóre banki osobnym kanałem wysyłają do swoich klientów kody autoryzacji (np. za pośrednictwem wiadomości głosowej lub tekstowej dostarczanej przez inne urządzenie niż PC), które są wpisywane dla potwierdzania poszczególnych transakcji. Jednak klient często potwierdza transakcje taką, jaką widzi, podczas gdy w tle trojan SSL może manipulować tym, co w rzeczywistości przekazywane jest do banku. Klient może być przekonany, że wykonuje małą transakcję, podczas gdy bank, z inicjatywy trojana, czyści konto i przekazuje jego zawartość do innego banku.

W tym przypadku wysyłanie kodu autoryzacji do klienta nie sprawdza się, ponieważ użytkownik potwierdza w istocie transakcję, której nie jest w stanie zobaczyć.

Lepszym rozwiązaniem jest przesłanie zwrotnie do klienta istotnych szczegółów transakcji - data, numery kont, wielkość itp. - wraz z unikatowym kodem autoryzacji, co pozwala użytkownikowi zatwierdzać rzeczywistą transakcję. Niektóre banki i ośrodki e-commerce stosują już takie rozwiązania, wykorzystując potwierdzanie pozakanałowe, np. pocztą elektroniczną.

Takie podejście, z wykorzystaniem innego kanału komunikacji, również budzi wiele wątpliwości. Ten typ schematu autoryzacji może się sprawdzać, ale często uważany jest za rozwiązanie zbyt ekstremalne. Trzeba mieć na uwadze, że klienci nie bardzo chcą akceptować rozwiązania ekstremalne. Raczej oczekują wygody.

Wiele banków, mając właśnie na uwadze wygodę swoich klientów, prawdopodobnie nie zaakceptuje takich ekstremalnych form uwierzytelniania. Urządzenia pozakanałowe mogą być często niedostępne lub uszkodzone. Wymaganie, aby klient każdorazowo potwierdzał każdą transakcję bankową taką metodą nie ma szans na szerszą akceptację w dzisiejszym świecie.

Lepszym rozwiązaniem może być oferowanie przez bank potwierdzania pozakanałowego jako opcji, np. związanych z wysokością transakcji.

Inne rozwiązania, to zastosowanie dodatkowej kontroli w oprogramowaniu zaplecza. Można np. zakazywać transakcji, które bank uważa za wysoce podejrzane, lub wymagać dodatkowego potwierdzenia (zob. tabela).

Trzeba też przyjąć założenie, że infekcje nie mogą być zatrzymane jedynie przez przekonywanie użytkowników, aby nie uruchamiali niepewnego oprogramowania. Żaden użytkownik świadomie nie instaluje szkodliwego oprogramowania, a trojan SSL może być niezauważony nawet przez ostrożnych użytkowników.

Jednym z najprostszych sposobów obrony jest po prostu zachęcanie użytkowników do częstego kontrolowania stanu swojego konta online. Oprócz tego powinni oni unikać instytucji finansowych niestosujących dodatkowych zabezpieczeń transakcji.

Lepiej wybrać bank, który wymaga silnego uwierzytelniania i autoryzacji transakcji, chociaż może to być czasami trochę bardzie absorbujące. Takie instytucje powinny także zachęcać użytkowników do zgłaszania ataków phishingu na specjalny adres e-mail, przeznaczony dla raportów bezpieczeństwa.

Dzisiaj zagrożeniem numer jeden dla sektora bankowego są nadal trojany przechwytujące logowanie, ale trojany SSL, mogące obchodzić proces uwierzytelniania, jawią się jako szczególnie trudny przeciwnik. Wymagają one wyjątkowej uwagi ze strony dostawców środków ochrony i instytucji szczególnie narażonych, zanim konsumenci stracą zaufanie do działalności online.