Cache-ups: Netværks- og klient-info tilgængelige i Danske Banks HTML-kode

Hjemmesiden for Danske Bank var i en periode i debug-tilstand, så klient-ip-adresser og interne server-informationer fremgik af HTML-koden. Der har ikke været adgang til netbank-data, understreger bankens it-sikkerhedschef.

En fejl i relation til Danske Banks hjemmeside har bevirket, at det i en periode på tre uger blandt andet har været muligt at se ip-adresser for vilkårlige brugere i HTML-koden bag siden, ligesom informationer om den interne netværksstruktur hos banken også har været synlig.

Danske Bank har nu ændret i server-setuppet, så informationerne ikke længere er tilgængelige.

»Man kan spørge, om det skulle have været tilgængeligt. Og nej, det skulle det ikke,« siger koncern it-sikkerhedschef i Danske Bank Poul Otto Schousbo og tilføjer:

»Det er vigtigt at understrege, at der ikke har været adgang til netbank. Og at oplysningerne ikke kunne bruges til at skabe adgang til netbank eller kundedata. Det har ikke noget med den kanal at gøre.«

Når de utilsigtede informationer i første omgang har været tilgængelige i koden bag Danske Banks hjemmeside, skyldes det, at bankens system ved en fejl har været sat i debug-tilstand, forklarer Poul Otto Schousbo.

Altså en tilstand, hvor udviklere får ekstra informationer fra eksempelvis en server for gøre det lettere at finde kodefejl. De ekstra informationer lader blandt andet til at have været ip-adressen for klienten - altså en opkoblet bruger - og samt hvilken browser og hvilket operativsystem, klienten anvender.

Og da Danske Banks hjemmeside - som mange andre hjemmesider - anvender en cache, så er det klientinformationer fra sidst cachen blev opdateret, der har været synlige i HTML-koden og ikke nødvendigvis informationer for den aktuelle bruger.

Så på den måde har det principielt været muligt for brugere at se blandt andet ip-adresse og browser- og styresystemsinformation for andre brugere. Uden det dog er ensbetydende med, at den faktiske identitet på disse brugere er kendt.

En fejl

På spørgsmålet om, hvordan Danske Banks driftsmiljø var havnet i debug-tilstand, svarer Poul Otto Schousbo:

»Det var en fejl, andet kan jeg ikke sige. Det skal ikke ske, og vi har været igang med et arbejde for at sikre, at det ikke sker. Vi har implementeret nogle kontroller, og nu arbejder vi på at forbedre dem, så vi kan sikre, at sådan noget ikke gentager sig.«

Han fortæller, at systemet bag hjemmesiden har været i debug-tilstand i tre uger, og at det stoppede den med at være 27. august.

Den dato fik hollandske Sijmen Ruwhof hul igennem til Danske Bank. Det var ham, som i første omgang opdagede, at noget var galt i HMTL-koden på bankens hjemmeside.

På sin Twitter-profil beskriver Sijmen Ruwhof sig som freelance sikkerhedskonsulent.

I et blogindlæg dateret 4. oktober fortæller Sijmen Ruwhof, hvordan han ved at kigge nærmere på HTML-koden bag Danske Banks hjemmeside, faldt over langt flere informationer, end der umiddelbart burde kunne læses i HTML-koden.

Blogindlægget har titlen »Hvordan jeg kunne hacke internet-bankkonti hos Danmarks største bank.«

De klient-data, som Sijmen Ruwhof i blogindlægget umiddelbart hæfter sig mest ved at have haft adgang til, er cookie-informationer. Som det vil være flere Version2-læsere bekendt bliver nogle cookies eksempelvis brugt til at opretholde en login-session, og Sijmen Ruwhof spekulerer i den forbindelse over, hvorvidt han ville have kunne have overtaget en brugers netbank-forbindelse med dataene.

Det afviser Poul Otto Schousbo fra Danske Bank blankt, skulle have været en mulighed.

»Fordi systemet har været i debug-tilstand, så er cachedata blevet gemt for en anden klient. Antagelsen i indlægget er, at der er tale om netbank, men den antagelse er forkert. Det er vores offentlige interface. Og der bruges caching jo som standard.«

For at være på den sikre side, gennemgik Danske Bank systemerne og hændelsesforløbet en gang til på baggrund af offentliggørelsen af blogindlægget.

»Det er klart, at efter vi læste blogindlægget, så validerede vi en gang til, om vores oprindelige vurdering var korrekt, og det er den. Det har ikke noget med netbank at gøre. Der har ikke været adgang til kundedata, og de data, der har kunnet ses, har ikke kunnet bruges til at skabe adgang til kundedata.«

Mødte danskere nær Berlin

Sijmen Ruwhof fortæller, at han fik idéen til at kigge i koden hos Danske Bank, da han i august var på besøg hos Chaos Communication Camp nær Berlin.

Her mødte han nogle danskere, og de kom til at tale om sikkerhed generelt i danske banker, og om hvordan det står sløjt til med SSL-sikkerheden på flere danske bankhjemmesider.

En af de banksider, hvor det på daværende tidspunkt så skidt ud i forhold til SSL var Danske Banks side. (Sidenhen har Version2 testet sitet via Qualys SSL Labs, og for så vidt SSL angår, ser bankens hjemmeside nu ud til at være i noget bedre stand, end da Sijmen Ruwhof testede den.)

Det daværende SSL-niveau på sitet fik Sijmen Ruwhof til at tænke, at der måske også var andre ting at komme efter på siden. I den forbindelse kiggede hollænderen i HTML-koden bag login-siden til netbank-delen af Danske Banks hjemmeside. Altså der, hvor mange danskere bliver bedt om at taste deres NemID-info for at komme i netbanken.

Klient- og server-informationer

I den forbindelse faldt Sijmen Ruwhof over javascript-kode med kommentarer, der så ud til at indeholde data, der ikke var ment til at være frit tilgængelige.

Ved at gå koden nærmere efter fandt Sijmen Ruwhof frem til flere variabler med blandt andet interne netværks-informationer. Eksempelvis interne ip-adresser, database-oplysninger og den absolutte sti, som webserveren kører i relation til.

Og hvad klient-informationer angår fandt Sijmen Ruwhof variablerne HTTP_CLIENTIP, HTTP_USER_AGENT og HTTP_COOKIE, der som navnene antyder viste sig at indeholde henholdsvis informationer om en klients ip-adresse, en klients browser og operativsystem og ikke mindst cookie-informationerne.

For ikke at gøre noget ulovligt, lod Sijmen Ruwhof dog være med at teste, om cookie informationerne kunne bruges til at overtage en netbank-session. Hvilket ifølge Poul Otto Schousbo altså heller ikke ville have været en mulighed.

I første omgang rettede Sijmen Ruwhof henvendelse til Danske Bank via telefonnummer, som han fandt via bankens hjemmeside. Det kom der umiddelbart ikke noget ud af. Først da Sijmen Ruwhof via LinkedIn kontaktede en person inden for it-sikkerhed hos Danske Bank forsvandt dataene fra hjemmesiden.

V2-blogger hjalp med LinkedIn

Det var direktør i Solido Network Henrik Kramshøj, der var en af danskerne, som Sijmen Ruwhof mødte ved med at finde frem til rette vedkommende hos banken via LinkedIn.

Udover at være blogger på Version2, så er Henrik Kramshøj vidende inden for it- og netværkssikkerhed.

»Det er basalt set mega pinligt for deres pentest folk, interne eller eksterne, og/eller for de driftsfolk der har slået det til og glemt at slå fra igen (debug-tilstand, red.),« skriver Henrik Kramshøj over en Skype-chat med Version2.

I sit blogindlæg nævner Sijmen Ruwhof værdien af flere af de parametre, der ser ud til at relatere sig til bankens interne netværks-setup. Sijmen Ruwhof skriver dog også, at han har ændret lidt på værdierne for ikke at videregive den nøjagtige information.

Og det er måske en god idé for ifølge Henrik Kramshøj kan den slags oplysninger potentielt bruges af en ondsindet hacker til at trænge i bankens systemer.

Værdien for parameteren APPL_PHYSICAL_PATH er i blogindlægget eksempelvis oplyst til at være: ‘d:\data\iis\www.danskebank.dk\wwwroot\’

»Afsløring af webroot - dvs. der hvor dokumenter ligger på systemet - kan gøre diverse angreb nemmere,« skriver Henrik Kramshøj.

Han forklarer, at med kendskabet til 'd:\data\iis\www.danskebank.dk\wwwroot\' »så ved man, at for at komme til roden skal man bruge ........«

Også informationer om database og interne ip-adresser kan misbruges til at kompromittere systemerne, påpeger Henrik Kramshøj.

I forhold til offentliggørelsen af, hvad der lyder til at have været interne netværks- og server-oplysninger siger Poul Otto Schousbo:

»De oplysninger skulle ikke have været tilgængelige, men de ville ikke kunne anvendes til noget.«

På baggrund af henvendelsen fra Sijmen Ruwhof, der altså måtte en tur om LinkedIn, vil Danske Bank fremover gøre det nemmere at komme i kontakt med banken, skulle man falde over noget mærkeligt i koden eller andre steder.

»Vi sørger for, at det via hjemmesiden bliver nemt og tilgængeligt i forhold til at rapportere sådan noget her,« siger Poul Otto Schousbo.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
Martin Jensen

Jeg ville som journalist udbede en teknisk redegørelse fra DanskeBank af hvorfor hollænderen ikke havde ret i sin antagelse om at han ville kunne overtage en session.

Det at man 'debuggede i produktion' lyder som en bekvem forklaring. Debug outputtet var på prod, og måtte vel være gyldigt?

Povl H. Pedersen

HTTP på indersiden af load balancer er meget normalt. Det er der ikke noget galt i. Det kræver "bare", at man skal have fornøden fokus på cleartext zonen.

Derudover, så passerer de samme data de fleste steder videre fra front-end til middleware til backend ukrypteret. Så HTTPS ind til frontend serveren er ingen garanti for at data ikke opsnappes.

Så man skal sikre sig, at man har styr på alle komponenterne, og den logiske såvel som fysiske adgang, på alle relevante komponenter.

Benjamin Bach

»De oplysninger skulle ikke have været tilgængelige, men de ville ikke kunne anvendes til noget.«

Den går ikke.

Problemet er, at oplysningerne bliver anvendelige sammen med andre sikkerhedshuller. Derfor er en følsom oplysning et sikkerhedshul, uanset om den er anvendelig i sig selv. Eksempel: Hvis der er et hul, der gør det muligt at uploade uautoriseret indhold på serveren. Så siger Danske Bank nok "den oplysning kan man ikke anvende til noget, da man ikke ved, hvor server-roden er". Men hov se, nu er serverroden jo lækket, og de to forskellige indirekte sikkerhedshuller giver kombineret et konkret kæmpe-problem.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017

Affecto has the solution and the tools you need

According to GDPR, you are required to be in control of all of your personally identifiable and sensitive data. There are only a few software tools on the market to support this requirement today.
13. sep 2017