On 2019-08-20, Kris <k...@g...com> wrote:

[...]

>> Chcę zrobić przelew, w znakomitej większości korzystam ze
>> zdefiniowanych. Haker nie może wiedzieć, jakie mam przelewy zdefiniowane
>> w systemie. Jeśli zatem widzę, że lista jest pusta to czy nie jest to
>> wystarczającym sygnałem ostrzegającym dla klienta, że ze stroną coś jest
>> nie tak?
>
> Haker nie wie tez jakie masz saldo konta czy tam innych rachunków. Więc jak
wejdziesz na fałszywą stronę to chociażby po saldzie konta widzisz że coś jest nie
tak

Napisanie "proxy" które będzie pobierało dane ze strony banku
to nie jest jakaś skomplikowana rzecz. W pierwszym kroku zawsze podajesz
login i hasło, więc wyczytanie tych informacji to dość trywialna
sprawa. Kwestia tylko i wyłącznie tego jak porządnie ktoś przygotuje
się do działania pod konkretny bank.

Pozatym ostatnie wektory ataku to są ataki nie bezpośrednio
na konto, tylko bardziej udające strony do płatności online.
Tam to już w ogóle jest łatwiej, bo przecież masz tylko
dwa ekrany:

- formatka do loginu i hasła
- stronę do autoryzacji transakcji

I jedyne miejsce gdzie możesz wychwycić że coś się nie
zgadza, to komunikat autoryzacyjny w SMS lub Push,
bo na ekranie Ci się wszystko będzie zgadzać.

--
Wojciech Bańcer
w...@g...com

do góry

Użytkownik "Wojciech Bancer" napisał w wiadomości grup
dyskusyjnych:slrnqlnr31.2gb6.wojciech.bancer@pl-test
.org...
On 2019-08-20, Kris <k...@g...com> wrote:
[...]
>Pozatym ostatnie wektory ataku to są ataki nie bezpośrednio
>na konto, tylko bardziej udające strony do płatności online.
>Tam to już w ogóle jest łatwiej, bo przecież masz tylko
>dwa ekrany:
> - formatka do loginu i hasła
> - stronę do autoryzacji transakcji

>I jedyne miejsce gdzie możesz wychwycić że coś się nie
>zgadza, to komunikat autoryzacyjny w SMS lub Push,
>bo na ekranie Ci się wszystko będzie zgadzać.

A tak swoja droga - ta dyrektywa ma przeciez umozliwiac zarzadzanie
kontem przez strony innej firmy.

Jest przewidziana jakas procedura weryfikacji tych innych firm i
dostepow przez nie, czy mozna sie spodziewac calej masy falszywek ?

J.

do góry

On 2019-08-20, Wojciech Bancer <w...@g...com> wrote:
> On 2019-08-20, Kris <k...@g...com> wrote:
>
> [...]
>
>>> Chcę zrobić przelew, w znakomitej większości korzystam ze
>>> zdefiniowanych. Haker nie może wiedzieć, jakie mam przelewy zdefiniowane
>>> w systemie. Jeśli zatem widzę, że lista jest pusta to czy nie jest to
>>> wystarczającym sygnałem ostrzegającym dla klienta, że ze stroną coś jest
>>> nie tak?
>>
>> Haker nie wie tez jakie masz saldo konta czy tam innych rachunków. Więc jak
wejdziesz na fałszywą stronę to chociażby po saldzie konta widzisz że coś jest nie
tak
>
> Napisanie "proxy" które będzie pobierało dane ze strony banku

Żeby nie być gołosłownym, to takie najbardziej prymitywne
rozwiązanie to chociażby:
https://github.com/chimurai/http-proxy-middleware

---
var express = require('express');
var proxy = require('http-proxy-middleware');

var app = express();

app.use('/', proxy({ target: 'http://strona.mojego.banku', changeOrigin: true }));
app.listen(3000);
---

Czyli jakieś 6 linijek kodu i wszystko masz "przekazywane", tak że jedynie
po domenie widzisz różnicę. Bank również dostaje wszystkie właściwe dane,
nagłówki przeglądarki itp., wszystko od Ciebie.

Oczywiście banki stosują pewne zabezpieczenia, ale jak ktoś wie co robi,
to i je obejdzie. A w środku powyższego możesz dodać kod dowolnie
modyfikujący wybrane fragmenty strony, czy tego co użytkownik
przekazuje.

Dopisanie więc, że przelew który użytkownik autoryzuje
zamiast 1,00 zł, to <saldo konta>,00 zł, to dość prosta
rzecz.

--
Wojciech Bańcer
w...@g...com

do góry

W dniu 2019-08-20 o 14:46, J.F. pisze:
> Ale ja wspominam Lukasa i jego tokeny RSA bez klawiaturki, wiec bez
> zabezpieczenia.

Tam też było tak, że do wpisania trzeba było podać hasło+wskazanie tokena.

> Kolejna sprawa, ze banki jak widac chca odejsc od SMS i autoryzacja
> bedzie w aplikacji.
> I tam sie juz haslo moze pojawic.

Mam wrażenie, iż jeszcze długo będą opcje alternatywne wobec aplikacji.
>> W przypadku tokena i fałszywej strony działania hakera musiałby się
>> odbyć w tym samym czasie. Czyli logowanie, przelew.
>
> Zaden problem - raz oszukales komputer usera, to pewnie jeszcze pare
> razy oszukasz.

Czyli zakładasz, że klient będzie kilkanaście/kilkadziesiąt razy
korzystał z fałszywki, bo haker "zbiera" informację, aby mieć pełne
hasło przy maskowanym?

>> Sytuacja jednak się komplikuje przy haśle maskowanym. Szanse, iż
>> klient wstuka na fałszywce te same pola, o które poprosi hakera
>> oryginalna strona są małe.
>
> Ale haslo jest stale ? To po paru probach ustali pelne haslo.

Tak, jest stałe. Potrzeba raczej kilkudziesięciu prób. W tym czasie
fałszywka ma się zachowywać jak prawdziwa? Tzn. realizować przelewy
itd., aby klient nie zorientował się, że np. nie dochodzą i coś jest nie
tak?

>> A gdyby tak system pytał np. o 3 z 6 wskazań tokena plus 3 dowolne
>> znaki hasła? Czy taka okoliczność poprawiłaby bezpieczeństwo?
>
> IMO nie, bo przeciez moze rownolegle laczyc do do banku i wymagac
> dokladnie tego samego co bank.

Masz rację. Wymagane byłoby pewne opóźnienie, ale z punktu widzenia
klienta może być niezauważalne.

> W dodatku 3 cyfry z tokena to zaczyna byc juz niebezpiecznie malo -
> mozna probowac w ciemno, a noz sie trafi ..

To mało prawdopodobne.

do góry

Użytkownik "Szymon" napisał w wiadomości grup
dyskusyjnych:qjgrur$144g$...@g...aioe.org...
W dniu 2019-08-20 o 14:46, J.F. pisze:
>> Ale ja wspominam Lukasa i jego tokeny RSA bez klawiaturki, wiec bez
>> zabezpieczenia.

>Tam też było tak, że do wpisania trzeba było podać hasło+wskazanie
>tokena.

Ale to nie to samo co token z klawiaturka, ktorego zlodziej nie
odblokuje.

>> Kolejna sprawa, ze banki jak widac chca odejsc od SMS i autoryzacja
>> bedzie w aplikacji.
>> I tam sie juz haslo moze pojawic.

>Mam wrażenie, iż jeszcze długo będą opcje alternatywne wobec
>aplikacji.

Byc moze, ale widac, ze pomysl im sie podoba, a przeciez "kazdy ma
smartfona".

>>> W przypadku tokena i fałszywej strony działania hakera musiałby
>>> się
>>> odbyć w tym samym czasie. Czyli logowanie, przelew.
>
>> Zaden problem - raz oszukales komputer usera, to pewnie jeszcze
>> pare razy oszukasz.

>Czyli zakładasz, że klient będzie kilkanaście/kilkadziesiąt razy
>korzystał z fałszywki, bo haker "zbiera" informację, aby mieć pełne
>hasło przy maskowanym?

Tak.

>>> Sytuacja jednak się komplikuje przy haśle maskowanym. Szanse, iż
>>> klient wstuka na fałszywce te same pola, o które poprosi hakera
>>> oryginalna strona są małe.
>
>> Ale haslo jest stale ? To po paru probach ustali pelne haslo.

>Tak, jest stałe. Potrzeba raczej kilkudziesięciu prób.

IMO mniej - zakladajac ze haslo ma np 10 znakow, z ktorych naraz
podajesz 4 czy 5.

A jesli bank nie spyta o ten dziesiaty znak przez kilka logowan ... to
moze do przelewu tez wystarczy 9 znanych.

>W tym czasie fałszywka ma się zachowywać jak prawdziwa? Tzn.
>realizować przelewy itd., aby klient nie zorientował się, że np. nie
>dochodzą i coś jest nie tak?

tak, jakies proxy uwazam za sensowne ... i chyba nawet mialy miejsce w
rzeczywistosci, bo jakby omineli hasla jednorazowe z listy ?
ale nawet jesli nie - tak trudno zasugerowac, ze cos jest zle ?
wysypac przegladarke, zamknac okno, napisac "serwer przeciazony,
sprobuj za kilka minut", czy "haslo nieprawidlowe - wprowadz jeszcze
raz" - i przekierowac na oryginalna strone.

>>> A gdyby tak system pytał np. o 3 z 6 wskazań tokena plus 3 dowolne
>>> znaki hasła? Czy taka okoliczność poprawiłaby bezpieczeństwo?
>
>> IMO nie, bo przeciez moze rownolegle laczyc do do banku i wymagac
>> dokladnie tego samego co bank.

>Masz rację. Wymagane byłoby pewne opóźnienie, ale z punktu widzenia
>klienta może być niezauważalne.

Jak bedzie realizowal komputer - to niezauwazalnie male.

>> W dodatku 3 cyfry z tokena to zaczyna byc juz niebezpiecznie malo -
>> mozna probowac w ciemno, a noz sie trafi ..
>To mało prawdopodobne.

1:1000. Tysiac prob i trafiles. Robiac dwie dziennie - efekt w ciagu
niecalych dwoch lat.
Ale majac namierzonych 10 frajerow - juz co dwa miesiace.

Pytanie tylko czy bank wczesniej nie zareaguje, bo zlicza te nieudane
proby ... albo podejrzany mu sie wyda adres IP ktory tak czesto sie
myli ..

J.

do góry

On 2019-08-20, J.F. <j...@p...onet.pl> wrote:

[...]

>> I jedyne miejsce gdzie możesz wychwycić że coś się nie
>> zgadza, to komunikat autoryzacyjny w SMS lub Push,
>> bo na ekranie Ci się wszystko będzie zgadzać.
>
> A tak swoja droga - ta dyrektywa ma przeciez umozliwiac zarzadzanie
> kontem przez strony innej firmy.
>
> Jest przewidziana jakas procedura weryfikacji tych innych firm i
> dostepow przez nie, czy mozna sie spodziewac calej masy falszywek ?

Pewnie to trochę będzie tak jak z terminalami.
By móc się podpiąć do systemu, musisz być wiarygodny, tzn. przejść
weryfikację (w przypadku kart masz PCI DSS). Serwisy online które
zapisują dane kart również muszą być zweryfikowane pod tym kątem.

--
Wojciech Bańcer
w...@g...com

do góry

W dniu 2019-08-20 o 15:40, J.F. pisze:
>> Mam wrażenie, iż jeszcze długo będą opcje alternatywne wobec aplikacji.
>
> Byc moze, ale widac, ze pomysl im sie podoba, a przeciez "kazdy ma
> smartfona".

Tak, masz rację. Jednocześnie Alior na swoich stronach podaje:
"Urządzenie z którego korzystasz do obsługi aplikacji Google Pay
(wczesniej Android Pay) musi być skutecznie zabezpieczone przed
zagrożeniami poprzez zainstalowanie aktualnego oprogramowania
antywirusowego renomowanego producenta."

Ciekawe czy ten wymóg może potem skutkować jakimiś problemami dla
klienta (np. z odrzuceniem reklamacji).
I dalej:

"Pamiętaj, że Twoje urządzenie mobilne to klucz do Twoich finansów! Jego
utrata lub przejęcie przez przestępców może skutkować przejęciem konta
bankowego, a w rezultacie utratą środków pieniężnych."

Myślę, że część klientów woli mieć do dyspozycji klawiaturę obsługując
system transakcyjny. Jeszcze innych przekona większy ekran monitora.
Stąd smartfonowe aplikacje będą mieć raczej ograniczony zasięg. No -
może do autoryzacji (wzorem tokenuGSM w EB).

Swoją drogą do obsługi foreksu często są dostępne aplikacje mobilne i na
komputery. Banki rozwijają te pierwsze, ale niekoniecznie drugie. Pewnie
mają swoje powody, ale być może aplikacja komputerowa dałaby większy
poziom bezpieczeństwa niż przez przeglądarkę.

do góry

"Dbaj o bezpieczeństwo Twojego telefonu komórkowego - nie pozostawiaj go
w miejscach, w których narażony może być na kradzież lub dostęp osób
niepowołanych. "

Zdaje się, że Alior ma świadomość, iż największym niebezpieczeństwem w
przypadku urządzenia mobilnego jest jego mobilność. ;-) Tylko jak tu
spełnić ten warunek? I czy nie będzie on potem wykorzystany przeciwko
klientowi (mimo ostrzeżeń banku zostawił telefon gdzieś tam i nie
dochował należytej staranności)...

do góry

Użytkownik "Szymon" napisał w wiadomości grup
dyskusyjnych:qjgv5d$1ig0$...@g...aioe.org...
W dniu 2019-08-20 o 15:40, J.F. pisze:
>>> Mam wrażenie, iż jeszcze długo będą opcje alternatywne wobec
>>> aplikacji.
>
>> Byc moze, ale widac, ze pomysl im sie podoba, a przeciez "kazdy ma
>> smartfona".

>Tak, masz rację. Jednocześnie Alior na swoich stronach podaje:
>"Urządzenie z którego korzystasz do obsługi aplikacji Google Pay
>(wczesniej Android Pay) musi być skutecznie zabezpieczone przed
>zagrożeniami poprzez zainstalowanie aktualnego oprogramowania
>antywirusowego renomowanego producenta."

>Ciekawe czy ten wymóg może potem skutkować jakimiś problemami dla
>klienta (np. z odrzuceniem reklamacji).

Nieznane sa wyroki sadow rejonowych :-)
Z jednej strony - oczywiscie moze, z drugiej ... a gdzie lista
renomowanych (dla banku) producentow ?

>I dalej:
>"Pamiętaj, że Twoje urządzenie mobilne to klucz do Twoich finansów!
>Jego utrata lub przejęcie przez przestępców może skutkować przejęciem
>konta bankowego, a w rezultacie utratą środków pieniężnych."

Ale to samo mialbys z tokenem.

>Myślę, że część klientów woli mieć do dyspozycji klawiaturę
>obsługując system transakcyjny. Jeszcze innych przekona większy ekran
>monitora. Stąd smartfonowe aplikacje będą mieć raczej ograniczony
>zasięg. No - może do autoryzacji (wzorem tokenuGSM w EB).

Dokladnie o autoryzacji pisalem ... ale mysle, ze sporo klientow
bedzie wolalo obslugiwac konto z telefonu.
Ewentualnie - odbiorce sobie zdefiniuja na komputerze, przelewac potem
beda z telefonu.

No i zobacz kolejne pomysly rozwojowe - np platnosci przez QR-kod.
A komputera nie odczytasz.

Co prawda ... fajnie sie to skanuje z papieru, ale papier jest drogi.
mozna zeskanowac e-maila z ekranu komputera ... ale jak ktos woli
e-maile czytac na telefonie ? :-)

>Swoją drogą do obsługi foreksu często są dostępne aplikacje mobilne i
>na komputery. Banki rozwijają te pierwsze, ale niekoniecznie drugie.

Ale tu inna sprawa - tu trzeba byc czujnym. I miec aplikacje zawsze
pod reka ... czyli w telefonie.

> Pewnie mają swoje powody, ale być może aplikacja komputerowa dałaby
> większy poziom bezpieczeństwa niż przez przeglądarkę.

A to swoja droga - czemu na telefonie dedykowany program, a na
komputerze przegladarka.
Przegladarka kompa wystarcza, a przegladarka z telefonu nie wyrabia ?
Nie akceptuje ActiveX ? ... od tego sie chyba odchodzi, javascript
potrafi duzo.
Strona duzo danych transmituje ?

Czy jednak bezpieczenstwo dedykowanej aplikacji ... czy po prostu chca
przy okazji wiecej danych zgromadzic - liste kontaktow np :-)

J.

do góry

W dniu 2019-08-20 o 14:46, J.F. pisze:
> W dodatku 3 cyfry z tokena to zaczyna byc juz niebezpiecznie malo -
> mozna probowac w ciemno, a noz sie trafi ..

Po trzech nieudanych razach konto jest już zablokowane.



--
animka

do góry