Girotel Online Hacking

Sinds 2002-11-08 werkt de Girotel Online site van de Postbank niet meer goed onder Linux met Mozilla, en op Mozilla gebaseerde browsers zoals Netscape 7 en Galeon. Omdat de Postbank tot op heden weigert hier iets aan te doen, is het tijd voor wat zelfwerkzaamheid.

[2003-08-06] Update: De Postbank heeft gereageerd, en heeft een aanpassing gemaakt ten behoeve van de Linux gebruikers! Het blijkt nu niet meer nodig om het hieronder beschreven proxy script te gebruiken. Het was een zware bevalling (9 maanden), maar moeder en kind maken het goed. Kennelijk hebben de diverse protest akties toch effect gehad, zoals blijkt uit dit artikel van Planet Internet. De mooiste quote vind ik "Het gaat om een relatief klein aantal klachten, maar die klachten zijn wel intensief". Ook Webwereld heeft een artikel.

Inloggen gaat in het algemeen goed, en de Girotel Online site lijkt te werken, totdat je een overschijving wilt doen. Na het invullen van de TAN code, en klikken op Versturen, krijg je een Javascript fout: Er is een probleem bij het initialiseren van de JAVA-applet. (Meldingscode: 3701)

Het probleem lijkt veroorzaakt te worden door een timing probleem bij het opstarten van de Javascript code en het Java applet dat nodig is voor het versturen van overschrijvingen. Het Java applet is meestal nog niet volledig opgestart op het moment dat de Javascript code dat verwacht. Het gevolg is dat het versturen van overschijvingen niet werkt. Soms helpt het om voordat je inlogt een reload van de inlogpagina te doen, maar deze truuk werkt niet bij iedereen. De code bevat kennelijk race conditions.

Ik heb het verkeer naar de Girotel Online site afgeluisterd door er een logging proxy script tussen te zetten, dat ik nog had liggen. Een probleem was alleen dat de site gebruik maakt van een gecrypte HTTPS verbinding. In eerste instantie heb ik daarom een tweede proxy gebruikt die ik ergens op het net vond (sslproxy). Deze proxy zet HTTP om in HTTPS.

Het proxy script is in Python geschreven, en na wat zoeken in de Python documentatie bleek het erg eenvoudig om een SSL verbinding direct vanuit het Python script op te zetten. Ik heb toen een nieuwe versie van het script gemaakt, die direct een verbinding met de Girotel Online site maakt. Het werkt als volgt: in de browser gebruik je als URL:

http://localhost:2000/

Op poort 2000 luistert het proxy script die het verkeer in een log file kopieert, en alle data doorstuurt naar:

https://gto.postbank.nl:443/

Bovenstaande oplossing werkt niet zonder meer, omdat er ook URL's heen en weer gaan, die door het gebruik van de proxy niet kloppen. Daarom worden in het proxy script URL's vervangen. Met deze constructie is het mogelijk om in te loggen op Girotel Online, maar de fout bij het overschrijven blijft bestaan.

De Girotel Online inlog pagina is zeer complex. Hij bestaat uit een aantal frames, die later met behulp van Javascript worden voorzien van een nieuwe inhoud. De gebruikte Javascript code is door een obfuscater gehaald, waardoor de layout en de oorspronkelijke identifiers zijn verdwenen. Het is daarom lastig de code te begrijpen.

In één van de frames wordt een Java applet geladen. Als dit frame compleet is, wordt een Javascript functie aangeroepen die controleert of de initialisatie van het Java applet is gelukt. Blijkbaar komt deze test te vroeg, want hij faalt meestal, waardoor ten onrechte geconcludeerd wordt dat Java niet beschikbaar is. Vervolgens wordt overgeschakeld naar een ActiveX applet! Op Linux nota bene! Dat lukt natuurlijk ook niet, maar je merkt dat pas als je een overschrijving wilt doen. In de log file van het proxy script kun je deze fallback naar ActiveX volgen aan de hand van de opgevraagde URL's:

GET /GTO/GNDH0576_Mosaic.html?MacMethod=JAVA HTTP/1.1
GET /GTO/PBGN.jar HTTP/1.1
GET /GTO/GNDH0576_Mosaic.html?MacMethod=ACTIVEX HTTP/1.1

Nu we ongeveer weten wat er mis gaat, is de volgende stap het wijzigen van de Javascript code. Dat kan on-the-fly in het proxy script, op dezelfde manier waarop de URL's vervangen worden.

Als eerste heb ik een alert() functie toegevoegd, die een popup geeft als de initialisatie van het Java applet is gelukt. Je hoeft dan niet een test overschrijving te doen, maar ziet meteen of het goed is. Na wat experimenteren, heb ik een tweede modificatie in het proxy script gezet, die een (te vroege) initialisatie bij het laden van de inlog pagina overslaat. Het blijkt dat de overgeslagen functie alsnog wordt aangeroepen als je op Inloggen klikt. Je moet alleen even wachten totdat het Java applet is geinitialiseerd (Applet g1 started in de status balk). Het inloggen zal nu iets langer duren dan normaal, vanwege de initialisatie. Als je nu een popup krijgt met Applet is loaded, dan is alles goed gegaan, en kun je overschrijvingen doen.

Bedenk wel dat met deze hack het SSL certificaat niet gecontroleerd wordt.

Het proxy script met de bovengenoemde wijzigingen werkt met een Python versie vanaf 2.0. Je moet dit gtoproxy script downloaden, executable te maken, en opstarten zonder verdere argumenten. Je kunt dan girotellen zonder het beruchte 3701 probleem via de volgende URL:

http://localhost:2000/

Voor alle duidelijkheid: je moet dit niet als proxy instelling gebruiken, maar direct aanklikken of invullen in de URL balk.

[2003-07-30] Update: Naar aanleiding van een suggestie van Rogier Wolff heb ik een variant van het proxy script, gtoproxy2 gemaakt, die in plaats van de popup bij het inloggen de kleur van het inlog venster even groen maakt als indicatie dat het laden van het Java applet is gelukt. Als de kleur rood wordt, is de initialisatie niet gelukt. De DOM code die ik hiervoor gebruik werkt trouwens niet in Netscape 4, maar GTO werkt in deze browser ook zonder proxy script.

[2003-08-02] Update: Er is inmiddels een derde versie van het proxy script, gtoproxy3. Het is gebaseerd op een nieuwere versie van het orginele proxy script, en heeft de volgende verbeteringen t.o.v. gtoproxy2:

• Het bewaren van het girotelnummer en codenummer werkt nu!
• Je kunt nu ook vanaf andere computers op je lokale netwerk de GTO proxy gebruiken. De vorige versies moesten op de lokale computer draaien. Waarschuwing: doe dit alleen in een volledig vertrouwde omgeving, want GIN en TAN codes gaan op deze manier onversleuteld over het netwerk!
• Je kunt de proxy met de -p optie op een andere poort dan 2000 laten luisteren. Als je poort 80 gebruikt (waarvoor je root moet zijn), hoef je geen poort nummer meer in de URL te zetten.
• Je kunt namen toekennen aan de rekening nummers in de list-boxes, wat handig is als je meerdere rekeningen beheert. Je moet hiervoor de voorbeeld patronen in het script aanpassen.

[2003-08-05] Update: De GTO site van de Postbank is aangepast, en het lijkt nu te werken met Galeon en Mozilla, zonder gebruik te hoeven maken van het proxy script! Het blijkt dat ze, zoals in onderstaande conclusie gesuggereerd, voor een aantal browsers het onLoad attribuut in de file GNDH0576_Mosaic.html weglaten. Ze doen dit niet voor Gecko browsers, maar voor alle browsers met de woorden Linux of Mac in de User-Agent header. Als deze twee woorden ontbreken, dan staat het onLoad attribuut er wel. Het Java applet is niet gewijzigd, alleen de RSA key is nieuw. Helaas is de code opnieuw door de obfuscator gehaald, zodat alle variabelen weer een andere naam hebben gekregen. Het proxy script werkt daardoor niet meer goed. Het is misschien niet meer nodig, maar ik heb toch nog een vierde versie, gtoproxy4, gemaakt, die nu onafhankelijk van de gekozen variabelen namen werkt. Het zou best kunnen dat je dit proxy script nog steeds nodig hebt als je iets anders dan Windows, Linux of MacOS gebruikt, b.v. FreeBSD of SunOS.

Het is nu ongeveer duidelijk wat er mis gaat, maar niet waar precies de fout zit. Kennelijk is in andere browsers zoals b.v. Internet Explorer het Java applet al volledig geinitialiseerd op het moment dat het onLoad event van de <BODY> tag optreedt. In Mozilla is dat dus niet altijd het geval. Ik weet echter niet of dit soort volgordes ergens gedefinieerd zijn. Zo ja, dan zit er een bug in Mozilla. Zo nee, dan bevat de Girotel Online code een race conditie, en is dus fout.

Afgezien van de schuldvraag, is dit probleem door de Postbank relatief eenvoudig op te lossen door voor alle op Mozilla (Gecko) gebaseerde browsers het onLoad attribuut in de file GNDH0576_Mosaic.html weg te laten. Het zou natuurlijk nog beter zijn om de code zo ver te vereenvoudigen dat dezelfde versie werkt met alle browsers. Helaas is het vaak zo dat het vereenvoudigen veel moeilijker is dan het complexer maken.

Een andere tip voor de Postbank: geef een popup met een waarschuwing als zowel het Java applet als het ActiveX applet niet geladen kunnen worden. Je ziet dan meteen dat er iets mis is, en weet dat het geen zin heeft om overschrijvingen in te voeren.

dick@streefland.neti bait+gto2@streefland.net

2006-06-03