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:
  2. Next, you can see sites being picked off these lists and registered. For example, which was in a list ( was registered ( 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 ( 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 (  

In the case of Scotiabank customers, this simply targets everything going through any part of Scotia Connect and sometimes the entire 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 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 for that reason and just use the main 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**/index.html
  2. <head**>
  3. <head**><script>top.location.href = ",,2,00.html";
  4. </script>
  5. https://www**
  6. <head**>
  7. <head**><script>var script_link = ""+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  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.

No comments:

Post a Comment