Thursday, May 26, 2016

Anomaly with City of Toronto site security...

I ran across an anomaly on the City of Toronto website today....

They go to pains to point out that you're on a secure site in a weird "in-ya-face" way.  This is normally a red flag for me. People make a point of pointing out something when they believe your mind needs to be changed.  For instance, I'm told my burgers are 100% beef because someone in marketing thinks we have ideas that maybe it's not.  I'm told the latest cars are much more fuel efficient, because someone thinks I might have other opinions on this.  Now I'm being told in big message boxes that something is secure.  Mental red flag.

OK, let's suspend disbelief for a second and imagine that it actually is secure - where is the browser padlock?  

(Click for bigger version)



I clicked the "Close" button and then got to the next screen, where again it points out that you are in a secure site on the first line.  Again, there's still no browser padlock.  I also noted the usual bank-trade trick of proclaiming things are secure and placing the onus on the user to make sure they've done their bit for security.... even though the padlock is still missing.

(Click for larger version)
 

So, I took a quick look at the certificate. The first thing you notice other than the City of Toronto is apparently in Macau, is the verification error that this is a self-signed certificate - so this is no more valid that if I generated one here on my computer and delivered it on a USB stick to City Hall. I've highlighted both items in red.


Jasons-2013-MacBook-Pro:~ jasoncoulls$ echo ^d | openssl s_client -connect secure.toronto.ca:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=CA/ST=Ontario/L=Toronto/O=City of Toronto/OU=Technology Infrastructure Services - macau-w1/CN=secure.toronto.ca
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
 3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRzCCBC+gAwIBAgIPb+ZsRia0KHZ5+v4/DWkpMA0GCSqGSIb3DQEBBQUAMIG1
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBh
dCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTEwMS8wLQYDVQQDEyZW
ZXJpU2lnbiBDbGFzcyAzIFNlY3VyZSBTZXJ2ZXIgQ0EgLSBHMzAeFw0xNTEwMDYw
MDAwMDBaFw0xNjEwMDUyMzU5NTlaMIGfMQswCQYDVQQGEwJDQTEQMA4GA1UECBMH
T250YXJpbzEQMA4GA1UEBxQHVG9yb250bzEYMBYGA1UEChQPQ2l0eSBvZiBUb3Jv
bnRvMTYwNAYDVQQLFC1UZWNobm9sb2d5IEluZnJhc3RydWN0dXJlIFNlcnZpY2Vz
IC0gbWFjYXUtdzExGjAYBgNVBAMUEXNlY3VyZS50b3JvbnRvLmNhMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnFUWzMyfTL6zFKFj69W8KdwwKlpogf1Z
3wJrZpH23x+oPVz9pA5Ti2NxG4PvqI6Y/ybcrLArIXa4+xD8e9zYDSIw8Umk4fSb
2OrmQTSAVlMtEGabAJZO1ksM1+kfmw2tXfV7n1a07gGSY9lpwWmqr5HGCvV6aCyO
xyojCOvOs9SI4m5UbRvW/Je5qaX4gfNzx2xQ9de/nC4s7dCVolFYm1ZI+OiwQiZ4
i0tnMGk1Zela70thnCmIU1TZ08FTXjffAFgpvxKK00m5hxvKrkZ0Bqmh3GG5K/G3
7dRdNKkAPoocBbOy3hwtwU61EgNrKRumNl/M5gcaRYwBV27YXvBsvwIDAQABo4IB
ZjCCAWIwHAYDVR0RBBUwE4IRc2VjdXJlLnRvcm9udG8uY2EwCQYDVR0TBAIwADAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGEG
A1UdIARaMFgwVgYGZ4EMAQICMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1j
Yi5jb20vY3BzMCUGCCsGAQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBh
MB8GA1UdIwQYMBaAFA1EXBZTRMGCfh0gqyX0AWPYvnmlMCsGA1UdHwQkMCIwIKAe
oByGGmh0dHA6Ly9zZC5zeW1jYi5jb20vc2QuY3JsMFcGCCsGAQUFBwEBBEswSTAf
BggrBgEFBQcwAYYTaHR0cDovL3NkLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0
cDovL3NkLnN5bWNiLmNvbS9zZC5jcnQwDQYJKoZIhvcNAQEFBQADggEBACmV9Q6g
KougvgnCPSItcved21qdGRtO2u8/LrOwI9BnKeXcDCg7824zCbD3y2q7X0GlbjoW
BFcfH0ZZX1NTer2V/AUK1cn3oOi0EUJH628AhED/HC3ld4Rpw+I8twp0aJNbo+1t
P6NBoTm3dQoMUlGhULGIgrMTtM6oRDQtqp/Qez3OBHRlqdlxardAV7ybDIvWH9pd
hyGwUp+4Kuv9n234D8Tc081B4Q0omGDwRozXd7rf1rBJFALY+1qonVRkquYE0krU
KNI0M9XjnqN61ynjkrIHO1WkeFaoXy4/7oLRHbLCSWqexSYSuWMGeVAPvCtowtXl
hyQyq2k6pA8zXVU=
-----END CERTIFICATE-----
subject=/C=CA/ST=Ontario/L=Toronto/O=City of Toronto/OU=Technology Infrastructure Services - macau-w1/CN=secure.toronto.ca
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4853 bytes and written 636 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES128-GCM-SHA256
    Session-ID: 00000D2AD210CD02429618321FAA1D60105219435858585857471DBB000016D0
    Session-ID-ctx: 
    Master-Key: DDEF69EA999B9A7FA1AAA0AE94D5F3A00F5F9FF5F47D854BAC1621B018CC81751C17BCE855B6FE497AD99445EAE5830C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1464278459
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

DONE


So, there you have it.  Whilst the city tells you it's secure, both the browser and the openssl tool verification gives errors or refuses to show the padlock.






Wednesday, May 25, 2016

Finally, a bank listened.

Anyone that has the smallest bit of familiarity with me will know that I keep a keen eye the security of Canada's banks and telcos, especially those that I know are putting me or my family at risk.  I might sound like a crackpot at times to some people, but those that know me well all know that I'm not going to publicly say something if I couldn't substantiate it.

Over the past month or so, I've spoken to each of these organizations in turn (sometimes I reached out to them, other times they phoned me first), as my concern levels are now at an all time high.  Some banks flat-out said they were not going to entertain the idea of paying me for my time to explain their problems, and that's their decision - I work in IT and I'm not working for free.  Some banks couldn't answer one way or the other as to whether they will or won't entertain the idea, and one bank positively jumped on the opportunity to hear me out.

It's no secret that I consider much of Canada's banks to be a security disaster in motion; I've been saying for years that things are broken.  Things have been surreal at times (for instance trying to fool the bank security into thinking my dog was me), and other times I think I'm moving forward only to find myself going backwards again.  As time has gone by (and especially recently) what started off as my documentation of a small set of issues with a few root causes with one bank has snowballed to something really huge that now spans the entire Canadian financial system and expands out of it in all directions.  

Obviously, I'm not going to say what I found, but it's an uncomfortable situation having the knowledge of what an amazingly precarious situation we are all in.  I know what's broken, what's not being tested. What is likely to be the major vectors to breach most banks and what went wrong in policy to allow this to happen.  So, when I see Twitter feeds from these banks telling their customers that their online banking is guaranteed secure, it makes me cringe because I know it's not secure.  I also know that if I know it's broken, others will know that too.  Of course all the banks in Canada have a standard public mantra throughout this of "It's secure until YOU lost your acct # or password" as if they believe it could never be them at fault for a breach, even though I know they're likely already compromised and they've more than a small chance of compromising other external organisations in the process.  

Now, I don't have to get into a convertible car with the top down to know that if it rains in the future that I'll get wet, because I know and understand what I'm looking at. It's like if a bank gives me an address of a branch in a town I've never visited, I can guess accurately that at night, they can't see the sun from that branch.   Same thing applies to digital banking at most banks in Canada - you don't have to hack them, go into them, or do anything untoward to them to know where and how they can be compromised.  

So, bearing the above logic in mind, I sat down with this bank and explained what's going on in Canada.  Like the car or sun analogy above works with the average person, what I had to say worked with bank security people.  So, I covered how Canadian's are at risk with their mobile apps, how the banks online banking systems are mostly all broken and then covered the security circus that we know of as Interac.  They got it immediately - I didn't have to explain a thing...

...and then I dropped the "Here's the really, really, bad side-effect of this" bombshell.  They got that too - understood it, crystal clear.  Not a single "You're wrong!".  No mention of "That's impossible!".  There was not a single ounce of disagreement.  Finally, after a very long time, I was talking to a major bank and they're like "Everything you say is understood".  

In a surprising twist, after being asked if I've ever considered a career in bank security, I actually got asked my thoughts on the SWIFT situation?  I had an immediate four point answer on what's broken (it needs certs on messages, cert-pinning with clients and servers, hashing of messages to stop alterations and a central pub-sub number authority to stop message injections in the sequence), but as I answered, I couldn't help thinking how far this situation had turned around; Usually big banks argue against me, and now here I was, being asked my opinion on how I'd fix the largest bank messaging system in the world.

This makes a big change from the status quo.

Whilst I have no idea what'll happen next with this particular bank, my immediate job is done. They know what I know and now hopefully there will be action as a result.

As for the other banks?  Well, time will tell if any come back to the table.

Sunday, May 15, 2016

How the Swift bank messaging heist will affect Canadian banks

If you've been paying attention to the news lately, you'll know that a large sum of money just got removed in a heist on the Bangladesh central bank using the SWIFT system.

First, a bit of background to explain what the mainstream media doesn't explain clearly...

The SWIFT messaging system doesn't actually move money itself and it keeps no account numbers or ledgers for the banks it goes between, or the money being instructed to move.  All it does is says "Bank A needs to settle this transaction with you" to Bank B.  It's then down to Banks A & B to sort that out between themselves.  You can replace SWIFT messages with a carrier pigeon note, or a note tied to a brick and though these are less secure than SWIFT messages and slower moving, it wouldn't actually make a blind bit of difference to the banks as far as money moving goes because this is down to the banks to achieve.

So, now you're up to speed, let's ask see what happened?

In plain English (and simplifying things immensely), what happened is this:  Robbers targeted the SWIFT (Society for Worldwide Interbank Financial Telecommunication) messaging system.  They simply added a few bogus SWIFT messages into the pipeline instructing the Bank A (Federal Reserve Bank of New York) to send money from the Bangladesh central bank account to a bunch of other banks in other countries.  Of course, the banks just blindly did what they were told.  Five messages went through and were settled to the tune of $81million, and then someone noticed a mistake in the sixth message and questioned things and this is when the messages were all discovered to be bogus.  The backlog of 30 messages not yet processed were totalling $850million.

How does this affect the Canadian banks?

The SWIFT heist wasn't an isolated incident.  The people that pulled this off knew that the banks considered themselves to be secure, but that security could be bypassed.  In Canada, we also have the SWIFT system, so the same risks apply to Canadian banks if they're not secure.  We also have a similar system for consumers in the form of Interac.

Just like SWIFT, Canada's Interac system doesn't move money either.  It sends messages to move money, and the banks figure out how they'll do that at the end of the day.

In plain English, it looks like this:

Bank A deducts $50 from Mr Jones who wants to send to Mr Smith. 
Bank A:  I've got $50 from my customer Mr Jones, for your customer Mr Smith.
Bank B:  OK - I'll add $50 to Mr Smith's account.

Mr Smith can now spend that money immediately.  At the end of the day, when the banks settle, this happens:

Bank A to Bank B:  I owe you $50.
Bank B to Bank A:  Well, I owe you $60 from an earlier transaction, so here's $10 and we can call it quits.

There's a lot of parallels to the SWIFT system in that it's purely based on trust.  This is the first problem.  For Canada's banks, they need to now harden up security on two systems that are kinda flakey if you don't do things correctly (SWIFT has strict procedures on how Banks should do things).  This trust issue is key to the whole security problem in Canada.  You have banks trusting each other - and trusting Interac - and customers trusting Interac and trusting the banks.

This is where the wheels fall off this wagon...  I reported to CIBC in January that Interac's servers were not secured properly from an SSL standpoint.  They fixed that in April, but there's two bigger underlying issues and I'll touch on one right now.

Let's imagine you are writing an iOS app in Canada and need to take debit cards.  You call Interac and they're like "Go away - we don't deal with the public -  go talk to one of our authorized integration partners".  So you deal with the integration partners who then have no sway over Interac to fix things when the situation goes sideways.

I've actually gone through this, where an iPhone had a 320 pixel wide screen, and some tool at Interac had hardcoded their CSS to 640 pixels wide, thinking that no computer would ever access their system on a screen less than 640 pixels.  So, I phone the integration partner and they phoned Interac. After a few days, the official word was Interac weren't going to change this.

How did I fix this?  Well, I did what everyone else did back then; you take Interac's broken CSS, fix it and store it in your app as a bundled resource.  Next, you make your normal calls to Interac's computers to initiate the transaction, get the HTML and CSS response, and you simply switch out their busted CSS and replace it with your own fixed CSS.  It's not like Interac ever designed anything to detect this kind of meddling.

If you're technically minded, you probably just realised this is the equivalent as a man-in-the-middle (MITM) attack.  Yes, it's common in Canada, that when Interac doesn't want to help a situation, you just code around them.

Of course, if you can switch the CSS (which determines how things are laid out) you sure as hell can change the HTML (the message the customer sees).  That's scary.  So, Interac is going to have to finally get it's act together and tighten up security...  As it stands, Interac can be compromised in two ways that I know of.

What about the banks themselves?

They are likely being told the same as everyone else - which is harden up.  This is a problem, though:  If you look (in Toronto, at least) at the banks and their current hiring process, you can see predictability - if it's a bank, it will think like a bank and it will act like a bank and it will hire the same type of security people that it did before.  That predictability combined with a sense of trust that the banks know what they are doing is where the danger is in Canada.

Here's a current security post from CIBC as an example:


If you're not quite sure of what you're looking at, let's break this down:
  • Right now, they want more of the same type of people that they hired to guard about 50 servers and all their technology infrastructure in 1998.  You're certified for the bank, fit the bank's culture and think and act like you belong in a bank...
  • It's not 1998, and smartphones came out in 2007, social engineering took off, the two gender tick boxes for customers are not enough to define people, and now customers are attacked outside the bank because they're mostly fighting the wrong war. 
When faced with an attack surface of some ten million devices and computers in Canada, that a technically curious average 15 year old can circumvent in two days, it's apparent that some Canadian banks are not in the same security arms race as their customers.  This means it's technically more feasible to compromise a bank through compromising it's customers.  That job above didn't even mention mobile, despite that being a massive vector for attacks caused by most bank's own ineptitude.

I will leave you with one last screenshot I pulled off Twitter two days ago.  Note the "1/4" response and how confident the bank is that they are secure and the insinuation that any failure that might happen will be the fault of the customer.  This is scary considering how broken the security is.

This is what I lose sleep over.  


Friday, March 4, 2016

Thoughts on the CIBC iOS App

I'm going to start this post with the very unlikely request of asking you to skim over some text from CIBC bank in Canada, that is explaining to its customers what data it collects and how it collects it.




Now, having read over that, you're probably asking yourself one of two things:
  • What was the point of that exercise?
  • What is with that "If you provide us with information on another individual, we will assume you have the authority to provide us with this information" bit all about?  
Today, I was following up on an unrelated issue with CIBC to do with a fault during Interac deposits and whilst I was at it, unloaded some more security related stuff - primarily that I'd spotted two servers that had not been patched against the DROWN attack, despite patching nearly everything else.  This got me thinking that it's been a while since I last took a look at the CIBC banking app.

You may remember that last year CIBC rushed out their Apple Watch app so fast, it still had iPad cruft sitting in it that contained backdoor URL's.  The acceptable solution to fixing the backdoor URL's was leaving the URL's in place, and renaming them to "BD" instead of "Backdoor".  After that, I found the mobile testing team's GPX file telling the world that Dundas Square is where they test this app (that's now removed).  There's also been a number of small niggles that I just get the feeling that I shouldn't trust this app, so on the grounds of security, I wouldn't let it on my phone.

Today, I decided to go and download the latest version and take a peek at it.

Now, in the interests of protecting my own security, I didn't set up the app with card or account information.  Instead, I did a straight install from the Apple App Store and then fired up the app, and when I saw the login screen, exit the app.

That's as far as I will allow the app to run. I'm definitely not trusting it with my banking information, so did not provide the app with that.  

A quick check of my iOS logs showed nothing untoward.  I could see the app going into springboard and I could see the app trying to get onto my watch - which it did, albeit minus the icon for the app.  

The next thing I checked was to see if the app was writing information about me onto the phone.  Bank apps shouldn't store anything on the phone that could lead to you being compromised as a result of storing this information, so I wanted to check to see what the app had done in the few seconds it had been running on my device.  

The app had created a .plist (Property List) on my phone under Library / Preferences.



I was intrigued as to what they'd stored as a "preference" when the app hadn't done anything yet.   I'd not set any preferences.  I'd not agreed to anything.  Whatever CIBC was writing was their preference not mine - so I took a look at the file and ran head first into this...



You may remember at the beginning of this article, the "How we collect your data" list? I don't remember it saying that they'd query my phone to find out who I pay my cellphone bill to, and storing that as a "preference"?  

Technically, this is also bad.  That stuff should have gone into the Documents directory, not hiding in Preferences.

I ran up the watch extension and took a peek there - as expected, they're not storing anything as a result of that extension running.  Now, taking a step back - I should explain something.  I get it, it's just analytics?  They want to know which network I'm running on, so they can pinpoint issues.  

Normally, I'd be fine with that if they told the user what they are doing - or asked me if it's OK to query that out - or wrote in their terms that by running up their app, they'd be mining out data about who my mobile provider is.

So what's going on under the hood?  In short, they're running Adobe's ADMS App Metrics - and what that's doing is pretty much this:


This is a standard iOS routine (the above code is what I personally use if I need to give someone on Rogers something specific, for instance), but the key here is you tell your users that you will access this stuff and not be sneaky about it.  First you ask the phone for the Mobile Country Code, and if it's 822, you know you're in Canada and if the Mobile Network Code is 370, 720, 820 or 920 then you're on Rogers.  

For the sake of completeness, here's the same code for Bell.


This sneakiness is indicative of a bigger problem, though.

As an app developer, I understand that when I am invited onto your personal phone, this is a privilege.  The way a bank sees it is the opposite:  When they get onto your phone, your phone is seen to be an extension of their network.  In other words, it's a privilege that you're accessing their services, not that they are on your phone.

And that is where the wheels start to fall off...  A brand is not what your marketing department tells people, it's what people tell other people.  And when you're doing sneaky stuff like this people talk.

By not being forthright and transparent about what data is being gathered, and then trying to sneak it out from under my nose, CIBC lost the privilege to be on my phone for the second time.





Tuesday, March 1, 2016

Canadian Financial Infrastructure and DROWN attack.

About three weeks ago, I reported that there was a security issue with etransfer.interac.ca, where the server was susceptible to the POODLE TLS attack.

Of course, before I said anything publicly, I gave CIBC a few weeks notice (CIBC was told on February 4th) to look into it and speak to Axcsys about fixing it (all the major banks in Canada have a stake in making sure this system works well)...  To date, it's not been fixed on Interac's end, and also CIBC hasn't gotten back to me either, which means they've likely not gotten very far in resolving things or it's dropped off their radar altogether.

Today, I found an additional problem.  The same server is also open to the DROWN attack.  I'm not going to go into the details about what that attack is, as it's fully documented here at drownattack.com.  There's also a complete paper on the full technicalities here.

I also quickly checked to see who else was vulnerable in the big Canadian banks.

In the bad pile, we see:
CIBC.  (UPDATE: As of March 4th, many CIBC servers have been patched)
TD.

In the middle we have ScotiaBank & RBC.
Scotiabank has less servers vulnerable.
RBC.com has some issues which RoyalBank.com does not.

In the clear is:
Royal Bank.
BMO.com.

There's some surprises for me here:  
Seeing TD in the bad pile does surprise me as they're usually pretty good with security.  I'm not surprised at all about CIBC.  I also thought that ScotiaBank would fare a little better than they did.  

I'll finish this post by coming back to Interac... The etransfer.interac.ca site is also vulnerable.  This doesn't surprise me as it's been a month since the first issue was first reported and still hasn't been fixed.  

I have a feeling we're about to see a lot of PR about security in financial services from Canada's big banks and Interac.

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_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)   INSECURE 56
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)   INSECURE  40
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)   WEAK 56
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64)   INSECURE 56

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
Chrome 47 / OS X  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
Firefox 31.3.0 ESR / Win 7TLS 1.0TLS_RSA_WITH_RC4_128_MD5  No FS  RC4
Firefox 42 / OS X  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
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 11 / Win 8.1  RTLS 1.0TLS_RSA_WITH_3DES_EDE_CBC_SHA  No FS
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
IE 11 / Win 10  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.