Wednesday, February 17, 2016

Security and Interac

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. 

Here's a summary (source)

So what's actually going on?

First, the good news:
  • That server has a certificate, so a padlock is shown to the user.

Now the bad news:
  • 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)   INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE  128 
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256

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.

Handshake Simulation
Android 2.3.7   No SNI 2TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 4.0.4TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 4.1.1TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 4.2.2TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 4.3TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 4.4.2TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Android 5.0.0TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Baidu Jan 2015TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
BingPreview Jan 2015TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Firefox 31.3.0 ESR / Win 7TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Googlebot Feb 2015TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
IE 6 / XP   No FS 1   No SNI 2Protocol or cipher suite mismatch
IE 7 / VistaTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
IE 8 / XP   No FS 1   No SNI 2TLS 1.0TLS_RSA_WITH_RC4_128_MD5  RC4
IE 8-10 / Win 7  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
IE 11 / Win 7  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
IE 10 / Win Phone 8.0TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
IE 11 / Win Phone 8.1  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
IE 11 / Win Phone 8.1 Update  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
Edge 13 / Win 10  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
Edge 13 / Win Phone 10  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
Java 6u45   No SNI 2TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Java 7u25TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Java 8u31TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
OpenSSL 0.9.8yTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
OpenSSL 1.0.1l  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
OpenSSL 1.0.2  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 5.1.9 / OS X 10.6.8TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 6 / iOS 6.0.1  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 6.0.4 / OS X 10.8.4  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 7 / iOS 7.1  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 7 / OS X 10.9  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 8 / iOS 8.4  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 8 / OS X 10.10  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 9 / iOS 9  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Safari 9 / OS X 10.11  RTLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Apple ATS 9 / iOS 9  RProtocol or cipher suite mismatch
Yahoo Slurp Jan 2015TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
YandexBot Jan 2015TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4

To recap what I’ve just pointed out to you:  "The server only supports TLS 1.0 and RC4 ciphers when you’re an Apple user or Android user".

You may be wondering what the big deal is here?  

Please allow me to point you to the February 2015 IETF memo on this matter:

The key sentences I’d like to highlight are...
Section 1.1 “RC4 can no longer be seen as providing a sufficient level of security for TLS sessions.
Section 2.0 “If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.

Just to really hammer this nail home, the PCI compliance rules also reflect a similar stance on this combination, as you have to get TLS 1.0 and RC4 off any PCI compliant server by June 30 2016.

If you Google this, you'll see this is no secret.

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.