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?  

Conclusion
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.