Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy
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.
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?
Oryginał tego wpisu dostępny jest pod adresem Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy
Autor: Paweł Goleń