It all started with a simple question: “Why does my bank’s website require my 2-factor token, but pulling my transactions into Quicken does not?" It made me wonder, how is Quicken getting the data? Obviously not the same way that I usually log in… and it seems less secure. I also wondered if there was a separate server or separate protocol between Quicken and my bank? I started to investigate. The journey took me 20+ years into the past and landed me on stage at DEFCON a few months ago to enlighten consumers like me as well as the financial industry.
How Your Bank Connects
Understanding Open Financial Exchange OFX Direct Connect
Like many people, I have various financial accounts, e.g., checking, savings, brokerage, retirement, and mortgage. And like most people, these accounts are in different places. I wanted a simple aggregator program to view all my accounts and transactions on a single pane. There are plenty of PFM (personal financial management) options but Quicken is the 800-pound gorilla and the one I chose.
Quicken has 3 different methods of connecting to your bank. They are:
Express Web Connect is an example of an account aggregator service. Other commercial aggregator services include Yodlee, Plaid, and MX. They provide a single, consistent, API for PFM clients to call and provide access to thousands of financial institutions, often by writing scripts which pretend they’re a human logging into the bank website. They essentially offer screen scraping as a service, but also clean/normalize transaction data.
As your data moves between these services and companies, there are some obvious architectural issues – most notably the lack of the concept of least privilege. You have only one set of credentials at your bank, which provide full read/write access to all of your accounts at that financial institution. These credentials, a plain text username and password, are sent through a series of middle men, which you must assume are securely transmitting and storing your credentials. This is not the way that secure web services are being developed today. A form of tokenized, application and time-based access control like OAuth is desperately needed.
Now let’s dig into what’s enabling all of this: OFX Direct Connect.
OFX, or the Open Financial Exchange, is an open specification and can be found at www.ofx.org. It is a protocol first written by Microsoft, Intuit, and CheckFree in 1997 to help customers interact with their bank electronically. Pretty much anything a normal consumer would do with their bank, OFX can do: check balances, download transactions, pay bills, transfer money, etc.
The protocol also supports secondary functions like password change and “email” messages sent between the user and the bank.
Security Risks and OFX
The OFX protocol is old, complex, and growing. That means potential security problems. When I say old, think CGI and SGML (the precursor to XML). The initial protocol version, 1.0.2 was published in 1997. In 2005 FFIEC (Federal Financial Institutions Examination Council, the same branch of the US government as the FDIC) published, “Authentication In an Internet Banking Environment” which strongly encouraged that multi-factor authentication (MFA) be used as a best practice in all financial institutions. In 2006, OFX version 1.0.3. added MFA capabilities. Unfortunately, none of these “MFA” capabilities are true multi-factor, but rather 2-step verification - adding those common questions to the username/password combo, e.g., mother’s maiden name, favorite color, birthplace, etc. The other suggested “MFA” methods are static strings that are defined once and then passed between client and server. Needless to say, they don’t add much additional security to the authentication path.
In 2007 the leading OFX server provider CheckFree was acquired by Fiserv, followed in 2009 by Microsoft discontinuing its popular Money product and leaving the PFM market. This left Intuit as the primary steward of the OFX ecosystem. As competition ceased, so did any improvements to the status quo.
OFX Version and Feature Information Tool: ofxpostern
As part of Security Innovation’s commitment to ongoing research and skills development, I developed a tool that scans publicly-available URLs for OFX version and feature information. I scanned approximately 2,000 sites and found that most implementations are using version 1.0.2 (from 1997) that provides no MFA support. Only 20% of deployments support weak “MFA” at a protocol level.
| Count of Financial Intuitions (FIs) | OFX Version (year published) |
| 1489 | 1.0.2 (1997) |
| 382 | 1.0.3 (2006) |
| 77 | 2.0.2 (2006) |
| 4 | 2.0.3 (2006) |
| 0 | 2.2.0 (2017) |
In 2005 the US Government started implementing MFA. 13 years later 1,600 banks have a front-end channel without it.
In addition to these architectural issues, there are a lot of security and privacy problems in production deployments. Here’s a list of issues I found with simple, high level, scans:
| Web server disclosure | MFA ignored |
| Web framework disclosure | SSN used as usernames |
| OFX server version disclosure | Internal IP disclosure |
| Backend DB disclosure | Valid user enumeration |
| Full stack trace on errors | Personal email disclosure |
| Full server file paths in errors | Unmaintained servers |
| Out-of-date software | Null values returned |
| Unhandled exceptions | Unregistered URL referenced |
| Long lived session keys | Reflected and stored XSS |
Mitigating Risk
For organizations that use Direct Connect and don’t plan to 'end of life' it, there are general mitigation measures they can take, along with specific ones, depending on their implementation.
High Level Best Practices Include:
If you would like to run a high level risk scan on your OFX implementation, download my ofxpostern tool to:
| Security Innovation’s deep understanding of the OFX protocol and its full spectrum of implementations ensures we can accurately assess risk and recommend steps to mitigate that risk. We can run a high level scan on your OFX implementation or conduct a specialized pen test to pinpoint risky and vulnerable areas. |