Thursday, August 25, 2016

Securing the news...

I read an interesting article today, about how the news outlets are getting targeted by hackers.

This doesn't surprise me for a number of reasons:
  1. Most news today is not an unbiased account of fact, but rather it takes sides and therefore it becomes a polarizing factor that can raise ire amongst some people.
  2. News media outlets today are not used to securing news, so something that is unprotected can be adulterated and changed into something it was never intended to be.
In Canada, we have two major corporations that control most of the news and media in general.
  • Bell Media 
  • Rogers Media
Regular readers of this blog will realise something:  This is Bell Canada and Rogers, the two monolithic cellphone and internet providers in Canada.  These two organisations are traditionally not good at security with their own customer facing systems, so you can imagine what type of security I have noted has been imposed on their media divisions.  

I did a quick 2 minute scan to see what I could find security wise....

What I found was this:  The media divisions are open to the exact same methods of being compromised as each parent company is currently known to be.  This percolates down through each media property such as a radio/tv station website, or newspaper site.  So, in short, it's possible to adulterate the news in Canada.  

We all know the phrase about those who control the message control the people - and that's what makes the media a target for hackers.





Wednesday, July 6, 2016

Moving Low and Slow In The Security Theatre.

As most of my regular readers know, I spent a bit of time over recent years fussing over my banks and Canada's financial institutions in general.  

For those that don't know what's going on, a quick recap...

Things started off with me gradually losing faith in my primary bank's ability to maintain a secure banking experience because of a series of events spanning a few years that highlighted to me that something was awfully awry, and things degraded slowly into more problems that were also spotted in my secondary bank.  Later, I found similar failures across many banks in Canada and eventually found the government at risk, too.  This culminated in the Spring of 2016, when I coordinated with one bank on the issue, and then successfully raised the alarm that basically most of the entire country of Canada was at risk and the RCMP leapt into action.   

Whilst all this was going on, I had to make sure to never do anything that amounted to, or could be construed as hacking.  This is actually very easy - and here's how it happened.

This is a Bentley convertible.  

(Click for bigger image)

I've never been in this particular car shown in the picture.  I can probably guess accurately that neither have you.  However, both you and I can probably agree that the roof is down on this car, and that if (hypothetically) we were in this car with this roof position and it started raining, we'd get wet.  The reason we know this without ever entering the car is simply because we understand what we're looking at.

Same applies to the banks and the Canadian government.  I can look at CIBC or ScotiaBank and without even logging into them, plainly see how they can be compromised because I understand what I'm looking at.  Same thing at the Canadian Government...

Often hackers are caught because having breached a system, they bang about inside, tripping monitors as they scan ports, probe and push systems trying to fumble about looking for the proverbial pot of gold.  

We see banks respond on social media about this type of threat, such as shown here:


The problem with this, as you can guess, is these measures only apply to hackers that break into a bank.  In my case, there was no hacking into any banks, no entry to any bank systems, and yet everyone at the law enforcement level is onboard with me because they understand what they're looking at.

Understanding technology like this is a variant of the "Low and Slow" method of hacking.  I say "variant" because whilst it shares all the traits of the "Low and Slow" method of hacking, there is no "hacking" here.

Additionally, it has to be pointed out that operating outside of a bank or government in this manner shows up something else; It's not security. It's "theatre". If you watch the show long enough, you start to see the props and the set moving about.  That needs to change.

I'll leave you with one last thought:  I'm just one guy who only wants his bank to not put him at risk, and with limited time on my hands, I figured out something that affects the entire country.  There are likely cadres of criminals out there figuring this out on a daily basis and, logically, they must go undetected as the banks cannot see them.


Monday, June 27, 2016

Verification versus Authentication

On my Twitter feed, I see there is a continuous trickle of tweets asking for CIBC bank to adopt two-factor authentication ("2FA").  It looks like this:




You normally see about 2 or 3 of these a week - and they all originate at the same site about 2FA.  As you can see, after the request to consider that the bank adopts 2FA, there's a canned response that goes like this "We take security very seriously, so we have two step verification".

Of course, that irks me, and here's why:  The customer is talking about authentication (i.e. making sure the person accessing their bank account is the correct authorized person who should be accessing the account), and the bank is responding on the subject of verification. In the case of a bank sending a code to a phone number on file, all the bank is verifying is that regardless of whether they're authorized or not, the person trying to access that account also has the phone belonging to the person who's account is trying to be accessed. 

That's a fundamental flaw in security.

If you don't know the difference, two step verification is where you supply a password, and the bank sends you a code and you type this in as well.  So, imagine your other-half has your phone and you're in the middle of a messy breakup, and they know your password, the bank sends a code to your phone in their hands, and voila!  

There's a really obvious problem here, and anyone with an ounce of security savvy will tell you, physical access is 9/10ths of the problem.  This is why people are asking for 2FA.

With 2FA, you have to supply something in addition to the password.  This usually is two items out of this list of three:
  • Something you have (eg password)
  • Something you know (eg maternal grandmothers maiden name)
  • Something you are:  (eg biometric, location, etc).
It doesn't have to be those three, but they are the most common.

As you can see, the response from the banks totally undermines any confidence that they even understand what's being asked, because in the situation pointed out above, the bank is providing the tools to the attacker to complete the compromisation of the customer.


Of course, the access agreement is written with a totally one-sided assumption that the customer is the only person who could ever put the bank or the customer into jeopardy.

(click for bigger)



The part that says "Without limiting the generality of the first sentence in this Section 9," makes me shake my head, because of course, the first sentence says that you are on the hook for "any losses" whilst ignoring the logical reasoning where as often happens, the bank has set the customer for failure in the first place.

In a nutshell, the security situation can is analogous to going into the sea to scuba dive and the dive master says "There are sharks here, and we take your security seriously, so here's some fresh raw beef steaks to hit the Sharks with", and then having setup the divers with the tools to be eaten, has them also agree to an agreement which is totally one-sided and places on blame on the customers.

And people wonder why I banned the CIBC mobile apps from my house?




Tuesday, June 7, 2016

An Overview of Canadian Bank Credential Phishing

In Canada, we have our fair share of bank account phishing.  Primarily, these scams mostly originate from two distinct teams, and each team has it's own trademark way of operating.

In one corner, we have Team Asia.

  • They register a proper domain.  
  • They set up their own DNS and make the site look like a proper clone of the real bank site.
  • They are sometimes able to operate for a few months before they get taken down.
  • They send invites from the SMS code 7000 (formatted as 700-0).

In the opposite corner, we have Team Russia.


  • They don't register a proper site, preferring to hang off the back of an existing site.
  • They don't set up their own DNS, preferring to use the short.cm service.
  • They get taken down quickly, so are much more proliferate.
  • They send text messages from full phone numbers, usually in Alberta, Ontario or British Columbia.

There are a few stragglers that I haven't assigned to one group or the other, but one particular code base does show up in a number of these, which means they're either the same person/group, or they're buying templates from the same source.

To give you an example of Team Russia:

Here's the SMS from area code 250.

As you can see, it's rather sloppy in comparison to Team Asia.  The final link hangs off a Brazilian site, seen here:



URL aside, the site looks real, until you try to navigate, at which point you run into this:


And for anyone interested in the data, here that is (click for bigger version).



As you can see, this isn't complicated at all, and that's a good thing because most of Canada's banks have online banking with holes that are not secure enough to guard against anything much more aggressive than this.

So, there you go.  The state of Canadian bank phishing in one quick post. 











Wednesday, June 1, 2016

Online Banking and Hosts File

Over the years, I've had my fair share of runaway data.  This is usually caused by Bell Canada, as they resell your data to third parties (if you want privacy, you have to pay Bell an extra fee of $2 per month), and once that data has left Bell, it's going to run and run as it passes from marketing company to aggregator to directory service to marketing again.

As a result of Bell Canada and the three year battle to get a data noose around them, we have a strange win-win situation; Bell Canada sells my data over and over to the marketing people so they get their money, and the buyers (marketing people, directory services, etc) then scrub my details from the incoming data.  That stopped the runaway data in it's tracks. As a bonus, I left my old residential data that Bell leaked some years ago online, so now it optically looks like Bell puts out stale data about me.  It's a wonderful system and works really well.

For this post, I'm going to cover how I tidied up a similar problem a while back with online banking.  When I log in to my two banks, I want to be dealing with the bank and the bank alone, not sharing my purchasing habits with the bank through a third party, or even know that any third party is tracking me at the bank and then reporting that to some computer hardware store 30 minutes later.

Both my banks use Omniture/Adobe Analytics.  Right there, you got the holy trinity of data sharing going on.  Between the two banks and Apple (all the iTunes and Apple store run through the same system), the amount of back and forth of data would be astonishing.  So, a while ago, I did something about it as a result of trying to work out why a password issue (unrelated) was giving me so much hassle.

I ended up just driving all the junk requests for tracking and analytics, and marketing to localhost (127.0.0.1). Yes, I could opt out of some of this stuff (the banks don't offer you the ability to opt out, but if you track where the banks send this stuff, you eventually end up at Adobe and THEY have a link that allows you to opt out), but that just sets a cookie in your browser, and as a developer, I'm resetting my browser cookies and environment more frequently than the average person, and that would opt-me-in again.  

So, my solution was just hack this stuff off at the knees by permanently editing my hosts file.  If anyone sends a page asking my browser to go talk to Adobe Analytics so it can generate another damn survey or indirect piece of targeted marketing, it will now go into a dark hole and never be seen again.

NOTE:  Only change your hosts file if you know what you're doing. I'm not going to tell you how to change the file, as I don't want to be responsible for what you might break. I'm just telling you what I did. YMMV.

So, what entries are in my hosts file? 

The Scotiabank entries look like this:

#ScotiaBank Changes
#Callback with Trusteer DMG.
127.0.0.1       www.splash-screen.net
#Omniture Profiling & Tracking
127.0.0.1       somniture.scotiabank.com
#Oracle Maxymiser, marketing & optimisation

127.0.0.1       service.maxymiser.net

The CIBC entries look like this:

##CIBC Related Changes
#Marketing
127.0.0.1       adobetag.com
#Omniture Profiling & Tracking
127.0.0.1       cdn.tt.omtrdc.net
127.0.0.1       adobe.tt.omtrdc.net
#General Adobe Hidden Profiling
127.0.0.1       adobe.demdex.net
#Oracle/TAG merchandising, marketing and live chat
127.0.0.1       as00.estara.com
127.0.0.1       liveperson.net
127.0.0.1       sales.liveperson.net
#More Marketing, targetting & feedback.
127.0.0.1       iperceptions.com
127.0.0.1       iperceptions01.azureedge.net
#Even More marketing.
127.0.0.1       api.demandbase.com

And there you go.  

It works for me.  Your mileage might vary.


Thursday, May 26, 2016

Anomaly with City of Toronto site security...

I ran across an anomaly on the City of Toronto website today....

They go to pains to point out that you're on a secure site in a weird "in-ya-face" way.  This is normally a red flag for me. People make a point of pointing out something when they believe your mind needs to be changed.  For instance, I'm told my burgers are 100% beef because someone in marketing thinks we have ideas that maybe it's not.  I'm told the latest cars are much more fuel efficient, because someone thinks I might have other opinions on this.  Now I'm being told in big message boxes that something is secure.  Mental red flag.

OK, let's suspend disbelief for a second and imagine that it actually is secure - where is the browser padlock?  

(Click for bigger version)



I clicked the "Close" button and then got to the next screen, where again it points out that you are in a secure site on the first line.  Again, there's still no browser padlock.  I also noted the usual bank-trade trick of proclaiming things are secure and placing the onus on the user to make sure they've done their bit for security.... even though the padlock is still missing.

(Click for larger version)
 

So, I took a quick look at the certificate. The first thing you notice other than the City of Toronto is apparently in Macau, is the verification error that this is a self-signed certificate - so this is no more valid that if I generated one here on my computer and delivered it on a USB stick to City Hall. I've highlighted both items in red.


Jasons-2013-MacBook-Pro:~ jasoncoulls$ echo ^d | openssl s_client -connect secure.toronto.ca:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=CA/ST=Ontario/L=Toronto/O=City of Toronto/OU=Technology Infrastructure Services - macau-w1/CN=secure.toronto.ca
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
 3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRzCCBC+gAwIBAgIPb+ZsRia0KHZ5+v4/DWkpMA0GCSqGSIb3DQEBBQUAMIG1
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBh
dCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTEwMS8wLQYDVQQDEyZW
ZXJpU2lnbiBDbGFzcyAzIFNlY3VyZSBTZXJ2ZXIgQ0EgLSBHMzAeFw0xNTEwMDYw
MDAwMDBaFw0xNjEwMDUyMzU5NTlaMIGfMQswCQYDVQQGEwJDQTEQMA4GA1UECBMH
T250YXJpbzEQMA4GA1UEBxQHVG9yb250bzEYMBYGA1UEChQPQ2l0eSBvZiBUb3Jv
bnRvMTYwNAYDVQQLFC1UZWNobm9sb2d5IEluZnJhc3RydWN0dXJlIFNlcnZpY2Vz
IC0gbWFjYXUtdzExGjAYBgNVBAMUEXNlY3VyZS50b3JvbnRvLmNhMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnFUWzMyfTL6zFKFj69W8KdwwKlpogf1Z
3wJrZpH23x+oPVz9pA5Ti2NxG4PvqI6Y/ybcrLArIXa4+xD8e9zYDSIw8Umk4fSb
2OrmQTSAVlMtEGabAJZO1ksM1+kfmw2tXfV7n1a07gGSY9lpwWmqr5HGCvV6aCyO
xyojCOvOs9SI4m5UbRvW/Je5qaX4gfNzx2xQ9de/nC4s7dCVolFYm1ZI+OiwQiZ4
i0tnMGk1Zela70thnCmIU1TZ08FTXjffAFgpvxKK00m5hxvKrkZ0Bqmh3GG5K/G3
7dRdNKkAPoocBbOy3hwtwU61EgNrKRumNl/M5gcaRYwBV27YXvBsvwIDAQABo4IB
ZjCCAWIwHAYDVR0RBBUwE4IRc2VjdXJlLnRvcm9udG8uY2EwCQYDVR0TBAIwADAO
BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGEG
A1UdIARaMFgwVgYGZ4EMAQICMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1j
Yi5jb20vY3BzMCUGCCsGAQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBh
MB8GA1UdIwQYMBaAFA1EXBZTRMGCfh0gqyX0AWPYvnmlMCsGA1UdHwQkMCIwIKAe
oByGGmh0dHA6Ly9zZC5zeW1jYi5jb20vc2QuY3JsMFcGCCsGAQUFBwEBBEswSTAf
BggrBgEFBQcwAYYTaHR0cDovL3NkLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0
cDovL3NkLnN5bWNiLmNvbS9zZC5jcnQwDQYJKoZIhvcNAQEFBQADggEBACmV9Q6g
KougvgnCPSItcved21qdGRtO2u8/LrOwI9BnKeXcDCg7824zCbD3y2q7X0GlbjoW
BFcfH0ZZX1NTer2V/AUK1cn3oOi0EUJH628AhED/HC3ld4Rpw+I8twp0aJNbo+1t
P6NBoTm3dQoMUlGhULGIgrMTtM6oRDQtqp/Qez3OBHRlqdlxardAV7ybDIvWH9pd
hyGwUp+4Kuv9n234D8Tc081B4Q0omGDwRozXd7rf1rBJFALY+1qonVRkquYE0krU
KNI0M9XjnqN61ynjkrIHO1WkeFaoXy4/7oLRHbLCSWqexSYSuWMGeVAPvCtowtXl
hyQyq2k6pA8zXVU=
-----END CERTIFICATE-----
subject=/C=CA/ST=Ontario/L=Toronto/O=City of Toronto/OU=Technology Infrastructure Services - macau-w1/CN=secure.toronto.ca
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4853 bytes and written 636 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES128-GCM-SHA256
    Session-ID: 00000D2AD210CD02429618321FAA1D60105219435858585857471DBB000016D0
    Session-ID-ctx: 
    Master-Key: DDEF69EA999B9A7FA1AAA0AE94D5F3A00F5F9FF5F47D854BAC1621B018CC81751C17BCE855B6FE497AD99445EAE5830C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1464278459
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

DONE


So, there you have it.  Whilst the city tells you it's secure, both the browser and the openssl tool verification gives errors or refuses to show the padlock.






Wednesday, May 25, 2016

Finally, a bank listened.

Anyone that has the smallest bit of familiarity with me will know that I keep a keen eye the security of Canada's banks and telcos, especially those that I know are putting me or my family at risk.  I might sound like a crackpot at times to some people, but those that know me well all know that I'm not going to publicly say something if I couldn't substantiate it.

Over the past month or so, I've spoken to each of these organizations in turn (sometimes I reached out to them, other times they phoned me first), as my concern levels are now at an all time high.  Some banks flat-out said they were not going to entertain the idea of paying me for my time to explain their problems, and that's their decision - I work in IT and I'm not working for free.  Some banks couldn't answer one way or the other as to whether they will or won't entertain the idea, and one bank positively jumped on the opportunity to hear me out.

It's no secret that I consider much of Canada's banks to be a security disaster in motion; I've been saying for years that things are broken.  Things have been surreal at times (for instance trying to fool the bank security into thinking my dog was me), and other times I think I'm moving forward only to find myself going backwards again.  As time has gone by (and especially recently) what started off as my documentation of a small set of issues with a few root causes with one bank has snowballed to something really huge that now spans the entire Canadian financial system and expands out of it in all directions.  

Obviously, I'm not going to say what I found, but it's an uncomfortable situation having the knowledge of what an amazingly precarious situation we are all in.  I know what's broken, what's not being tested. What is likely to be the major vectors to breach most banks and what went wrong in policy to allow this to happen.  So, when I see Twitter feeds from these banks telling their customers that their online banking is guaranteed secure, it makes me cringe because I know it's not secure.  I also know that if I know it's broken, others will know that too.  Of course all the banks in Canada have a standard public mantra throughout this of "It's secure until YOU lost your acct # or password" as if they believe it could never be them at fault for a breach, even though I know they're likely already compromised and they've more than a small chance of compromising other external organisations in the process.  

Now, I don't have to get into a convertible car with the top down to know that if it rains in the future that I'll get wet, because I know and understand what I'm looking at. It's like if a bank gives me an address of a branch in a town I've never visited, I can guess accurately that at night, they can't see the sun from that branch.   Same thing applies to digital banking at most banks in Canada - you don't have to hack them, go into them, or do anything untoward to them to know where and how they can be compromised.  

So, bearing the above logic in mind, I sat down with this bank and explained what's going on in Canada.  Like the car or sun analogy above works with the average person, what I had to say worked with bank security people.  So, I covered how Canadian's are at risk with their mobile apps, how the banks online banking systems are mostly all broken and then covered the security circus that we know of as Interac.  They got it immediately - I didn't have to explain a thing...

...and then I dropped the "Here's the really, really, bad side-effect of this" bombshell.  They got that too - understood it, crystal clear.  Not a single "You're wrong!".  No mention of "That's impossible!".  There was not a single ounce of disagreement.  Finally, after a very long time, I was talking to a major bank and they're like "Everything you say is understood".  

In a surprising twist, after being asked if I've ever considered a career in bank security, I actually got asked my thoughts on the SWIFT situation?  I had an immediate four point answer on what's broken (it needs certs on messages, cert-pinning with clients and servers, hashing of messages to stop alterations and a central pub-sub number authority to stop message injections in the sequence), but as I answered, I couldn't help thinking how far this situation had turned around; Usually big banks argue against me, and now here I was, being asked my opinion on how I'd fix the largest bank messaging system in the world.

This makes a big change from the status quo.

Whilst I have no idea what'll happen next with this particular bank, my immediate job is done. They know what I know and now hopefully there will be action as a result.

As for the other banks?  Well, time will tell if any come back to the table.