Banks and financial services providers love to make some big claims when it comes to the security of their products and networks. The truth is, the phrase "bank grade security" has become an oxymoron. Many institutions have failed to implement basic security controls, least to keep ahead of security curve. Yet we continue to place considerable trust in them, and put up with security controls that are counter-productive, all to maintain the theatre of security.
<<< TEST CLICKER >>>
<<<hit 5 and then the red button on switcher – check mic is on >>>
Welcome everyone, my name is Kieran Jacobsen. I am excited to be talking to you today about the security processes of some of Australia’s banks.
Before I continue with this presentation, I want to acknowledge the Traditional Owners of the country throughout Australia and recognise their continuing connection to the land, waters and culture. I pay my respects to their Elders, past, present and emerging.
All good stories have a hero. All good security stories need a hacker in a hoodie. In this one, Eve is our hero hacker in a hoodie.
Eve isn’t happy with their current bank, and like many of us, has decided that it is time for a change. Eve is passionate about security, they want to ensure that the next bank shares this passion.
They want to choose a bank that demonstrates the use of modern security practices. This isn’t simply a reading exercise. This isn’t just trusting what is promised on a website or pamphlet. Eve wishes to assess each bank for their actions, not their words.
One way that Eve can do this, is by looking at some of basic elements of how these organisations protect their web sites. The theory is that this will be a strong reflection on how their security teams, in fact, all of their IT teams regard security.
The first step is to put together a list of financial institutions.
Wikipedia has a list of Australian banks, from this Eve has selected a large group of banks. The list includes most house hold names, the big four banks, their subsidiaries and some more regional banks as well.
For each of these organisations, eve is going to test two websites. Their corporate website and their personal or home banking websites. Eve isn’t interested in business banking needs, so they don’t look at those websites.
It might seem that the banking sector here in Australia hasn’t changed much. Indeed Australia’s oldest bank, Westpac was founded in 1817. Yet, Australia now has 4 new banks who are rushing to get themselves established as the next generation of banks.
These banks are often called neobanks. They are 100% digital and make use of mobile applications. There isn’t a browser banking experience, and certainly no branches or ATMs. These banks are driven by technology, marketed to millennials and even more generally the IT industry.
Eve wants to know if these new commers are doing a better job than those banks who have been around for two centuries. Their corporate website and mobile API endpoints are included in the assessment.
Now that we have a list of banks, what criteria should we use?
Eve decides to assess each site on three different but related aspects. HTTP response headers, particularly those related to security; how the TLS stack has been configured and if it is vulnerable to any issues. Finally, is the reporting of security vulnerabilities made easy through the publication of a security.txt file.
Let's begin with security headers.
There are several HTTP headers that we can use to increase the security of our application and improve our monitoring of threats to our web applications. Setting these allows us to restrict modern browsers from running into easily preventable vulnerabilities.
These headers are typically very easy to implement. Often it is just a few lines of code in an application or HTTP server configuration file. These headers are not new, in technology terms some of these headers are ancient, having been introduced over 5 years ago. Yet, even with ease of implementation and age, their use is far from widespread.
Scott Helme maintains the site security headers dot com. This site will check a websites response headers to see if they are correctly configured. The results are combined into an overall rating from A+ down to F.
Eve has performed an assessment on each bank's websites, taking note of the grade each site received and which headers were part of the response. I am not going to go through all of the headers, just two of the more important ones, HSTS and CSP.
When compared to Tranco’s Top 1 million websites, Aussie banks perform significantly better than most. This is great, but there are still improvements that could be made.
Just a single bank <click>, Up is responsible for the A+ ratings you can see here. The majority of banks receive an C or D rating. They have implemented some of the security headers, but not all of them.
It is concerning to see 3 sites with a failing grade. For a site to receive this grade, it isn’t sending any security related headers. When we compare to the to 1 million sites, you could be forgiven for think this isn’t a problem; but its worth remembering this presentation is about banks, and not social media sites, blogs etc. Banks make big promises to keep our finances safe, any failure is unacceptable.
HTTP Strict Transport Security, or HSTS, is a safety net for TLS. It is one of the single most important improvement you can make for the TLS security of your web sites. HSTS provides strong protections against person-in-the-middle attacks by forcing communication over secure channels.
Once a browser visits a website, over HTTPS and receives this header, two superpowers are activated. The first is that all HTTP links on the site will be converted to HTTPS. Pretty cool. The second is that if a user receives a certificate warning for that website, they will not be able to chose to ignore the warning and click-through to the site. Now that is a powerful protection against PITM attacks.
HSTS also offers the option of preloading the configuration into modern web browsers. For sites preloaded in the browser no connection will ever take place over HTTP, all communications will take place over HTTPS. This is pretty awesome as you can ensure that no insecure connections will ever be made to your website.
So what is the preloading process?
First, the obvious one, have a valid certificate. Second, redirect all HTTP traffic to HTTPS.
Next, to serve all subdomains over HTTPS. This one can be tricky, remember that is every single subdomain where you have a website or web service.
The next step is to serve the HSTS header on the root domain. The header must specify a max-age of 1 year. This directive specifies how long the browser should store the HSTS instruction in its cache. The next directive we need to include is that subdomains are included and finally, we need to call out that the site is ready to be preloaded.
Once you meet these requirements, you can visit hstspreload.org and submit your domain for browser preloading.
How did the bank websites go?
Over 90% of the sites have some HSTS header. Initially this appears to be a great result, however the problem is with the directives in the header.
Only 4 banking sites specify the preload directive, and of those, only one, Xinja meets all of the preload requirements. Just one bank.
The most common issue is a max-age directive that is too small. Another common issue is redirecting a site from the root or apex of the domain to www dot. This blocks any chance of preloading.
A special shout out needs to go to one bank who transmits an invalid blank HSTS header. I guess that helped them pass a security assessment at some point.
It is disappointing that no banks are HSTS preloading. The protections afforded by HSTS to your users is tremendous. I really believe that financial institutions, government sites, social networks, telecommunication companies and any potentially large or obvious targets should be preloaded into the browsers.
To me, it feels that the banks are still lagging when it comes to protecting customers from person-in-the-middle attacks.
Content security Policy, or CSP, is the most effective measure against cross site scripting and data injection attacks. These attacks could be anything from data theft, site defacement or even the distribution of malware.
A CSP header is a whitelist of approved resources, provided by your application to the user’s browser. The browser will only load those resources that appear on the whitelist. Resource types include fonts, images, scripts and stylesheets. Violations of the whitelist can be reported using built-in reporting features.
To make the implementation of CSP easier, there is also a report-only mode. With this header, the whitelist isn’t enforced, violations are allowed, but they are reported.
Aussie banks specifying a content security policy has been slowly improving over the last 12 months, from 2 banks we now have 5 banks whose websites defined a CSP. Overall Australian banks do better than the global results from Tranco’s top 1 minion websites.
The most common CSP issue, banking or not, is the definition of a very lose policy and the inclusion of unsafe inline scripts. This is an issue we see at the Australian banks as well.
So what would happen if someone performed sneak XSS attack on a site that has a strong content security policy defined?
For this demo, I have opened the browsers developer tools, and tried to load some JavaScript via the console that results in the browser loading another stylesheet and play an mp3.
When the browser attempts to load the unapproved content, the policy blocks it from loading. As you see in this image. What happens if that isn’t blocked?
So I am about to play a video. This video contains some flashing text and images.
<click to start video>
<When it ends>
Isn’t that a great video? I just love David Hasselhof at the end.
I want to thank Brenno de Winter for the inspiration of this video.
It is worth mentioning that this video is a few months old, so some of these banks are now protected from these attacks.
Let’s give out some awards for those who deserve some praise.
<Click>
The clear winner is Up. After DDD Melbourne last year, they went to work and became Australia’s first banking site to score an A+. I was impressed with how they received the feedback and focused on delivering an outcome to their customers. I want to thank them for putting in such a great effort, their positive and professional response has been fantastic.
<click> Runner up is Xinja. While they don’t have an A+ rating, they are ready for HSTS preload.
So when you go back to the office, what can you do?
Review the response headers for your web applications to determine which headers your applications are not sending and deploy these.
Finally, check out using monitoring tools like report dash uri dot com. This is another site run by Scott Helme and Troy Hunt. This tool brings together all of the reports into a single consumable place.
It is 2020 and at times it might feel like we live in a dystopian cipher punk future.
From government spooks to local city councils, advertisers, security companies and even telecommunication companies are all trying to snoop or modify the content we see. Encryption, specifically HTTPS with TLS is the strongest level of protection against these negative behaviours. This protection is required not just to protect business transactions but all traffic.
As an industry, we realised the need for encryption, we pushed heavily on the use of TLS. We made it easy, deceptively easy to deploy TLS. This has been beneficial as more and more sites are now accessible via TLS. Unfortunately, as an industry we haven’t spent as much time ensuring that the default configurations of the various TLS stacks are secure.
What we are now seeing is many services being installed with insecure features, ciphers and protocols enabled. This isn’t just in your cloud or DevSecOps products, it is a particularly big problem with products from the major security vendors like Cisco, Citrix and F5.
How do we identify if the TLS configuration of a web site is up to scratch?
SSL Labs is a non-commercial effort lead by Qualys. The goal of the effort is to provide tools to help organisations and users follow best practice SSL/TLS guidelines.
Their SSL Server Test tool can be used to inspect the configuration of any public website. It looks at the certificates, protocols, cipher suites and if there are any known vulnerabilities present in the TLS stack. The results are combined into an overall rating from A+ down to F.
Eve has performed an assessment on each bank's websites. These results where then put into everyone’s favourite tool, Excel.
So what were the results?
Let’s take a look at the results as they stood late last year. Here we can see a comparison between the Australian banks and sites monitored by SSL pulse. SSL Pulse is a project maintained by SSL Labs, that monitors the configurations of 150 000 websites in Alexia’s list of the most popular websites.
Most Australian banks scored a rating of A or A+, a great result when compared to SSL Pulse. 10% of banks scored a rating of B, and no bank rated as a C. One bank scored an F. We will talk about that one later.
Unfortunately, things have changed dramatically when we look at the results taken a few days ago.
As you can see, the distribution of grades as fallen dramatically. From more than half of the banks receiving an A or A+ grade, the majority are now receiving a grade of B. A similar pattern appears in the SSL Pulse results as well.
Why has there been such a dramatic shift in the grades? The answer is quite simple, the banks are not keeping up with industry expectations.
Last year the browser makers, and the industry as a whole, decided to deprecate the TLS 1.0 and 1.1 protocols, with most browsers dropping support for 1.0 and 1.1 in March. With this decision, SSL Labs decided to cap the score of any sites supporting these protocols to B.
Unfortunately 53% of sites support TLS 1.1 and 43% of sites still support TLS 1.0. Several banks have taken action to disable these older protocols, and even enabled TLS 1.3, but most have taken no action to this significant change in the industry.
If the industry cannot convince the banks to disable the old protocols, perhaps compliance can. The PCI DSS standard requires that all sites accepting credit card payments to remove support for TLS v1.0 by June 2018, yet the banks don’t see a problem.
Most organisations will claim they need to support TLS v1.0 for customers connecting from older browsers, but is compatibility really a valid justification?
The website, CanIUse dot com, allows you to check which features are supported in what browsers. Lets look at which browsers support TLS 1.2. Wait, that is pretty much every modern browser.
It seems only the older browsers don’t. Do the banks really have a vast number of users running Internet Explorer 7 or Firefox 23?
One great feature of CanIUse is that it can answer this question for us. If you hover over each browser version, we can see how much of global web traffic is driven by those browser versions. I went through each of them and added up the usage of each red browser. 0.83% of global internet traffic is generated by the browsers seen in red, that don’t support TLS 1.2. It is crazy to think that the banks are really trying to support 0.83% of their users who couldn’t be bothered upgrading.
So which bank did the best?
Looking not just at the current results, but also some historical results. The winner here is <click> Xinja.
They have an SSL Labs grade of A+, have enabled TLS 1.3 and when considering they are ready for HSTS preloading, they seem to have their TLS security all nailed.
A special mention needs to go to one bank. Last year, one bank was receiving a failing grade for their Internet banking site. As you can see in the SSL Lab report from October, the site was vulnerable to several SSL vulnerabilities including Zombie POODLE, GOLDENDOODLE and OpenSSL 0-Length vulnerabilities.
The Zombie POODLE vulnerability was found in products from Citrix, F5 and others. GOLDENDOODLE can be found in Cisco, Citrix and F5 products. Finally, the OpenSSL 0-Length vulnerability impacts several OpenSSL versions and once again F5 products. It feels like there is a pattern here.
These vulnerabilities where discovered and patched in March 2019, yet 6 months later in October, they hadn’t patched.
Well, I can happily say they did put the effort in. Earlier this year, they finally made a push to fix these issues. <click> With their effort they now join the very small group of banks with an A+ rating.
What can we say about this result? Perhaps, just perhaps their patching processes are slow. If they are struggling to patch their load balancers and firewalls, what abut the rest of their network?
Another special mention has to go out to the banks who have their heads in the sand. These banks have actually asked SSL Labs to prevent scans of their internet banking sites or have blocked connections from SSL Labs to their sites. Security through obscurity is never a successful security solution.
Thankfully they haven’t blocked other TLS scanning tools, so I used those instead. I would estimate that these banks would get a grade of A or B, so it isn’t anything to hide.
It doesn’t make sense to hide or block these tools. What are they trying to hide from consumers?
So what steps should you be taking.
Please keep deploying TLS. While I focused on HTTPS today, you can use TLS for email and almost everything else that happens over a TCP stream. We need ubiquitous encryption on the internet.
It is also important that you disable legacy protocols like TLS 1.0 and 1.1.
If you want to ensure you configure things correctly, SSL Labs provides a guide on how to get thing setup correctly. This is a shortened link to that GitHub page.
Finally, use tools to ensure the configuration is right. Use SSL Labs to test your sites. There is even a plugin for Azure DevOps to perform SSL Labs tests as part of your pipelines. Make use of it to ensure that every time you deploy, your configuration is correct.
Sometimes people will find security vulnerabilities in websites and they will try to report them so they can be fixed. The problem here, is knowing who we can talk to.
I am sure that everyone here has seen a tweet like these from a security researcher. As a someone who leads an organisations IT team, and is responsible for our IT security, these tweets appear in my nightmares!
Disclosure is hard. Researchers will often spend a significant amount of time trying to find the right person to report a vulnerability to. Their goal is to find someone who is going to respond, action and understand the issues. They want someone who will work to fix the issue, not send in a swat team, or worse, involve lawyers.
Where do you even start? You could look for contract details on the site, if you are lucky there might be an email or contact form. Direct messages on social media are be a good idea particularly as the issue remains relatively private; however the issue is that these are often run by social media teams who don’t understand what steps they need to do. In one case, an Australian bank’s marketing team has a specific set of text they use whenever anyone raises a security issue via social media. It runs something like “we take security and privacy seriously”.
I know of security researchers calling organisations call centres, spending hours on hold, sometimes getting through. Linked is also a powerful tool as well.
Unfortunately, after repeated DMs, calls and emails, the only mechanism is a public tweet. Put it out into the world and hope it lands in the feed of someone who can help. These are super risky moves. You are broadcasting this loudly. Attackers might see something like this and launch attacks, or worse, if it’s a breach, they might take steps to cover their tracks.
This is the problem that Ed Foudil tried to tackle in his proposed IEFT standard. Known as security.txt or by its full name, “A Method for Web Security Policies”. The goal is to put security contact information in an easily discoverable location. That location is defined in RFC 5785, which defines the .well-known directory. Previous drafts placed the file in the root directory.
In this text file, you can specify information such as how you can contact the organization, either email or a URI, encryption keys, researcher acknowledgements, policies, hiring information and the preferred language for contact. The structure of the file is hellishly easy, you don’t need to know JSON, XML or YAML. There is a set structure so that every file contains similar information.
By doing this, everyone can quickly find the contact information, reducing the frustration and challenges around finding security contact information.
This is what a security.txt file looks like. This is Facebook’s file.
They have four entries in their file. Contact, which describes where you can go to contact them about security issues.
Facebook acknowledges the efforts of security researches who have helped them. They include a link to a page where they say thank you.
Next a link to Facebook’s policy that details what security researchers should do when searching for or reporting issues.
Finally, there is a link to the security team’s job openings.
Eve created a PowerShell script to make requests to test for security.txt files. Out of all of the assessments, the security txt file is where the banks truly fail out.
One bank has implemented a security.txt file, and that is <click> AMP. A single bank. This is their, slightly not specification with awesome ascii art security.txt file.
So how should these results be interpreted? Bluntly, you could infer that AMP is the only bank that encourages security researchers to report problems.
In reality, is this the case, probably not. Yet the problem stands that finding security contact information for the other banks is next to impossible. If these organisations really do care about the privacy and security of their customers, they would make it easier for issues to be reported.
Another problem, is how will an organisation react once they realise you know they have a legitimate security issue.
With all disclosure, be it via a call, email or a public tweet. It is always a gamble on how an organisation will respond.
Some organisations, take the reports, handle them professionally, fix the issues and improve. Up is a great example.
Others, well, people often respond poorly to criticism. They handle any disclosure as criticism and respond aggressively. Denial, legal threats, SWAT teams, even threating researchers employers. These organisations often don’t want to hear about issues, they want to silence anyone critical. Unfortunately, I had this response as well to this talk.
In some ways, this is the intersection of technology and mental health. As a global community, we need security researchers doing the important work they to. In her TED 2014 talk, Keren Elazari describes hackers as the Internet’s immune system. The sad truth is that toxic responses lead to hackers keeping vulnerabilities private, selling them to vulnerability brokers, or much worse, people dropping out of the industry.
I head horror stories when attending security conferences around Australia, and they didn’t prepare me.
I am super lucky and thankful to have a loving and caring support network. I have access to amazing health care professionals. Even now, I am still recovering, it has been hard to prepare even to speak today.
The information security industry has a particularly troubling history of mental health issues, alcohol and drug abuse. I personally believe disclosure is a large contributor.
As developers, admins, security people, and leaders, it is our responsibility to ensure that we as individuals and organisations make efforts to support those making these notifications.
What can you do when you go back to the office?
First, work out who in your organisation should handle these reports. They need to be empowered by management, legal and security to make decisions on how to act on reports they receive. Work with them to use the securitytxt.org website to generate your own file. Generate a PR and push the file to production.
If you are using a CMS or a third party platform or something where you can’t just upload a file, look at using your load balancer or WAF to route the security.txt file to some location where you can host the file.
For my personal website, I use CloudFlare and a page rule to route the security.txt path to GitHub where my security.txt file lives. You can also do this with Azure Front
So let’s try and bring this all back together.
What other criteria could have been looked out?
SPF, DKIM, DMARC, CAA and DNSSEC are all under deployed within the banking industry. Their benefits include protecting customers from phishing attacks and better reporting when attacks do occur.
MFA and Password requirements are another fun criteria to look at, however this often requires an account to be created to thoroughly test these.
Finally we could have looked at the breaches the banks have reported. Australia has mandatory breach reporting requirements. Several banks have had reportable breaches over the last few years. These can also provide insight into how their business processes are functioning.
By now, you are probably waiting to find out which bank Eve decided to choose. Which banks was the best and which was the worst.
Instead, I am going to simply say that I have presented you with the evidence, the choice you make, I leave up to you.
An argument could be made that this is all an activity in security absolutism The banks have other security controls in place, and these make up for the issues described today. You could argue that this is simply pedantic fussing over some issues that are very small in terms of the risks banks are facing.
My response to this, is that it is all about optics. Implementing these features isn’t expensive, it isn’t even labour intensive, perhaps a week or two of effort and testing.
Australian banks, by not implementing even the simplest levels of protection, aren’t presenting themselves in a favourable light. If you can’t do the basics, why should we trust that you can protect us using more complex security technologies and tools?
Before I finish up today, this is probably the one slide you will all want to get a photo of. If you don’t get these down, the slides will be up in a few days on The Tour website.
<pause to let people take a photo>
I want to thank you all for coming and listening to me.
If you want to get in touch, you can find me on twitter or via my blog at poshsecurity.com.
Please remember to complete your session evaluations. As a speaker I appreciate everyone who provides feedback!
Thank you all so much.
<<<<pause, wait for applause. ONLY IF TIME ASK FOR QUESTIONS>>>>
<<<<hit the ODS button then red button – switch mic off>>>>
