
How I could hack internet bank accounts of Danish largest bank in a few minutes - janvdberg
http://sijmen.ruwhof.net/weblog/584-how-i-could-hack-internet-bank-accounts-of-danish-largest-bank-in-a-few-minutes
======
awalGarg
I wonder how the server was replying with a different dump every time. It
wasn't the dump corresponding to the current request, but a random user's dump
on _every_ refresh. How would the server decide what information to dump?

Either: 1\. The server was programmed to dump the most recent available
session data, and presumably a lot of users were accessing the site
concurrently. This would not be the case in development and thus, during dev,
their devs would be seeing only the current session's information.

2\. Someone intentionally planted this backdoor.

I hope it is the first case. Because if it is not the second case, it would
take some really really apparent mistake or an extremely horrible debugging
fashion to match the described behavior.

~~~
Sijmen_Ruwhof
It's almost certainly not a backdoor, as it's way to noisy for that.

Why the random visitor technical details were shown is a really good question.
I have spent quite some thought time on that also and couldn't come up with a
solid answer.

------
radiospiel
While the leaked data is probably not cool and shows internal information
which a client should never see, the alarmist tone - HACKED! NO SSL! - is not
approbriate here… I think this is "just" a dumped HTTP GET request between the
SSL termination and the ultimative server (and not, as the article assumes,
some data from some client).

~~~
the_rosentotter
He would not have been able to hijack any sessions with this information, as
he claims. Danske Bank, like all banks in Denmark, uses the government's
public key infrastructure for authentication (based on one-time pads which all
citizens receive by mail).

Sloppy but pretty much a non-issue.

~~~
sasas
You are confusing how the attack is done. PKI has nothing to do with it. Try
this with Chrome -

1) Log into a site on one computer

2) In the javascript console (tools->developer tools) type 'document.cookie'

3) On a separate computer visit the same site but don't log in. Open the
javascript console.

4) Paste in the cookie, i.e document.cookie="keyofcookie=valueofcookie"

5) See if your authenticated using the account you 'stole' the cookie from
without actually having to authenticate on the second computer

(Rather then using two computers, you could use two different browsers on the
same computer)

Nowhere here was PKI used.

One way to mitigate this type of attack is to store the users IP address
server side and detect if they change IPs during the same session.

------
coldcode
People think all banks have the highest level of secure coding practices.
Having worked at a financial company with a bank I know its not remotely true.

~~~
tluyben2
I have the same experience. But they are usually not willing to invest until
they are hacked and even then. It is like the article yesterday on HN ;
correctness & security are nice, but almost always not in the budget. Even
when the result could be far larger losses. It is the 'could be' that prevents
almost the entire world from doing something about it as for most systems it
doesn't happen even though it very easily could happen at any time. Like the
example from this blogpost.

------
emerongi
They just have to claim it's test data. If they didn't, this could blow up
really bad - the regular user would be convinced that the bank messed up. In
this scenario, it can be played off as a "test to improve security" (or
whatever), if it ever were to end up in the mainstream media.

~~~
jasonjei
It's also likely a DevOps/IT team member trying to protect his or her own
skin...

------
elliotec
I was in Copenhagen last month for vacation. On a Saturday night, perfect
weather and everyone in the city out looking for a good time - the banking
system was down.

No joke, zero ATMs worked, zero CC machines worked, the entire _country 's_
electronic monetary system was completely shut down. Nobody in the country
could do anything until they brought it back up 4 hours later.

Apparently this happened several times this year (including Valentines day,
one of the biggest economic weekends of the year) with little press and no
responsible party blamed.

Being a software dev, first I was lamenting the irony of a "secure" central
banking system, then my mind went straight to how screwed I'd be if I wrote
the code that brought that down. Now I have a little more perspective and
don't feel any better.

~~~
jafingi
That's Nets, which controls the credit card payments in Denmark.

However, it's at best a non-issue, because CC terminals can be put in "offline
mode". So you can still pay, but the transactions will first be synchronized
when the line is back up. So until that, they're stored on the CC terminal
itself.

HOWEVER when running in offline mode, the shops will pay a larger transaction
fee. Also there are some risks, e.g. the transactions are lost if something
happens to the CC terminal, and furthermore, the shop cannot verify the card
(which is automatically done when it's online).

So unfortunately, many shops don't want to enable it..

However, the problem relies in Nets itself. They control the credit card
systems in Denmark, have monopoly on "Dankort" which is the danish equivalent
to Visa (actually you normally get a Visa/Dankort hybrid so that when you're
abroad, you use the Visa-part of the card). Nets also controls NemID, which is
the Danish authentication method for public stuff (one-time passwords).

They have been criticized, but IT in Denmark is run by morons (sorry..).

------
BuildTheRobots
Nice writeup and good read. Somewhat terrifying brush off when he reported it
too.

~~~
Zwitty
The brush off makes sense, he probably wasn't supposed to email him back at
all incase he posted the email on some sort of social media.

