Summary: Danske Bank Security Loopholes
- On decoding, keywords like: HTTP_CONNECTION and HTTP_ACCEPT were mentioned; Not meant for the guests, these keywords are supposed to be present at the server end.
- Ruwhof could see IP address of a probable customer (through variable HTTP_CLIENTIP) visiting Danske Bank’s website.
- Variable HTTP_USER_AGENT contains an operating system and web browser details; not used by Ruwhof.
- Variable HTTP_COOKIE was visible and full of information; credentials of a customer could be hijacked in real time (Ruwhof resisted on breaking the law).
- HTTP Basic authentication was not present as variables AUTH_USER and AUTH_PASSWORDwere not carrying any data.
- Danske Bank doesn’t use a secure HTTPS connection to transport customer banking traffic; as variable HTTPS was OFF and SERVER_PORT carried value 80.
- They’re still using COBOL code on their backend; for (Customer Information Control System) CICS and Database handling.
What He got in return was Nothing!
Wait, the Story doesn’t Ends Here:
“Someone at Danske Bank has messed up pretty hard, and they’re now covering the situation. That’s not honest and certainly not transparent.”
“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.”
Hacker Attack! Could they Steal from you?
- Cyber Attacks on 6 major banks
- Zeus Trojan- targeting banks in Japan
- The UK banks victims of Ramnit Banking Malware
- HDFC Bank’s Website Vulnerable to Identity Theft