We are in the midst of a digital revolution where both the Internet and digital technologies formulate and drive the way we live and communicate. Both elements have changed the world, connecting dispersed endpoints, and creating an entirely new culture of communication. Through the use of mobile technologies, we are now more connected than ever before.

The digital revolution improves lives and relationships; however, it also introduces a new wave of vulnerabilities. While the revolution is in full swing, effective security is a critical piece of the puzzle in this new age of digital communication.

While we have an amazing capability to introduce remarkable advances in technologies, the question on the tips of many tongues is: "are security professionals prepared to successfully face the onslaught of new cyber attacks and mitigate the resulting security breaches?" We are losing the cybersecurity battle due to the foundations built without security in mind. It is compounded by the inner workings of some of the Internet's most widely deployed protocols such as TCP, HTTP2, TLS/SSL, and DNS.

It's not that these protocols are completely flawed, it's just they have not evolved to match today’s connectivity model. In fact, in some cases, we have created new vulnerabilities in our quest to solve emerging problems such as DDOS.


DNS is the control plane that glues components together, and one could say it is the network’s focal point. Being over 30 years old, it acts similar to the foundation of a house.

Even though DNS has been improved over time to refine the security of data passed between DNS servers, the base lookup function is still completely unauthenticated and the administrative aspects of DNS that are used to update services and configurations require complex controls to ensure that this attack angle isn’t exploited.

A lot of interesting traffic flows based on the information gathered from a DNS lookup, which means it's a good starting point to compromise a network and launch an attack. This vulnerability has been exposed in an aggressive and well-documented cyber attack on what is believed to be Brazil’s Banrisul Bank last fall.

An organization's security posture is only as strong as the weakest link. A small hole can sink the ship. Likewise, a puny insecure network island or a hole in a protocol stack provides fertile breeding ground for vulnerabilities to spur a daisy chain of events, similar to a house of cards tumbling down.


The attack on the Brazilian Bank required sufficient planning and resources to indicate the involvement of organized crime or a nation-state. It was a very sophisticated and premeditated cyber event, but it could have been prevented. The attack involved many pre-planned steps culminating in the attackers flipping an external “switch” by performing a DNS redirection. This created a cascade effect that allowed the attackers to inject themselves into all the Bank’s online transactions including online (web and mobile) banking, ATMs, and point-of-sale transactions.

Firstly, the cybercriminals replicated all digital properties in look-and-feel to exactly match the Bank's digital properties. A free Certificate Authority was employed to make a new Certificate appear authentic to third-parties. For all practical matters to the unknowing end user, it was the real Bank's Certificate. Combined with the compromise of their DNS provider, within a short period, the bank lost control of core digital assets that formed the foundation of their services. A daisy chain of cybercriminal events ultimately took over the bank's services and ability to operate, resulting in the loss of millions of dollars.

This attack exposed multiple security issues that point a finger towards the authentication methods that the bank deploys to its customers as well as those used by their DNS Service Provider. We have talked about the problems; now let’s roll the spotlight over the solutions.


Password-based security is no longer sufficient. It’s a single authentication method and does nothing to protect the data. Further, password authentication gives up something to the attacker when a password is sent to the wrong site. Essentially, if a password is compromised, an intruder has access to all resources the account with that password is entitled to.

The vast majority of organizations are moving to a two-factor authentication (TFA or 2FA). This style of authentication employs two of the following factor classes - “something you have,” “something you are” and “something you know.” An example of 2FA would be a username/password and a one-time-pin issued to a hard token the user carries around.

Multi-factor authentication adds additional layers of security, creating a robust authentication method using two or more factor classes. It can be implemented using low-tech mechanisms such as pre-shared and single-use codes, or sophisticated technology including biometrics like iris or fingerprint scans and other emerging methods.

Through various probing techniques, the cybercriminals determined that the bank was not using a robust authentication method to their DNS Service Provider. They were able to retrieve the DNS registration credentials and at the right time flipped the DNS to point to a phony site. The bank should have used Multi-factor authentication to their DNS Provider. While MFA is best practice in almost any situation, it is absolutely vital in mission-critical services such as DNS.

The attack also exposed a more glaring issue with how authentication connectivity is handled today. Clients place their complete trust in the veracity of DNS and promiscuously connect to servers without going through any type of initial authentication. If the client connects to the wrong service, such as a phony Website, they have no idea and will continue to operate as normal while issuing private transactions. This flawed model enables an attack like this one to have devastatingly more far-reaching consequences.


Much of today's authentication is based on a “one-way” paradigm. The client authenticates to the server, but the server does not strongly authenticate back to the client. This is relevant to why the recent attack on the Bank was successful. The Client was completely unaware that the legitimate website was replaced with a fake one.

The server did not authenticate itself per se, and merely provided a digital certificate. The user believed the certificate was legitimate as it was signed by a trusted Certificate Authority (CA). The cybercriminals used a certificate signed by a free CA and tied that certificate to their domain. This created a situation where users would connect to the fake site but still see a green lock in their browser bar giving them a false sense of security.

By deploying strong Mutual Authentication, the server authenticates to the client using mechanisms that don’t rely on a third-party CA that can be compromised.


Uniken’s REL-ID is designed to prevent this type of attack (and other as yet unforeseen attacks as well). Today the attack surface is the entire Internet on port 443 (HTTPS). REL-ID massively constricts the attack surface by only allowing trusted users on trusted devices on trusted apps to even connect to your websites and services. It’s a comprehensive solution that operates at a one-to-one application process level providing the perfect defense-in-depth strategy.

REL-ID narrows the attack surface to a specific user on a specific application on a specific device, trying to connect to a specific service endpoint. This approach creates a bubble of security at the Application level, introducing a new Software Defined Perimeter.

REL-ID Mutual Authentication uses a split key mechanism where each the user and the service each have half of a split symmetric key which must be combined and validated for a successful connection. In this model, the client and server must both prove to each other they are legitimate, creating a significantly higher level of assurance in the transaction.

Let’s see how Uniken can prove to be the one-stop solution may it be a small-scale establishment or a massive organization like banks with an international chain of branches.


Within the Uniken REL-ID Security Framework, the mobile application would have tried to connect to the malicious site but, the “authenticate first” approach to security would result in clients never being allowed to connect in the first place. The user’s app would have attempted to combine its key half with the server, and when that failed, the transaction would have been stopped in its tracks.

Even for those users who began a valid session before the attack was triggered, REL-ID’s persistent authentication capabilities would have detected that the connection was now being diverted to an invalid party, and terminated the session.

Uniken creates strong security between the user, app, device, connection, and service (what we refer to as Unified Defense-in-Depth), and eliminates threat vectors from third-parties like DNS providers and CAs.

Contact us via the form below to learn more about how we can help secure your websites, services, and mobile apps.