Jak i z jakim skutkiem atakowałem kody SMS
Pora przedstawić wyniki eksperymentu dotyczącego skuteczności różnych metod autoryzacji transakcji, konkretnie SMS i tokenów C/R. Na początek opiszę wyniki dla kodów SMS. A jak przedstawiają się rezultaty? Na początek może napiszę, że w 45%25 przypadków atak kończył się sukcesem. To chyba całkiem niezły wynik w sytuacji, kiedy osoby uczestniczące w eksperymencie spodziewają się podstępu, prawda?
Do kiedy zbierałem dane
Dane, które są uwzględnione w tym podsumowaniu zostały zebrane do dnia 14 marca, mniej więcej do godziny 7 rano. Do tego czasu zarejestrowałem 319 przypadków testowych w 59 rożnych sesjach. W 140 przypadkach “aktywował się” malware, w 64 przypadkach atak malware zakończył się sukcesem, co daje 45%25 skuteczność. Te 45%25 to wartość średnia, rzeczywista skuteczność ataku zależy od konkretnego scenariusza ataku, o czym nieco dalej.
Ilość zebranych danych nie jest specjalnie duża, więc wyniki eksperymentu należy traktować z pewnym dystansem. Mimo wszystko uważam, że wyniki są na tyle ciekawe, iż warto się z nimi zapoznać. Taki mały eye-opener.
Kiedy atakowałem
W przypadku tego eksperymentu byłem w znacznie gorszej pozycji, niż prawdziwi atakujący. Osoby, które brały w nim udział , prawdopodobnie przeczytały wcześniej wprowadzenie do niego i spodziewały się jakiegoś podstępu. To zupełnie inna sytuacja, niż przypadek, gdy na naszym komputerze, któremu ufamy, zadomowi się nagle malware. Podejrzewam, że poziom czujności w tych dwóch przypadkach będzie “nieco” różny.
Musiałem w jakiś sposób uśpić czujność osób biorących w eksperymencie, w związku z czym:
- przy dwóch pierwszych operacjach malware nigdy nie atakował,
- prawdopodobieństwo ataku malware w kolejnych krokach to 4/5,
W rezultacie takich założeń malware był “aktywny” w mniej niż 50%25 prób wykonania przelewu. Co u niektórych powodowało pewien dyskomfort :)
Jakie zasadzki przygotowałem
Przygotowałem aż osiem różnych sposobów atakowania klientów. W wynikach oznaczane są one identyfikatorami 1 – 8 i w tej kolejności je opiszę.
- 1 - “jawna” podmiana rachunku źródłowego,
- 2 - “jawna” podmiana rachunku docelowego,
- 3 - “jawna” podmiana kwoty,
- 4 - podmiana rachunku źródłowego,
- 5 - podmiana rachunku docelowego,
- 6 - podmiana kwoty,
- 7 - podmiana rachunku docelowego na rachunek podobny,
- 8 - “jawna” podmiana rachunku docelowego na rachunek podobny,
Poniżej dokładniejsze wyjaśnienie poszczególnych ataków oraz ich skuteczność.
Jawna podmiana rachunku źródłowego (1)
Nad sensownością podmiany numeru rachunku źródłowego można dyskutować. Scenariusz takiego ataku, który mógłby mieć sens, to na przykład przelanie 100 jednostek waluty z konta w EUR zamiast z konta w PLN. Nie będę się spierał jak jak bardzo sensowny jest tego typu atak, jednak informacja o numerze rachunku źródłowego jest zawarta w wiadomości SMS z kodem jednorazowym do potwierdzenia transakcji, więc chciałem sprawdzić, czy i jak często jest weryfikowana przez użytkownika. Dla zwiększenia “prawdziwości” całego scenariusza mogłem do dodać walutę rachunku i modyfikować nie tylko sam numer rachunku źródłowego, ale również walutę, w jakiej operacja zostanie wykonana. Na ten pomysł wpadłem jednak już po rozpoczęciu eksperymentu i nie chciałem modyfikować warunków w trakcie jego trwania.
Pod pojęciem “jawna” podmiana należy rozumieć tu przypadek, gdy na stronie wyświetlanej użytkownikowi prezentowany jest numer rachunku zmodyfikowany przez malware. Inny niż ten, który użytkownik wpisał w pierwszym kroku, ale zgodny z numerem rachunku, który użytkownik widzi w otrzymanym SMS. Podobnie jest w innych “jawnych” przypadkach, zarówno dla rachunków docelowych, jak i dla kwoty. W wersji “jawnej” w drugim kroku prezentowane są zawsze dane po modyfikacji. Fakt, “jawna” to niezbyt szczęśliwe określenie, ale tak ten scenariusz nazwałem na początku i niech już tak zostanie.
Jawna podmiana rachunku docelowego (2)
Cel podmiany numeru rachunku docelowego jest oczywisty. Pieniądze trafią na konto podstawione przez atakującego. Tu również podmiana była “jawna”, czyli w drugim kroku prezentowany był inny numer rachunku niż ten wpisany przez użytkownika, ale zgodny z numerem otrzymanym w kodzie SMS.
Jawna podmiana kwoty (3)
Malware modyfikuje kwotę realizowanego przelewu. Jest to podmiana jawna, w drugim kroku wyświetlana jest kwota zmodyfikowana przez malware i zgodna z kwota otrzymaną w SMS.
Podmiana rachunku źródłowego (4)
Jest to nieco zmodyfikowany wariant pierwszego ataku. Modyfikacji podlega numer rachunku źródłowego, natomiast w drugim kroku widnieje na stronie ten numer rachunku, który wybrał użytkownik przy tworzeniu przelewu. Nie zgadza się on z informacjami o numerze rachunku źródłowego otrzymanymi w SMS.
Podmiana rachunku docelowego (5)
Tym razem jest to zmodyfikowana wersja drugiego ataku. Modyfikacji podlega numer rachunku docelowego, przy czym w drugim kroku wyświetlany jest ten numer rachunku, który został wpisany przez użytkownika w pierwszym kroku. Ten numer z oczywistych przyczyn nie zgadza się z numerem rachunku otrzymanym w SMS.
Podmiana kwoty (6)
W tym przypadku modyfikowana jest kwota, przy czym w drugim kroku wyświetlana jest kwota zgodna z wpisaną przez użytkownika w kroku pierwszym. Podobnie jak w dwóch poprzednich przypadkach, również i w tym wypadku wartość wyświetlana jest niezgodna z otrzymaną w SMS.
Podmiana rachunku docelowego na rachunek podobny (7)
Scenariusz ataku jest właściwie taki, jak w przypadku piątym. Jedyna różnica polega na tym, że wykorzystywany jest numer rachunku docelowego podobny do rachunku wpisanego przez klienta. W tym wariancie numer rachunku wyświetlany w drugim kroku jest zgodny z numerem wpisanym przez użytkownika w kroku pierwszym, ale niezgodny z otrzymanym w SMS.
Jawna podmiana rachunku docelowego na rachunek podobny (8)
Jest to najbardziej podstępny wariant ataku. Podobnie jak w poprzednim przypadku numer rachunku docelowego jest modyfikowany na numer rachunku podobny do numeru wpisanego przez użytkownika. Zmodyfikowany numer rachunku jest wyświetlany w drugim kroku, jest on więc zgodny z wartością otrzymaną w SMS. “Podobny” numer rachunku wygląda mniej więcej tak:
29716143087803837322023708 29716157089104017337032708
W pewnych przypadkach dla ataków (7) i (8) mogło się tak zdarzyć, że ostatnie 6 cyfr numeru rachunku wpisanego przez użytkownika i zmodyfikowanego przez malware będzie identycznych. Miało to miejsce w tych przypadkach, gdy obok siebie występowały dwie takie same cyfry i akurat “malware” postanowił właśnie je zamienić miejscami. Z tego co widzę, miały miejsce 4 takie przypadki.
Zwracam uwagę, że w niektórych przypadkach atakujący może kontrolować numer rachunku , przynajmniej częściowo. Przykładem może być tutaj usługa płatności masowych, w której klient otrzymuje od banku pewną “przestrzeń” numerów, którą następnie gospodaruje według własnego uznania. W szczególności pierwsze i ostatnie cyfry numeru rachunku mogą pozostawać pod jego kontrolą (patrz też: Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy).
Skuteczność ataków
Wyniki skuteczności ataków będą czytelniejsze, jeśli zostaną zaprezentowane w tabelce. Są one zgrupowane po typie ataku:
- modyfikacja rachunku źródłowego,
- modyfikacja rachunku docelowego,
- modyfikacja rachunku docelowego (rachunek podobny),
- modyfikacja kwoty,
Każdy z tych ataków wykonany był w dwóch wersjach, “jawnej” oraz “cichej”. Wersja “jawna” to ta, w której w drugim kroku wyświetlane są zmodyfikowane dane transakcji.
Typ ataku | Skuteczność (wersja “jawna”) | Skuteczność (wersja “cicha”) |
---|---|---|
Podmiana rachunku źródłowego (1 i 4) | 81%25 | 42%25 |
Podmiana rachunku docelowego (2 i 5) | 56%25 | 11%25 |
Podmiana rachunku docelowego, rachunek podobny (8 i 7) | 65%25 | 56%25 |
Podmiana kwoty (3 i 6) | 15%25 | 25%25 |
Jakie wnioski można wyciągnąć
Kilka podstawowych wniosków, które można wyciągnąć z tego eksperymentu:
- niewielka uwaga przykładana jest do weryfikacji rachunku źródłowego,
- duża uwaga przykładana jest do weryfikacji rachunku docelowego,
- uwaga przykładana do weryfikacji kwoty przelewu jest mniejsza niż przykładana do rachunku docelowego, ale większa niż ta w przypadku rachunku źródłowego,
- dane z SMS są porównywane z tym, co widać na ekranie, a nie tym, co zostało wpisane w pierwszym kroku operacji przelewu,
Nie ważne skąd, ważne gdzie
Warto zwrócić uwagę, że w ponad 80%25 przypadków atak (jawny) polegający na podmianie numeru rachunku źródłowego, kończył się powodzeniem. Wygląda na to, że to, z którego rachunku zostanie wykonany przelew, nie jest specjalnie istotne. Sprawdzenie polegało przede wszystkim na weryfikacji, czy wartość wyświetlona na stronie zgadza się z tą otrzymaną w SMS. To, czy to jest rzeczywiście ten numer rachunku, który został wybrany w pierwszym kroku, wydaje się sprawą drugorzędną.
Odpowiednim punktem odniesienie wydaje się tutaj atak polegający na podmianie numeru rachunku docelowego na numer, który nie jest specjalnie podobny, do rachunku oryginalnego. W tym scenariuszu (2) skuteczność wynosiła 56%25. Cóż, wygląda na to, że bardziej uważnie sprawdzane było to, gdzie trafią pieniądze, a nie to, skąd wyjdą.
Porównuję to, co widzę. Kwota nie jest (aż tak) ważna.
Zastanawiałem się kiedyś, co jest w rzeczywistości porównywane przez użytkowników w przypadku autoryzacji transakcji z wykorzystaniem SMS. Czy otrzymane w SMS są sprawdzane z tym, co widać na ekranie, czy raczej z tym, co zostało wpisane w poprzednim kroku. Rezultat jest zgodny z moimi przypuszczeniami: z tym co widać.
Potwierdzenie? Proszę bardzo. Wystarczy popatrzeć jeszcze raz na zbiorcza tabelkę zawierającą informacje o skuteczności ataków. Pierwsza wartość, to skuteczność ataku “jawnego” (czyli wartość wyświetlana w drugim kroku jest zgodna z wartością otrzymaną w SMS, ale niezgodna z danymi wpisanymi w pierwszym kroku), druga – dane zgodne z wpisanymi w pierwszym kroku, siłą rzeczy niezgodne z wartością otrzymana w SMS. We wszystkich przypadkach, z pominięciem modyfikacji kwoty, skuteczność ataku jest wyższa wówczas, gdy wartość wyświetlona na stronie jest zgodna z otrzymaną w SMS. Nie ważne, że dane te są niezgodne z danymi wcześniej wpisanymi w poprzednim kroku.
Ciekawym tematem może być również samo porównywanie dwóch ciągów liczb. Jeśli porównać przypadki (5) i (7), to różnica w ich skuteczności jest bardzo wyraźna: 11%25 vs. 56%25. Prawdopodobnie tutaj pojawia się ten przypadkek w któyrm czytmay początki i końce wyrazu i jeśli to, co widzimy pasuje do tego, czego się spodziewamy, nie zauważamy “drobnych” różnic. Przypuszczam, że tu grupowanie cyfr może odgrywać istotną rolę.
W przypadku kwoty operacji jest jednak inaczej. To jedyny przypadek, w którym wersja “jawna” ataku jest mniej skuteczna, niż wersja cicha. Wynika to prawdopodobnie z tego, że nie jest ona weryfikowana (lub jest weryfikowana mniej uważnie) z danymi otrzymanymi w SMS, natomiast w drugim kroku kwota inna niż wpisana wyraźnie “rzuca się w oczy”. Może to być po części związane z tym, ile przeciętny człowiek jest w stanie (na krótko) zapamiętać. Numer rachunku składa się ze zbyt dużej ilości cyfr, natomiast kwota zwykle jest na tyle krótka, by zmieścić się w pamięci krótkotrwałej.
Muszę przyznać jednak, że kwotę atakowałem w mniej wyrafinowany sposób, niż numer rachunku. Być może inaczej przedstawiałyby się wyniki, gdybym na przykład kwotę 1967,12 zmodyfikował na 1691,72 lub 133,12 na 138,12. Zastanawiam się jakie kwoty są zwykle przelewane. Czy są to kwoty “okrągłe”, czy może jednak takie, które dają większy potencjał na podmienianie cyfr albo przestawianie przecinka?
Gdzie sprawdzić swoje wyniki
Jeśli ktoś wykonał 10 operacji i chce sprawdzić, zapamiętał swój identyfikator i chce sprawdzić jak mu poszło, może to zrobić: Wyniki eksperymentu: kody SMS. Jak poszło?
EDIT: Jeśli sprawdzałeś swoje wyniki i otrzymałeś informację, że dla podanego identyfikatora brak jest danych – sprawdź jeszcze raz. Niestety sprawdzony wzorzec projektowy Kopiego-Pejsta po raz kolejny pokazał jedną ze swoich nielicznych wad :)
Oryginał tego wpisu dostępny jest pod adresem Jak i z jakim skutkiem atakowałem kody SMS
Autor: Paweł Goleń