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.

Wednesday, August 19, 2015

Telco security in Canada

This morning, I was checking up on some old security holes, just to see if any had been patched or not.  I looked at Rogers and I looked at Bell Canada.  Usually, not much changes, but this morning I noted that both had tackled some very very low hanging security fruit.

It may be coincidence that they both did this around the same time.  It may also be a case of one noticed that the other had "upped their game" and followed suit.  Either way, both of these flaws were schoolboy errors that allowed someone to start poking around in areas where the general public shouldn't be.

In the case of Rogers, you could access network infrastructure information that wasn't for public consumption.  In the case of Bell Canada, you could see what their PR machine was going to announce before they announced it.  After a little more poking around, I discovered Rogers still had a hole, so I've reached out for the them to contact me and I'll re-explain it to them.

Now, here's the kicker:  Both holes are visible in Google's caching mechanism, meaning you don't need to even touch or access their networks.  You just wait for Google's bots to crawl through the holes and report to Google what it found, then you just go and read it on Google where it's all spat out for all and sundry to see (if you know what to look for).

As you can see, this is schoolboy level stuff.  Luckily, in either case, it wasn't spewing out customer data - but each flaw does point to a bigger problem with security...

In Rogers case, it's usually that unless something involves billing or customer facing sales, websites and portals become neglected and forgotten - at which point security moves on and certain Rogers sites become relics of the past which are prime targets for problems like this.

In Bell Canada's case, their security problem is that they parade around saying how safe they are, pointing at firewalls and technological expenditures and monitoring equipment, then undermine all this with policy.  As I've said before, Bell can add as many guns as it thinks it needs to the decks of its battleship, but it doesn't make the blindest bit of difference to fixing the existing hole below the waterline.

Further, their myopic legal stance is basically paraphrased that if you report to them something you shouldn't know, they'll respond like you have perpetrated the crime.  This is analogous to you are on one side of the street and notice a burglar breaking into a house on the other side of the street and running off with the TV,  then you get arrested when you tell people you know the TV is missing.

This is what led to the rather silly situation with Bell Canada where nobody tells them what the specifics of their problems are, which reinforces Bell's notion of "Absence of evidence is evidence of absence" where security holes are concerned.  Meanwhile, crooks can run with compromised customer accounts that can't be reported.

So, in conclusion, whilst it's nice to see small incremental changes in security are happening at Canada's two major telco's, there's still bigger issues at play.



Tuesday, July 21, 2015

The Hymn Of Axciom

Today, I was looking again at another runaway data leak, which I am pretty sure originates within Bell Canada, but in order to know that for certain,  I have been tracing the source of the data through many different links in the chain through the usual methods of poking privacy departments, legal teams, etc, for the better part of the last month.

Today, that chain exited Canada as the last privacy team handed over the name of the next team I would be talking to. This turned out into Axciom, in North Little Rock, Arkansas.

If you've not heard of this company, you should go and research them.  This is a large data company who's practices get questioned a lot by privacy advocates.  So much so, there is even a song about them called "The Hymn of Axciom"...

Check it out.



Tuesday, June 30, 2015

IVR Security Hole Redux with CIBC

In January, I was dealing with the bank CIBC over an issue with their IVR system.

To recap, there was a problem with their automated system, where it would call and ask the person who picked up my phone to "press 1" if they were me.  If someone presses 1, the bank would then fail to verify if I'm actually me, or the cleaner, the child-care assistant or the robber that just stole my phone and would rattle off what I consider to be personal information.

Obviously, I wasn't happy about that security hole as I had reported it in early-2014.

Eventually, a dialogue opened up with the bank (after I complained the hole had been there for 9 months since I first reported it) in January 2015, and eventually the solution was rather than fix the issue for everyone the bank would unsubscribe me from it.  This meant I was at least protected, even if nobody else was.

Six months have now passed and CIBC has reversed this security fix and the system called me again today.

Seriously...


Saturday, June 13, 2015

Programmers and Interruptions

As a programmer, the single biggest problem I face is the interruption.  Whilst I can joke and empathise with other programmers about this, it's something that non-programmers don't understand. There's a well-worn cartoon in programming circles that I will share here, just incase you haven't seen it.



The point of the cartoon isn't lost on anyone, but what is lost on non-programmers is the time span that this may have taken place over.  For an average programmer on an average job, you're probably looking at 10-20 minutes.  For a programmer working on a really complicated system, this can be several hours.  Additionally, the mental workload involved can be draining enough that if this happens, say, three times in a day, the entire day can be written off. 

But what's going on here?

The crux of the problem starts with the differences between knowledge workers and non-knowledge workers.  Most people regardless of status in the workplace will work on a schedule where you focus on some thing, get interrupted, switch focus until interrupted again.  It's all about prioritising what is most important and getting these things off your plate as quick as possible.  You hear managers complain that they never get anything done because their day is full of interruptions, but really that is their schedule - it's just a series of interruptions and the only thing they have to worry about is what interruption is coming next.

This means when a manager/house-buddy/spouse walks up to a programmer and asks them "a quick question", they interpret the amount of time being expended by the interrupted is the same as the amount of time spent by the interrupter.  However, this is not the case...

First, let's introduce the programmers mental stack.  It's analogous to this receipt spike:


With a receipt spike, the first item on the spike is the last one to come off.  This spike is known in computer terms as a "stack", but it's the same thing.  For a programmer, the first item (so at the bottom) on the stack is what we are trying to accomplish (fixing a bug, writing a feature, etc).  Then we push onto the stack the next pieces of the puzzle.  

A real-life example of what I am talking about...  This is one I had today (remember, it's in reverse order, so start at the bottom) it's about 45 minutes :
  • Trace in my head the flow of the header packets that precede the payload packets to make sure this is the best way of doing things.
  • Double-check logic for endian-ness incompatibility.
  • Packets in wrong order still, so add stuff for that.
  • Rejig classes X1, Y1 and add new functionality to classes X2 and Y2 all in my head.
  • Build packet model in my head.
  • Refresh my head on how the packets are structured. 
  • Looks like a packet issue - maybe if I remodel how I'm dealing with the packets... 
  • Let's trace the code in scenario B and compare to what we just learned in scenario A.
  • Let's trace the code in scenario A to see precisely what's going on.
  • It fails in scenario B - must fix scenario B. 
  • It works in scenario A 
  • The device does not behave how I expected it to.
  • There's bug in my iOS Bluetooth code - must fix it.


Obviously, this is all done mentally in my head, and I'm tracking what changes I haven't yet done as well as concentrating on the actual task I'm working on at this precise moment, whilst making sure to balance the stack in my head so when I finish each task, I can go back to the task I was working on before.  When doing this, I'm not typing a single line of code.  I'm staring at a picture on the wall - probably not even taking in what my eyes are seeing - and my ears hear stuff, but I'm not actually listening.  I've likely got headphones on, just to drown out the things like talking that are happening around me, so I don't lose focus.

This is the moment when people say "Oh, as you're not busy right now, can I just ask a quick question" and then wonder why I'm annoyed.  As the person is still talking to me, my head is scrambling to work out how I'm going to recover from this as I still have about 3/4 of the stack in my head.  As I'm being asked if this was a bad time, my anxiety level is skyrocketing as I try to cling on to what I learned in tracing scenario A in that stack above... Was it header packet 0x02 that had the payload size 0x0400?  Must remember 400... no, it's not 400 as the bytes need to be swapped so 0400 is really 0004...   At this point, I must answer the question I'm being asked - so blurt it out - 4... must remember 4... what packet was that on again? 2? Was that in scenario A? Or B?

Now panic sets in...  If I can't remember whether the payload size 400... no... 4... is the right one or the wrong one, I need to go back and look at that again, which means we're now into another 30 minutes of building up the model in my head again.  Having answered the question, I'm staring at my screen and quickly trying to refresh my head.  This is when you hear the dreaded words "Before you get too engrossed again, can you just...."

Aargh!

Now, I can get back to work in a minute or two if I'm doing something trivial.  However, if I'm working on a really complicated issue (such as the above Bluetooth stack), then it's not uncommon for me to take 30 minutes or longer to get things straight from a cold start.  Really big issues can take 90 minutes to get my mental cache loaded up with the model of what I'm doing and how I'm doing it, plus all the states memorised as to what it's doing right now. 

And I'm not alone.... There's a study (see here) that was done over 10,000 programming sessions to see what the edit lag (how long it takes between interruption and starting to type again) that looks like this...



As you can see it takes a while to get back into things.

There is a retort from some managers (or other house guests if working from home) that we need to "learn to handle interruptions better".  This is just throwing fuel onto the fire as a knowledge worker is busy using concentration and focus to perform a task and interruptions cause a break in this focus, making the comment analogous to tripping up a footballer and telling them that they need to handle unplanned obstacles better.

One last thing I'll leave you with:  Never interrupt a programmer chatting to a rubber duck to ask them what they're doing.