Paweł Goleń, blog

Dwa podstawowe mechanizmy bezpieczeństwa w systemach bankowości internetowej to uwierzytelnienie użytkownika oraz autoryzacja transakcji. Autoryzacja transakcji jest bardzo ważnym elementem, między innymi powinna oferować:

Niezaprzeczalność

Użytkownik może chcieć się wyprzeć realizacji określonej operacji i żądać od banku potwierdzenia na jakiej podstawie operacja została wykonana. W końcu nie można zakładać, że atak na bankowość internetową to wyłącznie atak na klienta. Dlaczego atakującym nie ma być klient, a ofiarą - bank?

Potwierdzać parametry transakcji

Fakt potwierdzenia zlecenia operacji to nie wszystko. Ważne jest jeszcze to, jak ta operacja powinna wyglądać, czyli jej istotne parametry. W przypadku przelewu te istotne parametry to numer rachunku źródłowego, numer rachunku docelowego, kwota oraz waluta operacji. Użytkownik powinien potwierdzać nie tylko chęć wykonania operacji, ale również jej parametry. Dzięki temu w jakimś stopniu zabezpieczony jest zarówno bank przed próbą oszustwa ze strony klienta, jak i klient przed oszustwem lub błędem po stronie banku.

Skoro istotnym elementem autoryzacji transakcji jest potwierdzenie parametrów autoryzowanej transakcji, to metoda autoryzacji powinna dodatkowo umożliwiać wiarygodną weryfikację parametrów realizowanej transakcji. Wyświetlenie tych parametrów na stronie jest niewystarczające. Malware działający na stacji użytkownika te dane bez problemu może zmienić, w związku z czym użytkownik nie ma pojęcia jaką operację w rzeczywistości autoryzuje.

Czy tokeny challenge-response umożliwiają potwierdzenie parametrów transakcji? W pewnym stopniu tak, jeśli challenge generowany przez system jest związany z parametrami realizowanej w danej chwili transakcji. Teoretycznie dla dwóch różnych operacji challenge będzie różny, a więc i różny będzie response tokenu. Praktyka jest nieco inna...

Głównym ograniczeniem tokenów challenge-response jest długość użytego wezwania. Im dłuższe wezwanie, tym dokładniej może identyfikować czy potwierdzać parametry realizowanej operacji. Problem w tym, że takie wezwanie trzeba do tokenu przepisać. Jeśli wezwanie jest zbyt długie, to takie przepisywanie będzie uciążliwe dla klientów, zaczną się irytować, protestować, mogą podjąć decyzję o zmianie banku. Długość wezwania, pomijając kwestie techniczne, jest ograniczona cierpliwością przeciętnego użytkownika. Ilość parametrów operacji, które są przy tej metodzie autoryzacji potwierdzane jest z kolei ograniczona przez długość wezwania. To tyle, jeśli chodzi o potwierdzanie parametrów transakcji. A co z możliwością weryfikacji tych parametrów przez użytkownika?

Weryfikacja może odbywać się na dwa sposoby. W pierwszym z nich istotne dane transakcji są zakodowane w przygotowanym przez system wezwaniu. Po przepisaniu wezwania do tokenu informacja o zakodowanych w wezwaniu parametrach transakcji jest wyświetlana użytkownikowi. Musi on ją potwierdzić zanim token wygeneruje odpowiedź. Problem z tym, że ilość informacji jest niewielka. Taki obrazek można znaleźć w dokumentacji jednego z banków:

Ilość informacji o rachunku docelowym jest niewystarczająca do tego, by stwierdzić gdzie pieniądze zostaną przelane. Jeśli ktoś ma wątpliwości, odsyłam do mojego starego wpisu Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy.

Inną metodą weryfikacji parametrów operacji jest składanie przez użytkownika systemu wezwania z parametrów operacji, którą zamierza autoryzować. W trakcie tego składania teoretycznie ma sprawdzić, czy dane, które przepisuje, są zgodne z jego zamierzeniem. Podobnie jak w wyżej pokazanym przykładzie ilość informacji wchodzących w skład wezwania, a więc i weryfikowanych w trakcie jego konstruowania, nie wystarczy do jednoznacznej identyfikacji operacji. W obu przypadkach klient może autoryzować inną operację, niż chciał wykonać. Nie zauważy tego, bo ta operacja, którą wykona i ta, którą chciał wykonać w procesie weryfikacji transakcji może wyglądać dokładnie tak samo.

A gdzie jest ten zapowiadany przeze mnie na wstępie replay attack? Potencjalny atak jest w sposobie konstruowania wezwania. Skoro jest on oparty na parametrach realizowanej transakcji, to dla dwóch takich samych operacji powinien wyglądać tak samo, przynajmniej częściowo. Częściowo, bo być może elementem takiego wezwania będzie jakiś fragment losowy. Nie zapominajmy jednak, że długość wezwania jest ograniczona, w związku z czym jeśli mamy zmieścić w nim zarówno dane transakcji, jak i jakąś losową wartość, to ta losowa wartość nie może być zbyt duża. W efekcie istnieje niezerowe prawdopodobieństwo, że dla dwóch różnych operacji wezwanie wygenerowane przez system będzie takie samo. A jeśli tak, to odpowiedź tokenu również będzie taka sama, jeśli przy jej wyliczaniu uwzględniany jest wyłącznie klucz oraz wezwanie. W rezultacie atakujący dysponując jedną parą wartości wezwanie - odpowiedź może próbować wykonać w systemie transakcję, dla której system wygeneruje takie samo wezwanie. Atakujący odpowiedź już ma.

Ten scenariusz to taka luźna spekulacja. Teoretycznie jest możliwy do przeprowadzenia, na ile praktyczny - trudno mi powiedzieć. Dla mnie istotniejszą wadą metody autoryzacji transakcji z wykorzystaniem tokenu challenge-response jest ograniczona możliwość potwierdzenia parametrów transakcji i ich weryfikacji przez ofiarę. Bo przecież potwierdzenie przelewu na wszystkie poniższe konta na ekranie tokenu GSM pokazywanego wcześniej, będą wyglądały dokładnie tak samo:

12 2490 8997 4900 0000 0457 8901
12 2490 8997 4900 0000 0554 8901
12 2490 8997 4900 0000 0651 8901
12 2490 8997 4900 0000 0748 8901
12 2490 8997 4900 0000 0845 8901
12 2490 8997 4900 0000 0942 8901
12 2490 8997 4900 0000 1039 8901
12 2490 8997 4900 0000 1136 8901

Nawet jeśli challenge będzie unikalny, lub response generowany będzie na podstawie dodatkowych danych (licznik, czas), atakujący nadal może wykonać przelew na swoje konto. Jak? Podmieniając parametry realizowanej przez użytkownika transakcji w taki sposób, by w procesie weryfikacji użytkownik tej podmiany nie zauważył.