How I could hack internet bank accounts of Danish largest bank in a few minutes | Hacker News Reader

How I could hack internet bank accounts of Danish largest bank in a few minutes

sijmen.ruwhof.net

68 pointsjanvdberg18 comments

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.

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.

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).

I think the point is that the debug is leaking sessionid cookies, which could be transplanted into your browser to fake a session.

I think that these are bound to the user's own session, which is already in the browser cookie.

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.

Two points.

One) Can you please provide technical citations to support this? OTP and PKI are very different technology, and the only way I can make sense of your statement is to guess that the OTP is actually a one-time-password (not a one-time pad) used to initialize the user's PKI account.

Two) If the server is leaking data the user authentication is rendered pretty much irrelevant - and PKI with a one-time initialization code would be used for authentication. PKI may also secure the connection, e.g., using SSL/TLS, but it seems that in this case the server was being most dumb - even if my connection were secured using TLS and the best authentication in the world, it seems I would be able to get your data. Which I am sure you wouldn't want. Nor would you be much mollified by knowing exactly who it was that compromised you.

Session management and authentication (PKI / one time pad) are two complete different subjects. If a session cookies is leaked from a customer, then authentication checks can be bypassed completely. So certainly an issue.

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.

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.

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.

Seconded.

Actually, as a bank, you only need to be slightly more secure than your competitors.

Moreover, you will never need to be unbreachable; many times I have seen banks not fixing vulnerabilities, simply because these vulnerabilities were not profitable enough for attackers to exploit.

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.

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

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.

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..).

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

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.

Reply on news.ycombinator.com