Thursday, March 30, 2017

Everyone kept saying I could write a book...

... about the stupidity I've recently been through.

So I did, and it's here. (Click the image to go to Amazon)

Thursday, March 16, 2017

Follow up on the ScotiaBank phishing scam

When I last posted to this blog, the other day, I didn’t expect to see anything like the level of interest that the post generated.  There is one question I’ve been asked several times since, which I thought I would address in this post…  

Q. Is it possible to determine which ScotiaBank customers fell for scams?

The short answer is mostly yes.

The longer answer is it’s possible depending on a few factors, however I’m not going to publicly explain how to do this, as there’s a few issues here.  The biggest issue is simply that’s it’s not my data, and handling stolen data is illegal, so I’m simply not going to cross that line and I also refuse to enable anyone else to handle it either.  A second issue is that’s the bank’s job, and I’m not about to start giving out free IT help to banks…  

So what’s next?

The CCIRC were previously sent a much larger report on this issue, along with supporting proof of what historically goes wrong, when, and what was being missed.  I’ve already noticed that they've done some preliminary poking about based on it.   

We are now 2 days after my original post that said there is usually “ample warning” that a bank phishing attack is coming, and I'm now watching the same attackers' next site slowly coming together since the site was taken down yesterday.  

As you can guess, the CCIRC were notified this morning that the next scam site is now being readied.  I already gave the CCIRC the full list of 8 sites that I can see coming a few days ago, and so we’ve just checked off another one off that list. 

The current timelines are such now, that there are a clear five days of warning that this next scam is coming.  Now that I’ve successfully proved that the warnings are there if banks applies some common sense, the CCIRC is now in a position to monitor this next site from creation, to corroborate what I’ve been saying about the rest of the process in real-time. When the scam generates a signal on Twitter from customers reporting the scam in about 2 days from now, the stop-watch can be stopped when the site is taken down.  That gives outside observers like the CCIRC an idea of response times from when it’s first possible to know a phishing attack is coming to when a bank finally did something about it.  I’ve previously told the CCIRC that this can take as much as 12 days, but they need to see this for themselves and not just take my word for it.  Now they have that opportunity.

Tuesday, March 14, 2017

Deconstructing the average ScotiaBank phishing scam

I've been documenting the digital train wreck at ScotiaBank for quite some time now.  Today, I want to cover something different, though it's still to do with phishing and ScotiaBank.  But, instead of pointing out how bad the bank security is to allow phishing in the first place (they've known for a year now to switch on X-Frame Options, for instance and still haven't done it), I'm going to share how another angle works.

I'm going to talk about "Scotty".

If you're unacquainted with Scotty, here is the mobile version in action.

(Click for bigger)

Scotty is the common ScotiaBank phishing scam kit.  It's what drives nearly every targeted attack on ScotiaBank customers.  

Written in PHP, by the group l33bo_phishers it is intelligent enough to try and display a mobile form or full desktop form, as well as protecting itself with session checking, blacklisting IP addresses, not running in old browsers, and it logs a lot of information about the victims including their IP addresses.  Intriguingly, it also encrypts stored information with AES (Rijndael 128 to 256 bit - which the attacker can configure), so that any information the attacker gathers is somewhat protected until they can resell the victim information.

Scotty is primarily broken down as follows:
  • A login page - to gather card number and password.
  • A page which will gather the users name, social insurance details, date of birth, etc.
  • A page that gathers the user's secret question answers (shown in the image above).
  • A page that takes all this data and runs it against a list of swear words (to remove entries where the victim clearly knows it's a scam) and only posts the data if it looks legitimate.

The entire thing is configurable, so you can set whether you want logging of sent messages, what key to use to encrypt your data, enabling one-time access (so if the same IP address comes back, they're redirected to Google), and so on.

When a victim has been successfully scammed, if the attacker has switched it on, an email is sent out using this template...

PHP Template

So how do these kits get used?

This next bit will likely be out of date within hours
 of posting this, for obvious reasons.

As you can guess, it's a bit predictable in that attackers know they only have a short window of opportunity before a bank tries to take down any of their sites.  Talking specifically about ScotiaBank, there's an element of things working in the attacker's favour because there's a delay at the bank caused by how things like this are handled.  The attackers are afforded the time to set things up and often openly cooperate between themselves and once everything is setup, they turn on the SMS's that ask victims to visit their site and enter victim information.  

Naturally, this means an organization like ScotiaBank has ample warning that a scam is coming, but because they're reactive and not proactive, the attackers can take advantage of the delay the bank introduces.  In this blog post, I'll take advantage of the same delay, to show you what happens. 

So, let's jump into viewing a scam that's on everyone else's radar but not on the bank radar. As a refresher, there's two major teams (I call them "Team Asia" and "Team Europe") that target ScotiaBank and a bunch of disparate attackers whose hallmarks I can't tie to any particular team.  Here, we'll jump into what Team Asia is up to....  

The current signals say there's two sites coming.
That second one is part of a bigger multi-bank scam attempt that targets everyone except CIBC and BMO, which I'll come back to some other time, once they've registered the domain and I've had time to let the CCIRC know. 

We can see the first site ( is already up and running in France as that was registered three days ago.  This is the same team that had running last week.  In fact, everything is so textbook, they even used the same registrar to register the domain, the same hosting to host the site, etc.  

I had to wait for this one to be populated to be 100% sure that the Scotty kit is used, but "surprise!" it's running the Scotty kit.  They even posted the kit url for the rest of the team at so that it can be redeployed for the next site.

Right now, there's a clear 3 day lead that this attack is coming, and we can see that despite that 3 day lead, the bank hasn't reacted yet as the domain is still live.  It's likely to go live in the coming hours.

First Update:
Three hours after posting this article, I have proof the SMS campaign is now operational and this scam is underway.

Proof the scam is operational.

This means that in the coming hours or day, the SMS's will start.  Usually, you are able to pick this up on Twitter as many people clue-in that its a scam and post about it, giving you an idea of overall times live (which in ScotiaBank is normally between 7 to 14 days).

Once you understand the simple processes and the very long timelines involved in a standard ScotiaBank phishing scam and understand that you can often see these scams coming a mile off, it's difficult not to question why banks such as ScotiaBank never changed how they do digital security.  

Second update - About 16hrs after posting this article, the bank got round to addressing this particular scam.  The CCIRC has acknowledged receipt that they're digesting the info I sent (way more than is posted here).  

I've been watching this process for a while now as part of my documenting the repeating failures within the bank, and it's basically a textbook procedure every time.  Given the predictability of both attacker and bank, I can't help but scratch my head in disbelief that this is still going on.

Another hack at Enbridge

Being a customer of Enbridge naturally means I'm not a fan of Enbridge as they've given me plenty of reasons over the years to dislike them.

I ran across this today on one of their sites.

(Click for full-size)

Usually, if I spot something like this, I'd raise the alarm, however, given this is on Enbridge, I am not bothering to raise the alarm with this one.  

Wednesday, March 1, 2017

It's Fraud Prevention Month 2017

In Canada, it's Fraud Prevention Month again (this occurs every March).  I'm a bit annoyed to be honest, as some of the work I did last year to sort out the mess in Canada has been undone.  

It appears that between Christmas and now, someone in the Canadian Government rolled back the shared platform code to pre-June 2016 levels, meaning that just like Fraud Prevention Month in 2016, the Federal websites are wide open to a few abuses again.

Example of x-frame vulnerability, on the official "Get Cyber Safe" website.

What a circus!

Wednesday, December 21, 2016

ScotiaBank's Cybersecurity Problem - A video

As everyone knows, there's a few things about bank security in Canada that gets my goat.  I've documented a few in a little video, and explained why it's a problem.

Here's that video:

What I hope to achieve from this is that it kickstarts a proper dialog on what's continually going wrong.  Traditionally, this bank and I don't have proper communication - just the normal platitudes and rhetoric about security being paramount, etc, - so hopefully someone will see this and start taking seriously the points that I raise with the bank, instead of it going into the perpetual customer service blackhole.

Friday, December 9, 2016

Thoughts on Canada's Banks and Cloud Based HCE

Update - This turned out to be busted, but not for the reasons I thought it would be.  See here

This week, one of the big five banks in Canada rolled out an update to support cloud-based HCE (Host Card Emulation).  Specifically, it was the Rambus “Bell ID” system - which they call “Secure Element In The Cloud” or “SEITC” - though everyone else has known this for years as plain old “cloud based HCE”.

Whilst it’s always interesting to see technological changes, it’s equally important to think about the ramifications of such changes.  

Just rewinding for a second for some quick history, first we had “Google Wallet” V1.0.  This tried to use a hardware device element to hold encrypted data, but network operators had started their own ISIS system (used to be at ), which got renamed for obvious reasons as Softcard (which was at  Simultaneously, smartphone manufacturers started adding their own Secure Enclaves - Apple has one called “The Secure Element” for instance.  

Google Wallet V3 is radically different.  It uses a technology called Host-based card emulation (HCE) instead, where card-emulation and the Secure Element are separated into different areas. For example, in HCE mode, when an NFC enabled Android phone is tapped against a contactless terminal, the NFC controller inside the phone redirects communication from the terminal to the host operating system. Google wallet picks up the request from the host operating system and responds to the communication with a virtual card number and uses industry standard contactless protocols to complete the transaction. This is the card-emulation part. The transaction proceeds and reaches the Google cloud servers where the virtual card number is replaced with real card data and authorized with the real Issuer. Since the real card data is securely stored in Google’s cloud servers, the cloud represents the Secure Element part. In general, this approach is considered less secure compared to the embedded SE approach.

The problem that the banks are hitting is there are many people with devices that don’t have a hardware enclave, and the banks want to been seen to be trying to accommodate those users.  In this example, they've gone the Bell ID route.

When you consider that a major part of the security is that the secret sauce is stored in a secure part of the hardware that the OS generally has no access to, the idea of lifting this up and sticking it in the cloud immediately begs the question of what happens if that back-end is then compromised?

There is less privacy with cloud based HCE. The mobile payment providers can already see who uses a certain credit card number, and then they do choose to share that data further with merchants or other companies for commercial and advertising purposes. This is something Google has already done with Google Wallet.

When you consider the pros and cons, it is hard not to feel like the banks have opted to put security in second place behind the optics of convenience for what could be inherently insecure devices anyway.