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 scotiabank-helps.com 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.
  • http://scotiabank-helps.com
  • http://wwwinterac-refund.com/INTERAC/sco
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 (scotiabank-helps.com) is already up and running in France as that was registered three days ago.  This is the same team that had scotiabank-mobile.com 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 surplusloot.com/scotty 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.  

Thursday, March 2, 2017

Why I'm still pissed at ScotiaBank

Warning - This is going to have strong language.

I had yet another totally discouraging call with ScotiaBank this morning.  As I write this, it's now 12 hours later, at the other end of the day, and frankly I'm still angry about it.  Besides the usual condescension and "Not my monkeys, not my circus" answers that I now fully associate with the ScotiaBank experience, there were several moments where I was having a problem trying to reconcile the stupidity of the moment that I found myself in.

One part of the conversation that particularly annoyed me was when I offered to send proof of something to ScotiaBank, and they said they could only receive it as a fax....  It's now 2017 and they claim they can only receive a fax?  The average consumer doesn't have a fax machine at home, just like we don't normally have a clothes mangle, a gramophone, or blacking for the scullery.

I've run into this before; Banks will give excuses about digital methods not being secure, despite the fact that everyone from the government to newspaper reporters worked out 20+ years ago how to secure email with the general public using PGP keys, or even secure webforms for the "not so technical" people to upload through.  A bank in 2017 can't legitimately claim that just because it chooses not to secure something properly, that it is not secure, in the same way I can't leave my front door unlocked and then claim that all front doors are not secure.  It's a bullshit excuse and assuming that a fax machine is more secure is bullshit, too, because unlike an email that can be addressed to one person, faxes are usually open access in banks and offer no levels of security or authentication.

Further, the condescending guy that I spoke to at ScotiaBank is on some power-trip because although I called him, he's trying to grind my balls about the importance of knowing precisely when he's going to get my money, and is trying to impart to me how dates are important.

Someone at ScotiaBank is trying to tell me about dates?  

Let's back that truck up for a second...


  • ScotiaBank opened up ticket REF: A16042732708 on April 27th of 2016.  Their VP of Security (Rob Knoblauch), was apparently going to call me (this was when the "Fuck Kony" Android problem was first discovered).  After 120 days I threw this over to the CCIRC as a Canary that ScotiaBank wasn't checking things properly before going to the public.  I let ScotiaBank know that 120+ days had passed.  They never called, so didn't learn about this until mid November - by which point everyone else knew about it.... not that ScotiaBank ever called about it after the fact either.  Luckily for Canadians, the unauthorized code just swore at Kony Inc, and wasn't siphoning off credentials, because ScotiaBank had never checked that code and would have been none the wiser.
  • In November, I was speaking to someone (she wanted money, so magically knew how to reach me) who understood I was pissed off about being stabbed in the back in an unrelated incident, and my view on ScotiaBank's amoral way of dealing with things that a normal human being might question.  She said the Office of the President would be sent a message to call the next day.  That was four months ago - I'll update this post if someone ever calls.
  • On December 19 2016, their Twitter team noticed I was still pissed off about stuff (this was to do with the source code leak after their programmers breached protocol and uploaded server code to ideone.com, and said that the same VP wanted to discuss things with me.  This time, however, the hold-up was he needed my number.  Now, everyone in ScotiaBank who needs to speak to me about money seems to have no problem phoning me at any time of the day or night, and especially during children's bedtime routine, and the Office of the President had given it to him previously for the above incident (not that he ever used it), so this was a good excuse to test how serious this was to the bank, because if it was serious, he'd be able to reach me.   It's now March 2, 2016 - still not heard shit from ScotiaBank.  
  • The bank was warned last year that they're breaching code left, right and centre since they removed their Android security and they posted code all over the web.  They were also warned in mid 2016 that they've got a phishing problem.  Millions of Canadians are still at risk in 2017 as neither problem were ever fixed.
Tweet showing that someone who doesn't need money can't find my number.
And it's not just that every Tom, Dick & Harry can now view the source code to their banking app - no the problem is fundamentally bigger than this. They're not auditing this properly, not handling this properly, and so continually fail to realize that they've accidentally leaked the source code for other 3rd parties, too.  Some of it is quite disastrous. 

Example:  
Let's imagine you're a Toronto-based company like Sensibill?  Do you think you'd be happy that when you sold a license to the bank, they'd let all your source code loose, too?

Example showing how ScotiaBank leaked Sensibill's code.
And it doesn't stop there.  

You may remember in December 2016, the hoopla surrounding putting the secure element in the cloud? Well, the Amex HCE Client code is loose too, and why the hell is the EnStream stuff that the article mentions sending shit to Bell Canada over insecure HTTP instead of HTTPS? 

Either nobody did due diligence, or someone thinks Bank apps are fine over unsecured HTTP.


Other companies whose source code has breached include Visa and Bell (Well, Bell has leaked for years, but I don't help Bell).

I'm not going to make this a post about everything that I know is broken.  There's some truly scary stuff that needs to be held back for obvious reasons.  However, you can see it's one big train-wreck, and as each month passes, more cars further back along the train continue to pile into the already crashed cars.  

I'm sure that after tonight when they've read this, there will be the rhetoric about how they take security seriously, etc.  However, we've heard those words before and it contradicts the technical evidence.  

What bugs me most about this is that at the end of the day, because the bank is amoral and none of the above issues are illegal, or stop the bank being compliant with whatever rules it has lobbied the government for, or impacts shareholder value, the bank doesn't need to address any of it.  

Meanwhile, some condescending little wotsit will be back on the phone tomorrow, telling some other poor chump about responsibilities, dates, and deadlines. 



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 www.paywithisis.com ), which got renamed for obvious reasons as Softcard (which was at gosoftcard.com).  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.