Wednesday, February 17, 2016

About two weeks back (Feb 4th, to be precise), I raised an issue with CIBC regarding their Interac eTransfer pages where once you are logged in to CIBC, you are asked to enter a password and that password box is read only meaning you can't type anything, so you can't deposit your money. If you try to reload the page, you then get an error because CIBC thinks you've already deposited this money when you haven't. This was the second time in several months I've raised this as an annoyance. It's a funny little bug in CIBC's code, but it's just a major annoyance that something which should be simple doesn't always work.

As often happens, I did some cursory poking about myself, to see if I could spot the problem. I started with the email itself and I instantly found something more severe, which I will document here.

In Canada, we have a very restricted banking system. In order to facilitate getting consumer money around, it has to got through a third party called Acxsys, which runs a system called Interac. This Interac system's stakeholders are the same banks you are trying to move money between. A particular feature of Interac involves sending money via email, so the user clicks a link, selects the bank to deposit to, enters a password and the money is wired in.

In short, it runs like this:

Debit the money from your account.

Deposit the money to a holding account in your bank.

Send email with link to recipient.

Recipient clicks link, selects their bank.

Once logged in to their bank, the recipient types a password.

Interac authorizes the transfer and the recipient sees the money up front.

That night during settlement, the real transaction takes place.

In short, it's like credit card where the money is fronted for you to spend before it's settled and the only difference is instead of you settling with your card issuer, the sending bank settles with the receiving one.

The issue is the server that serves up these links is not particularly secure.

The only protocol it appears to support is TLS 1.0. Neither 1.1, or 1.2 are supported.

A quick run down of the cipher suites and bits on that server shows this:

TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE128

TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128

TLS_RSA_WITH_DES_CBC_SHA (0x9) WEAK 56

TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)112

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)128

TLS_RSA_WITH_AES_256_CBC_SHA (0x35)256

TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3) INSECURE 40

TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x60) INSECURE56

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8) INSECURE 40

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62) WEAK56

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64) INSECURE56

So, the server is mostly considered insecure with a few acceptable ciphers on it. You might be forgiven to thinking that these insecure ciphers are not in use and everyone is using the stronger ones, right?

Yes, about that…

If you run a handshake simulation on that server, and see what type of security each platform and browser defaults to when connecting, you see that it defaults to an insecure cipher on Mac and iOS 100% of the time, as well as Android, and totally mismatches on iOS altogether to the point that it’s equivalent to Windows XP.

So, right here we have consumers going to what is known to be an insecure server to initiate financial transactions. The icing on that cake is that the server is also vulnerable to the POODLE TLS attack, meaning you should be able to (in theory) pull off a man-in-the-middle attack.

In conclusion, having looked a bit more closely at what’s going on, I wouldn’t trust this system as far as I could throw it.

It's been 13 days since I first raised this with CIBC (one of the stakeholders). I'll update this when it's fixed.