Danish Bank Leaves Server In Debug Mode, Exposes Sensitive Data In JS Comments

An anonymous reader writes: Dutch IT security expert Sijmen Ruwhof has found a pretty big blunder on the part of Danske Bank, Denmark's biggest bank, which exposed sensitive user session information in the form of an encoded data dump, in their banking portal's JavaScript files. The data contained client IP addresses, user agent strings, cookie information, details about the bank's internal IT network, and more. He contacted the bank, who fixed the issue, but later denied it ever happened.

Similar experience here

[vikingpower]

I once did a penetration test on a web site / app running under Tomcat, for an Austrian ministry. (Someone breaking into the system might have involved quite the financial loss.) I broke off the test after a couple of minutes: the guys, eager to "do devops", had deployed binaries... and a .jar file with the complete source code.

Re:

[sexconker]

Then those credentials would be in a compiled binary.
The proper way to do credentials is to supply them by hand when a server/service starts up.
Yes, that means physical, human intervention every time the server/service restarts.

Re:

[bobbied]

Unless there's DB credentials or other sensitive information in it.

DB credentials In the SOURCE code? security: FAIL.

You NEVER put the DB credentials in the source, nor do you put things like internal IP's or hostnames. NEVER EVER. At the very least you put stuff like this in separately maintained configuration files. If you are wanting real security then you encrypt said files and provide the decryption key upon system startup. Just putting in plain text credentials is akin to hard coding SQL statements and other such foolish things I've seen folks do. If you have

Re:

[Zontar The Mindless]

Indeed, it's quite annoying.

Clean up your code!

[neoritter]

Seriously, clean up your code before committing or signing off on a task.

They didn't deny it happened, just that it was bad

[xxxJonBoyxxx]

From TFA, the bank wrote "We investigated your report immediately. However, the data you saw was not real customer sessions or data – just some debug information. Our developers corrected this later that day."

Sounds like a lot of crying over nothing. The bank acknowledged and fixed the problem. Winning, right?

Re:

[MTEK]

We investigated your report immediately. However, the data you saw was not real customer sessions or data – just some debug information.

--Baghdad Bob

These are not the Auth Cookies you are looking for

[MnO-Raphael]

The researcher didn't actually test if he could hijack a session.

If he had tried he would see that the cookies in question are not authentication cookies used by the bank. The cookies in question are described as 'statistical' cookies on http://www.danskebank.com/en-u... [danskebank.com]

I'm really amazed about the publicity one single blogger can get with such undocumented claims.

Re:These ARE the Auth Cookies you are looking for

[Bite The Pillow]

That page does not list these two cookies:

mbox=session#1440619645928-786416#1440611516;
QSI_HistorySession=http%3A%2F%2Fwww.danskebank.dk%2Fda-dk%2FPrivat%2FPages%2FPrivat.aspx~1440619560049

It's clearly ASP.NET, and WebForms. The dump is the Request.ServerVariables collection, and if you need to debug issues it's fairly standard. If you need to put it in production code, though, you always put it on a server that your load balancer will skip, because that should not be seen, at all, by anyone.

But how would

Re:

[MnO-Raphael]

QSI_HistorySession is listed as a "user survey" cookie on the danish version.

mbox is probably Site Catalyst: http://cookiepedia.co.uk/cooki... [cookiepedia.co.uk]

Anyway, A danish customer checked it and found out that session related cookies to the homebanking solution (which is hosted elsewhere) is called NSSID. https://twitter.com/kimtiede/s... [twitter.com]

They should have

[phantomfive]

They should have bought this book [amazon.com].

False Alarm

[m2pc]

The part where they wrote that the "HTTP_CLIENTIP" variable was apparently someone else's (another bank customer's) IP seems incorrect.

Analyzing the data I saw something strange. My own IP address wasn’t listed in variable HTTP_CLIENTIP and this listed address was also not an internal server IP address. When I translated IP address 80.166.145.257 to the corresponding fully qualified domain name, the result I got was 80-166-145-257-static.dk.customer.tdc.net. Notice the .dk in the result? That means it’s an IP address from Denmark. I live in The Netherlands myself. That probably means that the IP address I’m seeing is from a web site visitor, and very likely a customer of Danske Bank. If I refreshed the login screen again, I would get to see a different set of data, from another customer. I repeated that a few times and got back different records each time. This observation is very interesting, but then again: very alarming.

Most likely this was simply their IP address or the IP address of some networking hardware or proxy downstream from them and the only reason it changed between refreshes was that it was a dynamic IP.

Simply dumping the contents of the $_SERVER variable in PHP could yield a screen full of variables like this. Many of these name/value pairs are also present in the HTTP headers that are exchanged between the client and server.

What IP could it really be?

[grimJester]

He just says "a different set of data, from another customer" without saying what the IPs were. It's a bit of a stretch to assume it's the IP of another end user, but what could it reasonably be?

Re:

[gweihir]

One scenario for that would be a load-balancer in a specific configuration in the loop.

Re:

[spongman]

that doesn't explain the user-agent discrepancy.

Re:

[bobbied]

THAT's how you do security . . .

Well, it's a start anyway.... That they turned off the debugging information was also a step in the right direction too...

Noob Analysis

[barbariccow]

Umm... with exactly none of the information that was being dumped (looks like server headers, like $_REQUEST if php) could anything have been done.. Nobody in their right mind stores usernames/passwords in cookies, cookies are NOT secure. Usually it's a session ID, or a session object, which when combined with an ip or something provides the state of the session. Breadcrumbs, some basic user info, etc.

Re:

[barbariccow]

Also, he says it's insecure to use unencrypted on the backend? Well, since the backend servers aren't doing the handshake unless the frontend is a pure passthrough-load balancer, this makes perfect sense. Why would the worker nodes go through the process of doing their own SSL connections?

Re:

[barbariccow]

I said "ip or something" -- I didn't feel like typing a whole lesson on UUID generation and tracking, the point was to give an idea about identification. Also, if you're using SSL through a proxy server, why not just give up your credentials plaintext?

can be sued / jailed for loses at least in usa for

[Joe_Dragon]

can be sued / jailed for loses at least in usa for doing that hear.

Related background

[TeknoHog]

Danske is infamous for rewriting their online banking system as a Java applet around 2008. Standard https security wasn't enough so they decided to roll their own. I switched to another bank before the update took place, and pretty soon other people left the bank in hordes. They later returned to https, but the damage to reputation was already done.