Unauthorized access to sensitive financial information

In this post I will walk you through unauthorized access to sensitive financial information. I will access my own transaction history from a freshly started server in a different country without using my PIN, security questions, 2FA or any cookies.

But first, I will wear a hat of a legitimate innocent user performing her usual Online Banking routine. To be precise, me-the-innocent-user does the following:

  1. Login to the Bank's Online Banking from a PC. My account is fully protected with security PIN, 2FA, etc.
  2. I will click on my account to verify the transactions. Then I click on a big button in the middle of the screen "Download Transactions"
  3. I select the dates and the format, click the "Download" button and leave the "Download Complete" screen.
  4. Being a security conscious user, I click the "Log Out" menu option and go on with my life.
  5. I even delete the downloaded QFX file from the local file system after importing it into my personal accounting software.

At this point I am changing my hat to be a lowly lawless hacker. The hacker is allowed to steal just one bit of information from the innocent user - their browser's download history. Not the content of the file. None of the cookies. No secrets of any kind. Just the URL of the last file downloaded by the legitimate user.

I want to list just a few ways in which this could happen in real world.

  • Perhaps a hacker is a jealous spouse who has access to the same PC. For video games. The legitimate user is careful to always log out of anything sensitive in order to not get caught cheating.
  • Perhaps a hacker published a Download Manager software that the user installed. There are hundreds if not thousands of such applications in the application stores.
  • Perhaps the user used a company owned PC to access her online banking. And the company has a Computer Use Policy and monitors the URLs of the files employees donwnload.

Stealing an URL of a downloaded file should not be a big deal, right? Even if the hacker had my PIN, they would still need to answer a security question and go through my phone's 2FA. And if they try to perform that from a PC half way around the world the bank would detect it and reset my password. That's the expectation.

Let us look at exactly what the hacker has managed to steal:

https://ofx.thebank.ca/Daily%20Checking.QFX?
 fileType=QFX&
 ofxVersion=102&
 sessionId=tng&
 orgName=TheBank&
 bankId=0614&
 language=eng&
 acctType=SAVINGS&
 acctNum=4009999945&
 acctName=Daily%20Checking&
 userDefined=95a74dc187add661a30eee970d1713b758dc7555f20c08273ec7cb89d7439c4d8c72d1e11b3ca50b&
 startDate=20221101&
 endDate=20221116&
 orgId=10951&
 custom.tag=customValue&
 csvheader=Date,Transaction,Name,Memo,Amount

The hacker changes nothing in that URL at first. They just spin up a fresh instance on their favourite cloud provider and just curl the exact same URL. To their surprise, the download works. They see all the transactions between Nov 1st and 16th. They have no Cookies. They present no PIN. No 2FA challenge is invoked. The legitimate user did terminate their session via the "Sign Out" button, and yet the download link from that session still works. The hacker did not even bother to change the curl's User Agent string. Yet it triggers no security mechanisms on the Online Banking side.

The hacker notices the startDate and endDate parameters and changes them. Without changing anything else they modify the date and get access to the banking records dating even further back. Still, no security challenges are presented to the hacker. Turns out the userDefined parameter is a security token that lives for many hours even after Log Out action.

This is the extent of the attack. I want to just briefly talk about what a malicious actor might do with this access. The obvious dangers lay in the area of blackmail. Seeing someone credit card purchases might often lead to tracking them having a secret they do not wish to see become public. Lacking that, a determined actor might reach out to the user and be fairly convincing impersonating the very bank security. They might say there is a problem with one of the recent transactions - correctly stating the details of such a transaction - and coerce the user into disclosing their actual banking credentials.

All of that was possible for almost 2 years in which I was trying to contact the bank in question. Eventually, I succeeded and this problem has been mitigated. The bank has not shared the details of mitigation with me, but if you repeat the attack today, it will only work in the very narrow window. The userDefined token is revoked within minutes of user clicking the "Log Out" button. Some might think that it should've been revoked immediately or better still be a one-time-use token. Yet with the significantly reduced time window for the attack I believe the Online Banking of that particular financial institution is secure enough.

Thank you for reading this far.

Disclosure timeline:

  • January 15, 2021. The first email to the bank. Recipients: security-alert@thebank.ca, secure@thebank.ca, security@thebank.ca, support@thebank.ca, info@thebank.ca
  • January 25, 2021. The first phone call to the support line, providing all the details to the support person.
  • January 26, 2021. A response from info@thebank.ca informing me that nothing will be done by the support team.
  • March 30, 2021. The second phone call to the support line, providing all the details to the support.
  • March 30, 2021. The vulnerability details are printed out and mailed to the bank's official mailing address (the paper mail kind).
  • June 13, 2022. The third phone call to the support line. I also sent emails to info@, filled the "Feeback" form on the site and emailed an theclientresponsegroup@thebank.ca as well.
  • June 15, 2022. A response from theclientresponsegroup@ with a suggestion to contact a different bank. The different bank happens to be affiliated with the bank in question.
  • June 15, 2022. I record a video of me exploiting the vulnerability and publish it to an unlisted URL on this site.
  • June 15, 2022. An email sent to SRDP@anotherbank.com. It included a link to the exploit video.
  • June xx, 2022. Access logs on the site indicate that the security researchers watched the exploit video.
  • June 22, 2022. I sent an email to SRDP@anotherbank.com asking for any updates.
  • June 22, 2022. A response from the Security Team stating that "The vulnerability you submitted was determined to be valid. Immediate action is being taken to remediate the vulnerability."
  • July 14, 2022. I took down the exploit video and informed the Security Team about that via a separate email.
  • Fall, 2022. The "Download Transactions" page changed slightly, indicating to me that someone has touched it. I have verified that the security of the process has improved.
  • November 16, 2022. I finally got around to write this report.