Kan internetbankieren veilig zijn?

[Verwijderd]

Hoi,

Ik heb dit topic ook al eens op een ander forum gestart, maar daar kreeg ik niet echt een bevredigend responce.
Natuurlijk zijn er al veel topics als deze, maar na het gebruiken van de search kwam ik niet één topic tegen waar de situatie op deze manier word beschreven, vandaar dat ik dit topic graag een kans gun op GOT:

Hmmm,ik heb sinds kort zo'n edentifier van de abn-amro en ben dusz een beetje aan het bankieren daarmee....maar toen ik eens ging nadenken kwam ik tot de volgende conclusie:

het systeem van de edentifier werkt zo:

je steekt je kaart erin, toetst je pincode in...je meld je aan op de site van abn, daar kun je met rekeningnummer en pasnummer inloggen, en dan zie je een code,nadat je die intypt in je edentifier krijg je een andere code als responce, en met die code kun je daadwerkelijk inloggen en doen wat je wilt,even op een rijtje,je hebt om te kunnen inloggen dus nodig:

*bankrekeningnummer
*pasje
*pincode
*edentifier

dan denk je dat het dus vrij veilig is...maar wij weten hoe het internet werkt; al die gegevens om in te loggen (nummers en code's) maar ook bv. de opdrachten tot transacties na het succesvol inloggen worden gewoon
zogenaamd-encrypted over een standaard beveiligd SSL-verbindinkje verstuurd ,wat dus betekend dat je met de meest simpele vorm van hacken al iemand zijn bankrekening kan plunderen.
Hoeveel hackers of zelfs gewoon computerfreaks weten niet hoe je een packetstream omleid en onderschept? wie van ons weet niet hoe simpel het is met een sniffertje de paketjes te bekijken en hoe simpel je ze kan aanpassen en weer door kunt sturen naar plaats van bestemming? Hoe simpel is het om dit te automatiseren, een worm te schrijven die bij iedere transactie van een bedrijf een eurocent extra overboekt naar een andere rekening?
Ik ben benieuwd wat jullie hiervan denken en of één van jullie mij het tegendeel kan vertellen en me gerust kan stellen, want mijn beperkte kennis van computers en het internet kan ook betekenen dat ik iets mis of verkeerd interpreteer natuurlijk...

[Arnout]

SSL is niet zo onveilig. Vooral als je het in combinatie met andere methoden/technieken gebruikt kan best veilig zijn.

Daarnaast: alles is te kraken, alleen kost het soms meer en soms weinig moeite.

[BtM909]

Verwijderd schreef op 10 november 2003 @ 12:04:
zogenaamd-encrypted over een standaard beveiligd SSL-verbindinkje verstuurd ,wat dus betekend dat je met de meest simpele vorm van hacken al iemand zijn bankrekening kan plunderen.

Hoe wil je dit doen dan ?

_{Je doet in ieder geval wel je nickname eer aan}

[under-world]

Je zal dan wel eerst de sleutel die in de E-dentifier zit moeten hebben want anders heb je aan die data heel weinig....

[Spivvi]

En ook al gaat het mis de bank is toch ten alle tijde verandwoordelijk voor de eventuele schade die jouw wordt aangericht zonder dat je er iets aan kan doen.

Dus het lijkt me meer een probleem voor de bank dan voor de clienten.

[guanpedro]

Stel, op een of andere gekke manier onderscheppen zij jouw gegevens wanneer je inlogt.

Daar hebben ze niets aan omdat ze voor een transactie opnieuw aan de slag moeten met de e-dentifier. Daar moet dus weer een challenge en response voor komen en die hebben ze niet; Einde verhaal, ze kunnen alleen maar in je rekeningen kijken.

[OllieMongollie]

Verwijderd schreef op 10 november 2003 @ 12:04:
Ik ben benieuwd wat jullie hiervan denken en of één van jullie mij het tegendeel kan vertellen en me gerust kan stellen, want mijn beperkte kennis van computers en het internet kan ook betekenen dat ik iets mis of verkeerd interpreteer natuurlijk...

Als je nou jouw beperkte kennis van computers, internet en security een beetje opvijzeld door het een en ander te lezen, kan je je vragen bijna allemaal zelf beantwoorden

Of ben je gewoon lekker aan 't trollen??

[Janoz]

internet bankieren werkt met een chalenge response systeem dat oa gebaseerd is op hardware die niet toegankelijk is voor hackers (je edentefier).

Met het sniffen of introduceren van een worm oid alleen is het niet mogenlijk om een extra cent over te maken. Je zou een proxy kunnen maken die de pagina's herschrijft, maar dit is door de bank heel makkelijk te omzeilen door de structuur van de pagina zo af en toe te wijzigen.

Zolang je je pincode, edentifier en bankpas niet allemaal afgeeft kun je er van uit gaan dat het net safe is en dat 9is al safer dan gewoon pinnen aangezien je dan alleen de pincode en pas nodig hebt.

Verder is SSL een heel stuk veiliger dan jij doet vermoeden.

[Verwijderd]

En daar komt nog bij dat ze bij de bank ook niet helemaal gek zijn. En trouwens zo aantrekkelijk is zoiets niet voor een hacker meer kans op om gepakt te worden omdat bij iedere cent die naar zijn bank gaat hij vast wel een keer ondekt word. En banken werken zeer nauwkeurig die zien het gelijk als er steeds ook al is het maar een cent weg is. Denk maar aan een accoutant die iets nakijkt.

[littledreamer]

Verwijderd schreef op 10 november 2003 @ 12:20:
En daar komt nog bij dat ze bij de bank ook niet helemaal gek zijn. En trouwens zo aantrekkelijk is zoiets niet voor een hacker meer kans op om gepakt te worden omdat bij iedere cent die naar zijn bank gaat hij vast wel een keer ondekt word. En banken werken zeer nauwkeurig die zien het gelijk als er steeds ook al is het maar een cent weg is. Denk maar aan een accoutant die iets nakijkt.

Inderdaad, banken zijn echt niet achtelijk. En trouwens, alles wat door mensen is gemaakt kan volgens mij in 99,99% zoniet 100% van de gevallen ook weer door mensen worden gekraakt, stuk gemaakt, omgeleid en weet ik het allemaal niet meer.

[Guardian Angel]

Is gewoon veilig. Transactiecodes wijn alleen aan mij bekend (Postbank) en je mag 3 x een foute code hebben 6 cijfers voor de opdracht wordt afgewezen. Daarnaast kan je pas betaen als je 3 code intoetst maar die kunnen wel achterhaald worden. Echter denk ik dat ze dat eerder bij Roel Pieper of de Fam. Brennikmeijer zouden doen dan bij mij.

[Juup]

Nou, het kan wel hoor bv zo: recept:
1. Klant is dom genoeg om niet te zien dat hij op http:// adres zit te werken ipv https.
2. Infecteer klant met virus worm dingetje zodat als zijn browser naar https://bank.nl wil dat hij dan eigenlijk http://hacker.nl bezoekt.
3. Proxy op hacker.nl alle gegevens met challenge en response om in te loggen.
4. Laat alles normaal verlopen, door de proxy en schrijf ook nog even 5 euro over naar de hacker rekening.

[guanpedro]

Juup schreef op 10 november 2003 @ 12:26:
4. Laat alles normaal verlopen, door de proxy en schrijf ook nog even 5 euro over naar de hacker rekening.

Hoewil je die extra transactie ertussen krijgen maar zorgen dat de klant het niet ziet?

En vervolgens klopt het saldo niet meer, krijgt de klant argwaan, kijkt op zijn papieren rekeningsafschriften, ziet € 5 naar onbekende, belt bank en binnen no time heb je de hacker.....

Prima idee!

[ Voor 26% gewijzigd door guanpedro op 10-11-2003 12:33 ]

[Juup]

guanpedro schreef op 10 november 2003 @ 12:30:
[...]


Hoewil je die extra transactie ertussen krijgen maar zorgen dat de klant het niet ziet?

De klant is niet ingelogd op bank.nl, daar is de proxy op ingelogd.

[under-world]

De transactie vindt niet plaats, maar de hacker geeft indruk dat de transactie is afgerond. Ik denk echter niet dat dit werkt omdat de code die je van ABN krijgt aan bijvoorbeeld tijd of exacte inhoud is gelinkt, waardoor je de via een keylogger verkregen info van een transactie, nooit voor een andere transactie kan gebruiken....

edit:
Of dit waar is weet ik niet,

[ Voor 10% gewijzigd door under-world op 10-11-2003 12:35 ]

[guanpedro]

Juup schreef op 10 november 2003 @ 12:32:
[...]


De klant is niet ingelogd op bank.nl, daar is de proxy op ingelogd.

Kan niet, de challenge-response is transactie gebonden en kan dus niet gesimuleerd worden. Oftewel je zou het tussen de actuele transactie moeten proppen en zorgen dat de klant het niet merkt.

[Juup]

under-world schreef op 10 november 2003 @ 12:33:
De transactie vindt niet plaats, maar de hacker geeft indruk dat de transactie is afgerond. Ik denk echter niet dat dit werkt omdat de code die je van ABN krijgt aan bijvoorbeeld tijd is gelinkt, waardoor je de via een keylogger verkregen info van een transactie, nooit voor een andere transactie kan gebruiken....

Jawel. Het is hetzelfde als een gewone proxy die jouw ISP ook heeft.
Alle gegevens die de bank vraagt en geeft, die vraag en geef jij aan de klant.
En ook real time, dus niet wachten. Zodra de klant zijn code opgeeft logt de hacker in op de bank.

[ Voor 10% gewijzigd door Juup op 10-11-2003 12:37 ]

[Juup]

guanpedro schreef op 10 november 2003 @ 12:35:
[...]


Kan niet, de challenge-response is transactie gebonden en kan dus niet gesimuleerd worden. Oftewel je zou het tussen de actuele transactie moeten proppen en zorgen dat de klant het niet merkt.

DE PROXY LOGT IN OP DE BANK, de klant niet. Denk eerst even na voor je iets zegt aub

[guanpedro]

Juup schreef op 10 november 2003 @ 12:35:
[...]

Jawel. Het is hetzelfde als een gewone proxy die jouw ISP ook heeft.
Alle gegevens die de bank vraagt en geeft, die vraag en geef jij aan de klant.
En ook real time, dus niet wachten. Zodra de klant zijn code opgeeft logt de hacker in op de bank.

Ken jij het systeem dan wel? Inloggen en overboeken zijn aparte transacties. En de codes die hierbij gegenereerd worden zijn afhankelijk van de transactie. Dus de code die de klant via de proxy krijgt kan jij niet nog een keer gebruiken voor een andere transactie.

[Juup]

guanpedro schreef op 10 november 2003 @ 12:39:

Ken jij het systeem dan wel? Inloggen en overboeken zijn aparte transacties. En de codes die hierbij gegenereerd worden zijn afhankelijk van de transactie. Dus de code die de klant via de proxy krijgt kan jij niet nog een keer gebruiken voor een andere transactie.

Zodra de bank iets van de hacker wil weten vraagt de hacker het real time aan de klant. Het maakt niet uit WAT de bank wil weten, de klant geeft anwoord.

[under-world]

Toch heeft Jaap hier wel een punt omdat in zijn voorbeeld de klant helemaal 0,0 interactie heeft met de site van de bank en alleen met de proxy, TOT het moment van de 2e code... Maw, als de hacker dan tussendoor iets wijzigd in de overboeking werkt deze methode dan nog wel ?

Stel een klant maakt bijvoorbeeld een overboeking aan na inloggen met een code. Hij wil deze nu gaan versturen. Bank checkt inhoud en maakt op basis van bedrag/afzender een 2e code (bevestiginscode) die dus bijvoorbeeld gelinkt is aan de inhoud van de overboeking of de exacte tijd van 1e inloggen. Hacker wijzigt inhoud overboeking of logt reeel later in en komt dus niet door de 2e controle heen.

edit:
Toch kan ik me een nieuwsbericht herinneren van iemand die het kon en met een soortgeliijke manier die Jaap beschrijft. Hoe exact werd in dat artikel van een jaar of 2 geleden niet uitgelegd

[ Voor 34% gewijzigd door under-world op 10-11-2003 12:48 ]

[guanpedro]

Ik kan me dit voorstellen:

Klant gaat naar proxy en voert gegevens in.
Proxy verstuurt gegevens naar bank en krijgt challenge
Proxy verstuurt challenge naar klant
klant verstuurt response naar proxy
proxy verstuurt response naar bank en logt in.

En dan? hoe zorg je dat jij een transactie kan doen? daar heb jij ook weer een challenge-response voor nodig maar die kan je niet naar de klant sturen want daar heeft hij nooit om gevraagd.

[Verwijderd]

Je blijft altijd nog op je afschriften de overboekingen zien dus zo maar on opgemerkt iets van iemand z'n rekening afboeken......lijkt me wel erg lastig hoor.

[Freee!!]

under-world schreef op 10 november 2003 @ 12:44:
Toch heeft Jaap hier wel een punt omdat in zijn voorbeeld de klant helemaal 0,0 interactie heeft met de site van de bank en alleen met de proxy, TOT het moment van de 2e code... Maw, als de hacker dan tussendoor iets wijzigd in de overboeking werkt deze methode dan nog wel ?

Stel een klant maakt bijvoorbeeld een overboeking aan na inloggen met een code. Hij wil deze nu gaan versturen. Bank checkt inhoud en maakt op basis van bedrag/afzender een 2e code (bevestiginscode) die dus bijvoorbeeld gelinkt is aan de inhoud van de overboeking of de exacte tijd van 1e inloggen. Hacker wijzigt inhoud overboeking of logt reeel later in en komt dus niet door de 2e controle heen.

Elke hacker (en iedereen die hier post) die hier even over nadenkt kan hierop het antwoord verzinnen: Die extra betaling wordt op de proxy van de hacker toegevoegd aan het bericht dat de klant via de proxy van de hacker verstuurd naar de bank. De bank bepaald op basis hiervan een code, stuurt die (via de proxy van de hacker) naar de klant en de klant geeft gewoon de code terug die hij uit zijn e-dentifier krijgt. De hacker hoeft al niks meer te doen dan doorgeven.

guanpedro schreef op 10 november 2003 @ 12:44:
Ik kan me dit voorstellen:

Klant gaat naar proxy en voert gegevens in.
Proxy verstuurt gegevens naar bank en krijgt challenge
Proxy verstuurt challenge naar klant
klant verstuurt response naar proxy
proxy verstuurt response naar bank en logt in.

En dan? hoe zorg je dat jij een transactie kan doen? daar heb jij ook weer een challenge-response voor nodig maar die kan je niet naar de klant sturen want daar heeft hij nooit om gevraagd.

Je wacht gewoon tot de klant een transactie initieert, die onderschep je en daar voeg je je eigen transactie aan toe of je wijzigt die transactie zoals je zelf wilt.

[ Voor 23% gewijzigd door Freee!! op 10-11-2003 12:50 . Reden: Extra quote + reply ]

[guanpedro]

Een pinpas jatten of creditcard nummer is veel interessanter aangezien je daar vrijwel anoniem mee kan betalen. Dat is veel handiger dan moelijk moeten doen om een systeem te hacken en vervolgs over te boeken naar een rekeningnummer waarvan ze gemakkelijk de houder kunnen achterhalen.

[Exterazzo]

Het systeem van Jaap, zou in theorie moeten werken, maar welke hacker is nou zo achterlijk om een worm te schrijven en die te verspreiden zodat iedereen via die proxy surft. Dat is natuurlijk binnen no-time bekend en zal het rekening nummer waar het 'extra' geld wordt overgemaakt, en dus zal hij het er niet af kunnen halen.

edit:
spuitelf

[ Voor 7% gewijzigd door Exterazzo op 10-11-2003 12:51 ]

[OllieMongollie]

under-world schreef op 10 november 2003 @ 12:44:
Toch heeft Jaap hier wel een punt omdat in zijn voorbeeld de klant helemaal 0,0 interactie heeft met de site van de bank en alleen met de proxy, TOT het moment van de 2e code... Maw, als de hacker dan tussendoor iets wijzigd in de overboeking werkt deze methode dan nog wel ?[/edit]

Nee, geen punt. De challenge die jij krijgt, is afhankelijk van je trasanctie. Andere transactie, andere challenge. Het aanpassen van de transactie zou dus niet werken aangezien de challenge dan anders wordt.

Met andere woorden. Niet druk maken. Gewoon lekker doorgaan met telebankieren. En anders ga je toch lekker naar de bank om je zaakjes over te boeken

[Juup]

Mr. Liu schreef op 10 november 2003 @ 12:48:
Elke hacker (en iedereen die hier post) die hier even over nadenkt kan hierop het antwoord verzinnen: Die extra betaling wordt op de proxy van de hacker toegevoegd aan het bericht dat de klant via de proxy van de hacker verstuurd naar de bank. De bank bepaald op basis hiervan een code, stuurt die (via de proxy van de hacker) naar de klant en de klant geeft gewoon de code terug die hij uit zijn e-dentifier krijgt. De hacker hoeft al niks meer te doen dan doorgeven.

Ahhh eindelijk iemand die het begrijpt ;-)

[under-world]

Ik snap het nu ook helemaal, maar probeerde het eerst effe te doorgronden omdat ik niet zo in de materie zit...

[Juup]

Exterazzo schreef op 10 november 2003 @ 12:51:
Het systeem van Jaap, zou in theorie moeten werken, maar welke hacker is nou zo achterlijk om een worm te schrijven en die te verspreiden zodat iedereen via die proxy surft. Dat is natuurlijk binnen no-time bekend en zal het rekening nummer waar het 'extra' geld wordt overgemaakt, en dus zal hij het er niet af kunnen halen.

edit:
spuitelf

1. Wie heeft gezegd dat 'iedereen' die worm/virus moet krijgen?
2. Als je 24 uur de tijd hebt kun je het geld meerdere malen overboeken tussen rekeningen in wazige landen. Het is dan erg moeilijk te achterhalen.

[Juup]

OllieMongollie schreef op 10 november 2003 @ 12:51:
Nee, geen punt. De challenge die jij krijgt, is afhankelijk van je trasanctie. Andere transactie, andere challenge. Het aanpassen van de transactie zou dus niet werken aangezien de challenge dan anders wordt.

De hacker geeft een extra opdracht op aan de bank
de bank vraagt de hacker om een challenge
de hacker vraagt de klant die challenge
de klant geeft de response aan de hacker
de hacker geeft 'm aan de bank.

De klant weet niet VOOR WELKE TRANSACTIE hij de response geeft. Dit kan de overboeking zijn die hij zelf opgeeft, of 2 overboekingen.

[Freee!!]

Juup schreef op 10 november 2003 @ 12:53:
[...]
1. Wie heeft gezegd dat 'iedereen' die worm/virus moet krijgen?

Dit is hier en nu volgens mij niet echt een punt van discussie, het gaat om het principe

2. Als je 24 uur de tijd hebt kun je het geld meerdere malen overboeken tussen rekeningen in wazige landen. Het is dan erg moeilijk te achterhalen.

Het geld achterhalen is vrij lastig, maar de eerste rekening staat op een naam en daar gaan ze echt wel aankloppen.

[VisionMaster]

guanpedro schreef op 10 november 2003 @ 12:44:
Ik kan me dit voorstellen:

Klant gaat naar proxy en voert gegevens in.
Proxy verstuurt gegevens naar bank en krijgt challenge
Proxy verstuurt challenge naar klant
klant verstuurt response naar proxy
proxy verstuurt response naar bank en logt in.

En dan? hoe zorg je dat jij een transactie kan doen? daar heb jij ook weer een challenge-response voor nodig maar die kan je niet naar de klant sturen want daar heeft hij nooit om gevraagd.

Op dit moment in de tijd (na diverse transacties door sluizen) zou je kunnen cracken wat er er nu in een challenge verwacht wordt, welke gegevens veranderen, welke gelijk blijven en waarvoor welke gegevens veranderd zijn.
Dus na analyse kan je je eigen connecties maken en mogelijke codes forgen.

[ixi]

Handiger is het volgens mij om te kijken wat voor algoritme die e-dentifier gebruikt (iemand een e-dentifier over? ). Dan zou het misschien mogelijk zijn om als je weet wat het slachtoffer heeft ingevult de overige variabelen in het algoritme in te vullen zodat je alle challenges zelf kunt beantwoorden.
Trouwens, hoe komt het dat die e-dentifier mijn pincode kan controlleren? Heeft iemand hier al eens onderzoek naar gedaan?

[under-world]

ixi schreef op 10 november 2003 @ 12:57: Trouwens, hoe komt het dat die e-dentifier mijn pincode kan controlleren? Heeft iemand hier al eens onderzoek naar gedaan?

Die PIN zit in je pas he, dus das niet zo ingwikkeld....

[ Voor 6% gewijzigd door under-world op 10-11-2003 13:00 ]

[Freee!!]

VisionMaster schreef op 10 november 2003 @ 12:56:
[...]
Op dit moment in de tijd (na diverse transacties door sluizen) zou je kunnen cracken wat er er nu in een challenge verwacht wordt, welke gegevens veranderen, welke gelijk blijven en waarvoor welke gegevens veranderd zijn.
Dus na analyse kan je je eigen connecties maken en mogelijke codes forgen.

Dat is dus niet eens nodig, lees deze topic nog maar eens goed door. Op zich is dat trouwens wel een strakke actie, maar ik denk dat je een minimum van zo'n 100.000 transacties nodig hebt en daarna ben je nog wel even bezig met analyseren. De door mij geschetste methode levert een stuk sneller resultaten op

[guanpedro]

Juup schreef op 10 november 2003 @ 12:53:
[...]

2. Als je 24 uur de tijd hebt kun je het geld meerdere malen overboeken tussen rekeningen in wazige landen. Het is dan erg moeilijk te achterhalen.

Dan kunnen ze nogsteeds achterhalen wie het geld heeft en dus wie het heeft gedaan.

Overigens is de bank in de bovenstaande situatie al lang niet meer aansprakelijk. Een van de dingen die in de voorwaarden staan bij het aangaan van een internet bankieren contract is dat je altijd controleert of de communicatie via een beveiligde sesie loopt.

De bank ik ook niet aansprakelijk als iemand jou pinpas en pincode van straat raapt en ermee gaat feesten dus net zo min niet als jij zo'n onveilig systeem hebt dat bovenstaand verhaal mogelijk maakt.

[Freee!!]

under-world schreef op 10 november 2003 @ 12:59:
[...]
Die PIN zit in je pas he, dus das niet zo ingwikkeld....

Niet alleen in de pas, maar ook op de chipknip en die wordt gebruikt, zoals ook uit de documentatie blijkt (en ja, ik heb ook zo'n ding).

[Verwijderd]

Nog steeds het belangrijkste is waar ik het minste over lees die edentifier. Er is iets met tijd of datum wat invloed heeft op de code die dat apparaat ontwikkelt. Als je dus zou keyloggen of ook maar iets wat eroplijkt kom je altijd fout uit.

Het enigste wat kan is dat je de site namaakt en dit dan met weinig tijdverlies doet de en dan de overboekingen nabootst en 5 euro naar je eigen rekening doet. Je moet dan wel de hele site namaken en dus zorgen dat er iets word geweizigd binnen 10 sec zonder dat de inlogger het ziet. Klant ziet het niet maar het is er toch.

[guanpedro]

De server is degene die de Challenge code geeft aan de hand van rekening en pasnr. De e.dentifier heeft het algoritme waarmee de Response wordt uitgerekend. De server controleert of deze overeenkomen.

Dit is dus niet gebaseerd op tijd of datum. Om zelf responses te kunnen berekenen zal je dus eerst het algoritme wat de e.dentifier gebruikt moeten kraken. Deze responses zijn ook gebonden aan gegevens op de chip van de pinpas. om het te kraken heb je dus ook de pinpas zelf nodig

Overigens ook leuk leesvoer, een paar van de cruciale punten uit de algemene voorwaarden van het IB contract:

5.5 Client en Gebruiker zullen regelmatig met behulp van de meest recente versies van anti-virusprogramma's en andere programma's hun PC('s) scannen op computervirussen en andere schadelijke programma's en passende maatregelen treffen

5.8 Client en Gebruiker dienen alvorens Opdrachten te verzenden, te contoleren of er sprake is van een beveiligde sessie met de ABN AMRO.

Dus ze dekken zich hiervoor goed in.

[ Voor 12% gewijzigd door guanpedro op 10-11-2003 13:14 . Reden: redeneer foutje... ]

[Verwijderd]

Ja, maar als er iets gebeurt zal hierover veel onenigheid zijn. Het is namelijk niet echt duidelijk. Als je een of andere onbekende virusscanner hebt en je krijgt een zelfgemaakt trojan op je pc ben je dus niet verantwoordelijk.

[Danster]

Verwijderd schreef op 10 november 2003 @ 13:22:
Ja, maar als er iets gebeurt zal hierover veel onenigheid zijn. Het is namelijk niet echt duidelijk. Als je een of andere onbekende virusscanner hebt en je krijgt een zelfgemaakt trojan op je pc ben je dus niet verantwoordelijk.

Yep want dan treedt de volgende regel in werking dat je zelf moet controleren.
Skimming (die ene cent die de topicstarter noemt) zal meteen opvallen als tweede transactie dus heeft geen zin.

[Freee!!]

Danster schreef op 10 november 2003 @ 13:24:
[...]
Yep want dan treedt de volgende regel in werking dat je zelf moet controleren.

Dat is altijd een aardige.

Skimming (die ene cent die de topicstarter noemt) zal meteen opvallen als tweede transactie dus heeft geen zin.

Dus neem je een ander, logischer bedrag (€ 13,95) met een leuke omschrijving.

[ Voor 1% gewijzigd door Freee!! op 10-11-2003 13:27 . Reden: Typo ]

[Danster]

Dus neem je een ander, logischer bedrag (€ 13,95) met een leuke omschrijving.

klopt maar dat flik je ook maar 1x ..dus om al die moeite te nemen?
En grote bedragen? Mwoah..denk niet dat dat door de ballotage komt

[Janoz]

Over dat proxy verhaal heb ik het hier al Janoz in "Kan internetbankieren veilig zijn?" . Hier ontkracht ik het ook al gelijk.

De hacker zal een parser moeten schrijven die precies bijhoud wat er gebeurt en detecteerd waneer er een transactie word doorgevoerd. Waneer de bank ook hier random elementen toevoegd is het voor de hacker bijna onmogenlijk om een sluitende parser te schrijven die blijft werken. Het 'man in the middle' idee, zoals het officieel heet, is dus ook door de bank makkelijk te voorkomen.

[guanpedro]

Wat ik nog niet heb gemeld uit de voorwaarden (teveel overtypwerk) is dat de ABN niet aansprakelijk is voor het onrechtmatig gebruik van voor het moment dat je het meldt aan de ABN.

Overigens helpen ze je wel met het terugvorderen van het onrechtmatig overgeboekte geld.

Maar zo werkt het bijna overal; pinpas, creditcards etc

[Garyu]

[b][message=19212729,noline]Mr. Liu schreef op 10 november 2003 @
[...]

Het geld achterhalen is vrij lastig, maar de eerste rekening staat op een naam en daar gaan ze echt wel aankloppen.

Och, als internetbankieren toch zo onveilig is en makkelijk te hacken, dan hack je toch twee accounts, sluis je het geld door van de eerste naar de tweede, en van de tweede naar het buitenland? Vervolgens neem je de buitenlandse wazige landen nog even mee en uiteindelijk ben je een paar eurootjes rijker .

[Janoz]

Transacties naar het buitenland kunnen niet (zo makkelijk) met internet bankieren. Ongezien zo'n transactie ertussen frotten wordt dus nog moeilijker. Verder valt een overmaking naar het buiteland enorm op. Zolang je iets overmaakt binnen nederland kan er gewoon aangifte worden gedaan en kan de politie zo de gegevens achterhalen/inhoud vorderen.

Het overmaken naar een ander gehacked acount maakt weinig uit omdat je het dan toch ooit een keer over de grens zou moeten sturen. Daarnaast zijn er dan veel makkelijkere manieren om dit voor elkaar te krijgen (bank 1 of andere afrikaans land die genoeg heeft aan persoonsgegevens + handtekening + rekeningnummer om deze helemaal leeg te halen).

Kortom: Internet bankieren is niet onveiliger dan andere overmaak methodes en misschien zelfs nog veiliger.

[Freee!!]

Janoz schreef op 10 november 2003 @ 13:41:
[...]
Kortom: Internet bankieren is niet onveiliger dan andere overmaak methodes en misschien zelfs nog veiliger.

De kans op onderscheppen is waarschijnlijk kleiner dan met de post en/of het in de brievenbus van de bank douwen (hengelen ).

[guanpedro]

Of een handtekening op een overschrijvingskaart namaken.

[Verwijderd]

Mr. Liu schreef op 10 november 2003 @ 12:48:
[...]

Elke hacker (en iedereen die hier post) die hier even over nadenkt kan hierop het antwoord verzinnen: Die extra betaling wordt op de proxy van de hacker toegevoegd aan het bericht dat de klant via de proxy van de hacker verstuurd naar de bank. De bank bepaald op basis hiervan een code, stuurt die (via de proxy van de hacker) naar de klant en de klant geeft gewoon de code terug die hij uit zijn e-dentifier krijgt. De hacker hoeft al niks meer te doen dan doorgeven.

[...]

Je wacht gewoon tot de klant een transactie initieert, die onderschep je en daar voeg je je eigen transactie aan toe of je wijzigt die transactie zoals je zelf wilt.

Kijk, jij snapt hem! DE KLANT LOGT IN VOOR JOU!!! Het enige wat je hoeft te doen is de packetstream omleiden,onderscheppen en aanpassen, en weer door laten gaan naar plaats van bestemming!!!! De bank krijgt gewoon juiste inlog info en code's aleen zijn bv. het bedrag en rekeningnummer van de transactie-packet aangepast. En, komop, jullie gaan me niet vertellen dat je packetstreams niet kan omleiden en aanpassen he?! en oowja, over SSL?! Kijk eens wat vaker op sites voor hackers/crackers, dan had je daar al meerdere oplossingen voor

Verder wil ik benadrukken dat ik (helaas) niet alles weet en alle reacties zéér op prijs stel, maar ik ben van mening dat Mr Liu en Jaaap de enige zijn die begrijpen welk probleem ik schets, ik hoop dat we hier nog een aantal goed beargumenteerde replies op krijgen!!!

Thanks alvast voor de medewerking he!?

edit:

*zie bijlage voor wat ontkrachtende woorden indien u zich in een hokje geplaats voeld

[ Voor 4% gewijzigd door Verwijderd op 10-11-2003 14:16 ]

[Verwijderd]

edit:
woepszzz..... dubbelpost

[ Voor 98% gewijzigd door Verwijderd op 10-11-2003 14:01 . Reden: dubbelpost ]

[under-world]

Dat "hengelen" schijnt tegenwoordig ook niet meer zo heel gemakkelijk te zijn maar ik denk als je alle feiten naast elkaar legt, dat Janoz'uitspraak over de veiligheid van inetrnetbankieren en pinnen (en al zeker een normale overschrijving!!!) nog niet eens zo gek is. In de tijd tussen acceptgiro invullen en het daadwerkelijke versturen ervan door de bank, is voor creatieve geesten ook genoeg ruimte om een frauduleuze manier te vinden. Ik vond dat consumentenonderzoek over acceptgiro's van een aantal jaar geleden vrij schokkend. Handtekeningen als een zonnetje of boter-kaas en eieren werden probleemloos geaccepteerd evenals verbeterde bedragen van 20 naar 2000 gulden met doorgekraste --- en daarboven 00 ingevuld

Verder wil ik benadrukken dat ik (helaas) niet alles weet en alle reacties zéér op prijs stel, maar ik ben van mening dat Mr Liu en Jaaap de enige zijn die begrijpen welk probleem ik schets, ik hoop dat we hier nog een aantal goed beargumenteerde replies op krijgen!!!

edit:
Het kwartje is bij mij ook wel gevallen hoor en ik denk dat Janoz hem al veeeel eerder doorhad....

[ Voor 27% gewijzigd door under-world op 10-11-2003 14:12 ]

[Danster]

Verwijderd schreef op 10 november 2003 @ 13:56:
[...]


Kijk, jij snapt hem! DE KLANT LOGT IN VOOR JOU!!! Het enige wat je hoeft te doen is de packetstream omleiden,onderscheppen en aanpassen, en weer door laten gaan naar plaats van bestemming!!!! De bank krijgt gewoon juiste inlog info en code's aleen zijn bv. het bedrag en rekeningnummer van de transactie-packet aangepast. En, komop, jullie gaan me niet vertellen dat je packetstreams niet kan omleiden en aanpassen he?! en oowja, over SSL?! Kijk eens wat vaker op sites voor hackers/crackers, dan had je daar al meerdere oplossingen voor

Verder wil ik benadrukken dat ik (helaas) niet alles weet en alle reacties zéér op prijs stel, maar ik ben van mening dat Mr Liu en Jaaap de enige zijn die begrijpen welk probleem ik schets, ik hoop dat we hier nog een aantal goed beargumenteerde replies op krijgen!!!

Thanks alvast voor de medewerking he!?

Misschien is dit technisch wel haalbaar maar er zijn meer systemen achter de schermen bezig dan het venster dat je ziet. Plausibiliteitscontroles e.d.
Dit is iets wat misschien een paar dagen in de lucht kan zitten dan gaat er een alarmbelletje rinkellen en zullen er wel wijzigingen plaats vinden waardoor je plan wel in het water valt.

[Janoz]

Verwijderd schreef op 10 november 2003 @ 13:56:
[...]


Kijk, jij snapt hem! DE KLANT LOGT IN VOOR JOU!!! Het enige wat je hoeft te doen is de packetstream omleiden,onderscheppen en aanpassen, en weer door laten gaan naar plaats van bestemming!!!! De bank krijgt gewoon juiste inlog info en code's aleen zijn bv. het bedrag en rekeningnummer van de transactie-packet aangepast. En, komop, jullie gaan me niet vertellen dat je packetstreams niet kan omleiden en aanpassen he?! en oowja, over SSL?! Kijk eens wat vaker op sites voor hackers/crackers, dan had je daar al meerdere oplossingen voor

Verder wil ik benadrukken dat ik (helaas) niet alles weet en alle reacties zéér op prijs stel, maar ik ben van mening dat Mr Liu en Jaaap de enige zijn die begrijpen welk probleem ik schets, ik hoop dat we hier nog een aantal goed beargumenteerde replies op krijgen!!!

Thanks alvast voor de medewerking he!?

Ik snap je probleem ook wel en heb het beestje zelfs bij de juiste naam genoemd (man in the middle) . Punt is juist dat dit aanpassen erg lastig is. Je kunt niet snel ff in de source kijken voordat je de pagina verder stuurt om hier aanpassingen in te doen, dit moet automatisch gebeuren aangezien er anders timeouts optreden. Doordat de bank de layout en werking van de internet pagina's compleet in eigen hand hebben kunnenn ze hier wijzigingen in aanbrengen die ze zelf maar willen. Het toevoegen van een extra transactie is dus bijna niet mogenlijk. Ook bijvoorbeeld een rekeningnummer aanpassen is erg lastig, want hoe weet je nu wat het rekening nummer is? Voor het zelfde geld ben je een random sessie code aan het vervangen. Je zult de bank applicatie compleet moeten nabouwen en zodra de bank iets veranderd moet je weer opnieuw reverse engineren. Het idee is leuk, maar practisch niet uit te voeren.

Verder is SSL misschien met een flinke inspanning wel te hacken, maar vergeet niet dat het hier over een streaming connectie gaat. Hackersites kunnen van alles beweren en een ssl gecodeerd bericht is na veel inspanning wel te ontcijveren, maar on the fly decrypten is zonder een fixe berg rekenkracht onder je kont niet te doen!

[Verwijderd]

BIJLAGE

under-world schreef op 10 november 2003 @ 14:03:

[...]

edit:
Het kwartje is bij mij ook wel gevallen hoor en ik denk dat Janoz hem al veeeel eerder doorhad....

Hehehe, mijn nederige excuses, buiten het feit dat ik pagina 2 over het hoofd heb gezien moet ik zeggen dat ik nogal lui aangelegd ben en dit in combinatie met mijn
dwangmatige hang naar generalisatie weleens wil zorgen voor het onvermeld laten van enkele zéér gewaardeerde posters.

[under-world]

Ik vind het meestal wel spannend dit soort verhalen en verbaas me vaak over hoe creatief mensen kunnen zijn in het verzinnen van manieren om maar zo snel mogelijk voor de rest van hun leven aan een parelwit strand te liggen. Deze methode is wel even iets anders dan die medewerker van Gassan Diamonds die met een simpele magnetrondoos voor 20.000.000 euro buit wist te maken. Doe je het op zo'n easy way en dan geef je het terug, omdat je spijt hebt...

edit:
Ik denk dat iemand die het telebankieren kraakt iets minder snel spijt zal hebben

[ Voor 13% gewijzigd door under-world op 10-11-2003 14:26 ]

[Arunia]

Ik heb al sinds het begin de online versie van girotel. Hiermee heb ik eigenlijk nog nooit problemen gehad.

Je hebt hierbij een lijst met TAN-codes. Ok, als die lijst gejat wordt samen met je account codes waarvan de laatste te wijzigen is, dan is het natuurlijk heel makkelijk om geld over te schrijven. Hier wordt dus gewoon van te voren een lijst van 100 codes random aangemaakt. En de server vraagt hier dan uiteindelijk om welke je moet invoeren. Als je het fout doet vraagt ie om de volgende.

Ik denk zoals al vaker gezegd in dit topic, dat het best veilig is. Waar willen ze je geld dan heen sturen? Vroeg of laat kom je er toch wel achter dat er iets mis is.

[Verwijderd]

Tegenwoordig is het overmaken van geld naar een buitenlandse rekening juist makkelijk.
Bij de ABN krijg je zelf standaard al een Iban nummer, dus het is wel te doen.
En dan nog wat? De bank doet ieder half een batch ofzo voor de verwerking van de overboekingen. En pas na 5 of 6 batches komt de klant erachter, dan ben je toch echt wel te laat hoor!

Naar een andere bank overboeken of naar het buitenland duurt ook wel langer maar als je gewoon het omaatje van om de hoek neemt die merkt dat echt niet hoor!
Die doet maybe een keer in de 2 weken een overboeking en dan kan ik het geld allang in china op hebben genomen!

[Verwijderd]

Janoz schreef op 10 november 2003 @ 14:15:
Ik snap je probleem ook wel en heb het beestje zelfs bij de juiste naam genoemd (man in the middle) . Punt is juist dat dit aanpassen erg lastig is.

Waarom is dit lastig? Je weet immers, als man-in-the-middle zijnde wat er van beide zijden komt.

Je kunt niet snel ff in de source kijken voordat je de pagina verder stuurt om hier aanpassingen in te doen, dit moet automatisch gebeuren aangezien er anders timeouts optreden.

Precies, het tussenfrotten van een extra transactie zal echt niet zo moeilijk zijn. Je kan immers bij iedere HTTP-put die de client doet een extra HTTPS-put doen bij de bank.

Doordat de bank de layout en werking van de internet pagina's compleet in eigen hand hebben kunnenn ze hier wijzigingen in aanbrengen die ze zelf maar willen. Het toevoegen van een extra transactie is dus bijna niet mogenlijk.

De halve waarheid is een hele leugen. Bijna niet mogelijk is dus eigenlijk gewoon mogelijk.

Ook bijvoorbeeld een rekeningnummer aanpassen is erg lastig, want hoe weet je nu wat het rekening nummer is?

Duh, die heeft de client toch ingevoerd, die hengel je er dus als man-in-the-middle tussenuit.

Voor het zelfde geld ben je een random sessie code aan het vervangen.

Niet dus, want je weet welk bankrekeningnummer is ingevoerd.

Je zult de bank applicatie compleet moeten nabouwen en zodra de bank iets veranderd moet je weer opnieuw reverse engineren.

Reverse engineren lijkt me hier niet van toepassing. Het gaat erom dat je de content van de bank opvangt en doorstuurt naar de client en vica versa en daarbij moet je zorgen dat jouw extra data, onzichtbaar voor de client gemaakt wordt.

Het idee is leuk, maar practisch niet uit te voeren.

Weet ik zo net nog niet. Alleen denk ik dat als het je lukt dat je waarschijnlijk zo slim bent dat je beter op een andere, iets legalere manier, heel veel meer extra geld kunt verdienen.

Wil je zo iets doen, moet je zorgen dat je het goed doet. Heel veel geld in een zo kort mogelijke tijd binnen zien te krijgen via diverse banken naar het buitenland over maken, daar je geld innen en voor de rest van je leven niet meer opduikt.

Verder is SSL misschien met een flinke inspanning wel te hacken, maar vergeet niet dat het hier over een streaming connectie gaat. Hackersites kunnen van alles beweren en een ssl gecodeerd bericht is na veel inspanning wel te ontcijveren, maar on the fly decrypten is zonder een fixe berg rekenkracht onder je kont niet te doen!

Maar je hoeft HTTPS bij het man-in-the-middle principe helemaal niet te decoderen want je krijgt nog steeds als man-in-the-middle zijnde HTML binnen.

[Janoz]

Verwijderd schreef op 10 november 2003 @ 15:03:
[...]

Waarom is dit lastig? Je weet immers, als man-in-the-middle zijnde wat er van beide zijden komt.

Je weet exact welke bytes heen en weer gestuurt worden. Dit betekend nog niet dat ik precies weet wat welke byte inhoud. Om de betekenins te achter halen zal je de bytes moeten interpreteren.

[...]

Precies, het tussenfrotten van een extra transactie zal echt niet zo moeilijk zijn. Je kan immers bij iedere HTTP-put die de client doet een extra HTTPS-put doen bij de bank.

Hoezo een extra PUT? Meestal wordt er een heel scala aan pagina's doorlopen voordat een transactie is ingevoerd. Je kunt niet simpel een put rek=12.34.56.789&bedrag=E345,- er tussen frotten. Hoe weet je nu welk formulier veld daadwerkelijk de waarde bevat? Wordt dat uberhaupt als formulier veld doorgestuurd?

[...]

De halve waarheid is een hele leugen. Bijna niet mogelijk is dus eigenlijk gewoon mogelijk.

Hiermee bedoel ik meer dat het in theorie mogenlijk zou kunnen zijn, maar dat er veel makkelijkere manieren zijn om op een andere manier mensen van hun geld af te helpen.

[...]

Duh, die heeft de client toch ingevoerd, die hengel je er dus als man-in-the-middle tussenuit.

Er komen een berg bytes langs. Hoe weet je nu welke byte bij het rekening nummer hoort en welk niet? Het rekening nummer is variabel.

[...]

Niet dus, want je weet welk bankrekeningnummer is ingevoerd.

Dat weet je dus niet zomaar

[...]

Reverse engineren lijkt me hier niet van toepassing. Het gaat erom dat je de content van de bank opvangt en doorstuurt naar de client en vica versa en daarbij moet je zorgen dat jouw extra data, onzichtbaar voor de client gemaakt wordt.

Je zult precies moeten weten hoe de gegevens heen en weer gestuurd worden. Zodra je een goede parser geschreven hebt die een request precies kan ontleden in de gewenste velden is het geen garantie dat deze hetzelfde blijven. De bank veranderd de volgorde een beetje, noemt velden anders en je zit opgescheept met een waardeloze parser.

[...]

Weet ik zo net nog niet. Alleen denk ik dat als het je lukt dat je waarschijnlijk zo slim bent dat je beter op een andere, iets legalere manier, heel veel meer extra geld kunt verdienen.

Wil je zo iets doen, moet je zorgen dat je het goed doet. Heel veel geld in een zo kort mogelijke tijd binnen zien te krijgen via diverse banken naar het buitenland over maken, daar je geld innen en voor de rest van je leven niet meer opduikt.

Ik denk dat, waneer er plots via internet bankieren bij 1 bank heel veel overschrijvingen gedaan worden naar eenzelfde rekening of zelfde bedrag oid, dat er dan wel een alarmpje gaat klinken bij de bank. Het is natuurlijk niet zo dat ze het bij de bank helemaal niet in de gaten houden.

[...]

Maar je hoeft HTTPS bij het man-in-the-middle principe helemaal niet te decoderen want je krijgt nog steeds als man-in-the-middle zijnde HTML binnen.

Dit staat los van het eerste en slaat op 'ssl is makkelijk te kraken' wat dus niet waar is .

[Verwijderd]

Janoz schreef op 10 november 2003 @ 15:33:[...]
Je weet exact welke bytes heen en weer gestuurt worden. Dit betekend nog niet dat ik precies weet wat welke byte inhoud. Om de betekenins te achter halen zal je de bytes moeten interpreteren.

Dat hoeft dus niet want de client maakt van normaal HTTP gebruik (in dit voorbeeld dan he) en jij hebt de connectie met de bank. Jij krijgt je HTML via SSL. Je hoeft dus niet de bytes te interpreteren, dat doet jouw Internet Explorer, jij hoeft alleen de HTML source, eventueel aangepast, door te sturen naar de client.

Hoezo een extra PUT? Meestal wordt er een heel scala aan pagina's doorlopen voordat een transactie is ingevoerd. Je kunt niet simpel een put rek=12.34.56.789&bedrag=E345,- er tussen frotten. Hoe weet je nu welk formulier veld daadwerkelijk de waarde bevat? Wordt dat uberhaupt als formulier veld doorgestuurd?

Maakt toch niet uit. Als bij een transactie 3 pagina's dienen te worden doorlopen kun jij dat als tussenlaag (man-in-the-middle) simpelweg, aangepast herhalen.

Hiermee bedoel ik meer dat het in theorie mogenlijk zou kunnen zijn, maar dat er veel makkelijkere manieren zijn om op een andere manier mensen van hun geld af te helpen.

Was ook wel een beetje bijdehande opmerking van me

Er komen een berg bytes langs. Hoe weet je nu welke byte bij het rekening nummer hoort en welk niet? Het rekening nummer is variabel.

Je hoeft die berg bytes dus niet te onderscheiden. Het gaat om de uiteindelijke HTML.
Bij SSL gaat het erom dat de data die heen en weer verzonden wordt versleuteld is met 2 sleutels zodat niemand anders het kan aftappen. Maar in dit geval hoef je niet af te tappen aangezien de bank denkt dat de man-in-the-middle de transactie uitvoert en NIET de client. De client voorziet de man-in-the-middle van de benodigde data om transacties te doen.

Dat weet je dus niet zomaar

Tuurlijk zal het wel complexer zijn, ik geef het vereenvoudigd weer.

Je zult precies moeten weten hoe de gegevens heen en weer gestuurd worden.

Dat hoef je dus niet te weten.

Zodra je een goede parser geschreven hebt die een request precies kan ontleden in de gewenste velden is het geen garantie dat deze hetzelfde blijven.

Inderdaad maar ze zullen die velden waarschijnlijk niet ieder uur veranderen.

De bank veranderd de volgorde een beetje, noemt velden anders en je zit opgescheept met een waardeloze parser.

Als je als man-in-the-middle maar weet hoe je je parser zo snel mogelijk actueel kunt krijgen.

Ik denk dat, waneer er plots via internet bankieren bij 1 bank heel veel overschrijvingen gedaan worden naar eenzelfde rekening of zelfde bedrag oid, dat er dan wel een alarmpje gaat klinken bij de bank. Het is natuurlijk niet zo dat ze het bij de bank helemaal niet in de gaten houden.

Random bedragen tussen 5 en 25 eurie zullen denk ik niet snel opvallen en al helemaal niet als je het via bijvoorbeeld 30 bankrekening, verdeeld over bijvoorbeeld 5 banken doet.

Dit staat los van het eerste en slaat op 'ssl is makkelijk te kraken' wat dus niet waar is .

SSL is inderdaad niet makkelijk te kraken maar hoeft helemaal niet gekraakt te worden.

[VisionMaster]

Verwijderd schreef op 10 november 2003 @ 16:04:
[...]
SSL is inderdaad niet makkelijk te kraken maar hoeft helemaal niet gekraakt te worden.

Ik zal het strax eens bekijken van de Postbank, maar vind het maar een vaag verhaal van je. Bij mijn weten (en hopen) wordt de HTML page via SSL verstuurd. Dan issie dus met een sleuteltje versleuteld die een gebruiker op een beveiligde manier heeft ingevuld, of was het nu het idee om via de man-in-the-middle die versleuteling(stechniek) te onderscheppen en zelf te gebruiken voor alle inkomende acties?

[Janoz]

Verwijderd schreef op 10 november 2003 @ 16:04:
[...]

Dat hoeft dus niet want de client maakt van normaal HTTP gebruik (in dit voorbeeld dan he) en jij hebt de connectie met de bank. Jij krijgt je HTML via SSL. Je hoeft dus niet de bytes te interpreteren, dat doet jouw Internet Explorer, jij hoeft alleen de HTML source, eventueel aangepast, door te sturen naar de client.

Druk nu eens op de rechter muisknop en vervolgens op bron weergeven. De html code die de ene kant op gaan en de http request die de andere kant op gaan zijn inderdaad zo te lezen, maar voordat je weet welk stukje slaat op een rekening nummer zul je toch echt die pagina moeten parsen en dat gaat echt helemaal niet zo makkelijk als jij nu denkt. Het inlezen van de html lukt ook wel en je zou er ook nog wel wat van kunnen maken maar voordat je in 1 oogopslag kunt zien welk veld bedoeld is voor het rekening nummer en welke voor het een simpele zoek opdracht ben je toch wel ff ietsje verder. Zeker omdat de bank dit rustig aan kan passen in iets heel anders zonder dat het uiterlijk veranderd.

[...]
[
Maakt toch niet uit. Als bij een transactie 3 pagina's dienen te worden doorlopen kun jij dat als tussenlaag (man-in-the-middle) simpelweg, aangepast herhalen.

Ja, en waar moet je wat invullen. Wat is het zoek veld, welke varnaam wordt gebruikt voor het rekening nummer? Is de gebruiker nu met zijn spaar rekening bezig of doet hij een acceptgiro overschrijving? Open voor de gein eens je telebankieren pagina en sla alle pagina's eens op en probeer zelf eens een sluitende reguliere expressie te vinden die altijd het juiste resultaat oplevert. Daarnaast zul je met aangepast herhalen dit x keer moeten doen voordat je de bevestiging pagina kunt sturen waardoor die timeout weer om de hoek zou kunnen komen kijken.

[...]
Je hoeft die berg bytes dus niet te onderscheiden. Het gaat om de uiteindelijke HTML.
Bij SSL gaat het erom dat de data die heen en weer verzonden wordt versleuteld is met 2 sleutels zodat niemand anders het kan aftappen. Maar in dit geval hoef je niet af te tappen aangezien de bank denkt dat de man-in-the-middle de transactie uitvoert en NIET de client. De client voorziet de man-in-the-middle van de benodigde data om transacties te doen.

Goed, berg bytes is html of een http request. Dat is natuurlijk nog maar stap 1 van een lange weg. zie hierboven

[...]

Tuurlijk zal het wel complexer zijn, ik geef het vereenvoudigd weer.

Juist die mate van complexheid die je hier ff overslaat is zo enorm groot dat het door jou gestelde redelijk onhaalbaar wordt. Vergelijk het met TSP oid. Oplossing is heel simpel, gewoon ff alles proberen. Kijk je daar iets langer na dan blijkt een super computer een miljoen jaar nodig te hebben om al die mogenlijkheiden te berekenen.

[...]

Dat hoef je dus niet te weten.

Dus wel. Anders zit je straks de sessie var aan te passen ipv het over te maken bedrag.

[...]

Inderdaad maar ze zullen die velden waarschijnlijk niet ieder uur veranderen.

Ik zou niet eens raar opkijken waneer dit per request zou veranderen.

[...]

Als je als man-in-the-middle maar weet hoe je je parser zo snel mogelijk actueel kunt krijgen.

Probeer 'm eerst maar uberhaupt werkend te krijgen. Komt dat reverse enginering weer om de hoek krijgen. Je zult adhv de html code en de requests telkens precies moeten weten met welke actie een gebruiker bezig is op dat moment om exact te bepalen waar je wat zou moeten veranderen.

[...]

Random bedragen tussen 5 en 25 eurie zullen denk ik niet snel opvallen en al helemaal niet als je het via bijvoorbeeld 30 bankrekening, verdeeld over bijvoorbeeld 5 banken doet.

Wel als ze allemaal via dezelfde proxy worden overgemaakt

[...]

SSL is inderdaad niet makkelijk te kraken maar hoeft helemaal niet gekraakt te worden.

Klopt, zoals ik al zei staat dat los van mijn verhaal. Man in the middle is inderdaad wel een manier om ssl te omzeilen.

[Verwijderd]

VisionMaster schreef op 10 november 2003 @ 16:22:
[...]

Ik zal het strax eens bekijken van de Postbank, maar vind het maar een vaag verhaal van je. Bij mijn weten (en hopen) wordt de HTML page via SSL verstuurd. Dan issie dus met een sleuteltje versleuteld die een gebruiker op een beveiligde manier heeft ingevuld, of was het nu het idee om via de man-in-the-middle die versleuteling(stechniek) te onderscheppen en zelf te gebruiken voor alle inkomende acties?

Zo moeilijk te begrijpen is het toch niet...
client maakt connectie met man-in-the-middle terwijl client denkt dat hij in verbinding staat met bank. Man-in-the-middle maakt contact met de bank en verschaft dus de communicatie met de bank. De HTML wordt echter naar de client 'doorgestuurd' en de client geeft dus de benodigde informatie aan de man-in-the-middle die het weer kan gebruiken om aan de bank te verschaffen.

Bij SSL ben je alleen ~100% zeker dat de verbinding niet afgetapt kan worden met bijv. een sniffer.

[Janoz]

VisionMaster schreef op 10 november 2003 @ 16:22:
[...]

Ik zal het strax eens bekijken van de Postbank, maar vind het maar een vaag verhaal van je. Bij mijn weten (en hopen) wordt de HTML page via SSL verstuurd. Dan issie dus met een sleuteltje versleuteld die een gebruiker op een beveiligde manier heeft ingevuld, of was het nu het idee om via de man-in-the-middle die versleuteling(stechniek) te onderscheppen en zelf te gebruiken voor alle inkomende acties?

De grap van man in the middle is dat de haqcker je computer weet wijs te maken dat hij de postbank is (trojan die hosts aanpast) en vervolgens bij de postbank doet of hij jou is. Hierdoor denken de postbank en jij dat jullie met elkaar praten. Er wordt dus een ssl verbinding opgezet tussen jou en de hacker (of helemaal geen ssl verbinding), en de hacker zet een ssl verbinding op met de bank. Je hebt dus nooit een ssl verbinding met de bank opgezet. Kans is trouwens wel groot dat je een 'onbekend certificate' foutmelding voor je neus krijgt.

[Bor]

Verwijderd schreef op 10 november 2003 @ 16:26:
[...]

Zo moeilijk te begrijpen is het toch niet...
client maakt connectie met man-in-the-middle terwijl client denkt dat hij in verbinding staat met bank. Man-in-the-middle maakt contact met de bank en verschaft dus de communicatie met de bank. De HTML wordt echter naar de client 'doorgestuurd' en de client geeft dus de benodigde informatie aan de man-in-the-middle die het weer kan gebruiken om aan de bank te verschaffen.

Bij SSL ben je alleen ~100% zeker dat de verbinding niet afgetapt kan worden met bijv. een sniffer.

2 zijdige authenticatie voorkomt de man in de middle attack ook mits je het certificaat controlleerd.

[Verwijderd]

Bor_de_Wollef schreef op 10 november 2003 @ 16:29:
2 zijdige authenticatie voorkomt de man in de middle attack ook mits je het certificaat controlleerd.

Klopt helemaal, maar er zijn denk ik veel mensen die niet of nauwelijks opletten op hun verbindingen.

[Verwijderd]

Janoz schreef op 10 november 2003 @ 16:24:
Druk nu eens op de rechter muisknop en vervolgens op bron weergeven. De html code die de ene kant op gaan en de http request die de andere kant op gaan zijn inderdaad zo te lezen, maar voordat je weet welk stukje slaat op een rekening nummer zul je toch echt die pagina moeten parsen en dat gaat echt helemaal niet zo makkelijk als jij nu denkt. Het inlezen van de html lukt ook wel en je zou er ook nog wel wat van kunnen maken maar voordat je in 1 oogopslag kunt zien welk veld bedoeld is voor het rekening nummer en welke voor het een simpele zoek opdracht ben je toch wel ff ietsje verder. Zeker omdat de bank dit rustig aan kan passen in iets heel anders zonder dat het uiterlijk veranderd.

Ja, en waar moet je wat invullen. Wat is het zoek veld, welke varnaam wordt gebruikt voor het rekening nummer? Is de gebruiker nu met zijn spaar rekening bezig of doet hij een acceptgiro overschrijving? Open voor de gein eens je telebankieren pagina en sla alle pagina's eens op en probeer zelf eens een sluitende reguliere expressie te vinden die altijd het juiste resultaat oplevert. Daarnaast zul je met aangepast herhalen dit x keer moeten doen voordat je de bevestiging pagina kunt sturen waardoor die timeout weer om de hoek zou kunnen komen kijken.

Goed, berg bytes is html of een http request. Dat is natuurlijk nog maar stap 1 van een lange weg. zie hierboven

Juist die mate van complexheid die je hier ff overslaat is zo enorm groot dat het door jou gestelde redelijk onhaalbaar wordt. Vergelijk het met TSP oid. Oplossing is heel simpel, gewoon ff alles proberen. Kijk je daar iets langer na dan blijkt een super computer een miljoen jaar nodig te hebben om al die mogenlijkheiden te berekenen.

Dus wel. Anders zit je straks de sessie var aan te passen ipv het over te maken bedrag.

Ik zou niet eens raar opkijken waneer dit per request zou veranderen.

Probeer 'm eerst maar uberhaupt werkend te krijgen. Komt dat reverse enginering weer om de hoek krijgen. Je zult adhv de html code en de requests telkens precies moeten weten met welke actie een gebruiker bezig is op dat moment om exact te bepalen waar je wat zou moeten veranderen.

Wel als ze allemaal via dezelfde proxy worden overgemaakt

Klopt, zoals ik al zei staat dat los van mijn verhaal. Man in the middle is inderdaad wel een manier om ssl te omzeilen.

Je hoeft de HTML helemaal niet te kennen bedenk ik me net. Je kan namelijk heel simpel Internet Explorer aansturen met een heel eenvoudig scriptje (thank you Bill). Dan kun je heel simpel op zoek naar bijv een knopje met een bepaalde tekst en laat je je script automagisch daar op klikken.

Als man-in-the-middle ben je dan van de pagina-complexiteit af. Immers in plaats van dat je zelf op de knopjes drukt wat waarschijnlijk te lang zou duren zodat je timeouts krijgt, laat je dit door een applicatie of script doen. Je hoeft dan alleen de lay out van de pagina te kennen zoals we deze normaliter in de browser zien en laten alle acties door de computer overnemen van ons. De uiteindelijke HTML laten we alleen doorsturen.
De Internet Explorer, via OLE automation dan, zit zelfs zo slim in elkaar dat we gewoon geautomatiseerd bepaalde zaken 'invisible' kunnen maken/verwijderen (denk aan die ene transactie van de man-in-the-middle). De uiteindelijke HTML sturen we dan alleen nog door (met invisible/verwijderde transactie) zodat client denkt dat ie safe zit.

[Bor]

Iedereen heeft het leuk over zwaktes van SSL en man in de middle attack etc, maar wat dacht je van

- Configuratie fouten
- Software bugs Server / Middleware
- Software bugs Client
- Trojan horses op de client PC (keyloggers etc)
- Human error (verwerking en procedures).

Het is dus veel meer dan tot nu toe genoemd.

[Verwijderd]

Bor_de_Wollef schreef op 10 november 2003 @ 18:00:
Iedereen heeft het leuk over zwaktes van SSL en man in de middle attack etc.

Ik heb het helemaal nog niet over zwaktes van SSL gehad.

maar wat dacht je van
- Configuratie fouten
- Software bugs Server / Middleware
- Software bugs Client
- Trojan horses op de client PC (keyloggers etc)
- Human error (verwerking en procedures).

Het is dus veel meer dan tot nu toe genoemd.

Hier kun je als kwaadwillende niet zoveel mee, in ieder geval geen geld naar eigen rekeningen overmaken.

[Verwijderd]

Mr. Liu schreef op 10 november 2003 @ 12:48:
[...]

Elke hacker (en iedereen die hier post) die hier even over nadenkt kan hierop het antwoord verzinnen: Die extra betaling wordt op de proxy van de hacker toegevoegd aan het bericht dat de klant via de proxy van de hacker verstuurd naar de bank. De bank bepaald op basis hiervan een code, stuurt die (via de proxy van de hacker) naar de klant en de klant geeft gewoon de code terug die hij uit zijn e-dentifier krijgt. De hacker hoeft al niks meer te doen dan doorgeven.

[...]

Je wacht gewoon tot de klant een transactie initieert, die onderschep je en daar voeg je je eigen transactie aan toe of je wijzigt die transactie zoals je zelf wilt.

Die extra transactie voeg je toe als de klant de response al heeft gegeven, deze klopt dus niet meer voor de transactie.
Resultaat, de bank accepteerd je opdracht niet.

[Bor]

Verwijderd schreef op 10 november 2003 @ 18:13:
[...]

Ik heb het helemaal nog niet over zwaktes van SSL gehad.

[...]

Hier kun je als kwaadwillende niet zoveel mee, in ieder geval geen geld naar eigen rekeningen overmaken.

Klopt, maar de algemene vraag is "kan internetbankieren veilig zijn?". Verder kun je met software fouten / trojans, config fouten zeker wel wat als kwaadwillend persoon.

[ Voor 14% gewijzigd door Bor op 10-11-2003 18:42 ]

[VisionMaster]

Verwijderd schreef op 10 november 2003 @ 16:39:
[...]

Klopt helemaal, maar er zijn denk ik veel mensen die niet of nauwelijks opletten op hun verbindingen.

Bij ons is het dus zo dat we servers uitrusten met de key's en subject names van de certificaten die vertrouwde servers moeten hebben (X509) en waarmee geconnect wordt.

Clients hebben een beperkte lijst van CA's die het mag vertrouwen. Kom je hier niet in voor, dan zal de SSL verbinding niet worden opgezet, omdat er ergens in de X509 chain er een fout zit.
Het enige dat kan gebeuren is dat iemand Verisign hacked of naspeeld.

Dit systeempie is eenvoudig te handhaven ook voor huis-tuin-keuken gebruikers (bij installatie moet alles goed geconfiged zijn).

[ Voor 23% gewijzigd door VisionMaster op 10-11-2003 23:17 ]

[tweakerbee]

Het kan nog makkelijker: Vervang gewoon rek. nr. door je wazige Afrikaanse rekening.
Valt het bedrag in eerste instantie niet zo op.

Moet het wel even zo zijn dat er geen controle plaatsvindt op naam/nummer, maar er is vast wel een wazige bank die dat doet.

Mensen zullen nu veel te laat doorhebben dat het rekeningnummer niet klopt, zeker als je meerdere wazige rekeningen hebt.

[VisionMaster]

tweakerbee schreef op 11 november 2003 @ 00:30:
Het kan nog makkelijker: Vervang gewoon rek. nr. door je wazige Afrikaanse rekening.
Valt het bedrag in eerste instantie niet zo op.

Moet het wel even zo zijn dat er geen controle plaatsvindt op naam/nummer, maar er is vast wel een wazige bank die dat doet.

Mensen zullen nu veel te laat doorhebben dat het rekeningnummer niet klopt, zeker als je meerdere wazige rekeningen hebt.

Met een beetje beveilingmethode gebruik, mag ik hopen dat ze deze feitelijke gegevens meeversleutelen en dus dat de hele transactie versleuteld is.
Ik heb Internetbankieren van de Postbank en alles gaan over de SSL heen. Verder krijg ik een certificaat van de Postbank dit de server op echtheid kan verifieren. Helaas is mijn username, wachtwoord wel een invulvakje. Dit wordt versleuteld, maar ik vind deze methode eigenlijk niet veilig. Ik wil liever mezelf authenticeren bij de server aan mijn kant van de SSL verbinding.
Iedereen kan zich wel uitmaken als ikzelf.

[Schmoove]

Het systeem wat ABN-AMRO (en ook Rabobank) hanteren is vrij veilig.
De transacties zijn allemaal geencrypte en ook maar een beperkte tijd geldig.

Ik heb gehoord dat als je je eerste code intyped, dan die dan 5 minuten geldig is.... daarna wordt de code alweer gedropt. In deze 5 minuten zal de hacker dus een 128 bit (? volgens mij was het 128) moet en kraken met een bruteforce attack (aangezien de paswoorden niet voorzien zijn van enige structuur).
Dit gaat zelfs met de snelste computer niet. Misschien in de toekomst, maar dan zullen wel wel weer andere technieken hebben.

[Verwijderd]

Grappig dat zo veel mensen inderdaad zo enorm onderschatten hoe goed online banken in nederland wel niet beveiligd zijn en maar volledig aan Janoz' verhaal willen blijven voorbijgaan, terwijl hij het als een van de weinigen in deze topic inderdaad bij het juiste einde heeft. Encryptie van gegevens, encryptie van de stream en gebruik maken van challenge-response systemen op meerdere plaatsen. Knappe gast die dat ff kraakt

Okee, laten we het anders stellen. Als het echt zo makkelijk zou zijn als jullie denken, zou er dan in het verleden al niet enorm misbruik van gemaakt zijn
Als dat zo zou zijn, dan kunnen banken dat niet verdoezelen, simpelweg omdat het over geld gaat dat van klanten is en daarmee zou het onmiddelijk naar buiten toe komen.

[ Voor 12% gewijzigd door Verwijderd op 11-11-2003 01:52 ]

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 01:49:
Grappig dat zo veel mensen inderdaad zo enorm onderschatten hoe goed online banken in nederland wel niet beveiligd zijn en maar volledig aan Janoz' verhaal willen blijven voorbijgaan, terwijl hij het als een van de weinigen in deze topic inderdaad bij het juiste einde heeft. Encryptie van gegevens, encryptie van de stream en gebruik maken van challenge-response systemen op meerdere plaatsen. Knappe gast die dat ff kraakt

Okee, laten we het anders stellen. Als het echt zo makkelijk zou zijn als jullie denken, zou er dan in het verleden al niet enorm misbruik van gemaakt zijn
Als dat zo zou zijn, dan kunnen banken dat niet verdoezelen, simpelweg omdat het over geld gaat dat van klanten is en daarmee zou het onmiddelijk naar buiten toe komen.

Waar de meesten zich hier in vergissen is dat er gedacht wordt dat bij het man-in-the-middle principe de SSL-stream moet worden gekraakt, maar dat is niet zo!
Om mijn theorieen te staven heb ik het volgende geprobeerd:
1) Een applicatie gebouwd die probeert in te loggen op internet bankieren. (https://een.of.andere.bank.nl)
2) Deze applicatie heeft een invoervak waarin je de code kunt ingeven die je normaal dient in te geven op de inlogpagina van de bank. Deze code wordt 'onder water' simpelweg doorgegeven naar het desbetreffende invoer vak op de internetpagina aangezien er maar een invoervenster is, is deze vrij makkelijk te vinden). Daarna wordt automatisch ingelogd
3) De applicatie heeft een knop om een transactie te starten (geld overboeken tussen eigen rekeningen). De pagina werd inderdaad gewoon opgeroepen!

Ik ben niet verder gegaan en ik heb de code weer weggegooid want ik wil andere mensen niet in staat stellen om eventueel slechte dingen te doen met mijn ideeen. Maar dat het kan werken moge duidelijk zijn!

Kijk, SSL is allemaal veilig, daar ligt het probleem ook niet. Het internetbankieren is sowieso behoorlijk veilig want het moeilijkste is om de client te laten connecten aan the-man-in-the-middle. Bovendien ben je heel makkelijk traceerbaar als man-in-the-middle zijnde dus is het niet echt interessant om op deze manier geld in te zamelen.

[Verwijderd]

Schmoove schreef op 11 november 2003 @ 01:39:
Het systeem wat ABN-AMRO (en ook Rabobank) hanteren is vrij veilig.
De transacties zijn allemaal geencrypte en ook maar een beperkte tijd geldig.

Ik heb gehoord dat als je je eerste code intyped, dan die dan 5 minuten geldig is.... daarna wordt de code alweer gedropt. In deze 5 minuten zal de hacker dus een 128 bit (? volgens mij was het 128) moet en kraken met een bruteforce attack (aangezien de paswoorden niet voorzien zijn van enige structuur).
Dit gaat zelfs met de snelste computer niet. Misschien in de toekomst, maar dan zullen wel wel weer andere technieken hebben.

Wat je verkeerd begrijpt is het volgende: de paswoorden hebben inderdaad geen structuur, maar dat doet er niet toe, de code's worden ingevoerd door de klant, die hoef je niet te brute forcen!!
We zijn het er denk ik allemaal over eens dat ssl de enige bemoeijlijkende factor is in deze situatie, daar het challenge-responce systeem vanuit de klant (slachtoffer) word geauthentificeerd.

Problemen met SSL:

encryptie:

Wat er nodig is is een mogelijkheid voor het onderscheppen van packets van die SSL verbinding, de PACKETS zijn encrypted middels zowel symmetrische als asymmetrische encryptie.
Internet explorer maakt voor SSl gebruik van 128-bits SSL met MD5. Dit is dus een erg goede encryptie waar je behoorlijk wat rekenkracht voor nodig hebt.
Dit is aleen het geval met Internet explorer, vrijwel IEDERE andere browser gebruikt hiervoor een 40-bit RC4 sleutel, welke enkele jaren terug al omstreden was vanwege het hoge risico op misbruik.

data integriteit:

SSL kijkt of de data die verstuurd is overeenkomt met de data die de server ontvangt, dit is makkelijk te omzeilen door ip-nummer intact te laten en het eigen ipnummer te maskeren middels proxy. Verder is het van belang dat de packet zijn grootte behoud.

authenticatie:

De certificaten zijn waarschijnlijk nog het minst grote probleem, dit is in dit geval een éénzijdig systeem waarbij de bank zich wel authentificeerd, maar de klant niet aan de bank. Wat inhoud dat de klant aleen zal weten of hij daadwerkelijk is ingelogd op de server van de bank, en dat is het geval.
En zelfs in het geval dat eerder beschreven werd, met een mirror dan moet de klant in iedergeval op zijn hoede zijn, met de meeste browsers kun je malafide certificaten toch gewoon accepteren, en dat zal een onwetende gebruiker ook zonder moeite doen.

Verder wil ik benadrukken dat de rekenkracht voor de decryptie niet zo moeijlijk te verkijgen is, buiten het feit dat hackers (als ik ze zo mag noemen )vaak ubermachines hebben, hoef ik jullie toch niet uit te leggen hoe kevin mitnick aan zijn rekenkracht kwam voor dat "akkefietje"?! Das natuurlijk wel een ander tijdperk (toen wardialing nog stoer was), maar werd ook toen voor onmogelijk gehouden!! En geloof maar niet dat de ABN een tweede Shimomura in dienst heeft.

[VisionMaster]

Verwijderd schreef op 11 november 2003 @ 12:37:
[...]

authenticatie:

Hier zeg je precies wat ik al vertelde. Je bank is wel na te gaan op echtheid, maar een gebruiker is nog steeds niet op zijn identiteit te garanderen voor de bank. Ergo het kan een ander zijn.

[Janoz]

Verwijderd schreef op 11 november 2003 @ 10:27:
[...]

Waar de meesten zich hier in vergissen is dat er gedacht wordt dat bij het man-in-the-middle principe de SSL-stream moet worden gekraakt, maar dat is niet zo!
Om mijn theorieen te staven heb ik het volgende geprobeerd:
1) Een applicatie gebouwd die probeert in te loggen op internet bankieren. (https://een.of.andere.bank.nl)
2) Deze applicatie heeft een invoervak waarin je de code kunt ingeven die je normaal dient in te geven op de inlogpagina van de bank. Deze code wordt 'onder water' simpelweg doorgegeven naar het desbetreffende invoer vak op de internetpagina aangezien er maar een invoervenster is, is deze vrij makkelijk te vinden). Daarna wordt automatisch ingelogd
3) De applicatie heeft een knop om een transactie te starten (geld overboeken tussen eigen rekeningen). De pagina werd inderdaad gewoon opgeroepen!

Ik ben niet verder gegaan en ik heb de code weer weggegooid want ik wil andere mensen niet in staat stellen om eventueel slechte dingen te doen met mijn ideeen. Maar dat het kan werken moge duidelijk zijn!

Kijk, SSL is allemaal veilig, daar ligt het probleem ook niet. Het internetbankieren is sowieso behoorlijk veilig want het moeilijkste is om de client te laten connecten aan the-man-in-the-middle. Bovendien ben je heel makkelijk traceerbaar als man-in-the-middle zijnde dus is het niet echt interessant om op deze manier geld in te zamelen.

Jammer dat je op dat punt niet verder gegaan bent. Dan had je namelijk gezien waar het probleem zou liggen. Ik ben het helemaal met je eens dat je acties kunt toevoegen mbv een man in the middle attack. Een posting op GoT doen is bijvoorbeeld erg makkelijk op die manier.

Het doen van een transactie is echter meer dan een druk op een knop simuleren. Het toevoegen van een eigen transactie is in eigenlijk al niet te doen (densoods bouwt de bank in dat er minimaal x tijd moet zitten tussen het opsturen van een invul scherm en het terug krijgen van het resultaat met eventueel een chalenge response systeem erbij zodat het tussenvoegen van een request zonder dat de bank en/of de client het merkt onmogenlijk is)

Je zult ten eerste moeten herkennen dat er een invulscherm aan komt (door in de heen en weer gestuurde html te kijken) Het inloggen is een redelijk recht toe rechtaan traject waar telkens maar 1 (of 2) vervolg mogenlijkheden zijn. Zodra je op je overzichts pagina komt zijn er gelijk al veel meer mogenlijkheden. Om op het juiste moment de boel aan te kunnen passen zul je exact moeten weten waneer de gebruiker wat doet. Een transactie veranderen is meer dan een rekening nummer aanpassen. Het is detecteren waneer er een overmaking wordt opgestuurd en wat er daarna mee gebeurt (Ik kan bij een overmaking bijvoorbeeld kiezen of ik gelijk ga versturen of nog 1 infvul of een acceptgiro in ga vullen of wat dan ook). Waneer dit formulier wordt opgestuurt moet je de adres gegevens en het rekening nummer aanpassen (Rekening nummer met verkeerd adres wordt niet behandeld) Vervolgens komt er een bevestigings scherm waarin alles wordt opgesomt die je aan moet passen. Hier wordt weer een code ingevult waardoor de boel weer wordt verzonden en moet je misschien weer enkele dingen terug vervangen. Bij al die dingen moet je exact weten waar iets staat en waneer je dat zou moeten veranderen. Dit alles gebeurt in een dynamische pagina die zo is gemaakt dat het niet makkelijk zou moeten zijn om de content eruit te filteren. Het is geen got active topic list waarbij je met een leuke regexp zelf een lijstje met nieuws maakt voor je eigen frontpage.

Kortom: Je hebt helemaal gelijk dat het in theorie mogenlijk zou kunnen zijn mbv een man in the middle attack. Wat ik de hele tijd probeer te vertellen is dat het in de praktijk in de verste verte niet zo makkelijk is als jij doet vermoeden.

[Countess]

e-bankieren is veiliger als je creditkaart me geven aan de ober om te betalen.

net als met een creditkaart moet je je afschrijvingen controleren natuurlijk.
maarja dat moet je eigenlijk zowizo.
en valse cheques schrijven is makelijker and de bank hacken en geld overschrijven.

[Guru Evi]

Het probleem (of veiligheid) met SSL is dat er geen bit mag veranderd zijn. 1 bit veranderen maakt de hele sessie onbruikbaar.

Je apparaatje met je kaart, leest je kaart uit, en gaat samen met een paar computer-variabelen (ip-adres, hostname, tijd etc etc) de verbinding kaart-apparaat - pc beveiligen. Dan gaat je PC alles nog eens coderen en versturen.

Nu: de man-in-the-middle ben ik en ik ontvang die gecodeerde stream en allemaal. Ik kan mijn IP en hostname spoofen, dat gaat nog. Ik kan die gecodeerde stream doorsturen (proxyen) en opslaan (sniffen). Maareuh, ik kan totaal niets mee doen want ik heb de private key van de bank niet.

Als je een SSL stream wilt decoderen moet je de private & public keys van beide partijen hebben alsook de public key van het root-certificaat. Met de bank moet je nog es de private & public key hebben van dat apparaatje alsook de private & public key van de maker van het apparaatje.
Heb ik dat eenmaal allemaal gekraakt, zijn we al een paar dagen/maand verder en kan ik met de hele sessie niets meer doen behalve misschien zien wat hij heeft gedaan.

Private keys worden nooit verstuurd.
In het kort de werking van SSL: (persoon_1_data + hash van data) VERSLEUTEL (persoon_1_private key, persoon_2_public key) -----TRANSMIT----> (persoon_2_private key, persoon_1_public key) DESLEUTEL (data + hash data).
IF HASH DATA GEKREGEN = HASH VAN DATA GEGENEREERD dan is dat goed

[Verwijderd]

Die man in the middle attack werkt wel vast wel, maar je kan er niet 'zomaar een transactie tussenproppen'. Echter, als je een gebruiker zover krijgt op http://my.hacker.nl in te loggen in de plaats van https://my.bank.nl, dan kan je nog een ander trucje uithalen: Je laat een transactie zogenaamd mislukken. Je laat de gebruiker een foutmelding zien, terwijl ondertussen het geld wel doorgesluisd wordt naar een rekening.
Natuurlijk kan de gebruiker vervolgens in zijn afschriften wel zien wat er gebeurt is -- *behalve* als deze OOK door de man-in-the-middle interface worden bekeken. Die probleem wordt steeds groter, want in de toekomst zullen papieren afschriften verdwijnen vermoed ik.

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 10:27:


Kijk, SSL is allemaal veilig, daar ligt het probleem ook niet. Het internetbankieren is sowieso behoorlijk veilig want het moeilijkste is om de client te laten connecten aan the-man-in-the-middle. Bovendien ben je heel makkelijk traceerbaar als man-in-the-middle zijnde dus is het niet echt interessant om op deze manier geld in te zamelen.

De klant hoeft niet aan the man-in-the-middle te connecten! Het is bij de meeste van ons toch bekend hoe makkelijk is om een packetstream om te leiden? Daar hoeft de klant je niet bij te helpen hoor!

Verder is het zo dat je inderdaad nooit 100% onvindbaar kan zijn, maar ik kan je wel vertellen dat het behoorlijk makkelijk is om een lang traject van anonieme proxy's te gebruiken, buiten dat worden voor dit soort acties natuurlijk meestal ook nog een aantal zombies gebruikt (gehackte computers), waarvan de allerlaatste het uiteindelijke ip-nummer mee geeft, voor de politie gezien is het dus het eerste ip wat ze vinden, met daarna een hele reeks zombies en proxy's.

[Janoz]

Guru Evi schreef op 11 november 2003 @ 13:12:
Nu: de man-in-the-middle ben ik en ik ontvang die gecodeerde stream en allemaal. Ik kan mijn IP en hostname spoofen, dat gaat nog. Ik kan die gecodeerde stream doorsturen (proxyen) en opslaan (sniffen). Maareuh, ik kan totaal niets mee doen want ik heb de private key van de bank niet.

Je hoeft de SSL verbinding niet te 'proxy-en' Je zet gewoon normaal zoals elke browser dat ook zou doen een ssl verbinding met de bank op. Je hoeft niks te spoofen of aan de headers te veranderen of wat dan ook. De bank denkt dat de hack pc de client is en de client denkt dat de hack pc de bank is. Hier kan SSL niks aan doen behalve dat het certificaat dat de hacker uitgeeft niet hetzelfde certificaat is als de bank. Dit kan er voor zorgen dat er een waarschuwing komt met untrusted oid of een certificaat met een andere naam dan de bank. Alleen kennen we het doorklik gedrag van de gemiddelde gebruiker natuurlijk

[Verwijderd]

Janoz schreef op 11 november 2003 @ 13:35:
[...]

Je hoeft de SSL verbinding niet te 'proxy-en' Je zet gewoon normaal zoals elke browser dat ook zou doen een ssl verbinding met de bank op. Je hoeft niks te spoofen of aan de headers te veranderen of wat dan ook. De bank denkt dat de hack pc de client is en de client denkt dat de hack pc de bank is. Hier kan SSL niks aan doen behalve dat het certificaat dat de hacker uitgeeft niet hetzelfde certificaat is als de bank. Dit kan er voor zorgen dat er een waarschuwing komt met untrusted oid of een certificaat met een andere naam dan de bank. Alleen kennen we het doorklik gedrag van de gemiddelde gebruiker natuurlijk

Inderdaad, het enige probleem zijn inderdaad de hashes, maar zie hier zoals eerder beschreven,maar met probleemstelling:

Hacker(C) kan zich voor doen als afzender (A) en zijn eigen openbare sleutel opsturen aan de bank (B ). Indien C zich daarnaast ten opzichte van A voordoet als B is er sprake van een man-in-the-middle situatie.

C kan dan uit naam van A berichten naar B sturen en uit naam van B berichten aan A. Hierbij speelt een rol of A en B een vaste relatie met elkaar hebben en dus bekenden van elkaar zijn of niet. In het geval van een vaste relatie is de kans op het ontstaan van een man-in-the-middle situatie minder groot, omdat A en B bekenden van elkaar zijn en dus al in het bezit zijn van elkaars openbare sleutel.

Om te kijken van wie de sleutel daadwerkelijk is zet je TTP in, die kijkt aleen of de sleutel hoort bij de gebruiker die heeft ondertekend. Dit geeft echter geen zekerheid omtrent het feit dat wanneer de betreffende elektronische handtekening 'gezet' wordt dit ook daadwerkelijk door de houder van de handtekening en niet door een onbevoegde gedaan wordt. Om dit te garanderen zou je moeten gaan denken aan biometrie.

[Janoz]

Je redenering zou alleen opgaan waneer er slechts 1 computer was waarop je mocht internetbankieren. Dit is niet waar. Ik kan vanaf elke computer internetbankieren. De bank weet niet of ik plots in een internet cafe zit of dat ik bij mijn ouders ff mijn saldo check of dat er toch een hacker is die namens mij inlogt.

[Verwijderd]

Janoz schreef op 11 november 2003 @ 14:19:
Je redenering zou alleen opgaan waneer er slechts 1 computer was waarop je mocht internetbankieren. Dit is niet waar. Ik kan vanaf elke computer internetbankieren. De bank weet niet of ik plots in een internet cafe zit of dat ik bij mijn ouders ff mijn saldo check of dat er toch een hacker is die namens mij inlogt.

Nee hoor, je begrijpt me verkeerd,ik onderkende jouw stelling,maar waar jij het hier over hebt gaat voorbij aan het SSL verhaal, ik reageerde op dit verhaal:

Guru Evi schreef op 11 november 2003 @ 13:12:
Het probleem (of veiligheid) met SSL is dat er geen bit mag veranderd zijn. 1 bit veranderen maakt de hele sessie onbruikbaar.

blablabla...

Als je een SSL stream wilt decoderen moet je de private & public keys van beide partijen hebben alsook de public key van het root-certificaat. Met de bank moet je nog es de private & public key hebben van dat apparaatje alsook de private & public key van de maker van het apparaatje.
Heb ik dat eenmaal allemaal gekraakt, zijn we al een paar dagen/maand verder en kan ik met de hele sessie niets meer doen behalve misschien zien wat hij heeft gedaan.

Private keys worden nooit verstuurd.
In het kort de werking van SSL: (persoon_1_data + hash van data) VERSLEUTEL (persoon_1_private key, persoon_2_public key) -----TRANSMIT----> (persoon_2_private key, persoon_1_public key) DESLEUTEL (data + hash data).
IF HASH DATA GEKREGEN = HASH VAN DATA GEGENEREERD dan is dat goed

Ik heb middels 2 posts aangegeven wat de werking is van SSL en heb het gehad over de hashes. en met mijn vorige reactie ,op jou, onderstreepte ik nog even dat de hashes niet persé een probleem opleveren.

[Verwijderd]

En wat als we de 'man in the middle' er eens tussenuit laten.

Iemand schrijft een virus dat controleert of er een internetbankierprogramma op de geïnfecteerde computer aanwezig is. Zo niet dan vernietigt hij zichzelf.
Anders wacht het virus tot het internetbankierprogramma wordt opgestart. Is dat het geval dan wacht het tot dat de naam UPC (slechts als voorbeeld! Elk bedrijf dat miljoenen transacties genereert, voldoet) wordt ingegeven. Het virus vangt het daarna intoetste rekeningnummer af en verandert dat in het rekeningnummer van 'het Utrechts Politiek Collectief' (alleen niet op het scherm van de gebruiker). De bank en de klant geven elkaar akkoord en de transactie is een feit. De klant ziet op zijn overzicht dat de naam en bedrag kloppen.

Elke avond telebankiert de gelukkige virusschrijver het aldus op zijn rekening overgemaakte bedrag naar het buitenland en verder...

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 15:18:
En wat als we de 'man in the middle' er eens tussenuit laten.

Iemand schrijft een virus dat controleert of er een internetbankierprogramma op de geïnfecteerde computer aanwezig is. Zo niet dan vernietigt hij zichzelf.
Anders wacht het virus tot het internetbankierprogramma wordt opgestart. Is dat het geval dan wacht het tot dat de naam UPC (slechts als voorbeeld! Elk bedrijf dat miljoenen transacties genereert, voldoet) wordt ingegeven. Het virus vangt het daarna intoetste rekeningnummer af en verandert dat in het rekeningnummer van 'het Utrechts Politiek Collectief' (alleen niet op het scherm van de gebruiker). De bank en de klant geven elkaar akkoord en de transactie is een feit. De klant ziet op zijn overzicht dat de naam en bedrag kloppen.

Elke avond telebankiert de gelukkige virusschrijver het aldus op zijn rekening overgemaakte bedrag naar het buitenland en verder...

Slaap verder gozer!!! Welk "programma" gebruik jij om te internetbankieren?
whehehe, internet explorer ja, of een andere browser, je snapt duidelijk de ballen niet van het systeem, laat staan de discussie die gaande is!!!

[Verwijderd]

Janoz schreef op 11 november 2003 @ 12:54:
Jammer dat je op dat punt niet verder gegaan bent. Dan had je namelijk gezien waar het probleem zou liggen. Ik ben het helemaal met je eens dat je acties kunt toevoegen mbv een man in the middle attack. Een posting op GoT doen is bijvoorbeeld erg makkelijk op die manier.

Het doen van een transactie is echter meer dan een druk op een knop simuleren. Het toevoegen van een eigen transactie is in eigenlijk al niet te doen (densoods bouwt de bank in dat er minimaal x tijd moet zitten tussen het opsturen van een invul scherm en het terug krijgen van het resultaat met eventueel een chalenge response systeem erbij zodat het tussenvoegen van een request zonder dat de bank en/of de client het merkt onmogenlijk is)

Je zult ten eerste moeten herkennen dat er een invulscherm aan komt (door in de heen en weer gestuurde html te kijken) Het inloggen is een redelijk recht toe rechtaan traject waar telkens maar 1 (of 2) vervolg mogenlijkheden zijn. Zodra je op je overzichts pagina komt zijn er gelijk al veel meer mogenlijkheden. Om op het juiste moment de boel aan te kunnen passen zul je exact moeten weten waneer de gebruiker wat doet. Een transactie veranderen is meer dan een rekening nummer aanpassen. Het is detecteren waneer er een overmaking wordt opgestuurd en wat er daarna mee gebeurt (Ik kan bij een overmaking bijvoorbeeld kiezen of ik gelijk ga versturen of nog 1 infvul of een acceptgiro in ga vullen of wat dan ook). Waneer dit formulier wordt opgestuurt moet je de adres gegevens en het rekening nummer aanpassen (Rekening nummer met verkeerd adres wordt niet behandeld) Vervolgens komt er een bevestigings scherm waarin alles wordt opgesomt die je aan moet passen. Hier wordt weer een code ingevult waardoor de boel weer wordt verzonden en moet je misschien weer enkele dingen terug vervangen. Bij al die dingen moet je exact weten waar iets staat en waneer je dat zou moeten veranderen. Dit alles gebeurt in een dynamische pagina die zo is gemaakt dat het niet makkelijk zou moeten zijn om de content eruit te filteren. Het is geen got active topic list waarbij je met een leuke regexp zelf een lijstje met nieuws maakt voor je eigen frontpage.

Kortom: Je hebt helemaal gelijk dat het in theorie mogenlijk zou kunnen zijn mbv een man in the middle attack. Wat ik de hele tijd probeer te vertellen is dat het in de praktijk in de verste verte niet zo makkelijk is als jij doet vermoeden.

Gelukkig is het ook niet zo makkelijk en ik ben het ook helemaal met dit verhaal eens. Wat ik alleen probeer(de) duidelijk te maken is dat het op deze manier theoretisch mogelijk is en om te bewijzen dat je de SSL niet hoeft te ontrafelen/ontsleutelen heb ik even een stukje van het bankieren proberen te automatiseren met een eigen applicatie, en dat lukte.

[Verwijderd]

Guru Evi schreef op 11 november 2003 @ 13:12:
Het probleem (of veiligheid) met SSL is dat er geen bit mag veranderd zijn. 1 bit veranderen maakt de hele sessie onbruikbaar.

Je apparaatje met je kaart, leest je kaart uit, en gaat samen met een paar computer-variabelen (ip-adres, hostname, tijd etc etc) de verbinding kaart-apparaat - pc beveiligen. Dan gaat je PC alles nog eens coderen en versturen.

Nu: de man-in-the-middle ben ik en ik ontvang die gecodeerde stream en allemaal. Ik kan mijn IP en hostname spoofen, dat gaat nog. Ik kan die gecodeerde stream doorsturen (proxyen) en opslaan (sniffen). Maareuh, ik kan totaal niets mee doen want ik heb de private key van de bank niet.

Als je een SSL stream wilt decoderen moet je de private & public keys van beide partijen hebben alsook de public key van het root-certificaat. Met de bank moet je nog es de private & public key hebben van dat apparaatje alsook de private & public key van de maker van het apparaatje.
Heb ik dat eenmaal allemaal gekraakt, zijn we al een paar dagen/maand verder en kan ik met de hele sessie niets meer doen behalve misschien zien wat hij heeft gedaan.

Private keys worden nooit verstuurd.
In het kort de werking van SSL: (persoon_1_data + hash van data) VERSLEUTEL (persoon_1_private key, persoon_2_public key) -----TRANSMIT----> (persoon_2_private key, persoon_1_public key) DESLEUTEL (data + hash data).
IF HASH DATA GEKREGEN = HASH VAN DATA GEGENEREERD dan is dat goed

En nog steeds snap je niet wat er met de man-in-the-middle wordt bedoeld.
Even schematisch:

code:

          HTTP(s)                          HTTPS
client <-----------> man-in-the-middle <------------> bank

Uitleg:
De client maakt verbinding met man-in-the-middle; de client denkt echter verbinding te hebben gemaakt met de bank. De man-in-the-middle is dus een proxy.
De man-in-the-middle maakt een connectie met de bank en krijgt een onversleutelde HTML pagina van de bank, de pagina is wel via SSL door de bank aan de man-in-the-middle verzonden, en stuurt deze door naar de client.
De client vult zijn gegevens in en stuurt deze dus naar de man-in-the-middle en die geeft deze info dus weer door aan de bank waarop de man-in-the-middle weer een onversleutelde HTML-pagina via SSL terugkrijgt. Deze kan weer naar de client gestuurd worden.
Tot nu toe was het peanuts want zodra de klant overboekingen wil gaan maken willen wij daar als man-in-the-middle van mee gaan profiteren en dus moeten we transacties gaan simuleren maar wel wegfilteren voor de client; en dat is precies de moeilijkheid, maar niet onmogelijk!
Snap je het nu een beetje?

[Verwijderd]

Het zou zo in theorie idd mogelijk zijn.
Het enige wat je dus kunt doen is vrolijk kijen wat iemand anders met zn rekeningen aan het doen is, je hebt er geen fluit aan.

Maar die challenge die je krijgt is a.d.v. de transactie gegevens berekend.
Als je dus als m.i.t.m die transactie gaat veranderen, dan klopt de response niet meer.
Of denk ik nu te simpel ?

[ Voor 31% gewijzigd door Verwijderd op 11-11-2003 18:13 ]

[Guru Evi]

ik snap het wel, maar het probleem is nog steeds dat je kaartlezer het 1: codeert, 2: niet aanvaardt als je naar een niet-https pagina gaat (toch in belgie)

[Verwijderd]

Guru Evi schreef op 11 november 2003 @ 18:44:
ik snap het wel, maar het probleem is nog steeds dat je kaartlezer het 1: codeert, 2: niet aanvaardt als je naar een niet-https pagina gaat (toch in belgie)

Je kaartlezer staat hier hlemaal los van! In nederland heb je een draadloos kaartlezertje welke op geen enkele manier "verbinding" heeft, waneer je inlogd krijg je een code, die code is gekoppeld aan een responce van de kaartlezer, en met die responce kun je daadwerkelijk inloggen.
Je kaartlezer codeerd NIETS en heeft ook niets te maken met het aanvaarden van https-pagina's!!!!

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 18:12:
Het zou zo in theorie idd mogelijk zijn.
Het enige wat je dus kunt doen is vrolijk kijen wat iemand anders met zn rekeningen aan het doen is, je hebt er geen fluit aan.

Maar die challenge die je krijgt is a.d.v. de transactie gegevens berekend.
Als je dus als m.i.t.m die transactie gaat veranderen, dan klopt de response niet meer.
Of denk ik nu te simpel ?

Dit gebeurd allemaal voor het inloggen, wanneer je bent ingelogd, en dus "vrolijk kan kijken", kun je zonder enige moeitte gewoon overboeken, je hoefd niet nogmaals aan de challenge-responce te voldoen!

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 18:53:
[...]


Dit gebeurd allemaal voor het inloggen, wanneer je bent ingelogd, en dus "vrolijk kan kijken", kun je zonder enige moeitte gewoon overboeken, je hoefd niet nogmaals aan de challenge-responce te voldoen!

Bij de abn-amro wel hoor, voor elke transactie krijg je een challenge.
Bij de rabobank trouwens ook

[ Voor 6% gewijzigd door Verwijderd op 11-11-2003 19:07 ]

[Verwijderd]

Verwijderd schreef op 11 november 2003 @ 19:03:
[...]

Bij de abn-amro wel hoor, voor elke transactie krijg je een challenge.
Bij de rabobank trouwens ook

Dat is ook nogal logisch als je het mij vraagt. Sterker nog ik zou het niet meer dan normaal vinden dat daar dus het type overboeking, tegenrekeningnummer en bedrag etc allemaal in verwerkt zitten, waardoor het dus simpelweg onmogelijk wordt om dat soort waardes middels een man in the middel attack te veranderen.

Dus ook al onderschep je vanalles, verander je wat waardes en stuur je ze door, dan nog gaat het fout.