[Owasp-poland] Kryteria oceny bezpieczen??stwa bankowos??ci internetowej

Tomasz Dudzisz mem at unnameden.com
Tue May 18 10:06:03 EDT 2010


(wto, maj 18, 2010 at 02:44:20 +0200) Paweł Goleń:
> wdrożone. Okaże się po prostu nieopłacalne. To takie luźne zwrócenie
> uwagi na to, że nie można ograniczać się tylko do technologii, ważny
> jest jeszcze biznes :)

Owszem, przy okazji takich wdrożeń wychodzą różne historie - np takie,
że są jeszcze w użyciu telefony bez obsługi SMS, albo, że z jednego
telefonu korzysta cała wioska... :)

> Ten argument jest chyba nieco mniej istotny w tej chwili, choć ciężko go
> wykluczyć w przyszłości. Czy ktoś słyszał o problemach klientów z
> niedochodzącymi kodami SMS? Dużo częściej można usłyszeć o problemach z
> logowaniem się do systemu. Nie mam tu jednak wystarczającej ilości

Ten argument jest bardzo często podawany przez klientów, jako jedno 
z niedogodności tej technologii, niestety.

> To już zależy od konkretnego wdrożenia (implementacji). Przykładowo
> jeśli na wejściu do urządzenia/aplikacji jest ciąg 8 znaków jako
> challenge, to jest to JEDEN "wektor". Nie trzeba go podmieniać, atak
> malware wygląda następująco:
> 
> - użytkownik podaje dane przelewu,
> - malware przechwytuje dane klienta, wysyła do serwera inne dane przelewu,
> - serwer zwraca stronę z danymi przelewu i challenge,
> - malware podmienia na wyświetlanej stronie dane przelewu na oryginalne,
> pozostawia kod challenge wygenerowany przez serwer,
> - użytkownik przepisuje challenge do aplikacji, przesyła response do
> serwera,
> 
> Zadanie jest trywialne. Użytkownik nie ma możliwości sprawdzenia, jaką
> operację rzeczywiście autoryzuje.

No właśnie ma. Te wszystkie dane powinny być zawarte w kodzie challenge 
i wyświetlone wraz z wygenerowaniem kodu response.
W tych rozwiązaniach, które ja widziałem - użytkownik wraz z kodem response
widzi dane przelewu (np pierwsze i ostatnie cyfry konta, kwota, typ 
transakcji) i ma możliwość weryfikacji. W przypadku podmiany któregokolwiek
elementu z tych danych po drodze, użytkownik powinien zauważyć różnicę 
wyświetloną w telefonie i na monitorze (no chyba, że będzie to naprawdę 
sprytna kolizja - np różnica kwoty o jedno zero przy zachowaniu tej samej 
sumy kontrolnej całości, lub 'niewidocznej' części numeru konta - taki 
fraud będzie akurat łatwy i szybki do wykrycia, gdyż transakcja odbędzie
się w obrębie jednego banku).

> Sytuacja zmienia się, jeśli użytkownik do aplikacji ma przepisać np.
> challenge, jakieś cyfry z numerów konta źródłowego/docelowego i kwotę
> przelewu. Dalej nie jest to jednak w 100% bezpieczne, bo można zrobić
> "kolizję" numeru konta (już podsyłałem linka na ten temat). To samo
> dotyczy również kodów SMS, one również nie zawierają pełnych numerów konta.

Owszem, pewne scenariusze pozornie możliwe do wykonania są też stosunkowo łatwe
do wykrycia dodatkowymi algorytmami monitorującymi - wystarczy wiedzieć 
o nich i się na to przygotować.

> Możesz rozwinąć tą myśl?

No właśnie w ten sposób jak opisałem powyżej. Bank wyświetla dane przelewu
wraz z kodem challenge, który je podpisuje. Zawiera on własną sumę
kontrolną - wraz z response mają się wyświetlić dokładnie te same dane.
Użytkownik weryfikując dane na ekranie i w telefonie ma pewność, że podpisuje
dokładnie to co chce. Bank otrzymując poprawne response ma pewność, że
użytkownik podpisał to co widział i chciał.
W przypadku SMS - nie mamy pewności czy ktoś przechwytując nasz kod SMS nie 
potwierdził operacji, z której np nagle się rozmyśliliśmy. Albo nawet ktoś za
nas generuje transakcję, przechwytuje kod SMS i potwierdza bez naszej wiedzy.
W przypadku tokenów CR atakujący musiałby mieć dostęp fizycznie do telefonu,
albo bezpośrednio, albo np kopiując środowisko z telefonu (dlatego powinno się 
aplikację chronić, np: nieweryfikowalnym PINem).


-- 
TD


More information about the Owasp-poland mailing list