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

In August I visited the Chaos Communication Camp near Berlin. Once every four years this great and world’s greatest hacker festival is organized. I spoke with a couple of cool Danish hackers there and we talked about internet security and eventually about the security of Danish banks. Seemed like quite a lot of Danish bank have terrible HTTPS connection security (scoring a F on Qualys SSL Labs). That’s a bad sign and my gut feeling was telling me that this wouldn’t be the only security vulnerability they would have.

So I opened up the web site of Danske Bank, one of those bank sites. I clicked thru the site and was curious to see how the HTML code looked like, so opened the code of the customer login screen of the banking environment. I scrolled thru the code to get a grasp of the technology used. Then my eye caught JavaScript comments that seemed to contain internal server information. Not just a few variables, but quite a lot of confidential data actually (!). It was in URL encoded format, so I decoded it right away. Really wondering what kind of secrets it contained.

When I decoded it, I was shocked. Is this happening for real? I was less than a minute on their web site. This is just the HTML code of the login screen, one of the most visited pages of Danske Bank’s web site. I never heard of this bank, but my new friends told me it was the biggest bank in Denmark.

The leaked technical information
The HTML code of the login screen that got my attention was the following:

JavaScript comments

To the average eye, above code looks like gibberish, but I immediately saw words like HTTP_CONNECTION and HTTP_ACCEPT. That’s strange. These keywords are normally only used on the server itself, and should never been sent to visitors.

Did you notice the horizontal scroll bar in above picture? A lot of code is available if your scroll to your right. In above code a lot of percentage characters (%) are visible and that means the code is URL encoded. When you decode those codes and structure the data, then the following table can be constructed:

ASP.NET_SessionId = kbthxf55aiit4yn0zgx1ks55
APPL_MD_PATH = /LM/W5SVC/1255924431/ROOT
APPL_PHYSICAL_PATH = d:\data\iis\\wwwroot\
HTTPS = off
INSTANCE_ID = 1255724431
PATH_INFO = /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx
PATH_TRANSLATED = d:\dat\iis\\wwwroot\da-dk\Privat\Selvbetjening\raadgivning\Teknisk-support\Pages\Teknisk-support.aspx
QUERY_STRING = secsystem=JI
SCRIPT_NAME = /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx
URL = /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx
HTTP_ACCEPT = text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_LANGUAGE = da,en-US;q=0.7,en;q=0.3
HTTP_COOKIE = cookiesOn=yes; s_vi=[CS]v1|2ADB987F85111696-6000013120021EC1[CE]; mbox=session#1440619645928-786416#1440611516; s_cc=true; s_sq=%5B%5BB%5D%5D; s_sv_sid=695191168575;
HTTP_USER_AGENT = Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
HTTP_SOPSESMTTS = 2015-08-26-
HTTP_SOPTID = 2015-08-26-

The server seems to be configured in debug mode and that’s why it’s dumping these variables. I’ve modified above variable values a little bit in order not to give exact internal information (respecting Danske Bank’s security).

Analyzing the data
I saw something strange. My own IP address wasn’t listed in variabl HTTP_CLIENTIP and this listed address was also not an internal server IP address. When I translated IP address to the corresponding fully qualified domain name, the result I got was 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.

Hijacking bank accounts
Looking further at the data I saw that the variable HTTP_USER_AGENT contains an operating system and web browser that I’m not using. Hold your breath. Then I also saw that variable HTTP_COOKIE was visible and that it was full of information. For those not really familiar with cookies: cookies are the keys that give access to an account that is logged in. So, I’m now looking at the credentials of someone’s online banking account!

I’m shocked. I can’t believe this. It’s so obvious and in plain sight! How come that nobody at Danske Bank noticed this before?

If the customer from the data that we’re seeing is logged in at the moment, and if I copy those cookies and import them into my browser, then I’m also logged in as that customer. That’s how cookies work, and thus that’s how identify theft works.

I had to resist the urge to hijack this bank account to prove my case. If I hijacked this account, that would mean that I’m breaking the law. And that isn’t going to happen.

Reflection on technical data leakage
When looking at the table above there exists two variables that Danske Bank should be very lucky that they were empty: AUTH_USER and AUTH_PASSWORD. If Danske Bank would have used HTTP Basic Authentication technology for internal server network security, the password of it would have been printed in the HTML source code and the gaffe would have been bigger. Talking about luck that that didn’t happen! Or … talking about missing internal network authentication? It’s probably luck (giving them the benefits of the doubt), as I expect them to use a different server authentication method.

Another interesting variable is SERVER_PORT. This one has value 80 and variable HTTPS has value off. This means that on the internal network Danske Bank doesn’t use a secure HTTPS connection to transport customer banking traffic. The HTTPS traffic from customers is offloaded at their network gate and then the traffic is unsecured routed through various servers. Not something that is best practice nowadays from security standpoint. HTTPS should also be applied on internal networks, otherwise network administrators can read and change traffic, and thus the possibility opens for them to hijack customers bank accounts.

The variables HTTP_SOPDB2MEMBERHTTP_SOPQMGR and HTTP_SOPFECICS indicate that their Microsoft IIS server is connecting to a z/OS server that runs a DB2 database, message queue software 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.

Responsible disclosure
I didn’t contacted Danske Bank immediately, as I’ve a very busy professional schedule and not a lot of time for free vulnerability coordination and research. Two weeks after I initially found this critical vulnerability, I took the time to find a way to report it to them (on August 26).

Easier said than done. They don’t have a responsible disclosure process in place, so there was no e-mail address I could mail my findings to. I called a phone number on their web site and the lady that I spoke didn’t seem to understand the problem and said: “our technical guy will look at your finding”. I asked for her e-mail address so I could mail the details to her but she said that wasn’t possible. I didn’t get the feeling I was taken seriously, so I started looking on LinkedIn for IT security personnel that worked at the bank.

Found someone that worked in the security incident response department and mailed him my findings. That worked! I saw that within 24 hours the vulnerability was patched.

Danske Bank responds
I was eagerly looking at my mailbox for feedback on my finding that I just sent them, but that didn’t came soon. After twelve days (on September 7) they finally sent me the following:

Thank you for reporting a potential security vulnerability on our website.

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.

A potential vulnerability? Are you serious? The server was leaking all kinds of highly technical data. And what about using not real customer data? Is it suggested that Danske Bank is using test customer data in their production environment? That would be against all safety guards and all best practices. And creating test cookie data in production in combination with an IP address and user agent? Never seen that one before.

I’m not buying that. Over the last 17 years I’ve performed countless responsible disclosures and developed a good sense when companies are downplaying the situation. Someone at Danske Bank has messed up pretty hard and they’re now covering the situation. That’s not honest and certainly not transparent.

Wrapping up
For at least two weeks, but probably a lot longer, very confidential customer data in the form of session cookies were leaking on Danske Bank’s web site. With these cookies it should have been possible to hijack internet banking accounts of their customers. They closed the security hole quickly, but are now in denial of it.

Update October 8: Because of all publicity this story gets, Danske Bank now admits that their production server was in debug mode and that I saw information and cookies from other visitors (!). That’s quite a turn! Seems that media attention forces the bank to be honest. They still hold on that I couldn’t hijack banking sessions.

Update October 9: Danske Bank has now implemented a responsible disclosure process and created a web page about it so security researchers have now contact details to get directly in touch with their security team.

Sites that link to this story:

About Sijmen Ruwhof

Independent IT Security Researcher / Ethical Hacker
This entry was posted in responsible disclosure, website security. Bookmark the permalink.

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

  1. Remco (via Facebook) says:

    Denial is a very natural state of mind for some people…

  2. @sruwhof i think danske bank will be mad then

  3. Ralph (via Facebook) says:

    Nice finding but without actually copying the sessionID’s and taking over a session, it is indeed a ‘potential vulnerability’. I understand why you did not do that, but there’s no other way to prove your point. Nice work though nevertheless. One other nitpicky point: I would not advise using SSL on all connections, since any NIDS or IPS would not be able to look into the ssl tunnel and would therefore not be able to detect potential attacks. the tunnel has to be terminated somewhere…..

    • Banks normally don’t terminate a session when the IP address changes when logged in, as roaming users would be constantly logged out. The fraud threshold would however be raised, so making fraudulent transactions will be harder.

      I tried finding Danske Bank customers via my Danish friends who would like to test out a few things only under their account, but haven’t found one willing to participate 😉

      You could indeed temporary open up the HTTPS tunnel for network IDS/IPS inspection, but after that the tunnel should be closed again.

      • Igor Bukanov says:, the biggest bank in Norway, automatically logs user out on IP change but keeps the session. The only annoyance so far came from a phone that picked WiFi network when I logged in using mobile data connection.

  4. Whoa! Crazy post by @sruwhof: “How I could hack internet bank accounts of Danish largest bank in a few minutes”:]

  5. Wow.. Very surprising (and scary) story involving @DanskeBank_DK’s security.]

  6. @DanskeBankSE This is not ok] Your security posture is worrying to say the least /From a customer

  7. @mafintosh @wa7son you guys being the Danes in this scary story about @DanskeBank_DK ?]

  8. Really embarrassing story about Denmark’s largest bank @DanskeBank_DK and their online security—or lack thereof]

  9. Not again.

    How the hell do these debug modes make it into production is beyond me

  10. T. says:

    Wow, I would expect different from a bank. Nice work Sijmen! I understand why you did not took over the session, but I am very curious what would have happend.

    But I am really surprised to see that the run on Windows…?

    • Thanks T!

      I was also very curious to try it out. Would have resulted in a great screenshot if it indeed worked!

      The Danske Bank web site runs on Microsoft SharePoint (!), at least the part before the login screen. Microsoft servers are nowadays secure servers, so not that weird actually. However running your web site on SharePoint raises questions.

  11. Ha, you don’t need that much for breaking into Danish websites. The shared login system they all use is called “NemID”, and it works by basically telling the users to input their password into any NemID dialog they find on any page on the Internet. No effective instruction or limitation has been given on which domain names NemID dialog boxes can appear on.

    Want to log into your bank? Use NemID:

    Want to log into your cable TV provider? Use NemID:

    Want to use the password input there for logging in/tranferring money in the webbank? All good! Is it a problem that YouSee could trivially steal the NemID password I input into their page and log onto my bank? Nah, they are probably good people, lets trust them.

    So if you want to steal passwords, you can just make new page with a NemID dialog and start sending phishing spam. Or compromise any existing Danish page, and insert a fake NemID dialog box.

    Normal single sign-on systems like Googles have a cryptographic guarantee, that if you make sure you only input your password on , then your password gets sent only to Google. Knowing that you are sending your password to the right recipient is cryptographically guaranteed by knowing “” is owned by Google and HTTPS, with the browser’s address bar guaranteed to always show the correct address. That is far too fancy for Danish Internet security.

    NemID is two-factor, using one-time-keys read off a cardboard card the user has, in addition to the normal password. But that is easily circumvented using real-time MitM. Which has already been done and demonstrated:

    When I first saw a NemID dialog box in 2010, I spent the first two seconds thinking my computer had been compromised, since obviously a NemID dialog should not appear on my webbank’s webside. After those two seconds, when I realized how incompetent everybody involved must have been, I spent the next 30 seconds facepalming.

    I have contacted everybody involved in the Danish government and the private company running NemID. Nobody cares, nobody has any understanding. The media is too stupid, so when e.g. the government says “NemLog-in is a solution that has been developed with very high levels of security so citizens, employees and authorities can use it safely”, it becomes their word against mine, and no news story is run.

    I can do a full write-up if /r/netsec is interested.

  12. Worth a read. Shocking to see such poor security on a banking website.]

  13. @DanskeBank_DK Vi er vist mange som er EKSTREMT skuffet over den måde i håndterede denne sag på:]

  14. I bet you could script a crawler or make a google dork to look for this vuln easily.

  15. I’m glad I’m no longer a customer.

  16. Quand une grande banque Danoise laisse son serveur Web en mode debug @Korben @zataz @Damien_Bancal]

  17. Few thinks people should think to check.. while testing.]

  18. Researcher finds issues w/ bank website, leaking customer credentials. Bank is like ‘lol no that’s debug info’]

  19. #cccamp inspires creativity 😉 –
    “How I could hack internet bank accounts of Danish largest bank in a few minutes”]

  20. Danske Bank had their server in debug mode. Just wondering was .dk only one affected..]

  21. Really embarrassing story about Denmark’s largest bank @DanskeBank_DK and their online security—or lack thereof]

  22. How this guy could break into the biggest bank in Denmark in minutes of work:] … NOT GOOD ENOUGH @DanskeBank_DK

  23. @sruwhof BTW – I hear that a good legal defence to actually breaking into a session is to involve a journalist – acting in public interest

  24. @sruwhof Wow. They’re not just a local bank, I have a large multinational client that uses them.

  25. Just a note about not using HTTPS internally. It’s quite standard practice to terminate SSL on a separate device (often a load balancer with HW support for SSL) Also the data then can be encrypted in some other way (ipsec for example) that he wouldn’t see in the debug logs.

  26. Hey @version2dk – er det her et ægte problem eller ren konspiration? (Danske Bank med angiveligt sikkerhedshul).]

  27. anonymous coweird says:

    it is possible this entire thing is a honeypot so they can catch people hacking. or they are completely incompetent.

    there is no telling how deep and weird a bank will go with their security weirdness.

    but there is one thing for sure… you are not going to get a straight answer on this kind of thing.

    • Looking at the overall security posture of Danske Bank’s web site, thinking that this vulnerability is a honeypot is giving them too much credits. They are sloppy with the security of their web site. There’re more vulnerabilities in it that I haven’t disclosed yet.

  28. SYSMGR says:

    The most fundamental error they make is using an notorious insecure OS and web-frontend Instead they should use a system with proven security record and a webserver that adheres the same security standards. Such systems require more knowledge than the average web-developer has but it assures that the production system is of top quality.

  29. why companies should stop using the phrase “bank level security” –]

  30. Wow, I hope for their sake it was just ‘Debug’ info]

  31. Do you have faith in the security of your bank’s online banking?]

  32. whats happening? This is happening! #bank #bank #hack #careless #stupid !!!!! every hashtag

  33. Woups someone @DanskeBank_DK fucked up huh?

  34. @DanskeBank_DK –] – er der en opdateret holdning til den blog post? #denydenylielie

  35. @DanskeBank_UK I hope you have closed up this issue?] via @sruwhof

  36. God that’s… horrible.

    For comparison, Sweden has a similar government-approved (as in it has the same weight in the law as a written signature) authentication system, called BankID.

    The most common ways to use BankID are either with a browser plugin that uses private key crypto with a local certificate file on your computer, or using a 2 factor auth app on your smartphone. With both methods, the plugin/app will show the name of the company/site that you’re logging into or even show explaining text about what you’re signing/agreeing to (e.g. a bank will make the app say “You’re approving the transfer for $50 to NAME”). All of this makes MiTMing impossible.

  37. Great (and scary) reading.. Unfortunately this is how most banks operate today @DanskeBank_DK #cybersecurity #hacker]

  38. @sruwhof, great post. Interesting times, where you’d be a criminal for verifying a vuln, while their malpractice/dishonesty goes unpunished.

  39. @sruwhof @sharkdrink Fun fact; I was a gold bonus plus customer of Danske Bank, found a smaller bug than this and got kicked as a customer.

  40. I just read this post ‘How I could hack internet bank accounts of Danish largest bank in a few minutes’ by Sijmen Ruwhof (@sruwhof). I understood one thing from this, not all banks take security seriously. But isn’t it annoying to see Denmark’s largest bank not even having a Responsible Disclosure process in place ? What do Peerlysters think about this kind of mentality in banks ? What would you do if you were a customer in a bank that din’t even understand security ?
    I really found it funny when this bank responded back saying that the data he saw was not real customer data, but were test data. Do they really push testdata in their production servers ? Weird!

  41. Danske Bank also has presence in the UK. I just checked and their login page on the site does not have these variables.

    However they seem to be a big fan of leaving JS code in production that is commented out: I counted 4 blocks on the login page.

  42. Danske bank is not the only one with “debug information” leaking. Nordea had a similar issue a few months ago. Besides that, all sensitive accounts in Denmark are being accessed using NEM-ID (a java applet) which it too leaks (from time to time) debug info.

  43. Good read. #infosec #security
    “How I could hack internet bank accounts of Danish largest bank in a few minutes”

  44. Disturbing read on security leak in DanskeBank:]

  45. #danskebank hade rätt sugig säkerhet verkar det som….]

  46. Whoever says:

    Are you aware that the banking site is located under the domain and not

    So even if you’ve got real cookies for they would be of no use in accessing the account?

  47. Hmm a very interesting read on a fairly big mistake on Danish banks ..] /cc @troyhunt

  48. For Denmark, another whale of a debacle – this time about the security of its biggest bank #DanskeBank #FaroeIslands

  49. Great read about Danske Bank leaking information about logged in users of their banking site]

  50. There’s a place for debugging. Your bank’s live website isn’t such a place though. Good write-up by @sruwhof]

  51. Danske Bank seemingly leaking security credentials via race condition + debug mode in production

  52. SilverSwan says:

    Hey, great great post, nice finding 😀

  53. @sruwhof nice finding 🙂

  54. Bala Paranj says:

    You should not have given them any clue until you got compensated for your efforts.

  55. it is time to learn to not correct bugs for the NWO network… that’s not white nor black hat hacker… that’s stupid hacker… do not help them, see that they don’t care about you and they take you as the stupid ones… never correct their bugs, you have a more creative minds if you think for yourselves… and for those who care… not fairy tales systems…. 😉

  56. tsk2x! the researcher must be rewarded for that. They must fix the security hole and give a reward for that.

  57. There are modern versions of COBOL, pretty much everything mentioned requires MITB or MITM(MITM where there is no TLS or a TLS vuln to use). The lack of TLS is the only real problem outside of the lazy development that it makes vulnerable.

    If I as a attacker have a MITB scenerio even with good TLS and all the lazy stuff fixed I can still mine cookies and do requests as the logged user even if there is 2FA. Every bank in the world except the ones that use smartcard browser plugins are vulnerable to this, and only until I RE the plugin to intercept smartcard auth.

  58. Terrifying. Decoding the website of Danske Bank]

  59. Based on this @DanskeBank_DK has serious security problems both in tech and attitudes:] … #security

  60. Blog:’Nederlandse hacker kraakt grootste bank Denemarken’ Vraag:Strafbaar of held? @foxit @brenno @bnrdigitaal

  61. I’m worried @DanskeBank_UK. What are you doing about this?] … #security

  62. This is crazy..
    @sruwhof: “How I could hack internet bank accounts of Danish largest bank in a few minutes”]

  63. Para los frikis como yo: Como liarla siendo un banco y hacer como que no pasa nada.]

  64. Terrible security habits and bad reactions to responsible disclosure often do come in pairs. @sruwhof]

  65. @sruwhof Goed gedaan. De bank had je minimaal kunnen bedanken met een doos LEGO.

  66. @sruwhof I posted this to HN. Maybe you’d like to join the discussion 😉

  67. Think your banking website is secure, think again…]

  68. Bold @sruwhof, goed stuk

    White Hat Hacker Slams Danske Bank On Social Media For Security Failure After Failure To Get Heard… #infosec

  69. Puha danske bank. Kæmpe sikkerhedshul. Hvem laver it-revision?]

  70. This is just great reading… Danske Bank, you should take security a bit more seriously…

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

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

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

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

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

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

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

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

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

  77. Björn says:

    So, the output you put on the blog is sanitized, you obfuscate the actual IP Address? Since no IPv4 address can contain an octet higher than 255?

    • In order to protect the IP address of that other person I modified it. I didn’t wanted to obfuscate the IP address to another one that is pointing to an innocent computer or person on the internet, so that’s why I choose a number above 255.

  78. Ifitkhar says:

    When the things are outsourced to India, shit happens 🙁

  79. Thomas says:

    You won’t get in to the actual accounts without access to the customer’s unique/individualized NEMID card, which is completely analog and therefore non-hackable. A minor security breach I would say. The card I mention looks like this. Without it, no access.

    • You can *certainly* bypass NEMID card protection. NEMID is used for authenticating a customer. After the web site has validated the customer, it sends a session cookie towards the customer’s browser that the identity is validated. If you have that cookie as an attacker, you can bypass NEMID. So that would certainly be catastrophic in security terms.

      Session cookies are used, otherwise you should insert a NEMID code for *every* web page you visit. That would be highly secure, but unworkable and not user friendly (nobody is going to use such a system).

      • Whoever says:

        This is the flow of the NemID:

        To authenticate a user the JS in the inframe needs to sign his ticket with a data derived from password and OTP.

        Banking site is at different URL, so even if you had user cookies you wouldn’t be able to access anything.

        NemID can be spoofed and MitMed in real-time(you need to hijack dns, etc, so it’s not that easy to start with), but it is extremely difficult due to heavy crypto/obfuscation. And if the backend server detects a mitm attempt then you will have you account temporarily locked.

  80. Stig says:

    As a customer and former employee of Danske Bank, I can say the bank probably tells the truth when saying you didn’t see session information from ebank users. The logon-box is placed on the homepage, but when you log in, you are forwarded to another (sub)domain, and a completely independent website (that’s definitely true from a user’s perspective, and I’m pretty sure its also completely different technical environments). So I don’t think you have been anywhere near login-sessions or access to bank accounts. If you return to the homepage after having logged into the ebank, there’s no personal widget or functionality, no logout-button or anything related to a “personal session”. So it completely makes sense you didn’t see any data in AUTH_USER and AUTH_PASSWORD on the homepage.

    The technical platform in Danske Bank is a mixed one, but you are right. The “core” part is running on mainframes, and there’s a lot of PL1 and Cobol programs, and also a lot of DB2 databases.

    Btw, the “logon widget” is a “nemid widget”. “Nemid” is a common log-in solution used by most Danish banks, government websites (like for example Tax selfservice site), and a lot of other places.

  81. If you not already read:] Not good. It’s a big bank’s website…Then what we are waiting from small(er) companies?

  82. face it: your money are nothing but numbers and likely held in an unsecure digital environment…]

  83. they have good developers indeed…

  84. This is why #secure #coding and #application #security audit should be taken more serious !! #hack #bank #account]

  85. EPIC FAIL! How I could hack internet bank accounts of Danish largest bank in a few minutes:]

  86. Looks like best security practices are not quite being followed at Danske Bank. Fortunately I’m not their customer.]

  87. More common than acceptable |
    How I could hack internet bank accounts of Danish largest bank in a few minutes |

  88. How hard can it be to hack a leading European bank? Anyone with Intermediate knowledge can do it in a few minutes!]

  89. DanskeBank runs debug mode in production and quite interesting info is accessible via browser’s dev console]

  90. LN Security says:

    Great example of how web server config mistakes (especially re error msgs) can open the door to a data breach.]

  91. shockingly stupid security flaw for a bank web app]

  92. KabirSatwani says:

    Nice article. I liked the information shared here and anticipating more precious content than this. I know only little about hacking but it seems I will learn soon ;). l liked this “DanskeBank runs debug mode in production and quite interesting info is accessible via browser’s dev console”

Comments are closed.