Piotr Gałka <p...@C...pl> wrote on
2011-12-07_19:11
>
> Użytkownik "witrak()" <w...@h...com> napisał w wiadomości
> news:jbo65h$bue$1@srv.cyf-kr.edu.pl...
>
>>> Nie widzę nic specjalnie ryzykownego w automatycznej
>>> synchronizacji.
>
>> W granicach wąskiego przedziału (1 cykl na parę miesięcy) to
>> rzeczywiście nie. Ale wyobraź sobie trojana, który w twoim
>> komputerze opóźnia wysyłanie hasła. Przy automatycznej
>> synchronizacji po kilkunastu przelewach trojan ma już
>> zaoszczędzone całe jedno hasło, co jednak zauważyć jest dość
>> trudno. Wtedy czeka na wysokie saldo i wykonuje ten jeden przelew
>> bez możliwości zauważenia go przez użytkownika (tuż po
>> wylogowaniu).
>>
> Nie wiem, czy zegar służy tylko do logowania, czy też do haseł
> (może kiedyś sprawdzę).
> Jakby nawet też do haseł to trojan nie ma żadnego dodatkowego
> hasła (ilość jest ta sama).
> Po podaniu przez użytkownika ostatniego hasła trojan musi udać dla
> użytkownika, że operacja się udała (wykonać jej nie może, bo
> potrzebuje tego hasła dla siebie) a potem korzystając z tego hasła
> wykonać swoją operację.

Nie,nie. Przeciwnie - symulując brak opóźnienia a od strony banku
spóźnianie się zegara doprowadza do sytuacji, w której klient
wprowadza *następne* hasło, mimo, że poprzednie jest jeszcze
ważne. W pewnym momencie oczywiście musi oszukać klienta, że źle
wprowadził hasło (przy logowaniu) i o od tej chwili do wylogowania
uzytkownika ma w zapasie jedno hasło, o którem user nic nie wie.

> Ale taka możliwość nie jest skutkiem automatycznej synchronizacji.

Taka jak opisałem powyżej jak najbardziej ma. Gdyby synhronizacja
nie była automatyczna, to user musiałby rozmawiać z infolinią z
chwilą osiągnięcia przez opóźnienie pełnego cyklu.

> Jak zakładamy obecność trojana, to powyższe jest równoważne udaniu
> dla użytkownika, że się zrobiło to co chciał i wykonaniu w tym
> samym czasie swojego przelewu.

To jest jednak trudniejsze, a przede wszystkim wymaga więcej pracy
- trzeba symulować całą stronę (albo właściwie kilka) - jeśli
użytkownik nie ma być od razu zaalarmowany. W opisanym przeze mnie
schemacie można sobie wyobrazić, że trojan włącza się tylko w
strumień komunikacji opóźniając wysyłanie niektórych requestów, a
swoje działanie aktywne przeprowadza tylko, gdy ma już "hasło
zapasowe w kolejce". Oczywiście, aby to było opłacalne, cracker
musiałby zainfekować wiele kompów i po jakimś czasie zezwolić im
na wykonanie fraudu 9 po czym likwidować interes.

> W opisie digipassa było coś, że producent dostarcza jakąś
> aplikację - nie wiem, czy autoryzacje nie są w ogóle robione za
> pośrednictwem ich serwera. Kwestie obsługi zegarów byłyby wtedy
> załatwiane przez serwer producenta.

Bardzo sensowne. Dla Vasco ZTCW tak było.

witrak()