Tuesday, October 10, 2017

The dangerous cybersecurity pattern I see at Scotiabank

I’ve noticed something of a dangerous repetition at Scotiabank in Canada.  

October is Cyber Security Awareness Month (CSAM), and for the second year in a row, during CSAM, I found the bank has been compromised and more by luck than skill has dodged a catastrophic cybersecurity problem.

In April 2016 I noticed that Scotiabank was pushing out Android mobile apps that had an “unauthorised addition” in them, after a frustrated programmer added their own personal content to drop an f-bomb at one of the bank’s vendors.  Trying to alert the bank went nowhere and by summer the Canadian Federal agency “CCIRC” (Canadian Cybersecurity Incident Response Centre) was alerted and monitoring the situation too, as regular updates of the app were pushed out by the bank with the unauthorised code.  Scotiabank finally got the message after 230 days on November 15th 2016.  On November 16th Canada had “f-bomb free” apps.

This means that during CSAM 2016, Scotiabank was compromised and not aware of it, even though everyone around them was fully aware.

We can only infer that one of two things happened;  Either someone checked that code and OK’d they insult (an unlikely scenario), or we were seeing that if a terrorist wants to get code out to the masses, they just have to get a job as a mobile programmer with Scotiabank.

Given the situation that unsavoury additions to apps were pushed through to the public, the bank was extremely lucky that any offender only chose to insult a vendor, rather than adding code to syphon off customer information.

For CSAM 2017, the situation repeated, but it also got markedly worse.  

I reported to the CCIRC on October 7th 2017, that a vendor to Scotiabank had posted the keys for the backbone API of the bank to a public GitHub repository.  

In addition to the keys, the source for a Windows-based security application was also public, and the XSD’s for that API as well as the mock XML requests and responses and other documentation for that API were also available.  I also spotted that a .Net DLL for client side security (referenced in a December 2016 leak) was included, and this was fully reverse-engineerable with no obfuscation. This meant that two annual leaks could be cross-correlated and the DLL used both the AES key and Triple DES key that were in this latest leak, too.

The icing on this cake was this information has been public since November 2015.

In conclusion, what really got me during this episode is that Scotiabank has been potentially compromised for two years, and it’s going to be really tough for Scotiabank to prove that nobody has already used this information to gain unauthorised access to that API.