Slashdot Mirror
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.
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.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Seriously, clean up your code before committing or signing off on a task.
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?
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...
I'm really amazed about the publicity one single blogger can get with such undocumented claims.
Was it a Dane who did this or an Indian? H1Bs put the "B" in B-Player.
They should have bought this book.
"First they came for the slanderers and i said nothing."
In Denmark.
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.
THAT's how you do security . . .
We investigated your report immediately. However, the data you saw was not real customer sessions or data – just some debug information.
--Baghdad Bob
I mean, who puts their pastries in a bank anyway? And, what could possible be sensitive about this information?
Joe Schmo doesn't like apple Danishes? Is allergic to cherry?
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?
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.
can be sued / jailed for loses at least in usa for doing that hear.
In the Fascist States of Amerika, instead of a simple denial, government thugs would be busting down his door with their full auto assault rifles trained on him for 1337 h4x0r'ing the bank.
"Furthermore, he was also able to come to the conclusion that the bank does not use HTTPS on its internal network, even if customer connections are using HTTPS.
While internal networks are usually pretty well isolated, this is generally considered a bad security practice, because even if attackers never breach the internal network, information about customer activities are still being exchanged in clear text inside it."
No, it's called SSL Offloading and it's a pretty common practice.
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.
Escher was the first MC and Giger invented the HR department.
That page does not list these two cookies:
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 you get someone else's session? It's impossible.
Scott Hanselman has one suggestion as to how it might happen, and it's 100% code errors.
There's a comment there "You just found the famous TLS bug :)" So maybe not impossible. Windows uses Thread Local Storage to store things like static variables. The thread handling the request might change, and ASP.NET properly sets the .NET Thread data (and HttpContext data for MVC applications) every time it processes an event so it should all line up. But, static variables are thread-locked, so they can transfer between request handlers. That's the TLS Bug referenced there. It is possible to access someone else's session data if it is stored in TLS (static variable is one possibility).
So, this is not "a lot of crying over nothing" - it could be very serious. Having said all of that, it is very unlikely that you would see someone else's information consistently with that bug - it might show up once and go away.
If this were replay data for load tests or unit tests, it's unlikely that the dates would be the same as when it was reported. The user admits altering some of the data, so we can't draw concrete conclusions there.
A security professional wouldn't draw attention to *possible* leakage of Basic Auth, because that's really unlikely at the SSL interface behind a username/password login. At least a knowledgeable one, I think.
If the IP address were a load balancer, the User agent should have matched what the user expected. Dynamic content hosted by a CDN/edge provider? If the data changed, it's probably dynamic. So, what is the conclusion?
I don't know, but it doesn't sound like something that can be dismissed so nonchalantly. If users were getting each others' sessions, we would likely have heard about it, since it happened for two weeks. That's the only thing I can conclude, but that supposes that the news would have made it to international press.
Major Oops!
QSI_HistorySession is listed as a "user survey" cookie on the danish version.
mbox is probably Site Catalyst: http://cookiepedia.co.uk/cooki...
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...