Paweł Goleń, blog

Do kiedy zbierałem dane

Wyniki, które tu prezentuję, dotyczą danych zebranych do 18 marca. Niestety, druga część eksperymentu spotkała się z dużo mniejszym zainteresowaniem, niż ta dotycząca kodów SMS. W rezultacie zebrałem tylko 136 przypadków testowych w 27 różnych sesjach. W 60 przypadkach aktywował się mój "malware", 38 z tych ataków zakończyło się sukcesem. Daje to skuteczność ataku na poziomie 63%.

W tym przypadku również 63% jest wartością średnią bo, podobnie jak w przypadku SMS, typów ataku było wiele. Skuteczność poszczególnych ataków w istotny sposób różniła się między sobą. Część z ataków była tak pomyślana, by ich oczekiwana skuteczność wynosiła 100%.

Kiedy atakowałem

Ponieważ przykład symulujący token C/R jest modyfikacją przykładu dotyczącego kodów jednorazowych przesyłanych przez SMS, zasady dotyczące tego, kiedy "aktywował się malware" są identyczne z tymi opisanymi dla kodów SMS.

Jakie zasadzki przygotowałem

Zasadzki, które były przygotowane dla tokenu C/R były prawie identyczne z tymi opisanymi dla SMS. Musiałem wprowadzić jednak pewne, niewielkie zmiany w kilku przypadkach, w związku z czym całość zasadzek opiszę jeszcze raz.

Jawna podmiana rachunku źródłowego (1)

Identycznie jak w przypadku przykładu dla SMS, numer rachunku źródłowego był podmieniany na inny numer rachunku użytkownika. Nowy rachunek źródłowy był wyświetlany w drugim kroku. Użytkownik miał szansę anulować operację przelewu, jeśli tylko zauważył podmianę. Warto zauważyć, że informacja o numerze rachunku źródłowego nie jest uwzględniana przy konstruowaniu challenge, a przynajmniej użytkownik nie był tego świadomy.

Jawna podmiana rachunku docelowego (2)

Tu numer rachunku docelowego jest podmieniany na jeden z rachunków z listy. Nowy numer rachunku nie jest specjalnie podobny do rachunku oryginalnego (chyba, że przez przypadek). Nowy numer rachunku jest prezentowany na stronie w drugim kroku operacji.

Jawna podmiana kwoty (3)

Zasada działania jest identyczna z przykładem dla SMS. Kwota przelewu jest podmieniana i nowa kwota jest prezentowana w drugim kroku. Użytkownik ma szansę zobaczyć, że została ona zmodyfikowana i przerwać operację przelewu. Warto zwrócić uwagę, że w przypadku tej "implementacji" tokenu C/R kwota nie jest weryfikowana przez użytkownika podczas konstruowania challenge. Challenge składał się z dwóch części:

• (prawie) losowych dwóch cyfr,
• dwóch pierwszych i czterech ostatnich cyfr numeru rachunku docelowego,

W rzeczywistości kwota jest uwzględniana w challenge, ponieważ te "losowe" dwie cyfry uwzględniane w challenge generowane są na podstawie danych realizowanej transakcji, jednak użytkownik nie jest o tym informowany, nie ma również możliwości sprawdzenia, czy te dwie cyfry są "prawidłowe" dla parametrów realizowanej przez niego operacji.

Podmiana rachunku źródłowego (4)

W tym wypadku podmieniany jest numer rachunku źródłowego, jednak w drugim kroku prezentowany jest oryginalny numer rachunku. Tutaj użytkownik nie dysponuje właściwie żadnym sposobem sprawdzenia, czy na pewno przelew zostanie wykonany z rachunku, z którego miał być wykonany. Widać to również w wynikach eksperymentu, skuteczność tego ataku to 100%.

Podmiana rachunku docelowego (5)

Przypadek ten jest tożsamy z przypadkiem (2). Powód jest prosty - skoro do autoryzacji transakcji wykorzystuję pierwsze i ostatnie cyfry rachunku docelowego, nie mogę wyświetlić innych. Wówczas użytkownik przepisujący te cyfry, które zostaną wyświetlone w drugim kroku nie będzie mógł autoryzować transakcji. A że będzie przepisywał właśnie te cyfry, które widzi, byłem prawie pewny na etapie przygotowania eksperymentu. Jak pokazały wyniki dla SMS, moje przypuszczenia były słuszne.

Podmiana kwoty (6)

Tutaj modyfikacji podlega kwota operacji. W drugim kroku wyświetlana jest jednak wartość wpisana przez użytkownika. Nie ma on żadnej przesłanki, które pozwoliłaby mu stwierdzić, że operacja, która zostanie wykonana jest inna, niż ta, którą w rzeczywistości chciał wykonać. Skuteczność ataku powinna wynosić 100%, w rzeczywistości jest to mniej. Dlaczego? Wyjaśnienie dalej.

Podmiana rachunku docelowego na rachunek podobny, wersja 1 (7)

Podmianie ulega rachunek docelowy, jednak jest on modyfikowany w taki sposób, by pierwsze dwie i cztery ostatnie cyfry nowego rachunku były identyczne z tymi, w rachunku oryginalnym. Na stronie wyświetlany jest oryginalny numer rachunku. Ofiara nie ma możliwości stwierdzenia, że wykonuje w rzeczywistości przelew na rachunek inny, niż zamierzała. Ponownie, skuteczność tego ataku to 100%.

Podmiana rachunku docelowego na rachunek podobny, wersja 2 (8)

W tym wypadku, podobnie jak dla SMS, numer rachunku jest modyfikowany w taki sposób, że cyfry biorące udział w procesie autoryzacji różnią się tylko nieznacznie od tych w oryginalnym numerze rachunku. Na stronie wyświetlany jest zmodyfikowany numer rachunku, więc użytkownik jest w stanie przerwać operację przelewu, jeśli zauważy subtelne różnice w wyświetlanym numerze rachunku. Powinien je zauważyć, różnice występują również w tych cyfrach, z których skonstruować musi challenge.

Skuteczność ataków

Skuteczność ataków przedstawię w analogicznej jak dla SMS formie, trzeba pamiętać jednak, że w tym wypadku nie zawsze druga i trzecia kolumna są ze sobą związane w taki sposób, jak miało to miejsce dla SMS. Niestety, jak już wspominałem przykład z tokenem C/R wzbudził mniejsze zainteresowanie, niż ten z SMS. W rezultacie jest mniej danych, co niestety widać w rezultatach eksperymentu. Podane tu informacje na temat skuteczności poszczególnych ataków trzeba traktować z pewnym dystansem.

Kilka wyjaśnień do wyników

Po pierwsze - różnica w wynikach między przypadkiem (2) i (5) jest i jest duża. Przypadek (5) zaprezentował skuteczność na poziomie 0%, podczas gdy (2) miał skuteczność rzędu 28%. Jest to dziwne, skoro oba te przypadki są identyczne. Dlaczego tak się stało? Wyjaśnienie jest proste - bardzo mała ilość prób, w takich przypadkach statystyka nie działa. Dla przypadków (2) i (5) lepiej popatrzeć na nie, jak na całość. Wówczas skuteczność tego typu ataku kształtuje się na poziomie 20% i taka wartość podana jest w tabeli w nawiasie.

W przypadku ataku (6) oczekiwana skuteczność to 100%. Jeśli jednak popatrzeć do wyników okazuje się, że skuteczność ataku to (tylko) 87%. Dlaczego tak jest, skoro użytkownik nie ma właściwie szansy zobaczenia, że rzeczywista kwota przelewu będzie inna? W tym wypadku brakujące 13% to jedna transakcja, która została przerwana. Przerwanie tej transakcji można uznać za błąd, który akurat w tym przypadku okazał się "szczęśliwy".

Skoro już o tym mowa, to w zebranych danych jest osiem przypadków, w których transakcja nie została ukończona, mimo tego, że nie było tam żadnego ataku. W czterech przypadkach realizacja transakcji zakończyła się po wpisaniu jej danych, w kolejnych czterech transakcja została świadomie anulowana. Świadome anulowanie poprawnej transakcji mogło wynikać z pewnych problemów z wygodą użytkowania całego narzędzia, pisał o tym na przykład Mariusz Kędziora w komentarzach po udostępnieniu przykładów.

Co jest ciekawego w wynikach

Zdecydowanie nie powinna dziwić 100% skuteczność ataku w przypadku (4), (7) i prawie 100% przypadku (6). Tak jak napisałem, ofiara nie miała w tych przypadkach praktycznie żadnych przesłanek by stwierdzić, że w rzeczywistości zostanie wykonany przelew inny, niż ten, który planuje zrobić. Przypadki te powinny w pewnym stopniu pokazać wartość dodaną wynikająca z dostarczenia informacji na temat realizowanej transakcji inną drogą, jak ma to miejsce w przypadku autoryzacji z wykorzystaniem kodów SMS. Niestety, problem z kodami SMS jest taki, że komórki przestały być zaufanymi urządzeniami. Właściwie nigdy nie były, ale prawdopodobieństwo zainstalowania wrogiego kodu na starym telefonie jest dalece mniejsze, niż w przypadku współczesnych telefonów.

Muszę przyznać, że nieco zaskoczyła mnie niska skuteczność ataków w przypadkach (2) i (8). Choć zgodnie z oczekiwaniami podmiana rachunku na podobny do rachunku oryginalnego (8) jest skuteczniejsza od podmiany na rachunek, który podobny nie jest (2), to skuteczność tych dwóch ataków w przypadku C/R jest wyraźnie niższa, niż w przypadku kodów SMS. Być może wynika to z małej ilości zebranych danych, ale możliwe jest również, że przepisanie kilku cyfr bardziej angażuje użytkownika, niż tylko spojrzenie na nie. To taka hipoteza, ale może warto ją w przyszłości zweryfikować. A może już w jakichś mądrych książkach ta różnica jest opisana i wyjaśniona?

Gdzie sprawdzić swoje wyniki

Te osoby, które wykonały co najmniej 10 prób i otrzymały swój identyfikator, mogą sprawdzić swoją (lub moją) skuteczność tutaj: Wyniki eksperymentu: token C/R.