Every few months another report comes out about a hacker group taking aim at large banks around the world. Most recently, we have seen an interesting switch to target government central banks. All types of financial institutions being a target makes sense because, even if the attack is not successful, the attention one can get impacts the entire gamut – from a bank CEO to the individual with $20 in their savings account. In short, everyone cares when money is involved because the stakes are so high and so personal.
Big banks have been obvious targets since the days of the Wild West, only today attacks happen in milliseconds, leaving no time for Dudley Do-Right, wearing his red serge, to ride in on his horse and save the day. We assume that the primary motives to attacking a financial institution are making money, in the form of outright stealing, ransomware demands or indirectly through data theft. However, it is also notable that many hackers use multi-vector attacks to hide their activities while nuisance hacking and hacktivism are still an active threat to any recognizable brand. Also, according to a financial post article from late last year, smaller institutions are also targets yet often do not have the same resources to combat attacks.
CIRA’s role in helping Canadian organizations be more secure started with a secondary anycast DNS network designed for Canadian traffic. We have recently added a DNS firewall service that is in pre-release with some clients in the MUSH sector (municipalities, universities, school boards and hospitals). In other words, we are locating DNS server infrastructure in Canadian IXPs to help to make Canadian organizations, domain name holders and Internet users safe from attacks at home and from abroad.
With the authoritative DNS more than one supplier is prudent risk management
Focusing on the authoritative DNS servers of Canadian financial institutions, the primary threat is hackers targeting the DNS in a large scale multi-vector DDoS attack like the ones that targeted several UK banks earlier this year. A DDoS attack attempts to flood a resource with so much traffic that it is unavailable to handle legitimate requests. And while disruptive, it is less of a personal data problem than other types of threats.
In part one of this article, we reviewed the top level architecture of over 150 schedule 1 and 2 banks, REITs, insurance companies, and brokerage firms. That review led us to conclude that financial institutions in Canada generally did not have more than one DNS supplier – a recommended best practice to help keep email, websites and web applications resilient to outages. The other benefit is that setting up a secondary network is easy, cost effective and risk-free when compared to the real cost of even one small attack mitigation. Notably, if we look at some recent high-profile attacks, like the one that hit Dyn DNS last year, we see that a huge number of organizations can be brought down when they aren’t even the target of the attack; and there are similar examples against other cloud service and hosting companies as well.
In addition to looking at the number of suppliers, for this second look we ran a more detailed analysis on the health of the DNS for a select group of the institutions using the D-Zone DNS Configuration Test.
Focusing on those with higher probability of configuration issues
At least one large financial institution in Canada had a DNS that we can only describe as weird. And just to be clear, we are talking about their .com and their .CA because the latter simply redirects to the former. It was a very strange set-up because it used Akamai. Notably, that would have excluded the institution from this particular comparative analysis of authoritative name servers, however, things were so unusual that we are calling it out here. Firstly, it did not perform well when run through the DNS Configuration Test. Now, in a CDN scenario we don’t necessarily expect the DNS to behave “normally”. In this case their Akamai servers refer to what appear to be in-house DNS servers (meaning that they aren’t providing consistent answers that match the registry). More importantly, when we look at the responses from the name servers we see that two out of the four servers were down when we queried them. In short, it appears that they have an unnecessarily complicated and 50% broken DNS without much apparent redundancy and no global backup from a second DNS provider. We’re trying to stay positive and not naming-names, but we recommend everyone run a test to see how your DNS is performing.
To understand the prevalence of configuration issues, for the rest of this review we excluded those using large DNS suppliers, with visible redundancy, or those using a CDN for their DNS (i.e. Akamai). This was an attempt to focus on those that are more likely to have DNS configuration issues and to recognize that in a multi-server content delivery network scenario, the DNS decisions are more complex.
What did we find with our deeper dive on the DNS of financial institutions? We are happy to report a significantly healthier DNS in the financial sector versus other sectors we have looked at. So much so that it was actually unnecessary to chart problems in a meaningful table. This great news is likely due to the fact that financial institutions have been targets for so long that they have had to ensure all parts of their IT stacks are being managed close to perfectlion. Notably, we ran a similar analysis on a cross section of organizations outside the financial sector that were running their own name servers (available in our resource section with registration) and found an average of three DNS issues per organization. As a result we are focusing some of the minor issues that came up most often during this review.
- The DNS uses TCP when UDP is not accessible and with quite a few financial institutions one or more DNS servers were not accessible over TCP. This is actually pretty common as the firewall people and the networking people are not always in sync.
- Several had name servers that failed to answer requests. This can occur in a few circumstances but in a well architected DNS should never be necessary. First, that a name server is being maintained. Second, that one is simply not in use and nobody updated their DNS records at the Registrar. Third, that there is a problem and the institution has less redundancy than they think.
- You need a PTR record if you run a mail server and a mismatched PTR result was seen in several situations. It can be a signal to spam filters that your emails are not legitimate. Probably not something your mutual fund salespeople want happening.
- We still see a lot of name server records on the same AS, or network ID. This is not necessarily bad as the DNS configuration can be architected with the necessary redundancy on a single AS. However, having DNS servers on multiple different networks or network providers is another good best practice that is easy to implement with a secondary.
What else? Locking down the DNS for your domain name
Big news hit the security circles last week in that an unnamed Brazillian financial institution had its DNS hijacked by thieves. This was a report by Kaspersky Lab on an incident that took place in October 2016 and was very different than other recent hijackings that were aimed at delivering a hactivist message. In this case it was more of a professional redirection to transfer all 36 of the bank's domains to phony websites that looked like the bank's real web services. They also had control of the bank email rendering it difficult to communicate the issue to customers during the 5 hour problem. The impact is that customers gave away user names and passwords to their accounts to a fake site in addition to infecting the customers with malware. Our analysis can't evaluate what banks have their .com domains locked, but all domains for every financial institution should be locked at the registry.
In conclusion, in running a cross-section of Canadian financial institutions' domain names through our DNS Configuration Test we were really quite impressed with the quality of their configuration in general. The single most significant issue was the lack of a multi-supplier architecture to help keep services online in the event of an outage at one supplier. Good job! Now go out there and back it up!