Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 48, views: 20.990 •
Submitter: hypetrax

De Android-applicatie van ABN Amro, waarmee klanten geld kunnen overmaken, bevatte een beveiligingslek waardoor man in the middle-aanvallen mogelijk waren. De applicatie controleerde niet of het gebruikte ssl-certificaat wel klopte.

ABN Amro logoDe ABN Amro-app voor Android controleerde wel of er een ssl-certificaat was, maar niet of de domeinnaam waarvoor het certificaat was uitgegeven wel juist was. Dat schrijven studenten van de Universiteit van Amsterdam in hun onderzoekspaper. Het paper stamt al uit december, maar is nu pas openbaar gemaakt door de universiteit.

Doordat het domein waarvoor het certificaat was uitgegeven niet werd gecontroleerd, was het voor een kwaadwillende mogelijk om de verstuurde gegevens te ontsleutelen. Daarvoor zou hij of zij eerst de internetverbinding van de gebruiker moeten onderscheppen via een man in the middle-aanval, bijvoorbeeld door een malafide wifi-hotspot op te zetten.

Op 17 december, enkele dagen nadat de studenten hun bevindingen meldden aan de bank, werd een gepatchte versie uitgegeven. Gebruikers die hun app niet hebben bijgewerkt, zijn echter nog steeds kwetsbaar, tekent de universiteit aan. Het is onduidelijk waarom de bank klanten met een onveilige versie van de applicatie niet blokkeert. De bank was niet bereikbaar voor commentaar.

Het is het tweede beveiligingsprobleem bij ABN Amro in een halfjaar tijd. In augustus bleek het mogelijk om het apparaat dat wordt gebruikt om de identiteit van de klant te controleren, te kraken. Transacties konden worden gemanipuleerd, waardoor kwaadwillenden geld zouden kunnen doorsluizen naar hun eigen rekening. Vorig jaar bleek dat de bankier-app van ING het ssl-certificaat van de bank niet controleerde.

Reacties (48)

Reactiefilter:-148047+126+212+31
de 2de fout is dat ik geen screenshots meer kan maken van mijn afschrift, erg lastig soms :( dit kon eerder nog wel
Zoals ik het artikel lees zijn er aantal problemen met de app:
- Eenvoudig te decompilen
Hierdoor is de logica ontdekt van de berichten over de lijn en het RSA gedeelte ontdekt.

- Vertrouwen op HTTPS voor het versturen van de (session) public key
Omdat HTTPS niet goed gecontroleerd wordt is het dus mogelijk deze public key te onderscheppen en te veranderen. Hierdoor kan de gegevensuitwisseling hierna kunnen worden uitgelezen/aangepast.

Ik vraag mij dan af waarom de ABN geen algemene private key gebruikt om het bericht waarmee de session public key verstuurd wordt te encrypten. Op deze manier zal je alleen de public key in de code vinden om de sessionkey te decrypten. Omdat je niet de beschikking hebt over de private key is het niet meer mogelijk om de public key aan te passen.

Vind het altijd een grote hersenkraker dat RSA dus ik ben erg benieuwd of het klopt wat ik zeg :)
Wel superhandig hoor die bankapps alleen voor je saldo en afschrijvingen te controleren dat dan weer wel helaas.
Die kant gaan we toch op alles word digitaal in de toekomst :*)
'Pro Tip': Alle mobiele bank applicaties zijn zo lek als een mandje, weten jullie nog? jaartje geleden hele campagnes tegen phising, en er word al jaaaaaaaren geroepen dat je geen bank zaken over een draadloze verbinding moet doen.

En ja, een telefoon verbind natuurlijk alleen maar draadloos, los van dat de telefoons zelf vaak ook behoorlijk 'lek' zijn, alles is simpel uit te lezen volgens mij.
Het is onduidelijk waarom de bank klanten met een onveilige versie van de applicatie niet blokkeert. De bank was niet bereikbaar voor commentaar.
Als software engineer weet ik wel hoe dit komt.

Je kan als software engineer nog zo'n ontzettende goede developer zijn, maar het zijn de managers die beslissen. En ten opzichte van een beetje software developer heeft elke manager wel last van ADHD. Beslissingen moeten snel en resoluut genomen worden, en de software engineer wordt al snel gezien als 'nee-zegger'. Hem wordt gevraagd om een uittreksel te maken, terwijl zoiets bij software beveiliging niet kan omdat elk detail belangrijk is.

Meestal komt het dan neer op 'mitigation' voor het geval de beveiliging inderdaad gehacked wordt. En dat is dan weer geen taak voor de software engineer. Dus die software engineer laat dat over aan een ander.

En ALS het dan mis gaat, om wat voor reden ook, dan blijkt meestal dat de mitigation niet serieus genoeg genomen werd en er eigenlijk geen procedures klaar liggen om de schade beperkt te houden.

Als software engineer kun je jezelf niet goed genoeg indekken tegen dit soort gevallen. Zorg er voor dat je je bezwaren aan zo veel mogelijk mensen overbrengt. Als dan na je implementatie blijkt dat het inderdaad snel gehacked is, kunnen ze JOU er in ieder geval niet de schuld van geven.

Heel jammer dat je als software engineer dit soort dingen moet doen.
Het probleem komt niet van 1 kant. Veruit de meeste softwareontwerpers- en bouwers die ik ken willen niks met management te maken hebbe ("suits"). Door de taal van managers te spreken kan je echter behoorlijk wat bereiken, en daar gaat het meestal mis. Als je het management in 2 zinnen de impact van een probleem kunt uitleggen dan wordt er echt wel wat mee gedaan. Je moet alleen niet, zoals ik vorig week meemaakte, over Java classes met de CTO gaan praten.
Uiteindelijk is de Security Manager ook verantwoordelijk voor het advies richting het hoger management. De engineer zal niet snel verantwoordelijk zijn voor dit advies, hooguit voor de correctheid van de gegevens en informatie die hij aanlevert aan de Security Manager.

Als je als bedrijf de controle en adviserende rol bij de uitvoerende kant (System Engineer/Software Engineer) dan ben je sowieso al niet slim bezig. Er moet altijd een scheiding zijn tussen de controlerende (audit) kant en de uitvoerende kant. Anders krijg je belangenverstrengeling.
Precies. En aangezien het niet controleren van de domeinnaam in een SSL certificaat een beginnersfout is, had dit door de controlerende kant gevonden moeten worden.

Waarom is zoiets als dit er dan doorheen geglipt?

Maar wat nog erger is: Er was heel snel een patch. Prima! Maar de bank heeft niemand ingelicht, waardoor er nog veel mensen zijn die hun software nooit hebben geupdate.

Het is toch echt een management-beslissing geweest om de mensen niet in te lichten.

Ik vind dat erg laakbaar, de bank laat mensen onnodig risico's lopen. Ik zou verwachten dat de verantwoordelijke manager inmiddels thuis sollicitatiebrieven zit te schrijven.

Maar goed, ik ben nooit fan geweest van ABN-AMRO, en ik krijg al jaren alleen maar bevestiging dat dat terecht is.
Ja dit is wel een beetje een aanname hoor.

Er kan ook makkelijk een fout gemaakt zijn, zoals hierboven al aangehaald door raugustinus de verkeerde class gebruikt ofzo.

Uiteindelijk moet er wel geld verdient worden, dat doe je niet door alle mogelijke veiligheidsvragen te proberen te beantwoorden, zelfs niet bij een bank. Dat is meer een taak voor universiteiten en andere bedrijven.
Naja, goed, het kan ook een software engineer zijn die onvoldoende ervaring heeft.

Maar je zou niet verwachten dat een bank een onervaren software engineer laat werken aan een betaalapplicatie.
Uiteindelijk moet er wel geld verdient worden, dat doe je niet door alle mogelijke veiligheidsvragen te proberen te beantwoorden, zelfs niet bij een bank.
Kijk, en DIT is natuurlijk een ONTZETTEND foute uitspraak...

Als de betaalapp namelijk niet goed is, is het niet de bank die de problemen heeft, maar de gebruiker. De gebruiker kan het natuurlijk weer proberen te verhalen op de bank, maar dat kost hem tijd, geld en stress waar hij niet op zit te wachten.

Wat jij eigenlijk zegt is dat de bank uit winstbejag best bereid mag zijn om zijn klanten risico's te laten lopen...

Ik denk dat veel mensen het daar oneens mee zijn. Een bank heeft een maatschappelijke verantwoordelijkheid, en die verantwoordelijkheid mag simpelweg niet ondergeschikt gesteld worden aan winstbejag. Doordat banken dat wel hebben gedaan zitten we nu in een crisis en kunnen we de komende paar jaar geen cent uitgeven omdat alles aan belasting op gaat.
Interessant, waarschijnlijk gebruikt ABN de http://developer.android....ificateSocketFactory.html ipv de http://developer.android....l/HttpsURLConnection.html welke standaard al de hostname verification doet.

Waarschijnlijk wel een beetje slordig tenzij ABN geen HTTP gebruikt voor de communicatie met hun servers.
Als gebruiker bescherm ik mijzelf. en installeer ik altijd de nieuwste app van mijn bank. Je kan stellen dat mijn veiligheid van mijn rekening alleen verantwoordelijkheid is van de bank. Maar ik zorg ervoor dat ik als klant zo veel mogelijk veilig probeer te handelen zo dat de kans het kleinst is dat mijn rekening iets overkomt.
Als gebruiker bescherm ik mijzelf. en installeer ik altijd de nieuwste app van mijn bank.
Nieuwe versie van een app heeft ook weer nieuwe bugs in zich. Dus juist met jouw instelling kun je wel eens meer risico lopen dan je wil.

Zo makkelijk als jij denkt is het niet...
Dus..

-De boef moet eerst het internetverkeer van de telefoon onderscheppen
-Dan wachten totdat er iemand langs komt met een android toestel
-Dan hopen dat diegene zijn ABN-AMRO APP opstart
-Dan kan je de "pincode' onderscheppen (zoals er staat in het originele artikel) maar dit is niet juist, de code die je gebruikt in de app is anders als die EMV chip staat

Als iemand dus AL die moeite heeft gedaan kunnen ze geld overmaken naar mijn eigen glazenwasser of iemand anders met wie ik zaken doe...

Ik vraag me af of het echt wel de moeite loont om dit uit te voeren, ik denk dat zakkenrollen sneller geld oplevert.

[Reactie gewijzigd door Alcmaria op 13 februari 2013 14:34]

Er is een heel makkelijke social-enginering te bedenken om veel mensen bij elkaar te hebben, te laten internetten via jou AP en dan hopen dat er iemand gaat internet bankieren. Denk aan een AP bij Koning(inne)dag, 5 Mei, Lowlands, wat niet al meer.

Hierboven is al eerder gezegd dat het met goedekope hardware en beschikbare (OS?) software kan worden gedaan, je hoeft dan alleen een eigen AP op te zetten, mensen daarop in te laten loggen (Gratis WiFi, iemand?) en te wachten op de pakketten. Als je het bij mij om de hoek gaat doen, hoeft het geen probleem te zijn. In andere gevallen waarschijnlijk wel.
Je zit ernaast. We hoeven enkel de DNS entry naar www.abnamro.nl aan te passen.

Dit kan bijvoorbeeld door:
-DNS Poisoning.
-Malware die de hostfile aanpast op de telefoon.
-Een "onveilig" wifi netwerk.

Geld moet juist overgemaakt worden naar een rekening die niet eerder gebruikt is (waarvoor dus een e-dentifier nodig is) om de transactie te kunnen aanpassen.

Is dit een hack die een kwaadwillende veel geld oplevert? Nee... Toch is het spijtig dat deze fout in de app zat. Ik wil namelijk liever niet dat andere mensen inzicht hebben in mijn financiele zaken, dat is prive.

Daarnaast gebruiken veel mensen een pin-code in de applicatie waarin hun daadwerkelijke pin-code (van hun bankpas) zit verwerkt.
-De boef moet eerst het internetverkeer van de telefoon onderscheppen
-Dan wachten totdat er iemand langs komt met een android toestel
-Dan hopen dat diegene zijn ABN-AMRO APP opstart
-Dan kan je de "pincode' onderscheppen (zoals er staat in het originele artikel) maar dit is niet juist, de code die je gebruikt in de app is anders als die EMV chip staat
Punt 1: Da's niet zo moeilijk. Veel gebruikers hebben 'automatically connect to wifi' aan staan, dus je hoeft bij de supermarkt of pompstation alleen maar een open wifi hotspot neer te zetten. De telefoon doet de rest.

Punt 2: Er zijn ontzettend veel mensen met een Android toestel. En pompstations hebben ontzettend veel klanten.

Punt 3: Bij een pompstation is de kans groot dat dat gebeurt. Tenzij de app gewoon onhandig is.

Punt 4: Als je die pincode hebt, kun je in ieder geval als man-in-the-middel zelf een transactie in elkaar frutselen en die authoriseren. De SSL connectie met de bank heb je al, en de code krijg je van de Android telefoon. Simpel om achter de transactie van de telefoon nog even snel je eigen transactie te sturen die eenzelfde bedrag overmaakt, maar dan naar jouw eigen rekening.

Of om het rekeningnummer van het pompstation te vervangen door je eigen rekeningnummer, en gewoon het geld te stelen. Dan gaat als klant je betaling aan het pompstation wel niet door, maar dat is niet het probleem van de hacker.

Er zit nog meer aan vast, want het geld moet weer weggesluisd worden van de rekening naar een anonieme rekening. Maar dat zijn technicalities.
Inderdaad, hoewel dit zeer ernstig is (het niet controleren van het certificaat), is er niet een zeer grote dreiging geweest volgens mij.

Ik denk dat de interne huishouding aan de kaak gesteld moet worden. Want het is schandalig dat dit soort zaken nog steeds kunnen gebeuren. En kennelijk is de imagoschade niet groot genoeg dat ze hier nog steeds geen adequate maatregelen voor nemen. Je zou verwachten dat met de peperdure ontwikkelstraten en protocollen dit soort zaken niet kunnen gebeuren.

Tegelijkertijd moet wij (consument) steeds meer betalen aan bankrekeningen onder het mom van extra beveiligingen ed. Vroeger waren rekeningen gratis!

Wanneer worden hier eens kamervragen over gesteld?
Vroeger kon je alleen geld opnemen bij de Balie, tussen 10 uur 's morgens en 4 uur 's middags en niet in het weekend. Dus als je vrijdag vergeten was geld te halen .. kon je niks!.. er waren nog geen ATM's, geen betaalterminals, niks...

Als je geld over ging maken naar iemand anders moest je overboekingsformulieren halen, die invullen en dan in de brievenbus bij de bank gooien.

Je wist pas of je salaris gestort was als je 1x per maand je bankafschrift kreeg.

Dus tja.. zijn we er echt zo op achteruit gegaan?
Ja, we zijn over de optimale-product curve heen.

ICT was een progressie-tool , winst opleverend.

Nu is het te grootschalig, divers, en de basis voor 'zaken' waar je dat niet wil.

Oftewel het begript 'TE' veel ict, dus meer fouten, grotere bedragen(danwel meer kleine) weg, WANT gemaakt door feilbare mensen.

Dat crimi's hun best blijven doen en voor blijven lopen vooralsnog zegt gewoon opzich al genoeg.
Het eigen risico en de veiligheids eisen voor de klant zijn sick, nietmand is 100% up to date, ook die banken niet zo blijkt telkens weer. En dan nog...

Ook al word de boef gepakt, hun motto is en blijft 'elke kluis is te kraken'.
"Tegelijkertijd moet wij (consument) steeds meer betalen aan bankrekeningen onder het mom van extra beveiligingen ed. Vroeger waren rekeningen gratis!

Wanneer worden hier eens kamervragen over gesteld?"

Waarom ga je niet naar een andere bank? zoals je het zelf al zegt je bent consument dus zij (banken) kunnen geld vragen voor bepaalde/alle diensten.
Ben je het hier niet mee eens kan je altijd nog naar een andere bank.
Ik heb ooit nog rente gekregen op mijn gewone betaalrekening. Was slechts een paar tienden van een procent, maar toch.
Ja een 'boef' kan er eigenlijk niet zoveel mee, of het moet een heel ingewikkelde constructie worden. Je moet namelijk een rekening gebruiken die je eerder (meen een jaar terug maximaal) hebt gebruikt in het telebankieren.

Ook als ze het verkeer onderscheppen en het bedrag en rekening wijzigen lijkt mij dat dit rekeningnummer bij verificatie niet gebruikt is en wordt de betaling afgekeurd.
Helaas is dat geen enkel probleem. Als iemand al een grotere transactie heeft staan (default limieten kan je aanhouden als malafide app) dan krijg je, tot een bepaald totaalbedrag, alleen 1 willekeurig gekozen code die je op je eDentifier moet invoeren. Ook kan je daarna de malafide transacties filteren in het overzichtsscherm.

En nog mooier: nadat iemand 1x zo'n transactie heeft geaccordeerd kan de boef per dag het maximumbedrag overmaken naar zijn rekening, tot hij gepakt wordt, zodra hij 1x de pincode 'ziet' (bijv bij het inloggen).
De eerste keer dat je geld overmaakt via de app, moet je de edentifier gebruiken, dus zul je al geld moeten hebben overgemaakt naar de kwaadwillende. Daarnaast moet je bij bedragen boven de 500,- sowieso de edentifier gebruiken.
Alleen, als je het verkeer opvangt kun je het ook aanpassen.
Dus als ik 10 euro wil overmaken, de tussenpersoon maakt daar 500 van en stuurt dat naar de abnamro website. Die stuurt iets terug met een code die je moet invoeren, de tussenpersoon vervangt de bedragen erin en mogelijk de tekst en je bent klaar..
80% van de mensen controleren niet in het tussenliggend scherm of de tekst die ze zien (oftewel het stappenplan) nog gelijk is en wat ze normaal zien.

(overigens ben ik hier even uitgegaan van de rabobank schermen, geen idee welke schermen/stappen er bij de abn amro voorbij komen).
Wat ik vooral ernstig vind is dat ABN niet zelf meteen is gaan checken of haar app wel veilig was nadat bij ING precies dit lek al was gevonden. Wat dat betreft was dit een makkelijke opdracht voor de studenten, gewoon lekken bij andere banken nalopen. Dat kunnen criminelen dus ook doen.
Ze gaven aan dat ze dit wel deden, maar dan enkel met een self signed certificate. Wij hebben een certificaat voor ons eigen domein gebruikt, wat gesigned was door een trusted third party.

Op dit item kan niet meer gereageerd worden.