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.