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:
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\www.danskebank.dk\wwwroot\ |
AUTH_TYPE | = | |
AUTH_USER | = | |
AUTH_PASSWORD | = | |
LOGON_USER | = | |
REMOTE_USER | = | |
CERT_COOKIE | = | |
CERT_FLAGS | = | |
CERT_ISSUER | = | |
CERT_KEYSIZE | = | |
CERT_SECRETKEYSIZE | = | |
CERT_SERIALNUMBER | = | |
CERT_SERVER_ISSUER | = | |
CERT_SERVER_SUBJECT | = | |
CERT_SUBJECT | = | |
CONTENT_LENGTH | = | 0 |
CONTENT_TYPE | = | |
GATEWAY_INTERFACE | = | CGI/1.1 |
HTTPS | = | off |
HTTPS_KEYSIZE | = | |
HTTPS_SECRETKEYSIZE | = | |
HTTPS_SERVER_ISSUER | = | |
HTTPS_SERVER_SUBJECT | = | |
INSTANCE_ID | = | 1255724431 |
INSTANCE_META_PATH | = | /LM/W3SVC/1175724431 |
LOCAL_ADDR | = | 10.197.22.250 |
PATH_INFO | = | /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx |
PATH_TRANSLATED | = | d:\dat\iis\www.danskebank.dk\wwwroot\da-dk\Privat\Selvbetjening\raadgivning\Teknisk-support\Pages\Teknisk-support.aspx |
QUERY_STRING | = | secsystem=JI |
REMOTE_ADDR | = | 10.197.22.123 |
REMOTE_HOST | = | 10.197.22.123 |
REMOTE_PORT | = | 63276 |
REQUEST_METHOD | = | GET |
SCRIPT_NAME | = | /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx |
SERVER_NAME | = | www.danskebank.dk |
SERVER_PORT | = | 80 |
SERVER_PORT_SECURE | = | 0 |
SERVER_PROTOCOL | = | HTTP/1.1 |
SERVER_SOFTWARE | = | Microsoft-IIS/7.5 |
URL | = | /da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx |
HTTP_CONNECTION | = | Keep-Alive |
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; QSI_HistorySession=http%3A%2F%2Fwww.danskebank.dk%2Fda-dk%2FPrivat%2FPages%2FPrivat.aspx~1440619560049 |
HTTP_HOST | = | www.danskebank.dk |
HTTP_REFERER | = | http://www.danskebank.dk/da-dk/Privat/Pages/Privat.aspx |
HTTP_USER_AGENT | = | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 |
HTTP_REVERSE_VIA | = | W93917 |
HTTP_CLIENTPROTOCOL | = | https |
HTTP_CLIENTIP | = | 80.166.145.257 |
HTTP_CLIENTPORT | = | 45483 |
HTTP_SOPSECRETURNCODE | = | 000 |
HTTP_SOPGSAFTLNR | = | C002334 |
HTTP_SOPGSSESSION | = | jYcemDSCIjJk |
HTTP_SOPLSID | = | WYU2PQGXGYYSWU5344YMAFJZ |
HTTP_SOPGLOBALUSERID | = | C002334 |
HTTP_SOPSESMTTS | = | 2015-08-26-20.03.26.132946 |
HTTP_SOPCENTER | = | 1 |
HTTP_SOPMVS | = | M2SR |
HTTP_SOPDB2MEMBER | = | DEP9 |
HTTP_SOPQMGR | = | QBPL |
HTTP_SOPFECICS | = | CICRPPI |
HTTP_SOPTID | = | 2015-08-26-22.07.44.322171 |
VTI_IS_INCLUDED_PATH | = | 1 |
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 80.166.145.257 to the corresponding fully qualified domain name, the result I got was 80-166-145-257-static.dk.customer.tdc.net. 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_SOPDB2MEMBER, HTTP_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.
Links
Sites that link to this story:
- TheHackerNews
- Reddit /r/netsec/
- Reddit /r/denmark/
- SANS ISC StormCast: Daily Network Security Podcast
- CIGTR
- Tivi
- Softpedia
- Ycombinator: Hacker News
- Finextra
- Digitoday
- Spain Noticias
- FinansWatch.dk
- SecurityLab
- Slashdot
- Version2
- E Hacking News
- Banks EU
- Oversite Sentry
- IT Viikko
- SecNews
- TechStart
- Misco
- Jupiter Broadcasting (video)
- Tech Viral
- IB Bank
- Checkmarx
- CIGTR
Denial is a very natural state of mind for some people…
It’s also a river in egypt 😉
No, it’s not!
The Nile
The river you saw was not a real river or water – just some debug riverino.
@sruwhof i think danske bank will be mad then
@Googleulv If I was a customer of Danske Bank, I would be mad. And, as it was a “potential vulnerability”, Danske Bank shouldn’t be mad 😉
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.
dnb.no, 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.
Whoa! Crazy post by @sruwhof: “How I could hack internet bank accounts of Danish largest bank in a few minutes”: http://sijmen.ruwhof.net/weblog/%5B..]
@troyhunt @sruwhof unbelievable
@troyhunt @sruwhof Bank grade security! Not long ago they were vulnerable to POODLE (https://twitter.com/MikkelVej/status/637659133500592128 …) But they seem to have fixed it
@MikkelVej @troyhunt I also noticed they got an A grade now. Was curious why they proactively improved security. Too bad it had to be a RD
@troyhunt @sruwhof ‘Bank grade security ‘ buzzword is slowly becoming the new ‘enterprise software’ i.e run for your life
@sapiensworks Haha 😀 Not all banks take security seriously; there *always* has to be a security incident before banks invest in security
@troyhunt @sruwhof I don’t think any of the cookies are Auth cookies. Tried to login (I am a customer) and Auth cookie looks different
@kimtiede I’ve seen different cookies in different requests. What are the names of the auth cookies? I think auth cookies leaked too.
Potential session hijacking and appalling infosec at #danskebank. Sadly, I’m not too amazed.
Wow.. Very surprising (and scary) story involving @DanskeBank_DK’s security. http://sijmen.ruwhof.net/weblog/%5B..]
@DanskeBankSE This is not ok http://sijmen.ruwhof.net/weblog/%5B..] Your security posture is worrying to say the least /From a customer
@1njected Thank you for your observation and in-put and for making us aware.. We will analyze the issue and the link that you provided.
@mafintosh @wa7son you guys being the Danes in this scary story about @DanskeBank_DK ? http://sijmen.ruwhof.net/weblog/%5B..]
@olegam @mafintosh @DanskeBank_DK No comments
@olegam @mafintosh @DanskeBank_DK Their handling of the case isn’t very comforting 🙁 I’m thinking someone should tell Datatilsynet 😉
@olegam @mafintosh @DanskeBank_DK “data was not real customer data, just debug information” aka these aren’t the droids you’re looking for
Really embarrassing story about Denmark’s largest bank @DanskeBank_DK and their online security—or lack thereof http://sijmen.ruwhof.net/weblog/%5B..]
Not again.
How the hell do these debug modes make it into production is beyond me
debug = true // bob please change this
This .. is actually quite terrifying because of how real it is.
//be right on it boss
…and the code was never touched again.
// bob – on parental leave for 2 months.
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.
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: https://www.danskebank.dk/da-dk/Privat/Selvbetjening/raadgivning/Teknisk-support/Pages/Teknisk-support.aspx?secsystem=JI
Want to log into your cable TV provider? Use NemID: http://login.yousee.dk/personalpages/nemid.aspx
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 https://accounts.google.com , then your password gets sent only to Google. Knowing that you are sending your password to the right recipient is cryptographically guaranteed by knowing “accounts.google.com” 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: http://www.version2.dk/artikel/video-saadan-kan-nemid-hackes-32396
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.
I’m actually interested, so if you wouldn’t mind, and you have the time, I’d like to hear more.
Please do, I’m actually interested to hear more.
Yes please! This is even more interesting than South Korea forcing Internet Explorer on online banking.
+1 on the write-up.
In Norway banks and other sites use a similar system called BankID that shares exactly the same problem. The form is shown embedded into the page training users to type blindly their credentials on random sites. They should have taken a clue from PayPal that asks for authentication on own top-level page page where PayPal is clearly visible in the address bar.
this is amazing
Interestingly, that is not far from how the Danish government describes NemID’s security.
Worth a read. Shocking to see such poor security on a banking website. http://sijmen.ruwhof.net/weblog/%5B..]
@DanskeBank_DK Vi er vist mange som er EKSTREMT skuffet over den måde i håndterede denne sag på: http://sijmen.ruwhof.net/weblog/%5B..]
I bet you could script a crawler or make a google dork to look for this vuln easily.
There are already bots that crawl github for AWS ssh keys
I’m glad I’m no longer a customer.
Quand une grande banque Danoise laisse son serveur Web en mode debug @Korben @zataz @Damien_Bancal
http://sijmen.ruwhof.net/weblog/%5B..]
Few thinks people should think to check.. while testing.
http://sijmen.ruwhof.net/weblog/%5B..]
Researcher finds issues w/ bank website, leaking customer credentials. Bank is like ‘lol no that’s debug info’
http://sijmen.ruwhof.net/weblog/%5B..]
@josephfcox but bank still fixes the problem >.<
Its not like debug mode on web servers doesn’t do other cool things in case of error, oh, wait
http://arstechnica.com/security/2015/10/patreon-was-warned-of-serious-website-flaw-5-days-before-it-was-hacked/ …
@josephfcox
#cccamp inspires creativity 😉 –
“How I could hack internet bank accounts of Danish largest bank in a few minutes” http://sijmen.ruwhof.net/weblog/%5B..]
Danske Bank had their server in debug mode. Just wondering was .dk only one affected.. http://sijmen.ruwhof.net/weblog/%5B..]
Quite cool #hacking http://sijmen.ruwhof.net/weblog/%5B..]
Really embarrassing story about Denmark’s largest bank @DanskeBank_DK and their online security—or lack thereof http://sijmen.ruwhof.net/weblog/%5B..]
How this guy could break into the biggest bank in Denmark in minutes of work: http://sijmen.ruwhof.net/weblog/%5B..] … NOT GOOD ENOUGH @DanskeBank_DK
@sruwhof BTW – I hear that a good legal defence to actually breaking into a session is to involve a journalist – acting in public interest
@qc_sec I think you’re right. Thanks! Journalists may break the law if that serves public interest. Haven’t thought about that option.
@sruwhof Wow. They’re not just a local bank, I have a large multinational client that uses them.
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.
Hey @version2dk – er det her et ægte problem eller ren konspiration? (Danske Bank med angiveligt sikkerhedshul). http://sijmen.ruwhof.net/weblog/%5B..]
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.
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.
why companies should stop using the phrase “bank level security” – http://sijmen.ruwhof.net/weblog/%5B..]
Wow, I hope for their sake it was just ‘Debug’ info http://sijmen.ruwhof.net/weblog/%5B..]
Do you have faith in the security of your bank’s online banking? http://sijmen.ruwhof.net/weblog/%5B..]
whats happening? This http://goo.gl/RQoKtj is happening! #bank #bank #hack #careless #stupid !!!!! every hashtag
Whoops! http://sijmen.ruwhof.net/weblog/%5B..]
Woups someone @DanskeBank_DK fucked up huh? http://bit.ly/1OSwsPQ
@DanskeBank_DK – http://sijmen.ruwhof.net/weblog/%5B..] – er der en opdateret holdning til den blog post? #denydenylielie
@DanskeBank_UK I hope you have closed up this issue? http://sijmen.ruwhof.net/weblog/%5B..] via @sruwhof
@danskebank_uk Ah I see @sruwhof says you have, I’ll trust him and not look myself then. I’m glad someone is looking…
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.
That sounds perfectly reasonable, assuming the browser plugin and app are open source.
Great (and scary) reading.. Unfortunately this is how most banks operate today @DanskeBank_DK #cybersecurity #hacker
http://sijmen.ruwhof.net/weblog/%5B..]
@sruwhof, great post. Interesting times, where you’d be a criminal for verifying a vuln, while their malpractice/dishonesty goes unpunished.
@msgrasser Thanks! And yeah, you’re completely right. Our laws have unfortunately no room for ethical hacking.
@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.
@thisisredundant @sharkdrink Really? Wow, that’s awful! What did you found? Seems that they are really scared for ethical hackers.
@sruwhof @sharkdrink Basically NemID-authorised actions can be hijacked w/n00b client-side script. Altered server request, and UX untouched.
@thisisredundant @sharkdrink The whole NemID architecture seems insecure and very prone to phishing attacks.
@sruwhof @sharkdrink It is. Tried to tell Danske Bank that registered requests can differ from client’s as confirmation prompt isn’t linked.
@thisisredundant @sruwhof That’s horrible to hear about … losing your accounts for speaking up. And yeah. NemID is basically the worst.
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!
Danske Bank also has presence in the UK. I just checked and their login page on the .co.uk 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.
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.
Good read. #infosec #security
“How I could hack internet bank accounts of Danish largest bank in a few minutes”
http://goo.gl/RQoKtj
Disturbing read on security leak in DanskeBank: http://sijmen.ruwhof.net/weblog/%5B..]
#danskebank hade rätt sugig säkerhet verkar det som…. http://sijmen.ruwhof.net/weblog/%5B..]
Are you aware that the banking site is located under the domain netbank2.danskebank.dk and not http://www.danskebank.dk?
So even if you’ve got real cookies for http://www.dansebank.dk they would be of no use in accessing the account?
Hmm a very interesting read on a fairly big mistake on Danish banks .. http://sijmen.ruwhof.net/weblog/%5B..] /cc @troyhunt
For Denmark, another whale of a debacle – this time about the security of its biggest bank #DanskeBank #FaroeIslands http://fb.me/3hnMmzZzt
Great read about Danske Bank leaking information about logged in users of their banking site http://sijmen.ruwhof.net/weblog/%5B..]
There’s a place for debugging. Your bank’s live website isn’t such a place though. Good write-up by @sruwhof http://sijmen.ruwhof.net/weblog/%5B..]
@martijn_grooten @sruwhof As if that was demo data. Really?
Danske Bank seemingly leaking security credentials via race condition + debug mode in production http://buff.ly/1OTUBWe
New Normal? @DanskeBank_DK http://sijmen.ruwhof.net/weblog/%5B..]
Hey, great great post, nice finding 😀
@sruwhof nice finding 🙂
@yorickkoster Thanks Yorick! 🙂
You should not have given them any clue until you got compensated for your efforts.
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…. 😉
tsk2x! the researcher must be rewarded for that. They must fix the security hole and give a reward for that.
They fixed the vulnerability within 24 hours after reporting it to them, so it’s closed now. They offered me some bottles of wine a month ago, but I haven’t received them yet.
Just received my bounty from Danske Bank 🙂
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.
Terrifying. Decoding the website of Danske Bank http://sijmen.ruwhof.net/weblog/%5B..]
Danske Bank security: http://sijmen.ruwhof.net/weblog/%5B..] Previously: https://hsivonen.fi/sampo-epic-multifail/
This is really disappointing
http://sijmen.ruwhof.net/weblog/%5B..]
Choking
#Danishbank #security #danskebank
http://sijmen.ruwhof.net/weblog/%5B..]
Based on this @DanskeBank_DK has serious security problems both in tech and attitudes: http://sijmen.ruwhof.net/weblog/%5B..] … #security
Blog:’Nederlandse hacker kraakt grootste bank Denemarken’ http://bit.ly/1FSNPgx Vraag:Strafbaar of held? @foxit @brenno @bnrdigitaal
I’m worried @DanskeBank_UK. What are you doing about this? http://sijmen.ruwhof.net/weblog/%5B..] … #security
This is crazy..
@sruwhof: “How I could hack internet bank accounts of Danish largest bank in a few minutesâ€
http://sijmen.ruwhof.net/weblog/%5B..]
Para los frikis como yo: Como liarla siendo un banco y hacer como que no pasa nada.
http://sijmen.ruwhof.net/weblog/%5B..]
@JorgeRcr si los comentarios del js ya te dan instrucciones de como hacer el hackeo apaga y vamonos colega xD
@JohnyTheKiller hombre es un poco mas especial que eso, no seas pesimista jajajaja
@JorgeRcr apunte mental no meter nada en ningún banco danés
@JorgeRcr no claro que te envÃe la mitad de las variables que necesitas saber para probar cosas no es la mitad del trabajo, mi ma…
Terrible security habits and bad reactions to responsible disclosure often do come in pairs. @sruwhof
http://sijmen.ruwhof.net/weblog/%5B..]
@phelmig Soo true! A company threatened to sue me today if I disclosed their vulnerabilities. Is even a bigger story. Will publish it anyway
@sruwhof Goed gedaan. De bank had je minimaal kunnen bedanken met een doos LEGO.
@markdeiss Ze hebben een paar flessen wijn aangeboden, maar tot op heden nog niet ontvangen. Gaat denk ik nu ook niet meer gebeuren 😉
@sruwhof I posted this to HN. Maybe you’d like to join the discussion 😉 https://news.ycombinator.com/item?id=10337317
@loginn Thanks Jan for the notification! I’ve joined the discussion.
Think your banking website is secure, think again…
http://sijmen.ruwhof.net/weblog/%5B..]
Bold @sruwhof, goed stuk
White Hat Hacker Slams Danske Bank On Social Media For Security Failure After Failure To Get Heard… http://www.finextra.com/news/fullstory.aspx?newsitemid=27937 #infosec
@RizaW Dank voor de tip! Kende het nieuwsbericht nog niet. Inderdaad een hele mooie samenvatting.
Puha danske bank. Kæmpe sikkerhedshul. Hvem laver it-revision? http://sijmen.ruwhof.net/weblog/%5B..]
This is just great reading… Danske Bank, you should take security a bit more seriously…
Ej nej nej nej
nem id bliver ogsÃ¥ flÃ¥et i stykker hvis du læser comments….
Det kommer vel ikke bag på nogen?
Jo, lidt Line… De ting han beskriver i artiklen er insanely basic
den eneste grund til, at jeg bruger nem id er, at jeg ikke har andre muligheder. Men jeg er overhovedet ikke glad for det.
Jeg er over basic
Haha… Det er virkelig skræmmende hvor lidt sikre utroligt mange ting er pÃ¥ nettet…
Hej Peter
Jeg forstår godt, at du bliver lidt bekymret, når du læser det.
Men vi kender sagen godt, og der er altså ikke tale om, at én har fået adgang til vores systemer, kundata eller konti!
For nogle måneder siden gjorde bloggeren os opmærksom på, at han mente, at han havde set nogle sikkerhedshuller. Det er meget vigtigt for os, at vores kunder kan føle sig trygge ved, at vi behandler deres data. Derfor tager vi sådan en henvendelse meget seriøst. Vi undersøgte straks sagen, og vi fandt ikke noget sikkerhedsproblem.
Venlig hilsen og god aften
Poul Otto Schousboe
Chef for Group IT Security & Risk
Det er sgu skægt at I nægter det sÃ¥ hÃ¥rdnakket… Jeg ved godt at han ikke fik adgang – det skriver han jo netop selv, at han undlod at gøre. Men det data han fik ud, kan bruges til det, og det faktum at I pÃ¥stÃ¥r at det bare er debug data han fik ud, det fÃ¥r jer til at se endnu mere dumme ud.
I ville være 10 gange mere troværdige hvis I bare sagde “hey, vi lavede en fejl – tak fordi du fandt den – her er en flaske vin… og nu har vi i øvrigt rettet det”…
Men Peter: Poul og resten af Danske Bank, er fejlfrie 🙂
Shit det er pinligt Danske Bank.
#tv2news
“Bare rolig, det var testdata du sÃ¥ i vores produktionssystem” — sagde ingen troværdig person nogensinde
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…
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.
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.
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.
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.
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.
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.
When the things are outsourced to India, shit happens 🙁
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.
http://handicapkonventionen.dk/wp-content/uploads/2010/09/Nem_ID_456057a.jpg
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).
This is the flow of the NemID:
http://www.nets.eu/products/nemid-javascript/technical-changes/Pages/default.aspx
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.
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.
If you not already read: http://sijmen.ruwhof.net/weblog/%5B..] Not good. It’s a big bank’s website…Then what we are waiting from small(er) companies?
face it: your money are nothing but numbers and likely held in an unsecure digital environment… http://sijmen.ruwhof.net/weblog/%5B..]
they have good developers indeed… http://fb.me/7DL1aqIjp
This is why #secure #coding and #application #security audit should be taken more serious !! #hack #bank #account http://sijmen.ruwhof.net/weblog/%5B..]
#code comments with priviledged #Information is one of those basic things you look for…How did this get into production? 🙁 #danishbankhack
That’s it! New #cybersecurity #practice:code comment #obfuscation:the code does not get obfuscated but comments do!!! #hack #coding #nice
EPIC FAIL! How I could hack internet bank accounts of Danish largest bank in a few minutes: http://sijmen.ruwhof.net/weblog/%5B..]
Whoops http://sijmen.ruwhof.net/weblog/584%5B..]
Looks like best security practices are not quite being followed at Danske Bank. Fortunately I’m not their customer. http://sijmen.ruwhof.net/weblog/%5B..]
More common than acceptable |
How I could hack internet bank accounts of Danish largest bank in a few minutes | http://ow.ly/Tarbr
Wow: http://sijmen.ruwhof.net/weblog/%5B..]
How hard can it be to hack a leading European bank? Anyone with Intermediate knowledge can do it in a few minutes!
http://sijmen.ruwhof.net/weblog/%5B..]
DanskeBank runs debug mode in production and quite interesting info is accessible via browser’s dev console http://sijmen.ruwhof.net/weblog/%5B..]
Great example of how web server config mistakes (especially re error msgs) can open the door to a data breach. http://sijmen.ruwhof.net/weblog/%5B..]
shockingly stupid security flaw for a bank web app http://sijmen.ruwhof.net/weblog/%5B..]
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”