kx wrote:
Tak samo bank myśli, że 'rozmawia' bezpośrednio z twoją
> przeglądarka, a w rzeczywistości rozmawia z aplikacją oszusta. No i cały
> opisany scenariusz działa.
>
z jednym wyjątkiem, oszust nie ma certyfikatu banku i moja przeglądarka
zaczyna wrzeszczeć, że ktoś tu sobie ze mną leci w kulki.

do góry

Użytkownik <r...@a...net.pl> wrote:
> No, ale na to fachowcy z tego banku muszą najpierw wpaść.

Latwo ci oceniac ;)
Wpadli daaawno temu, tylko cholera wie, czemu jeszcze nie wprowadzili tego.

--
Michał 'Amra' Macierzyński || http://PRnews.pl
Banki, karty, konta oraz public relations.
Zadbaj o swoje pieniądze!

do góry

kx napisał(a):
>>W tych bankach internetowych, w których mam/miałem konta (Inteligo,
>>mBank, e-Integrum BGŻ) zaraz po wejściu pierwsze co widzę to stan mojego
>
> po wejściu tzn. po zalogowaniu ? bo jeżeli tak, to aplikacja oszusta
> zaloguje się na strone banku - uda ciebie używając własnie otrzymane od
> ciebie dane (login i haslo), odbierze dane, które wyskoczą po zalogowaniu i
> prześle ci na przeglądarke - nic nie zauważysz (może jedynie to, że strona
> załaduje się troche wolniej).
>
>
>>[ciah...]
>
> Możesz jaśniej ? Albo ja ciebie nie rozumiem, albo ty mnie.
>
> A wyobraź sobie kolejną sytuacje:
> Załóżmy, że ty masz bezpieczny komputer (oprogramowanie antywirusowe oraz
> system regularnie updatowany, nie ściągasz żadnych śmieci z netu, itd...).
> Co więcej, jesteś rozsądnym użytkownikiem - nie dasz się złapać na phishing.
> Bank również jest całkowicie bezpieczny - ma dobrych adminów. Ale twój
> provider wałki wali, albo oszut wpierniczył mu sie na serwer i on tym nie
> wie. Zamiast routować pakiety z twojej przeglądarki do serwera banku cała
> transmisja jest odbierana przez oszusta, który napisał aplikacje udającą
> stronę banku. Tak samo bank myśli, że 'rozmawia' bezpośrednio z twoją
> przeglądarka, a w rzeczywistości rozmawia z aplikacją oszusta. No i cały
> opisany scenariusz działa.
>
> kx

OK, ale to już nie byłby phishing, tylko raczej konieczny byłby atak na
serwer DNS, o którym wiadomo, że jest bardziej niebezpieczny od
phishingu. Opisana przez Ciebie sytuacja nie wystąpi jeżeli sam
wchodzisz na stronę, której adres wpisujesz ręcznie, albo nawet
wybierasz z zakładek, a nie korzystasz z podrzuconego w mailu linku, a
serwer DNS mojego providera działa prawidłowo. Piszesz o sytuacji, w
której mój ISP leci w kulki, albo ma zhakowane serwery. W tej sytuacji
mój dalszy wywód nie miałby sensu, gdyby nie fakt, że w temacie postu
jest mowa o phishingu i w związku z tym powinniśmy odrzucić taką
możliwość. Jednakże w takiej sytuacji pozostaje to, o czym ktoś już tu
pisał, czyli certyfikat strony. W razie podejrzeń możesz go zweryfikować.

--
"- Why do they call him a bullet dodger?
- Because he dodges bullets, Avi." (Snatch)

do góry

> OK, ale to już nie byłby phishing, tylko raczej konieczny byłby atak na
> serwer DNS, o którym wiadomo, że jest bardziej niebezpieczny od
Niekoniecznie DNS. Router, przez który przechodzą pakiety może zrobić
z nimi co zechce - mam na myśli, że może sam konstruwać z nich sesje tcp
i odpowiadać na zapytania przeglądarki.

> phishingu. Opisana przez Ciebie sytuacja nie wystąpi jeżeli sam
> wchodzisz na stronę, której adres wpisujesz ręcznie, albo nawet
> wybierasz z zakładek, a nie korzystasz z podrzuconego w mailu linku, a
> serwer DNS mojego providera działa prawidłowo. Piszesz o sytuacji, w
O ile nieprawidłowo działający serwer DNS jest łatwo wykryć, no bo po
włamaniu o zapytanie domeny nagle zaczął podawać inny IP, o tyle w/w
metodę już jest trudniej wyłapać. Wierzysz swojemu providerowi, który
dołożył wszelkich starań, żeby dobrze zabezpieczyć serwer, ale po drodze
jest jeszcze kilkanaście (lub więcej) routerów.

> której mój ISP leci w kulki, albo ma zhakowane serwery. W tej sytuacji
> mój dalszy wywód nie miałby sensu, gdyby nie fakt, że w temacie postu
> jest mowa o phishingu i w związku z tym powinniśmy odrzucić taką
> możliwość. Jednakże w takiej sytuacji pozostaje to, o czym ktoś już tu
czyli zagrożenia nie ma? ciekawa logika :)

> pisał, czyli certyfikat strony. W razie podejrzeń możesz go zweryfikować.
To fakt, certyfikat jest nie do podrobienia.


kx
>
> --
> "- Why do they call him a bullet dodger?
> - Because he dodges bullets, Avi." (Snatch)

do góry

kx napisał(a):
> czyli zagrożenia nie ma? ciekawa logika :)

Nie to napisałem, tylko metody ataku opisane przez Ciebie nie są już
phishingiem, a tego dotyczy topic.

>
>>pisał, czyli certyfikat strony. W razie podejrzeń możesz go zweryfikować.
>
> To fakt, certyfikat jest nie do podrobienia.
>
>
> kx

To potwierdza, że phishing jest niebezpieczny przede wszystkim dla
nieostrożnych.


--
"- Why do they call him a bullet dodger?
- Because he dodges bullets, Avi." (Snatch)

do góry

kx wrote:
>
> Niekoniecznie DNS. Router, przez który przechodzą pakiety może zrobić
> z nimi co zechce - mam na myśli, że może sam konstruwać z nich sesje tcp
> i odpowiadać na zapytania przeglądarki.

>
> O ile nieprawidłowo działający serwer DNS jest łatwo wykryć, no bo po
> włamaniu o zapytanie domeny nagle zaczął podawać inny IP, o tyle w/w
> metodę już jest trudniej wyłapać. Wierzysz swojemu providerowi, który
> dołożył wszelkich starań, żeby dobrze zabezpieczyć serwer, ale po drodze
> jest jeszcze kilkanaście (lub więcej) routerów.

tak, ale routery nie są zarządzane przez osoby z budki z piwem.
Nie wiem, który administrator routera by się na to odważył. Dobrze wie
co mu grozi.
Najbardziej bałbym się właśnie routera tego najbliższego, własnego
providera, który zwykle należy do małej sieci osiedlowej i tam naprawdę
nie wiadomo co się na nim dzieje.

z tym, że właśnie po to wymyslili certyfikaty, aby takie sytuacje wyłapywać.

do góry

W artykule <d67uet$8bo$1@nemesis.news.tpi.pl> kx napisal(a):

>> pisał, czyli certyfikat strony. W razie podejrzeń możesz go zweryfikować.
> To fakt, certyfikat jest nie do podrobienia.

Wyjątek stanowią dziurawe przeglądarki które można oszukać - jak
osławiona dziura w IE (chyba załatana), gdzie można było podstawić oszukany
certyfiakt.

do góry

kx wrote:
> Odnosze wrażenie, że hasła jednorazowe i tokeny ni jak się mają do
> bezpieczństwa...
>
> Prosty scenariusz:
> Pewien klient daje się złapać na phishingu - wchodzi na jakąś podejrzaną
> strone myśląc, że to strona jego banku, ale nieświadom niebezpieczeństwa
> loguje się i dokonuje pewnej tranzakcji. Podejrzana strona, to nie jakiś
> prosty formularz do wyciągania haseł, ale bardziej wyrafinowany system
> oszusta. Otoż, ten system równocześnie symuluje działanie klienta na
> prawdziwej stronie banku:
> 1) klient loguje sie na stronie oszusta
> 2) system oszusta, przy użyciu właśnie uzyskanych danych loguje się na
> prawdziwą strone banku
> (system oszusta może nawet pokazać błąd w przypadku błędnego logowania)
> 3) klient chce dokonać tranzakcji - wypełnia stosowny formularz i przesyła
> go do strony oszusta
> 4) system oszusta przekazuje te dane na prawdziwą stronę banku zmieniając
> jedynie numer konta oraz kwote przelewu
> 5) system bankowy odpowiada prośbą o podanie hasła jednorazowego, bądź
> (kiedy używamy tokena) generuje liczbę, która trzeba wpisać w token. System
> bankowy w tym momencie prawdopodobnie bedzie przesyłał również szczegóły
> przelewu (tak żeby klient sobie zobaczył, czy sie nie pomylił, no i w
> efekcie potwierdził tranzakcje)
> 6) system oszusta, przekazuje prośbe do przeglądarki klienta (jeśli
> potrzebne zmienia informacje o numerze konta i kwocie na prawidłowe)
> 7) klient wpisuje hasło jednorazowe / liczbę otrzymaną z tokena i wysyła
> 8) system oszysta przekazuje to dalej - do banku i przelew został
> potwierdzony.
>
> O ile hasła jednorazowe nie wymagają tworzenia systemu, który działa "w
> locie", to tokeny już tak, bo liczby przez nie generowane mają swój limit
> ważności czasowej.
>
> pozdr.
> kx
>
>
Kilka uwag:
Teoretycznie wszystko można zlamać, lecz nie wszystko jest łatwe.
1. Komunikacja idzie bezpiecznym kanałem - we wszystkich bankach;
2. Stosowanie podpisu - token, hasła jednorazowe.
Tu można łatwiej lub gorzej zabezpieczyć - jeśli podpis idzie pod
transakcją, to łatwiej podmienić jest samą treść transakcji a dopisać
tylko podpis klienta.
Lepsze rozwiązanie polega na przesłaniu treści transakcji do banku (wraz
z adresem IP naszej maszyny), który generuje dla niej sumę kontrolną,
którą następnie wpisuje się do tokena i tym podpisuje transakcję która
ponownie jest przesłana do banku.
Wtedy włamywacz musi: a. przechwycić samą transakcję i adres IP;
b.wysłać własną do banku z własnym adresem; c. pobrać cyfry z banku;
odesłać stronę do klienta z treścią jego transakcji; d. jeszcze raz
przechwycić transakcję klienta z podpisem;
e. po podmianie treści odesłać do banku podmienioną transakcję z dobrym
podpisem; f. odesłać potwierdzenie do klienta;

Tomek

do góry

> Użytkownik <r...@a...net.pl> wrote:
> > No, ale na to fachowcy z tego banku muszą najpierw wpaść.
>
> Latwo ci oceniac ;)
> Wpadli daaawno temu, tylko cholera wie, czemu jeszcze nie wprowadzili tego.

Bo na atak typu man in the middle
to i tak nie pomoże.

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Tue, 17 May 2005 14:33:02 +0200, w <d6cnrs$qqr$1@news.onet.pl>, "SDD"
<s...@t...wszechwiedza.pl> napisał(-a):

> Ewentualnie rozpowszechnic zawczasu jakis miniwirusik, edytujacy plik HOSTS
> (w Windowsie).

Podobno od któregoś service-packu plik hosts jest ignorowany.

do góry