Kan internetbankieren veilig zijn?

[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.

[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