Cookies op Tweakers

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: 21.274 •
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
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...
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.
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.
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.
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.
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.
'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.
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 :*)
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 :)
de 2de fout is dat ik geen screenshots meer kan maken van mijn afschrift, erg lastig soms :( dit kon eerder nog wel

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Samsung Smartphones Privacy Sony Microsoft Apple Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013