Wpis ten jest związany z tematem autoryzacji transakcji, który wielokrotnie już poruszałem. Mimo tego temat wciąż nie został wyczerpany, jest ciągle wiele aspektów, o których się mówi. Jeden z nich chcę tu poruszyć, tak trochę w ramach ciekawostki.
Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy
Krótkie wprowadzenie
Autoryzacja transakcji służy między innymi do tego, by użytkownik potwierdził chęć wykonania operacji o określonych parametrach. Zawężając temat do przelewu krajowego za istotne parametry należy uznać:
- rachunek źródłowy,
- rachunek docelowy,
- kwotę operacji,
Dalej zawężając obszar zainteresowania do ochrony przed malware powyższą listę można zawęzić w zasadzie do dwóch istotnych parametrów:
- rachunku docelowego,
- kwoty operacji,
Użytkownik powinien otrzymać informację na temat tych parametrów kanałem, który nie jest kontrolowany przez malware, zweryfikować te parametry z zamierzoną operacją i dopiero w takim przypadku autoryzować transakcję.
W tym wpisie chcę zająć się tematem związanym z weryfikacją istotnych parametrów operacji, a konkretnie - co użytkownik powinien sprawdzić by upewnić się, że przelew trafi na konto, na które myśli, że trafi.
Numer rachunku w formacie IBAN
W tej chwili warto zapoznać się z formatem IBAN. Wystarczy zapamiętać, że numer rachunku składa się z:
- sumy kontrolnej (2 cyfry),
- numeru rozliczeniowego (8 cyfr),
- numer rachunku bankowego (16 cyfr),
W sumie daje to 26 cyfr. Długość numeru rachunku jest problemem, bo:
- ludzie się gubią przy weryfikacji,
- zajmują "dużo miejsca" (jeśli kanałem komunikacji jest np. SMS),
Z tych powodów informacja o rachunku źródłowym/docelowym zwykle zawiera jedynie część tego numeru. Problem w tym, że nie zawsze wystarczającą.
(Nie do końca) unikalne numery rachunków
W tej chwili pozwolę sobie wybrać pewien losowy numer rachunku bankowego, by wykorzystać go w przykładach. Posłuży mi do tego generator numerów rachunków w formacie IBAN.
12 2490 8997 4914 9249 3867 8901
W tym losowym numerze rachunku mamy:
- cyfry kontrolne: 12,
- numer rozliczeniowy: 2490 8997,
- numer rachunku: 4914 9249 3867 8901,
Dodatkową pomocą może być tu ewidencja numerów banków. Na jej podstawie można łatwo ustalić, że chodzi o Alior.
Na co warto zwrócić uwagę:
- numer rozliczeniowy musi być unikalny,
- numer rachunku nie musi być unikalny,
Oznacza to w praktyce, że w innym banku może istnieć klient, którego numer rachunku to 4914 9249 3867 8901. Oczywiście nie ma "kolizji", bo w numerze IBAN jest informacja gdzie szukać numeru rachunku, w jakim banku.
Problemy ze sprawdzaniem
Opisana wyżej sytuacja powoduje, że sprawdzając ostatnie 4 (lub więcej) cyfr rachunku nie mamy pewności, czy pieniądze trafią na pewno do tego odbiorcy, do którego myślimy, że trafią. Sprytny malware mógł tak zmodyfikować numer rachunku przy definiowaniu przelewu, że przelew co prawda trafi na konto z końcówką 8901, ale w zupełnie innym banku.
Skoro ostatnie cyfry nie są wystarczające, to może sprawdzać dwie pierwsze i ostatnie? W tym wypadku 12..8901. Przecież 12 to suma kontrolna, więc powinno być bezpiecznie... Błąd, ta suma ma służyć do wychwycenia przypadkowych błędów, a nie celowej modyfikacji numeru rachunku.
Dodanie do sprawdzanej wartości numeru rozliczeniowego banku (lub jego fragmentu), np.: 12 2490..8901, choć stawia poprzeczkę zdecydowanie wyżej. Jest to szczególnie ciekawy scenariusz, choć przyznać trzeba, że mało prawdopodobny.
Płatności masowe, indywidualne konta
Zadanie jest proste, wygenerować "kolizję", czyli znaleźć takie numery rachunków, które będą spełniały warunek (maskę) 12 2490 XXXX XXXX XXXX XXXX 8901. Innymi słowy trzeba dobrać takie wartości w miejsce XXXX by dla numeru rozliczeniowego 2490 i końcówki numeru rachunku 8901 liczbą kontrolną było 12. Zadanie jest wykonalne matematycznie, ale czy jest również możliwe do zrealizowania "w rzeczywistości"? Przecież to bank, nie klient nadaje numer rachunku... Po raz kolejny - błąd. W niektórych przypadkach numer rachunku nadaje jednak klient, przynajmniej częściowo. Istnieją przecież usługi płatności masowych.
W przypadku płatności masowych klient (w sensie - korporacja) otrzymuje pewną "przestrzeń" numerów rachunków, w obrębie której może generować konta "wirtualne". Taki "wirtualny" rachunek może wyglądać na przykład tak (klient kontroluje cyfry oznaczone przez X):
CC 2490 8997 49XX XXXX XXXX XXXX
Na bazie powyższego "rachunku wirtualnego" należy stworzyć kolizję, przy czym atakujący jest ograniczony do cyfr znajdujących się na pewnych pozycjach w numerze rachunku:
CC 2490 8997 49XX XXXX XXXX 8901
Szybki PoC:
Mała zagadka, na który z poniższych rachunków przelane zostaną pieniądze, jeśli rachunek docelowy jest identyfikowany przez następujące dane:
- ..8901,
- 12 ..8901
- 12 2490..8901
12 2490 8997 4900 0000 0069 8901 12 2490 8997 4900 0000 0166 8901 12 2490 8997 4900 0000 0263 8901 12 2490 8997 4900 0000 0360 8901 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 (...)
Poprawność powyższych numerów można sprawdzić na przykład za pomocą weryfikatora różnych numerów.
Pytania dodatkowe:
- ile cyfr będzie się chciało sprawdzić użytkownikowi?
- z czym użytkownik sprawdzi otrzymane w "bezpieczny sposób" dane transakcji?
Gdyby WSZYSTKIE banki w Polsce chciały zagwarantować unikalność ostatnich czterech cyfr numeru rachunku, to byłaby możliwość założenia tylko 10000 rachunków. Gdyby "globalnie unikalne" miały być cztery ostatnie cyfry i liczby kontrolne, wówczas liczba ta wzrosłaby do 1 000 000 (w rzeczywistości mniej, ale to nieistotne). Można do tego jeszcze dodać numery rozliczeniowe banków (nie wszystkie możliwe, tylko te "używane"), ale dalej liczba możliwości nie powala...
Chwila z googlem i znalazłem inne konto, które z moim kontem ma "kolizję" w przypadku XX XXXX..XXXX.
Druga informacja to taka, że jednostki zajmujące się płatnościami masowymi są zazwyczaj wydzielone i mają inną drugą połowę numeru rozliczeniowego.
Co do zagadki - to nie rozumiem pytania
A rozumiem, że pytania dodatkowe są retoryczne
Tak, jednostki zajmujące się płatnościami masowymi są wydzielone i druga część numeru rozliczeniowego (ostatnie cztery cyfry) jest inna, można to zweryfikować w wykazie dostępnym na stronie NBP.
Zagadka jest prosta - ryzyko "kolizji" maleje wraz ze wzrostem ilości cyfr z numeru rachunku, które użytkownik powinien sprawdzić. Tylko im więcej cyfr ma sprawdzić, tym przeciętny użytkownik jest mniej skłonny do współpracy (czyli - nie sprawdza). Ciekawy jestem jaka jest wartość maksymalna ilości cyfr, po której przekroczeniu ilość użytkowników rzeczywiście uważnie sprawdzających zgodność dwóch numerów zaczyna gwałtownie spadać.
Drugie pytanie to też coś, co mnie ciekawi. Z moich obserwacji wynika, że ludzie otrzymane np. SMS dane transakcji sprawdzają z numerem wyświetlonym na stronie, a nie tym numerem, który wpisywali do systemu. Zastanawiam się, czy wynika to z "próbki", na której prowadziłem obserwacje, czy rzeczywiście tak robi znacząca część (większość?) użytkowników.
Powyższe pytania są istotne, bo trzeba zwrócić uwagę, że atak przy pomocy malware zwykle jest atakiem masowym. Nie musi być idealnie dopracowany, ważne, by się opłacał, czyli by istniała wystarczająca liczba użytkowników, którzy dadzą się złapać. W tym kontekście po co kombinować z "kolizjami", jeśli np. 65% użytkowników nie sprawdza danych transakcji, lub robi to patrząc na dane wyświetlone na stronie, które są potencjalnie kontrolowane przez malware?
http://generatory.it/