Bank denies it was real user information, only test data

Oct 6, 2015 14:49 GMT  ·  By

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.

Mr. Ruwhof started to research Danish banking policies out of curiosity, after attending a security conference in Germany, where some of his friends discussed the sad state of security policies for Danish banks.

After spending less than a few minutes on the site of Danske Bank, Denmark's largest bank, Mr. Ruwhof was able to identify a pretty critical security problem, which he found in the JavaScript files delivered when accessing the banking portal's login screen.

The server was left in debug mode, exposed user details

According to his research (see screenshot below), inside the JavaScript files there was a blob of encoded data which, after he passed through a decoder, was stupefied to find out that it contained debug information which is usually present only in testing environments when servers are running in a debug mode.

This data was being printed to all users accessing the site, but instead of showing data specific to each user, the data contained session details that belonged to other users accessing the site at that specific moment.

The data was neatly arranged inside a table (check Mr. Ruwhof's blog for a sample), and contained details like:

  • HTTP_CONNECTION and HTTP_ACCEPT - HTTP information usually present only on the server
  • client IP addresses
  • user agent strings
  • cookie information
  • details about the bank's internal IT network
All these were more than enough for an attacker to hijack user sessions, and gain access to customer accounts.

Debug data embedded in the bank's JavaScript files
Debug data embedded in the bank's JavaScript files

From the other details found in the debug table, Mr. Ruwhof was also able to come to the conclusion that the Danske Bank is using an IIS server which connects to a z/OS server that runs a DB2 database and CICS.

"That’s a pretty normal (but old!) software stack for a bank. Probably also means they’re still using COBOL code on their backend," Ruwhof says.

HTTPS is not used inside the bank's internal network

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.

Since the bank did not have an email address listed where such incidents can be reported, Mr. Ruwhof tried to contact Danske Bank via telephone to report the bug, but customer support refused to supply him with an email address where he could report his findings.

He eventually found someone from the bank's IT department on LinkedIn and reported his findings on August 26.

The debug dump data stopped appearing in the JavaScript code the following day, but in an email Ruwhof received on September 7, a bank representative denied the incident. You can read the bank's response using the button below.

Danske Bank login page
Danske Bank login page
Danske Bank Response

Danske Bank incident (3 Images)

Danske Bank exposes sensitive data inside JS files
Debug data embedded in the bank's JavaScript filesDanske Bank login page
Open gallery