Kan internetbankieren veilig zijn?

[MasterMaceMichu]

En jullie denken dat ze bij de banken niet weten wat een man-in-the-middle is?
Laat me dit zeggen: er is weldegelijk een MIM controle en die werkt heel goed.

[Verwijderd]

Mjah sommige lieden denken hier gewoon iets te simpel over dingen die redelijk complex in elkaar zitten

[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

WHEHEHE, TRUE!! TRUE!!, zat met me stonede harses weer eens niet bij de les.

[eghie]

Man in the middle progjes/scriptjes kun je ook heel makkelijk afweren als bank zijnde. Elke keer als je inlogt even een getal invullen dat als plaatje op de site staat en dat plaatje ook een beetje onleesbaar maken zodat het niet herkent kan worden door het scriptje, zo kan alleen een persoon als man in the middle gaan spelen en dan heb je iig geen last meer van scriptjes.

[weerdo]

Verwijderd schreef op 11 november 2003 @ 19:29:
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.

Degeen die in staat is om dit alles te bouwen, is ook in staat om enkele transactie-regels weg te laten; zeker als de crimineel (ik noem degeen die dit gaat doen maar zo) precies weet welke transactie-regels hijzelf toevoegt.

De gebruiker tekent over een waarde, een hash; maar hoe die hash opgebouwd wordt is voor de gebruiker onbekend..

[ Voor 8% gewijzigd door weerdo op 11-11-2003 22:13 ]

[Verwijderd]

Het kan wel volgens mij. Automatiseren zal echter lastig worden.

Ik ben X en ik ga Y oplichten.

- X laat Y inloggen op mijn site. Met de inloggegevens die X krijgt, gaat X inloggen bij Y z'n bank.
- Y krijgt een melding van X dat de login succesvol was. Erachter zit een (qua uiterlijk) exacte kopie van het telebankiersysteem van Y.
- Y begint transacties in te voeren. De inhoud daarvan is onbelangrijk.
- Intussen maakt X een transactie bij Y z'n bank en wil die uitvoeren. Hij krijgt de controlecode voor zijn edentifier.
- Y is klaar met zijn transacties en wacht op de controlecode van de bank.
- Y krijgt de code, maar in feite is dat de code die X kreeg voor het doorvoeren van zijn transactie.
- Y voert de code in op z'n edentifier en voert de code die de edentifier krijgt weer in.
- X voert die code weer in bij Y z'n bank en de transactie is voltooid.

Lijkt mij waterdicht. Alleen lastig te automatiseren. Wil je echter maar 1 persoon oplichten is het makkelijk Niet gepakt worden is natuurlijk een ander verhaal

Overigens zul je er wel een onderhoudsverhaal aan vast moeten knopen. "Wegens onderhoud kan het zijn dat uw rekeningsaldo en transactiegegevens tijdelijk niet beschikbaar zijn. Onze excuses voor de overlast"

[ Voor 11% gewijzigd door Verwijderd op 12-11-2003 00:49 ]

[Janoz]

eghie schreef op 11 november 2003 @ 20:54:
Man in the middle progjes/scriptjes kun je ook heel makkelijk afweren als bank zijnde. Elke keer als je inlogt even een getal invullen dat als plaatje op de site staat en dat plaatje ook een beetje onleesbaar maken zodat het niet herkent kan worden door het scriptje, zo kan alleen een persoon als man in the middle gaan spelen en dan heb je iig geen last meer van scriptjes.

??? Ik zie niet in wat dit makkelijker zou maken. Het scriptje stuurt gewoon de complete html pagina door en krijgt het antwoord terug van de client. We praten hier niet over een Bot, maar over een proxie. Alles info die wordt gevraagt kan de proxie gewoon aan de eigenaar vragen omdat de proxie ook aan die kant een verbinding heeft. De moeilijkheid komt pas waneer je daarin dingen aan wilt passen.

[Janoz]

Verwijderd schreef op 12 november 2003 @ 00:38:
Het kan wel volgens mij. Automatiseren zal echter lastig worden.

Ik ben X en ik ga Y oplichten.

- X laat Y inloggen op mijn site. Met de inloggegevens die X krijgt, gaat X inloggen bij Y z'n bank.
- Y krijgt een melding van X dat de login succesvol was. Erachter zit een (qua uiterlijk) exacte kopie van het telebankiersysteem van Y.
- Y begint transacties in te voeren. De inhoud daarvan is onbelangrijk.
- Intussen maakt X een transactie bij Y z'n bank en wil die uitvoeren. Hij krijgt de controlecode voor zijn edentifier.
- Y is klaar met zijn transacties en wacht op de controlecode van de bank.
- Y krijgt de code, maar in feite is dat de code die X kreeg voor het doorvoeren van zijn transactie.
- Y voert de code in op z'n edentifier en voert de code die de edentifier krijgt weer in.
- X voert die code weer in bij Y z'n bank en de transactie is voltooid.

Lijkt mij waterdicht. Alleen lastig te automatiseren. Wil je echter maar 1 persoon oplichten is het makkelijk Niet gepakt worden is natuurlijk een ander verhaal

Overigens zul je er wel een onderhoudsverhaal aan vast moeten knopen. "Wegens onderhoud kan het zijn dat uw rekeningsaldo en transactiegegevens tijdelijk niet beschikbaar zijn. Onze excuses voor de overlast"

Dit is nu precies het systeem waar hvdberg en ik het al pagina's terug over hebben en waarvan ik probeer duidelijk te maken dat het lang zo makkelijk niet is als dat je nu suggereert.

[py.mosjuh]

bij internet bankieren gewoon altijd ff checken of je certificaat path goed is.. dubbelklik op het "slotje" onderin de IE browser en als er iets als

code:

VeriSign/RSA Secure Server CA
  bankieren.rabobank.nl

staat zit je goed, staan er andere servers tussen dan moet je je afvragen of het wel slim is wat je aan het doen bent..

[Verwijderd]

Janoz schreef op 12 november 2003 @ 09:56:
Dit is nu precies het systeem waar hvdberg en ik het al pagina's terug over hebben en waarvan ik probeer duidelijk te maken dat het lang zo makkelijk niet is als dat je nu suggereert.

Nee, jullie spreken voortdurend over het aanpassen van transacties van de klant. Hetzij via andere rekeningnummers, hetzij via extra transacties die onzichtbaar zijn voor de klant. Dat is helemaal niet nodig.

Je laat de klant denken dat hij zijn transactie uitvoert, maar in feite wordt er maar 1 transactie uitgevoerd. De betaling die de "hacker" er inzet. Daarvoor heb je 2 keer een code nodig. 1 keer om in te loggen en 1, die wordt afgeleid van een code van de bank, om transacties te verzenden. De eerste code voert de opgelichte gewoon in. De tweede ook, nadat hij de code die de hacker van de bank heeft gekregen heeft doorgekregen. De hacker krijgt 2 codes. Hij kan de transactie uitvoeren.

Lastig is het dus helemaal niet. Als ik jouw telefonisch die 2 nummertjes doorbel kun je namens mij een transactie uitvoeren. Dit is precies hetzelfde, alleen krijg je ze via internet binnen. Het lastige punt: automatiseren. Ik vraag me alleen af of je dat wel wilt. 10 keer €10.000 overboeken en je hebt een ton op je rekening. Doe het 100 keer en je bent miljonair. Daarvoor wil ik best zelf wat cijfertjes intikken.

[Verwijderd]

eghie schreef op 11 november 2003 @ 20:54:
Man in the middle progjes/scriptjes kun je ook heel makkelijk afweren als bank zijnde. Elke keer als je inlogt even een getal invullen dat als plaatje op de site staat en dat plaatje ook een beetje onleesbaar maken zodat het niet herkent kan worden door het scriptje, zo kan alleen een persoon als man in the middle gaan spelen en dan heb je iig geen last meer van scriptjes.

Dat maakt nog steeds geen ene fluit uit, en dit bewijst maar weer dat bijna niemand het principe snapt, en nee ik denk niet te simpel, de meesten denken gewoon te moeilijk Je kunt immers dat plaatje gewoon doorsturen als man-in-the-middle zijnde net zoals alle andere codes, die worden dan door de client ingevuld en hoef je als man-in-the-middle niks zelf te verzinnen.

[it0]

Internet bankieren is gewoon safe, zelfs als er alleen ssl gebruikt zou worden dan zou ik me niet te veel zorgen maken. Dan blijven er nog 2 zwakke plekken over.

1 De professionele gemanagede server van de bank.
2 De gare windows bak van de klant

En daar maak ik me veel meer zorgen over, beide punten wel te verstaan.

[Danster]

Verwijderd schreef op 12 november 2003 @ 10:29:
[...]
Lastig is het dus helemaal niet. Als ik jouw telefonisch die 2 nummertjes doorbel kun je namens mij een transactie uitvoeren. .

Eh nee dit kan niet. Je krijgt nl een andere challenge dan degene die je belt.

[Verwijderd]

Danster schreef op 12 november 2003 @ 10:37:
Eh nee dit kan niet. Je krijgt nl een andere challenge dan degene die je belt.

Nee. Want de challenge die ik krijg geef ik door. Via mijn nep telebankiersysteem kun je betalingen uitvoeren. Om ze te verzenden geeft mijn systeem een challenge. Welke challenge? Juist ja, de challenge die ik zelf nodig heb om mijn illegale transactie door te voeren.

[Danster]

Verwijderd schreef op 12 november 2003 @ 10:40:
[...]
Nee. Want de challenge die ik krijg geef ik door. Via mijn nep telebankiersysteem kun je betalingen uitvoeren. Om ze te verzenden geeft mijn systeem een challenge. Welke challenge? Juist ja, de challenge die ik zelf nodig heb om mijn illegale transactie door te voeren.

Dus je wil de rekening van, je kennis noemen we hem maar even, plunderen met zijn medeweten?

[Verwijderd]

py.mosjuh schreef op 12 november 2003 @ 10:09:
bij internet bankieren gewoon altijd ff checken of je certificaat path goed is.. dubbelklik op het "slotje" onderin de IE browser en als er iets als

code:

VeriSign/RSA Secure Server CA
  bankieren.rabobank.nl

staat zit je goed, staan er andere servers tussen dan moet je je afvragen of het wel slim is wat je aan het doen bent..

Hoeveel mensen denk je dat dat daadwerkelijk doen? Ik schat in niet zoveel aangezien er bijv. bi de rabobank het volgende staat:
Controleer of het adres in de adresbalk begint met https://bankieren.rabobank.nl/
Als man-in-the-middle zijnde kun je je proxy toch zo instellen dat jij gewoon https://bankieren.rabobank.nl/ staat. Maar het principe staat en valt natuurlijk met de oplettendheid van de 'argeloze' client.

[Verwijderd]

Verwijderd schreef op 12 november 2003 @ 10:29:
Nee, jullie spreken voortdurend over het aanpassen van transacties van de klant. Hetzij via andere rekeningnummers, hetzij via extra transacties die onzichtbaar zijn voor de klant. Dat is helemaal niet nodig.

Ik denk zelf dat het de enigste manieren zijn om het te laten lukken.

Je laat de klant denken dat hij zijn transactie uitvoert, maar in feite wordt er maar 1 transactie uitgevoerd. De betaling die de "hacker" er inzet. Daarvoor heb je 2 keer een code nodig. 1 keer om in te loggen en 1, die wordt afgeleid van een code van de bank, om transacties te verzenden. De eerste code voert de opgelichte gewoon in. De tweede ook, nadat hij de code die de hacker van de bank heeft gekregen heeft doorgekregen. De hacker krijgt 2 codes. Hij kan de transactie uitvoeren.

Ok, so far heb je dus 1 verborgen transactie maar je moet de klant laten denken dat hij al z'n transacties uitvoert. Bij het laatste scherm, voor het uitvoeren van de transactie moet je 2 codes invoeren (los van inloggen). Op datzelfde scherm staan de transacties en daar zul je dus de transacties van de klant moeten tonen i.p.v. jouw ene transactie. Probleem hierbij is dat je waarschijnlijk heel wat intelligentie in je hacker-app moet bouwen om de transacties te vergaren zodat de klant denkt dat zijn transacties goed zijn over gekomen.

Lastig is het dus helemaal niet. Als ik jouw telefonisch die 2 nummertjes doorbel kun je namens mij een transactie uitvoeren. Dit is precies hetzelfde, alleen krijg je ze via internet binnen. Het lastige punt: automatiseren. Ik vraag me alleen af of je dat wel wilt. 10 keer €10.000 overboeken en je hebt een ton op je rekening. Doe het 100 keer en je bent miljonair. Daarvoor wil ik best zelf wat cijfertjes intikken.

Als je gaat doorbellen dan is er waarschijnlijk een tweede in connectie met de bank en waarschijnlijk zal dat afgeschermd zijn aangezien het me niet gebruikelijk lijkt dat je vanaf twee verschillende machines tegelijk transacties uitvoert bij de bank. Daarnaast zit je dan nog met het tijdsverschil, die codes zijn maar beperkt 'houdbaar' en alleen op bepaalde transacties van toepassing.

[py.mosjuh]

Verwijderd schreef op 12 november 2003 @ 10:42:
[...]

Hoeveel mensen denk je dat dat daadwerkelijk doen? Ik schat in niet zoveel aangezien er bijv. bi de rabobank het volgende staat:
Controleer of het adres in de adresbalk begint met https://bankieren.rabobank.nl/
Als man-in-the-middle zijnde kun je je proxy toch zo instellen dat jij gewoon https://bankieren.rabobank.nl/ staat. Maar het principe staat en valt natuurlijk met de oplettendheid van de 'argeloze' client.

dat bedoel ik: internet bankieren is gewoon safe, zoals al vaker is gezegd. zolang je gewoon je ogen open houdt bij wat je met je geld doet gaat het gewoon goed..

[Verwijderd]

Onderstaand een schema hoe je de boel kunt oplichten.



Je begint bij klant logged in op nep systeem. De correcte login voor de gebruiker gaat nu naar mij. Hij komt dan in een nepsysteem terecht. Plaats er een opmerking dat wegens onderhoud de transactiegeschiedenis en rekeningsaldo's niet aanwezig zijn, maar dat transacties wel kunnen worden uitgevoerd. Hij begint z'n transacties aan te maken. Jij logged inmiddels in met de klant zijn code bij de bank en maakt ook een transactie naar een rekening van jou. De bankt geeft je een challenge.

De klant is klaar met het aanmaken van transacties en wil ze verzenden. Je geeft hem de challenge die je zelf van de echte bank hebt gekregen. De klant voert de challenge in op z'n edentifier, krijgt een returncode en voert die weer in. Hij krijgt een bericht dat z'n transacties worden verzonden. Jij hebt de returncode en voert die in bij het echte systeem. De transactie wordt uitgevoerd.

[Danster]

leuk linkje

http://support.microsoft.com/default.aspx?kbid=257587

[esf]

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

En hoe wil je de SSL verbinding omzeilen? Zonder SSL verbinding zou dit kunnen werken, met wordt het een stuk lastiger

[Verwijderd]

esf schreef op 12 november 2003 @ 11:27:
En hoe wil je de SSL verbinding omzeilen? Zonder SSL verbinding zou dit kunnen werken, met wordt het een stuk lastiger

Die wil ik niet omzeilen.

Ik krijg de echte logincode van de klant via mijn nepsysteem. Daarmee log ik gewoon zelf in bij zijn bank. Ik maak een transactie aan, wil die versturen, maar krijg een challenge die je normaal op je edentifier invoert, zodat je een returncode krijgt. Omdat ik zijn edentifier niet heb geef ik op mijn nepsysteem de challenge die ik zelf heb gekregen van de echte bank. De klant voert dat in op zijn edentifier. Krijgt een code en voert die in. Dat is mijn returncode voor de challenge die de bank mij gaf. Ik typ die code gewoon in. Klik op verzenden en de transacties worden verwerkt.

Ik kraak niks bij de bank. Ik ontfrutsel gewoon de codes van de klant

[Janoz]

diddel, lees even het hele topic en vooral de discussie van hvdberg en mij. Datgene dat jij hebt getekend waren wij al lang achter, maar we zijn er ook al uit waarom het practisch onhaalbaar is.

[Verwijderd]

Janoz schreef op 12 november 2003 @ 11:34:
diddel, lees even het hele topic en vooral de discussie van hvdberg en mij. Datgene dat jij hebt getekend waren wij al lang achter, maar we zijn er ook al uit waarom het practisch onhaalbaar is.

Nee. Ik wil je zelf aanraden om te lezen. Ik heb het topic wel gelezen, nu zelfs voor de tweede keer en blijf bij mijn standpunt.

Waar jij en hvdbergde mist in gaan is dat jullie de transacties van de klant willen gaan uitvoeren. Waarom zou je? Je bent een oplichter, wat maakt het jou nou uit of de transacties van de klant nou doorgaan of niet. Laat de klant op je nepsysteem maar zoveel transacties aanmaken als hij wil. Hij krijgt ze mooi in een lijstje te zien, etc. Vervolgens wil hij ze "verzenden". De transacties van de klant wordt niks mee gedaan. Er wordt gevraagd om een challenge. Dat is de challenge die ik nodig heb bij zijn bank voor mijn transactie naar mijn rekening. Of hij nu 20, 100 of 500 transacties heeft ingevoerd. Die challenge is bij mijn nepsysteem altijd gelijk. Zijn transacties worden namelijk niet uitgevoerd.

Het gaat je om 2 dingen. De logincode en de returncode van de challenge. Over de eerste zijn we het eens dat je die makkelijk krijgt. De returncode krijg je nadat de klant zijn neptransactie heeft verzonden.

[Janoz]

Verwijderd schreef op 12 november 2003 @ 11:53:
[...]
Nee. Ik wil je zelf aanraden om te lezen. Ik heb het topic wel gelezen, nu zelfs voor de tweede keer en blijf bij mijn standpunt.

Waar jij en hvdbergde mist in gaan is dat jullie de transacties van de klant willen gaan uitvoeren. Waarom zou je? Je bent een oplichter, wat maakt het jou nou uit of de transacties van de klant nou doorgaan of niet. Laat de klant op je nepsysteem maar zoveel transacties aanmaken als hij wil. Hij krijgt ze mooi in een lijstje te zien, etc. Vervolgens wil hij ze "verzenden". De transacties van de klant wordt niks mee gedaan. Er wordt gevraagd om een challenge. Dat is de challenge die ik nodig heb bij zijn bank voor mijn transactie naar mijn rekening. Of hij nu 20, 100 of 500 transacties heeft ingevoerd. Die challenge is bij mijn nepsysteem altijd gelijk. Zijn transacties worden namelijk niet uitgevoerd.

Het gaat je om 2 dingen. De logincode en de returncode van de challenge. Over de eerste zijn we het eens dat je die makkelijk krijgt. De returncode krijg je nadat de klant zijn neptransactie heeft verzonden.

Dan zul je dus de complete bank applicatie na moeten bouwen. Vervolgens zul je ergens moeten detecteren dat de transacties uitgevoerd dienen te worden om je eigen transactie door te voeren. Wat voor challenge je krijgt is echt helemaal het probleem niet. Het detecteren waneer je het krijgt en wat je er mee moet doen is het wel. Denk hierbij aan time outs die optreden en onlogische stappen door de site. Formulieren die kunnen wijzigen die ingevuld moeten worden, maar ook aangevraagd moeten worden.

Het is echt niet zo makkelijk.

[Verwijderd]

Janoz schreef op 12 november 2003 @ 12:14:
Dan zul je dus de complete bank applicatie na moeten bouwen.

Klopt. Alleen zeg je dat er onderhoud is, zodat bepaalde functies niet toegankelijk zijn. Uiteraard zijn dit alle functies waar gebruikersdata inzit, want die weet je niet (transactiegeschiedenis, rekeningsaldo's, adresboeken, etc).

Vervolgens zul je ergens moeten detecteren dat de transacties uitgevoerd dienen te worden om je eigen transactie door te voeren. Wat voor challenge je krijgt is echt helemaal het probleem niet. Het detecteren waneer je het krijgt en wat je er mee moet doen is het wel. Denk hierbij aan time outs die optreden en onlogische stappen door de site. Formulieren die kunnen wijzigen die ingevuld moeten worden, maar ook aangevraagd moeten worden.

Zoals ik al zei, automatiseren is een stuk moeilijker, maar ik vraag me af of je dat wil. 10 keer 10.000 euro handmatig stelen is al aardig

Het enige wat je moet weten is wanneer de klant op je nepsysteem gaat verzenden. Of hij dat nu van pagina A doet of van Z, dat maakt niet uit. In je nepsysteem verwijzen alle verzendknoppen naar dezelfde verzendpagina. Daarvoor zou je een "delay-pagina" in kunnen bouwen. Een pagina die mij een signaal geeft van: "hij gaat verzenden", zodat ik in het echte systeem de challenge code kan oproepen en die in het nepsysteem kan plakken en intussen de klant een 15 a 20 seconden vertraagd (wit scherm, blauw lopend balkje onderin). Als de challengecode is geplakt is de delay ook ongeveer afgelopen (je moet een beetje snel zijn natuurlijk). De klant krijgt de pagina met de juiste challengecode. Voert z'n nummer in en ik ben rijk

Het is echt niet zo makkelijk.

Het is niet heel moeilijk. Alleen kost het veel tijd om te maken.

[it0]

Het lijkt mij dat de challenge/code rekening houdt met je transactie.

Dus bv

ik wil 2 rekeningen overmaken

123456 500 euro
234567 100 euro


Dan zou ik als programmeur zijnde daar een hash van maken en deze integreren met mijn challenge. Dus zelfs als mijn key/challenge wordt onderschept dan kunnen alleen deze transacties worden voltooid, het veranderen van je rekeningnummer of getallen, verandert ook de hash.

Dus als je deze hash ook nogs een integreerd met een timestamp dan kan je er niks tegen doen ook al wordt deze onderschept.

[Janoz]

Verwijderd schreef op 12 november 2003 @ 12:28:
[...]
Klopt. Alleen zeg je dat er onderhoud is, zodat bepaalde functies niet toegankelijk zijn. Uiteraard zijn dit alle functies waar gebruikersdata inzit, want die weet je niet (transactiegeschiedenis, rekeningsaldo's, adresboeken, etc).


[...]
Zoals ik al zei, automatiseren is een stuk moeilijker, maar ik vraag me af of je dat wil. 10 keer 10.000 euro handmatig stelen is al aardig

Het enige wat je moet weten is wanneer de klant op je nepsysteem gaat verzenden. Of hij dat nu van pagina A doet of van Z,

Dat is JUIST een probleem. Hoe weet je dan of hij een opdracht verzend, of gewoon een zoek actie uitvoerd?

dat maakt niet uit. In je nepsysteem verwijzen alle verzendknoppen naar dezelfde verzendpagina.

Daarmee creeer je alleen maar meer problemen. Als de gebruiker een actie uitvoert verwacht hij bijbehorende responces. Je kunt niet met construcite pagina's blijven gooien.

Daarvoor zou je een "delay-pagina" in kunnen bouwen. Een pagina die mij een signaal geeft van: "hij gaat verzenden", zodat ik in het echte systeem de challenge code kan oproepen en die in het nepsysteem kan plakken en intussen de klant een 15 a 20 seconden vertraagd (wit scherm, blauw lopend balkje onderin). Als de challengecode is geplakt is de delay ook ongeveer afgelopen (je moet een beetje snel zijn natuurlijk). De klant krijgt de pagina met de juiste challengecode. Voert z'n nummer in en ik ben rijk

Dat is neit het probleem, en dat zeg ik ook niet. Jij hebt het over 'je eigen transacties invoeren' en je hebt nog nergens een sluitend antwoord op die vraag gegeven. Ten eerste moet je een request doen van het formulier, daarna moet deze ingevuld terug gestuurd worden. Vervolgens komt er een bevestiging waarop een code moet worden igevult. ALs er tussen het versturen van het formulier door de bank en het ontvangen van het compleet inbgevulde formulier door de bank maar 20 seconden zit gaan er bij de bank natuurlijk allemaal alarmbellen af aangezien niemand zo'n formulier binnen 20 seconden in kan vullen.

[...]
Het is niet heel moeilijk. Alleen kost het veel tijd om te maken.

Ik heb het gevoel aslof ik in dit topic tegen een muur loop te praten. Ff weer eens een dooddoenende auto metafoor. Iedereen brult hier dat je, met zo'n staaf van de wegsleep dienst, makkelijk een dikke auto kunt jatten omdat je daar de deur zo mee open krijgt en zo met de auto weg kan rijden. Als ik vervolgens zeg dat je wel makkelijk de auto in komt, maar dat het zo goed als ondoenelijk is om de motor te starten vanwege de start onderbreking en de digitale sleutel die je niet hebt, leest iedereen er overheen en komt met het argument dat je met die staaf makkelijk de deur open krijgt.

[Verwijderd]

Janoz schreef op 12 november 2003 @ 13:23:
Dat is JUIST een probleem. Hoe weet je dan of hij een opdracht verzend, of gewoon een zoek actie uitvoerd?

Dat weet je juist doordat de gemenerik de webserver is voor de client. Jij kunt dan ook rustig een heel eenvoudige webpagina (die natuurlijk als 2 druppels water lijkt op die van de bank) naar de client sturen zonder moeilijke wijzigende namen etc.

Daarmee creeer je alleen maar meer problemen. Als de gebruiker een actie uitvoert verwacht hij bijbehorende responces. Je kunt niet met construcite pagina's blijven gooien.

Nee, maar als je eenmaal duidelijk hebt laten zien dat er onderhoudt aan de pagina's is zullen de meeste clienten niet meteen beginnen te zeuren als ze bepaalde functies missen, niet kunnen vinden of niet werken.

Dat is neit het probleem, en dat zeg ik ook niet. Jij hebt het over 'je eigen transacties invoeren' en je hebt nog nergens een sluitend antwoord op die vraag gegeven. Ten eerste moet je een request doen van het formulier, daarna moet deze ingevuld terug gestuurd worden. Vervolgens komt er een bevestiging waarop een code moet worden ingevult.

Je kunt rustig de klant met jouw webserver laten babbelen en transacties laten doen, zodat de klant denkt dat deze transacties bij de bank aankomen. Jij doet ondertussen je transactie en wacht gewoon totdat de klant op de 'verzend transacties' of whatever klikt. De gemenerik krijgt de challenge-code van de bank, speelt die door aan de client die de response code geeft die jij op jouw beurt weer doorgeeft aan de bank. Transacties voltooid, verteld de klant nog dat zijn transacties voltooid zijn (stiekum niet), de gemenerik gaat van een lui lekker leven genieten en hopen dat hij niet gepakt wordt.

ALs er tussen het versturen van het formulier door de bank en het ontvangen van het compleet inbgevulde formulier door de bank maar 20 seconden zit gaan er bij de bank natuurlijk allemaal alarmbellen af aangezien niemand zo'n formulier binnen 20 seconden in kan vullen.

Dat is vrij simpel te omzeilen natuurlijk.

Ik heb het gevoel aslof ik in dit topic tegen een muur loop te praten.

En dat gevoel heb ik ook al de hele tijd, of ik leg het niet goed uit, kan natuurlijk ook.

Ff weer eens een dooddoenende auto metafoor. Iedereen brult hier dat je, met zo'n staaf van de wegsleep dienst, makkelijk een dikke auto kunt jatten omdat je daar de deur zo mee open krijgt en zo met de auto weg kan rijden. Als ik vervolgens zeg dat je wel makkelijk de auto in komt, maar dat het zo goed als ondoenelijk is om de motor te starten vanwege de start onderbreking en de digitale sleutel die je niet hebt, leest iedereen er overheen en komt met het argument dat je met die staaf makkelijk de deur open krijgt.

Vind ik een beetje appels met peren vergelijken, maar goed, je hebt wel gelijk, alleen er is niemand hier die zegt dat het heel makkelijk is, alleen er zijn dus ook mensen die zeggen dat het mogelijk is, en waarschijnlijk heel goed ook.

[Verwijderd]

Janoz schreef op 12 november 2003 @ 13:23:
Dat is JUIST een probleem. Hoe weet je dan of hij een opdracht verzend, of gewoon een zoek actie uitvoerd?

Ik heb alleen ervaring met rabobank telebankieren, daar baseer ik mijn verhaal dus ook op. De verzendknop is daar de pagina waar je een overzicht krijgt van je openstaande transacties, met daaronder de challenge met uitleg en daaronder een invulveldje. Die pagina is altijd hetzelfde, met uitzondering van de transacties die net zijn aangemaakt. Die zijn echter aangemaakt op jouw nepsysteem en dus kun je die daar zonder problemen tonen. Hij verwacht die pagina ook zodra hij op verzenden klikt. Voor de rest maak je het systeem gewoon compleet. Per acceptgiro, bankgiro etc kun je allemaal betalen en dat lijkt ook allemaal te werken. Besluit hij daar toch niet te verzenden, dan komt hij op een later tijdstip wel terug om te gaan verzenden en kun je dan wederom de challenge aanpassen.

Dat is neit het probleem, en dat zeg ik ook niet. Jij hebt het over 'je eigen transacties invoeren' en je hebt nog nergens een sluitend antwoord op die vraag gegeven. Ten eerste moet je een request doen van het formulier, daarna moet deze ingevuld terug gestuurd worden. Vervolgens komt er een bevestiging waarop een code moet worden igevult. ALs er tussen het versturen van het formulier door de bank en het ontvangen van het compleet inbgevulde formulier door de bank maar 20 seconden zit gaan er bij de bank natuurlijk allemaal alarmbellen af aangezien niemand zo'n formulier binnen 20 seconden in kan vullen.

Ik kan bij de rabobank een betaling er inzetten (bijvoorbeeld een bankgiro). Op een later moment kan ik dan de bijbehorende challenge doen. Zodra dus de persoon die ik wil oplichten inlogt op mijn nepsysteem log ik meteen in op het echte systeem met zijn gegevens. Ik maak de transactie vast aan en zet hem in de wachtrij. Is de persoon die ik wil oplichten klaar met zijn transacties op mijn nepsysteem en wil hij ze verzenden dan is dat het moment om voor mij ook te gaan verzenden. Ik krijg m'n challenge. Paste die in de neppagina van de persoon die ik wil oplichten, krijg zijn returncode en vul die in. Dat duurt iets langer dan wanneer je het normaal zelf intikt op je eigen edentifier, maar niet zo lang dat het opvalt.

Ik heb het gevoel aslof ik in dit topic tegen een muur loop te praten. Ff weer eens een dooddoenende auto metafoor. Iedereen brult hier dat je, met zo'n staaf van de wegsleep dienst, makkelijk een dikke auto kunt jatten omdat je daar de deur zo mee open krijgt en zo met de auto weg kan rijden. Als ik vervolgens zeg dat je wel makkelijk de auto in komt, maar dat het zo goed als ondoenelijk is om de motor te starten vanwege de start onderbreking en de digitale sleutel die je niet hebt, leest iedereen er overheen en komt met het argument dat je met die staaf makkelijk de deur open krijgt.

Ik snap je frustratie. Die ontstaat denk ik grotendeels doordat ik een slechte uitlegger ben. Punt is alleen dat het wel degelijk kan, zolang je het maar gelijktijdig met de klant doet en je snel bent. Jij moet de opdracht om €10.000 overtemaken naar jouw rekening, sneller verwerken dan hij zijn opdracht(en). Dan ben je eerder gereed voor de challenge en kun je de echte challenge in het nepsysteem gooien, zonder dat de klant het doorheeft.

[Verwijderd]

it0 schreef op 12 november 2003 @ 13:05:
Het lijkt mij dat de challenge/code rekening houdt met je transactie.

Dus bv

ik wil 2 rekeningen overmaken

123456 500 euro
234567 100 euro


Dan zou ik als programmeur zijnde daar een hash van maken en deze integreren met mijn challenge. Dus zelfs als mijn key/challenge wordt onderschept dan kunnen alleen deze transacties worden voltooid, het veranderen van je rekeningnummer of getallen, verandert ook de hash.

Dus als je deze hash ook nogs een integreerd met een timestamp dan kan je er niks tegen doen ook al wordt deze onderschept.

Denk dat je nog even goed moet lezen. Er wordt niks onderschept

[Verwijderd]

Verwijderd schreef op 12 november 2003 @ 15:38:[...]
Ik heb alleen ervaring met rabobank telebankieren, daar baseer ik mijn verhaal dus ook op. De verzendknop is daar de pagina waar je een overzicht krijgt van je openstaande transacties, met daaronder de challenge met uitleg en daaronder een invulveldje. Die pagina is altijd hetzelfde, met uitzondering van de transacties die net zijn aangemaakt. Die zijn echter aangemaakt op jouw nepsysteem en dus kun je die daar zonder problemen tonen. Hij verwacht die pagina ook zodra hij op verzenden klikt. Voor de rest maak je het systeem gewoon compleet. Per acceptgiro, bankgiro etc kun je allemaal betalen en dat lijkt ook allemaal te werken. Besluit hij daar toch niet te verzenden, dan komt hij op een later tijdstip wel terug om te gaan verzenden en kun je dan wederom de challenge aanpassen.

Ik kan bij de rabobank een betaling er inzetten (bijvoorbeeld een bankgiro). Op een later moment kan ik dan de bijbehorende challenge doen. Zodra dus de persoon die ik wil oplichten inlogt op mijn nepsysteem log ik meteen in op het echte systeem met zijn gegevens. Ik maak de transactie vast aan en zet hem in de wachtrij. Is de persoon die ik wil oplichten klaar met zijn transacties op mijn nepsysteem en wil hij ze verzenden dan is dat het moment om voor mij ook te gaan verzenden. Ik krijg m'n challenge. Paste die in de neppagina van de persoon die ik wil oplichten, krijg zijn returncode en vul die in. Dat duurt iets langer dan wanneer je het normaal zelf intikt op je eigen edentifier, maar niet zo lang dat het opvalt.

Ik snap je frustratie. Die ontstaat denk ik grotendeels doordat ik een slechte uitlegger ben. Punt is alleen dat het wel degelijk kan, zolang je het maar gelijktijdig met de klant doet en je snel bent. Jij moet de opdracht om €10.000 overtemaken naar jouw rekening, sneller verwerken dan hij zijn opdracht(en). Dan ben je eerder gereed voor de challenge en kun je de echte challenge in het nepsysteem gooien, zonder dat de klant het doorheeft.

Precies wat ik bedoel! Denk dat wij elkaar wel snappen, nu alleen de rest nog!
Nu ging ik me trouwens afvragen:
De e-dentifier, weet of je een goede/foutieve pin hebt ingetoetst. Pin is slechts 4 cijfers dus zou je de e-dentifier niet zo kunnen aanpassen zodat ie bijv. een gekopieerde bankpas gaat bruteforcen en de pincode(s) teruggeeft, kun je rustig als gemenerik internetbankieren/pinnen!

[Verwijderd]

Verwijderd schreef op 12 november 2003 @ 15:46:
Precies wat ik bedoel! Denk dat wij elkaar wel snappen, nu alleen de rest nog!

Of niet natuurlijk... ik zag nog een leuk huisje op de bahama's...

Nu ging ik me trouwens afvragen:
De e-dentifier, weet of je een goede/foutieve pin hebt ingetoetst. Pin is slechts 4 cijfers dus zou je de e-dentifier niet zo kunnen aanpassen zodat ie bijv. een gekopieerde bankpas gaat bruteforcen en de pincode(s) teruggeeft, kun je rustig als gemenerik internetbankieren/pinnen!

Denk dat dat gaat tegenvallen. In principe zou je dan met elke willekeurige cardreader de pincode kunnen aflezen. Als dat zou kunnen, zou dat al veel eerder gedaan zijn vermoed ik.

Het geniale van het tussenpersoontelebankieren is juist dat je geen enkele beveiliging kraakt, maar gewoon profiteert van de onoplettendheid van de gebruikers.

[Wokschotel]

Verwijderd schreef op 12 november 2003 @ 15:38:
[...]
Ik heb alleen ervaring met rabobank telebankieren, daar baseer ik mijn verhaal dus ook op. De verzendknop is daar de pagina waar je een overzicht krijgt van je openstaande transacties, met daaronder de challenge met uitleg en daaronder een invulveldje. Die pagina is altijd hetzelfde, met uitzondering van de transacties die net zijn aangemaakt. Die zijn echter aangemaakt op jouw nepsysteem en dus kun je die daar zonder problemen tonen. Hij verwacht die pagina ook zodra hij op verzenden klikt. Voor de rest maak je het systeem gewoon compleet. Per acceptgiro, bankgiro etc kun je allemaal betalen en dat lijkt ook allemaal te werken. Besluit hij daar toch niet te verzenden, dan komt hij op een later tijdstip wel terug om te gaan verzenden en kun je dan wederom de challenge aanpassen.


[...]
Ik kan bij de rabobank een betaling er inzetten (bijvoorbeeld een bankgiro). Op een later moment kan ik dan de bijbehorende challenge doen. Zodra dus de persoon die ik wil oplichten inlogt op mijn nepsysteem log ik meteen in op het echte systeem met zijn gegevens. Ik maak de transactie vast aan en zet hem in de wachtrij. Is de persoon die ik wil oplichten klaar met zijn transacties op mijn nepsysteem en wil hij ze verzenden dan is dat het moment om voor mij ook te gaan verzenden. Ik krijg m'n challenge. Paste die in de neppagina van de persoon die ik wil oplichten, krijg zijn returncode en vul die in. Dat duurt iets langer dan wanneer je het normaal zelf intikt op je eigen edentifier, maar niet zo lang dat het opvalt.


[...]
Ik snap je frustratie. Die ontstaat denk ik grotendeels doordat ik een slechte uitlegger ben. Punt is alleen dat het wel degelijk kan, zolang je het maar gelijktijdig met de klant doet en je snel bent. Jij moet de opdracht om €10.000 overtemaken naar jouw rekening, sneller verwerken dan hij zijn opdracht(en). Dan ben je eerder gereed voor de challenge en kun je de echte challenge in het nepsysteem gooien, zonder dat de klant het doorheeft.

Maar dit werkt dus alleen als jij een klant kan vinden die niet kijkt naar URL's (alhoewel dat met een hosts-filtje makkelijk aan te passen is) en SSL-certificaten, right?

[silentsnake]

Umm...misschien een erg domme opmerking hoor...maar je kan toch nooit een identieke SSL key generate als de orginele server, met het gevolg dat de browser weergeeft dat het certificaat dat je vertrouwd veranderd is, en de gebruiker afraad om verder te gaan...

[Verwijderd]

Wokschotel schreef op 12 november 2003 @ 16:06:
Maar dit werkt dus alleen als jij een klant kan vinden die niet kijkt naar URL's (alhoewel dat met een hosts-filtje makkelijk aan te passen is) en SSL-certificaten, right?

Klopt. Het hele systeem valt of staat met de oplettendheid van de gebruiker. Maar goed, hoeveel % controleert dat? De url misschien nog wel, maar die is makkelijk te faken, dat zeg je zelf al. De gemiddelde Nederlander heeft geen flauw idee wat SSL is, dus die mist het ook niet. Ik denk dat het wel losloopt

[Wokschotel]

Verwijderd schreef op 12 november 2003 @ 16:12:
[...]
Klopt. Het hele systeem valt of staat met de oplettendheid van de gebruiker. Maar goed, hoeveel % controleert dat? De url misschien nog wel, maar die is makkelijk te faken, dat zeg je zelf al. De gemiddelde Nederlander heeft geen flauw idee wat SSL is, dus die mist het ook niet. Ik denk dat het wel losloopt

Zo is het. Deze truuk is niet nieuw natuurlijk, maar ik denk dat ie in de praktijk nog steeds zal werken. Uiteraard komt de rekeninghouder er vanzelf wel achter zodra hij zijn rekeningafschrift ziet (papier is een stuk moeilijker te faken ) maar dan ben je al te laat. Je zou zelfs de boel real-time van bv de Rabobank-server af kunnen halen en weergeven via je eigen server, dan ziet de gebruiker niet eens dat er onderhoud ofzo is.

[fetcher]

Neem van mij aan dat er echt wel is nagedacht over een veilige werking van internet bankieren en dat er een hoop geld/tijd en mankracht word gestoken om de boel secure te ontwikkelen en te houden.

Dit geld voor zowel de fysieke locatie, netwerk apperatuur, applicatie's en de procedures er omheen

Trouwens, in principe is alles te hacken.

[ Voor 38% gewijzigd door fetcher op 12-11-2003 16:18 ]

[hendrikjan]

Spivvi schreef op 10 november 2003 @ 12:09:
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.

dan zou ik de algemene voorwaarden van de bank er nog maar eens goed op nalezen als ik jouw was

[Verwijderd]

Wokschotel schreef op 12 november 2003 @ 16:15:
Je zou zelfs de boel real-time van bv de Rabobank-server af kunnen halen en weergeven via je eigen server, dan ziet de gebruiker niet eens dat er onderhoud ofzo is.

Maar dan krijg je weer het probleem dat je ook zijn transacties mee moet gaan sturen en dat dus de challenge steeds veranderd. Je zal het wel moeten splitsen. Misschien dat je alleen de transactiedata en rekeningsaldo's over kan pompen, maar daar wordt het wel veel ingewikkelder van. Onderhoud lijkt me het makkelijkste

fetcher schreef op 12 november 2003 @ 16:15:
Neem van mij aan dat er echt wel is nagedacht over een veilige werking van internet bankieren en dat er een hoop geld/tijd en mankracht word gestoken om de boel secure te ontwikkelen en te houden.

Het systeem zelf is inderdaad veilig (voor zover bekend). De gebruiker is het alleen niet. Door de gebruiker te foppen krijg je alle veiligheidscodes die je nodig hebt. Het is hetzelfde principe als de behulpzame man bij de pinautomaat, alleen net wat geraffineerder

[fetcher]

Valt wat mij betreft onder het kopje "in principe is alles te hacken"

Als ik op straat loop en iemand slaat me tegen de grond en dwingt mij mijn pincode te vertellen kan de overvaller ook mijn rekening leeg pinnen

Zo zie ik het ook een beetje in de digitale wereld

[Verwijderd]

silentsnake schreef op 12 november 2003 @ 16:10:
Umm...misschien een erg domme opmerking hoor...maar je kan toch nooit een identieke SSL key generate als de orginele server, met het gevolg dat de browser weergeeft dat het certificaat dat je vertrouwd veranderd is, en de gebruiker afraad om verder te gaan...

Klopt, dus zul je als gemenerik er voor moeten zorgen dat de klant gewoon via HTTP gaat en boodschappen als: let erop dat het adres met https://bank.nl begint moeten weglaten of vervangen door: let erop dat het adres met http://bank.nl begint.

[begintmeta]

fetcher: bij veel mensen is wel een groter bedrag bereikbaar via internetbankieren. Een overvaller die laptop en gprs-verbinding heeft, zou je ook kunnen dwingen even al je rekeningen leeg te halen. (en de trucjes om pincodes/passen te kopieren zijn inmiddels ook bekend) Daarom zijn er ook mensen die 1 rekening hebben om te pinnen en 1 om toegang tot internetbankieren te krijgen.

[fetcher]

begintmeta schreef op 12 november 2003 @ 16:33:
fetcher: bij veel mensen is wel een groter bedrag bereikbaar via internetbankieren. Een overvaller die laptop en gprs-verbinding heeft, zou je ook kunnen dwingen even al je rekeningen leeg te halen. (en de trucjes om pincodes/passen te kopieren zijn inmiddels ook bekend) Daarom zijn er ook mensen die 1 rekening hebben om te pinnen en 1 om toegang tot internetbankieren te krijgen.

Correct.

Sterker nog, ik zit in dezelfde situatie omdat ik naast mijn prive rekening ook een internetbankieren account heb waar je alleen maar bij kan via internetbankieren

Wat niet weg neemt dat er niets valt te halen van "normale" rekeningen natuurlijk

[Verwijderd]

fetcher schreef op 12 november 2003 @ 16:15:
Neem van mij aan dat er echt wel is nagedacht over een veilige werking van internet bankieren en dat er een hoop geld/tijd en mankracht word gestoken om de boel secure te ontwikkelen en te houden.

Dit geld voor zowel de fysieke locatie, netwerk apperatuur, applicatie's en de procedures er omheen

Trouwens, in principe is alles te hacken.

Zonder een systeem met public en private keys is een MITM attack eigenlijk niet echt te detecteren

Alles valt of staat dus met de SSL verbinding die opgebouwd dient te worden. Als daarbij niet opgelet wordt door klant en deze of onbeveiligd verbindt of middels een ander certificaat verbindt dan is het in principe mogelijk om bovenstaande verhalen waarheid te laten worden.

Probleem is en blijft natuurlijk wel dat je MITM moet worden (wat nauwelijks mogelijk is in de meeste gevallen. Zeker bij gewone thuisgebruikers die Internet op gaan via hun ISP. Hoewel ook hier natuurlijk wel weer oplossingen in de vorm van een trojan o.i.d. op te vinden zijn).

Als bovenstaande gelukt is moet de persoon (de klant) dus ook nog eens niet opletten bij het certificaat cq de beveiligde verbinding.

Daarna moet er dus een systeem van de MITM zijn die even alles af gaat handelen. Dit systeem is tamelijk ingewikkeld om zodanig te bouwen dat de klant pas iets in de gaten heeft als zijn bankrekening geplunderd is.


Tot slot zit je nog altijd met het probleem, dat zoiets tamelijk snel ontdekt wordt en dat het traceren een relatief eitje is.

[edit]
Overigens denk ik dat het schrijven van een Trojan die de computer van de gebruiker "infecteert" en inhaakt op IE een alternatief is dat veel beter zou werken.
Als je weet hoe de pagina's opgebouwd worden, dan is het wel te doen om getallen tevoorschijn te laten toveren op het scherm van de gebruiker die precies overeenkomen met hetgeen hij/zij ingevoerd heeft, terwijl er onderhuids in de communicatie heen en terug met andere cijfers gewerkt wordt.
Hier geldt overigens natuurlijk ook weer dat je zoiets niet even in een avondje in elkaar klust en verder kan ik me zo voorstellen dat er expres "randomness" in pagina's van banken verwerkt zitten

Op zich is dit wel een leuk onderwerp om een scriptie o.i.d. over te schrijven

[ Voor 20% gewijzigd door Verwijderd op 13-11-2003 01:57 ]

[Verwijderd]

Verwijderd schreef op 13 november 2003 @ 01:48:
Alles valt of staat dus met de SSL verbinding die opgebouwd dient te worden. Als daarbij niet opgelet wordt door klant en deze of onbeveiligd verbindt of middels een ander certificaat verbindt dan is het in principe mogelijk om bovenstaande verhalen waarheid te laten worden.

Hoeveel % van de internetbankierengebruikers denk jij dat daadwerkelijk controleert of ze een SSL verbinding hebben? Als het 1% is vind ik het veel. Het ontbreken van de SSL verbinding is dus niet zo'n probleem.

Probleem is en blijft natuurlijk wel dat je MITM moet worden (wat nauwelijks mogelijk is in de meeste gevallen. Zeker bij gewone thuisgebruikers die Internet op gaan via hun ISP. Hoewel ook hier natuurlijk wel weer oplossingen in de vorm van een trojan o.i.d. op te vinden zijn).

Het beste idee lijkt mij inderdaad een trojan. Nadeel is alleen dat je trojan niet kan ruiken welk systeem de client gebruikt. Als je een Rabobank systeem hebt gefaked heeft het weinig zin om een ABN-Amro klant te infecteren. Daarnaast weet je niet wat voor klant je oplicht. Is het een student met 12 euro op z'n rekening of is het een rentenier met 100.000 op z'n internetspaarrekening. In feite zou je de trojan dus mee moeten sturen met een programma wat de rijke doelgroep aanspreekt

Tot slot zit je nog altijd met het probleem, dat zoiets tamelijk snel ontdekt wordt en dat het traceren een relatief eitje is.

True, je kan je server wat verstoppen, door het signaal via meerdere servers te laten gaan, maar achterhalen kan altijd. Echter heb je ook niet gek veel tijd nodig. Als je 100 mensen op 1 dag oplicht voor gemiddeld 10.000 heb jij al een miljoen op je (bijvoorbeeld) Afrikaanse bankrekeningen staan. Zorg er voor dat je een mannetje in Afrika hebt zitten die direct dat geld cash gaat opnemen en voor ze hier in Nederland je identiteit hebben (als ze die al vinden, via openbare computers kun je dit grapje namelijk wel uitvoeren) zit jij al lang ergens in Zuid Amerika

[begintmeta]

of het mannetje in afrika

[Verwijderd]

begintmeta schreef op 13 november 2003 @ 13:56:
of het mannetje in afrika

Of je gaat het vanuit Afrika doen Hoef je ook niet te delen

[Falcon]

Hele leuke verhalen en ideëen hier, maar als ik morgen in de krant lees een grote fraude op electronic banking systeem van een bank dan weet ik lekker wie het gedaan heeft

[MSalters]

Ik denk dat er een ding vergeten wordt in de MITM attack: een bank applicatie die initieel een Javascript meestuurt die de geladen pagina's analyseert, en md5 hashes daarvan in een hidden frame bewaart, en ook meestuurt. De bank weet precies hoe die hashes eruit zouden moeten zien. Als de gebruiker een enkele overboeking doet onthoudt de Javascript code dat dus. Bij het verzoek tot bevestiging wordt een code meegestuurd die client-side zorgt dat alleen het originele verzoek geauthoriseerd kan worden.

Een MITM kan hier nog steeds tussen zitten, maar moet vol-automatisch want binnen een paar seconden de onbekende Javascript hacken. Het werkt alleen als de MITM een vergelijkbaar stuk Javascript kan maken wat de goede challenge retourneert aan de bank, dwz de complete page load simuleert.

Het wordt helemaal ingewikkeld als de client-side Javascript nog een post-processing doet op de door de gebruiker ingevoerde code. Laat de JS een inverteerbare functie F uitvoeren op de code, en de bank voert vervolgens de inverse F^-1 uit. Omdat de functie f per page load kan verschillen moet de MITM niet alleen de page load simuleren, maar ook nog zelf de functie F los laten op de input. Maar welk stukje van de JS is nou die functie F? Dat is niet heel snel te bepalen.
Een simpele stap als het opsturen van het controlenumber samen met de te bevestigen opdracht als .PNG maakt het nog moeilijker. Dan moet de MITM on-the-fly die image gaan photoshoppen

[Verwijderd]

MSalters schreef op 29 november 2003 @ 00:08:
Ik denk dat er een ding vergeten wordt in de MITM attack: een bank applicatie die initieel een Javascript meestuurt die de geladen pagina's analyseert, en md5 hashes daarvan in een hidden frame bewaart, en ook meestuurt. De bank weet precies hoe die hashes eruit zouden moeten zien. Als de gebruiker een enkele overboeking doet onthoudt de Javascript code dat dus. Bij het verzoek tot bevestiging wordt een code meegestuurd die client-side zorgt dat alleen het originele verzoek geauthoriseerd kan worden.

Een MITM kan hier nog steeds tussen zitten, maar moet vol-automatisch want binnen een paar seconden de onbekende Javascript hacken. Het werkt alleen als de MITM een vergelijkbaar stuk Javascript kan maken wat de goede challenge retourneert aan de bank, dwz de complete page load simuleert.

Het wordt helemaal ingewikkeld als de client-side Javascript nog een post-processing doet op de door de gebruiker ingevoerde code. Laat de JS een inverteerbare functie F uitvoeren op de code, en de bank voert vervolgens de inverse F^-1 uit. Omdat de functie f per page load kan verschillen moet de MITM niet alleen de page load simuleren, maar ook nog zelf de functie F los laten op de input. Maar welk stukje van de JS is nou die functie F? Dat is niet heel snel te bepalen.
Een simpele stap als het opsturen van het controlenumber samen met de te bevestigen opdracht als .PNG maakt het nog moeilijker. Dan moet de MITM on-the-fly die image gaan photoshoppen

En je hebt nog steeds niet gesnapt wat wij hebben proberen duidelijk te maken. Je hoeft helemaal de pagina's niet te ontleden en te interpreteren want je hebt direct verbinding met de bank. Jij stuurt alleen nep-pagina's naar de eindgebruiker zodat die denkt dat ie echt verbinding met zijn bank heeft. Hij geeft dan ook de codes die je nodig hebt en je kunt zo'n plaatje dan ook gewoon doorspelen aan de klant en die zal er op reageren.
Nog even een keertje alles doorlezen dus!

[Janoz]

Verwijderd schreef op 02 december 2003 @ 10:16:
[...]

En je hebt nog steeds niet gesnapt wat wij hebben proberen duidelijk te maken. Je hoeft helemaal de pagina's niet te ontleden en te interpreteren want je hebt direct verbinding met de bank. Jij stuurt alleen nep-pagina's naar de eindgebruiker zodat die denkt dat ie echt verbinding met zijn bank heeft. Hij geeft dan ook de codes die je nodig hebt en je kunt zo'n plaatje dan ook gewoon doorspelen aan de klant en die zal er op reageren.
Nog even een keertje alles doorlezen dus!

Nu reageer je alleen op het plaatje en niet op het stuk wat ervoor staat. Hoe weet je trouwens welk plaatje je door moet sturen?

[Verwijderd]

Janoz schreef op 02 december 2003 @ 11:01:
[...]

Nu reageer je alleen op het plaatje en niet op het stuk wat ervoor staat. Hoe weet je trouwens welk plaatje je door moet sturen?

Deze reactie is niet alleen op het plaatje. Lees nou maar gewoon alles nog een keer door want het is allemaal al een keer uitgelegd hoe het zou kunnen werken en waar de knelpunten liggen, bovenstaande punten zijn daarbij zeker geen knelpunten.

[Verwijderd]

Even een kleine reactie, omdat het topic nu op tweakers.net relevant blijkt (Postbank.nl).

Pas geleden is hier in België een postbeambte zo aardig geweest om, tijdens de kerstvakantie, een 'extra overboeking' te doen van een amnesty-rekening (of soortgelijk instituut) naar zijn eigen rekening: 3mln euro.

Slim dat hij dat deed in de kerstvakantie, want nu had hij maar liefst een week de tijd om te verdwijnen. Snappen jullie waar ik op doel? Het is niet mogelijk om de overboeking zo te wijzigen, dat het geld naar mijn rekeningnummer gaat, terwijl de bank de originele overboeking registreerd; het heeft nu juist die registratie nodig om de overboeking te doen.

Gevolg: op het rekeningafschrift staat een overboeking naar iemand die je niet kent. Ook wanneer je gewoon 5 euro extra toevoegt, of iets dergelijks. Je zou er dus nog wel kunnen tussenkomen, maar ermee wegkomen is een kwestie van véél haast en dus weinig tijd om veel te verdienen.

[Verwijderd]

Als we het nou eens vanuit een andere invalshoek bekijken: stel nou dat de maker geen winst wil maken, maar alleen chaos wil scheppen, een soort internet-terrorisme. Hierbij wijk ik eerst een beetje van de originele vraag af door op de huidige situatie in te gaan, maar hierop kom ik later terug.

Worm

Er wordt hier veel gefocust op de man in the middle attack, het idee van een virus is wel geopperd, maar is niet echt uitgewerkt. Uit eerdere voorvallen blijkt al dat wormen zeer succesvol kunnen zijn, een goed geschreven worm kan in een korte tijd een enorme hoeveelheid systemen infecteren. De release van een worm kan samenvallen met de ondekking van een gat, de worm zelf kan bijvoorbeeld al klaarliggen. Op die manier kun je toeslaan op het moment dat er zoveel mogelijk systemen kwetsbaar zijn.

Eenmaal op een systeem heb je de volledige controle. Met behulp van BHO's (browser helper objects) is het mogelijk om de verrichtingen die de gebruiker in internet explorer uitvoert exact te volgen. Met wat meer moeite (denk ik, ik ken de mogelijkheden van BHO's niet precies), het patchen van wininet of iets dergelijks, is het mogelijk om zowel SSL als normale verbindingen af te luisteren en aan te passen. Op deze manier is het een fluitje van een cent om te detecteren of de gebruiker gebruik maakt van internetbankieren.

De volgende stap is het inbouwen van ondersteuning voor verschillende internet-bankieren websites. Bij sites die per challenge/response of andere vorm van authenticatie meerdere transacties ondersteunen kunnen op de achtergrond transacties worden toegevoegd, anders kan de originele transactie onzichtbaar voor de gebruiker vervangen worden door een 'spooktransactie'. Uiteraard worden deze transacties volledig verborgen gehouden voor de gebruiker, door alle responses van de bank exact te filteren.

Maar dan nu de vraag: waar moet dat geld dan heen? Het antwoord is eenvoudig: Als je alleen op chaos uit bent maakt het niet uit waarheen, als het maar ergens heen gaat. De worm kan uit bijvoorbeeld uit een geschiedenis van transacties proberen zoveel mogelijk rekeningnummer/naam-combinaties filteren. Door deze gegevens mee te nemen bij de verspreiding, of zelfs door direct contact tussen de wormen onderling, kan snel een grote hoeveelheid geldige rekeninggegevens verzameld worden. Indien de maker zelf toch geld wil verdienen kan deze proberen een voorkeur te geven aan rekeningnummers die aan bepaalde voorwaarden voldoen, bijvoorbeeld "rekeningnummer deelbaar door 63", en zo te hopen op een groter aandeel van de transacties. Hierbij is de maker niet persoonlijk identificeerbaar en maakt hij misschien een kans om weg te komen in de ontstane chaos.

Als de worm zichzelf snel verspreidt, en het aantal ondersteunde banksystemen groot genoeg is, heeft dit in zeer korte tijd een enorme hoeveelheid spooktransacties als gevolg. De chaos kan hierdoor enorm zijn.

Snelheid is de kritische factor bij de uitbraak, zodra de worm bekend wordt, is een kleine wijziging in de code aan de kant van de bank voldoende om de website onbruikbaar te maken voor de worm. Alles komt dus aan op de eerste klap, de worm zal zich zeer snel moeten verspreiden.

Beveiliging

Bovenstaand scenario is nog niet voorgekomen, doordat het een grote opgave is een dergelijke worm te ontwikkelen. Alles is echter technisch goed haalbaar. Om deze reden denk ik dat je zowel de computer van de gebruiker als het internet als 'untrusted' moet beschouwen.

Een mogelijke oplossing voor dit probleem is een extern kastje, vergelijkbaar met een rabox met een groter display, verbonden via USB met de computer. Dit apparaat in combinatie met de bankpas is beveiligd met een pincode en beschikt over encryptiefuncties. De bankpas van de gebruiker bevat de private key van de gebruiker, gebruikt voor communicatie met de bank.

Op het moment dat transacties op het punt staan naar de bank gestuurd te worden, krijgt de gebruiker deze op het schermpje van het apparaat te zien. Na het accepteren van de gegevens zorgt het apparaat voor de versleuteling van de transactiegegevens en geeft deze door aan de computer. De computer van de gebruiker kan vervolgens niets beginnen met de gegevens, omdat deze de private key nooit te weten komt.

Heeft iemand nog op- of aanmerkingen m.b.t. de veiligheid en haalbaarheid van deze methode? Of is het misschien allemaal te moeilijk gedacht en kan het veel eenvoudiger?

[prototype]

Verwijderd schreef op 16 januari 2004 @ 22:25:
Als we het nou eens vanuit een andere invalshoek bekijken: stel nou dat de maker geen winst wil maken, maar alleen chaos wil scheppen, een soort internet-terrorisme. Hierbij wijk ik eerst een beetje van de originele vraag af door op de huidige situatie in te gaan, maar hierop kom ik later terug.

Worm

Er wordt hier veel gefocust op de man in the middle attack, het idee van een virus is wel geopperd, maar is niet echt uitgewerkt. Uit eerdere voorvallen blijkt al dat wormen zeer succesvol kunnen zijn, een goed geschreven worm kan in een korte tijd een enorme hoeveelheid systemen infecteren. De release van een worm kan samenvallen met de ondekking van een gat, de worm zelf kan bijvoorbeeld al klaarliggen. Op die manier kun je toeslaan op het moment dat er zoveel mogelijk systemen kwetsbaar zijn.

Eenmaal op een systeem heb je de volledige controle. Met behulp van BHO's (browser helper objects) is het mogelijk om de verrichtingen die de gebruiker in internet explorer uitvoert exact te volgen. Met wat meer moeite (denk ik, ik ken de mogelijkheden van BHO's niet precies), het patchen van wininet of iets dergelijks, is het mogelijk om zowel SSL als normale verbindingen af te luisteren en aan te passen. Op deze manier is het een fluitje van een cent om te detecteren of de gebruiker gebruik maakt van internetbankieren.

De volgende stap is het inbouwen van ondersteuning voor verschillende internet-bankieren websites. Bij sites die per challenge/response of andere vorm van authenticatie meerdere transacties ondersteunen kunnen op de achtergrond transacties worden toegevoegd, anders kan de originele transactie onzichtbaar voor de gebruiker vervangen worden door een 'spooktransactie'. Uiteraard worden deze transacties volledig verborgen gehouden voor de gebruiker, door alle responses van de bank exact te filteren.

Maar dan nu de vraag: waar moet dat geld dan heen? Het antwoord is eenvoudig: Als je alleen op chaos uit bent maakt het niet uit waarheen, als het maar ergens heen gaat. De worm kan uit bijvoorbeeld uit een geschiedenis van transacties proberen zoveel mogelijk rekeningnummer/naam-combinaties filteren. Door deze gegevens mee te nemen bij de verspreiding, of zelfs door direct contact tussen de wormen onderling, kan snel een grote hoeveelheid geldige rekeninggegevens verzameld worden. Indien de maker zelf toch geld wil verdienen kan deze proberen een voorkeur te geven aan rekeningnummers die aan bepaalde voorwaarden voldoen, bijvoorbeeld "rekeningnummer deelbaar door 63", en zo te hopen op een groter aandeel van de transacties. Hierbij is de maker niet persoonlijk identificeerbaar en maakt hij misschien een kans om weg te komen in de ontstane chaos.

Als de worm zichzelf snel verspreidt, en het aantal ondersteunde banksystemen groot genoeg is, heeft dit in zeer korte tijd een enorme hoeveelheid spooktransacties als gevolg. De chaos kan hierdoor enorm zijn.

Snelheid is de kritische factor bij de uitbraak, zodra de worm bekend wordt, is een kleine wijziging in de code aan de kant van de bank voldoende om de website onbruikbaar te maken voor de worm. Alles komt dus aan op de eerste klap, de worm zal zich zeer snel moeten verspreiden.

Beveiliging

Bovenstaand scenario is nog niet voorgekomen, doordat het een grote opgave is een dergelijke worm te ontwikkelen. Alles is echter technisch goed haalbaar. Om deze reden denk ik dat je zowel de computer van de gebruiker als het internet als 'untrusted' moet beschouwen.

Een mogelijke oplossing voor dit probleem is een extern kastje, vergelijkbaar met een rabox met een groter display, verbonden via USB met de computer. Dit apparaat in combinatie met de bankpas is beveiligd met een pincode en beschikt over encryptiefuncties. De bankpas van de gebruiker bevat de private key van de gebruiker, gebruikt voor communicatie met de bank.

Op het moment dat transacties op het punt staan naar de bank gestuurd te worden, krijgt de gebruiker deze op het schermpje van het apparaat te zien. Na het accepteren van de gegevens zorgt het apparaat voor de versleuteling van de transactiegegevens en geeft deze door aan de computer. De computer van de gebruiker kan vervolgens niets beginnen met de gegevens, omdat deze de private key nooit te weten komt.

Heeft iemand nog op- of aanmerkingen m.b.t. de veiligheid en haalbaarheid van deze methode? Of is het misschien allemaal te moeilijk gedacht en kan het veel eenvoudiger?

Goed punt.

[Verwijderd]

Verwijderd schreef op 16 januari 2004 @ 22:25:
Heeft iemand nog op- of aanmerkingen m.b.t. de veiligheid en haalbaarheid van deze methode? Of is het misschien allemaal te moeilijk gedacht en kan het veel eenvoudiger?

Je moet er voor zorgen dat jouw computer de enige is die kan communiceren met de bank en niet de computer van de MITM. Dat kan uiteraard met een stuk hardware, maar misschien kun je softwarematig ook iets bereiken. Bijvoorbeeld een sleutel die op jouw systeem zit. Grote nadeel is het feit dat je aan mobiliteit gaat inboeten. Ik kan nu op elke plaats in de wereld mijn rekening bekijken. Met een vaste bankier pc kan dat niet meer.

Wat betreft wegkomen met het geld: Je hebt niet veel tijd, maar je hebt ook niet veel tijd nodig. Papieren afschriften zijn niet up to date. De gegevens zijn meestal van 1 a 2 dagen terug. Je worm zorgt er wel voor dat je via internet je saldo ook niet op kunt vragen. Je hebt dus minimaal 1 dag voor je fraude. Via diverse bankrekeningen in het buitenland kun je dan het geld vrij makkelijk contant opnemen.

[Verwijderd]

Verwijderd schreef op 18 januari 2004 @ 19:36:
[...]
Je moet er voor zorgen dat jouw computer de enige is die kan communiceren met de bank en niet de computer van de MITM. Dat kan uiteraard met een stuk hardware, maar misschien kun je softwarematig ook iets bereiken. Bijvoorbeeld een sleutel die op jouw systeem zit. Grote nadeel is het feit dat je aan mobiliteit gaat inboeten. Ik kan nu op elke plaats in de wereld mijn rekening bekijken. Met een vaste bankier pc kan dat niet meer.

Nadeel is dat die sleutel op je computer staat, en ook leesbaar wordt voor het programma dat de encryptie uitvoert. Elke worm/virus kan er specifiek op gericht zijn die sleutel te onderscheppen.

Mobiliteit is een erg belangrijk punt denk ik. Een klein usb device plus pasje kan je overal meenemen, zodat je ook bv in een internet-cafe kunt bankieren. Dan moet je op die computer natuurlijk wel een usb apparaat kunnen gebruiken (die kan zich eventueel zelfs als mass storage device voordoen, of iets anders waar altijd drivers voor zijn), en je moet een activex control of signed java applet kunnen gebruiken voor communicatie met het apparaat. Dat is al een beperking, maar al stukken beter dan vastzitten aan 1 pc.

[Verwijderd]

Nog even wat extra uitleg over de werking van het usb device dat ik voorstel, ik merkte dat er wat onduidelijkheid over bestond in een discussie op irc.

Een gebruiker voert alle handelingen voor het voorbereiden van de transacties via z'n browser uit, hij is natuurlijk wel eerst ingelogd. Het USB device versleutelt alle communicatie met de bank. Op dit punt kan een worm nog dingen spoofen, aangezien de gebruiker niet precies kan zien wat er exact over de lijn gaat. Anders wordt het op het moment dat een transactie of een aantal transacties geaccepteerd wordt:

• De computer verstuurt alle transactiegegevens via een browser-plugin naar het USB apparaat
• Het apparaat toont de transacties op het ingebouwde schermpje, dus bijvoorbeeld, naam, rekeningnummer, bedrag
• De gebruiker accepteert de gegevens, geeft de transactie vrij met z'n pincode
• Het apparaat versleutelt de bevestigde gegevens en stuurt ze terug naar de computer
• De browser-plugin ontvangt de gegevens van het usb apparaat en stuurt ze door naar de bank

Het grootste gevaar hierin ligt bij de gebruiker. Deze heeft immers de transacties via z'n browser al een keertje ingevoerd, daarna is hij misschien te lui om ze nog eens te controleren. Iedereen weet dat je voorzichtig moet zijn met je pasje en je pincode, maar de noodzaak van het controleren van de gegevens is misschien niet bij iedereen even snel doorgedrongen.

[Verwijderd]

Heb het hele topic zon beetje nu door gelezen en is wel interessant.

Ik blijf toch bij die e.dentifiers en RR's steken en ik vraag me af wat er in zon apparaatje gaande is.

Stel nou dat je er wel 1 open zou kunnen krijgen... Hoe wil je dit dan in godsnaam op de pc aansluiten om te zien wat er gaande is.

[TrailBlazer]

Welkom op GoT en ik denk dat je meteen genomineerd kan worden voor de grootste schop van het jaar. Het blijft een interessant onderwerp natuurlijk alleen om een topic waarin de laatste reactie al 3,5 jaar geleden is geplaatst heeft niet zo heel veel zin. Als je in Beveilig en virussen kijkt zijn er wel meer van dit soort topics die een stuk recenter zijn.

[Verwijderd]

o dat mag indd ook wel een hele harde schop zijn, foutje

[TrailBlazer]

Die schop was niet richting jouw bedoeld hoor maar sloeg op het topic. Een topic kicken is reageren in een topic waar al lang niemand meer heeft gepost.
Pas als je het een 2e keer doet worden we fysiek gevaarlijk