Backdoors keep sneaking in through backdoors

Backdoors are something that exist as long as access restrictions have been in place. There are always motivations for implementing backdoors whenever there is a justified situation to have "alternative" access. According to the ones creating it.

No surprise, backdoors are installed for good and for more questionable reasons, as well as for outright maliciously purposes. All of them necessitate some secrecy about their existence, and certainly on how to (ab)use them. Unfortunately, secrets are poor security. Well-intended backdoors tend to be found sooner or later and get abused.

Governments, law enforcement agencies, the military, vendors … all push for backdoors to facilitate their missions. If such a backdoor leaks, the users of the backdoored system risk being flooded with attacks.

The reality is that backdoors keep popping up, sometimes years after they were build-in. They are a latent threat to the users and owners of a backdoored system.

Once upon a time …

You have a front door and you have a backdoor, a common practice in the country. The backdoor is for friends and family only, and they should never use the front door, as allowing the use of the backdoor is a sign of trust and hospitality. It is never locked. If you are not close to the people living in the house, you must not use the backdoor, that would be rude and feel very aggressive.

That system was based on local communities and shared ethics. It wasn't perfect and yes, abuse did happen even then once in a while.

Along came the spider web (internet) …

The internet is totally unlike the above situation. Any door is tested. No lock? People just go in. Weak lock? People break in. Strong lock? People still attempt to get in any door they find, including backdoors. These doors may be reachable from any place in the web.

Backdoors come in all colors, styles and sizes

What is a backdoor in internet context? A backdoor allows access to a system with weaker or no controls. It may be a backdoor in the authentication system, or a backdoor increasing authorizations, or both.

Backdoors come in many variations, that allow access to (part of) the system if either:

• the backdoor account name is used

• the hardcoded password is used
• a dedicated service is called
• a specific sequence of interactions is used
• request with additional parameters are used
• (use your imagination)

The effect may be that

• the user gets logged in an does not need to use for instance MFA
• the user gets privileged access
• the user gets additional functionality at his disposal
• logging is deactivated
• the database is wiped
• (use your imagination)

Why are backdoors present in systems?

Because people can make good use of backdoors!

Many systems contain backdoors with the best of intentions. You very likely have some in your organization, not hidden at all, and you may have authorized them.

The hardware version: locks and keys

We start the discussion with the backdoors in the physical world, linked to keys. It demonstrates similar issues and ideas than the backdoors in IT systems.

For physical access keys are still very common. If you lose these, they can be replicated without leaving a trace, and put back near where they were lost, for you to find it and stay ignorant. This replication issue is annoying, not a backdoor.

A common motivation for backdoors is to provide alternative access if the primary access fails. Most of us at some point are locked out of a place, a cupboard, a safe, … because we lost the key. If that key is the only way to get access, we are in trouble. So alternatives solutions are implemented.

To avoid having to hand out duplicates of keys, you see a lot of key safes appearing, small boxes, protected with a PIN, containing the key. The intruder now does not have to be able to open the door lock without key, the challenge became opening the box. This is a backdoor. Some people put the box in plain sight. Others try to hide the box, not under the mat as you would do with a key, still, often there are not so many good hideouts available.

The other well-known back door for key systems is the master key, common in hotels. Guests lose their key, leave them inside, … too often requiring a solution. Another access requirement demanding an alternative is maintenance personnel. They need access to multiple rooms and a keyring is cumbersome (and adds key copying as a risk). Nowadays digital variations of master keys are used, with enhanced flexibility and risk reduction.

If you lose a key, a blacksmith can open the lock for you. The blacksmith should ask you to prove that you are entitled to unlock the door. They use a backdoor method to open the lock that does not require the key, it is based on understanding the technology and a good toolset. Not surprisingly lockpicking is often a hobby of IT security people.

Authorized IT backdoors

Today organizations are using Multi Factor Authentication (MFA) routinely, typically using a dongle or a smartphone app as part of the process. Especially with the hybrid mode of working, you may find yourself separated from the device when you need it. With common commute times, you will not be inclined to make the roundtrip to retrieve the authentication device. The helpdesk likely provides you with alternative access, an authorized access backdoor.

To reenable legitimate users to access the systems there are also automated recovery options. The notorious secret questions system was a common solution. Actually, the questions are not secret, even if they could be, the answers however must be. You go to the recovery site and provided the right answer to three questions for which you registered the answers earlier, and only you are supposed to know. This is a weak backdoor system.

Another authentication backdoor is replacing the MFA complex password generator by a static password for a limited time. That amounts to activating an authorized backdoor mechanism.

Developer backdoors

Simplification of access controls during development and testing

Developer backdoors are backdoors put in place by developers to facilitate their work. The most common case is replacing whatever production grade authentication would be with nothing, or with userID and (simple) passwords.

As the system must be ready to work with other authentication mechanism finally, the simple access is made conditional, so that it is easy to switch. How this switch operates is important. There are too many options to list these. What matters most is: is the mechanism still present in production, and could the switch be toggled in production?

What complicates matters is that at some point the code is considered "final" and testing and QA are following. Tests are easier with a simple authentication mechanism just like in development. In theory, once it has been tested and approved, nothing should change in the code anymore. And there you see a case where benign backdoors mutate into a potential problem.

Trouble shooting backdoors

A very widely applicable principle in security (and applicable outside too) is that everything can and will fail eventually, and at the worst possible time (if you add Murphy's "optimistic" view). All software contains bugs. Bug hunting is an art not receiving enough attention.

In bug hunting a key achievement is reproducing the wrong behavior systematically. Localizing the spot where it goes wrong is facilitated if the system crashes, typically dumping data about where it crashed. Collecting data related to the error is another item on the list. It is still very common to insert statements dumping values in a file, hoping the data help locate the problem.

These trouble shooting log files, may contain any data that is processed by the application. There is often little screening on it, or even knowledge about its existence, as it will only be activated in case of need. Private or secret data may leak into these files.

At some point a long time ago the system I worked on contained many routines to dump specific complex data structures that were never called in normal use. They could be launched from within the debugger on selected structures. Such a system might also do other stuff in transaction systems.

Special accounts for special circumstances and special people

Intervention teams

Intervention teams used in upgrading, deploying, fresh installations etc. do need a large set of privileged accesses routinely. The simplest way is to provide the team members with all the privileged accesses they might need, permanently. They often expect this as part of a reasonable way of working with minimal red tape.

When the security policy forbids permanent privileged access, and only allow motivated elevation requests, it might be that you see these tickets daily, in the morning, for the next 10 hours,

Emergency backdoors

In case of a crisis, the crisis manager must be able to do away with anything standing in the way of resolving the crisis. Activating the crisis situation changes many rules. This is not relying on a single backdoor, rather creating an open house for disciplined and trained firefighters.

When organizations are faced with a serious crisis, a disaster of some kind, a high priority intervention, normal access procedures do get in the way: the personnel that is authorized for the required actions is not present, cannot access remotely, is on leave, is of duty, … many good reasons for the lack of access.

During such a contingency the actions required are unknown beforehand, and they can span a wide set of accesses, so the normal set-up for authentication and access control is not suited.

Even if the identity and access management !IAM) system would be prepared for special situations, the more fundamental risk is the unavailability of key infrastructure, like IAM. It is no good to have a privileged access management (PAM) system if it is not available anymore. Adding backdoors for extreme situations may just increase the risk under normal circumstances and not be very helpful in the worst case.

A completely autonomous alternative solution for IAM and PAM is an option. A non-operational system is secure, but useless. Activating the alternative increases IT risks in exchange for business risk reduction. Many movies show the potential of triggering the alternative solution maliciously. It is up to the crisis management and especially its first responders to judge which is the best course of action.

Legal backdoors

The motivation is understandable

The most tricky type of backdoors are legal backdoors. The idea that law enforcement must be able to access all systems whenever they have a warrant to do so, is a very understandable point of view. That law enforcement access is hidden to not reveal an ongoing investigation makes sense. Hiding that they have this type of access again makes sense in certain cases.

The specifications are not always clear, and hard to meet

The problem is that a backdoor system with the above specifications is hard to build, if possible at all. Only law enforcement must be able to use the facility, so strong authentication is required, for defined user populations. They must have a warrant covering their access, and that must be checked. The data they extract must be in line with the warrant. The system must conceal all interactions. It must not be possible to derive information on the investigation from the observable exchanges.

At on point I designed a system that had a subset of these requirements and it was complicated enough. Even the organization hosting and operating the application was not authorized to identify what was happening over this special law enforcement channel.

Implementations rely mostly on secrecy

Proposals to implement such systems either lead to a system with no control over the use cases, or do not properly address the security of the solution, opening up the backdoor for unauthorized people.

Confidentiality, blessing or curse?

Trap-doored cryptography is a recurring example of a backdoor that leads to serious problems. The main reason why it pops up all the time is the strength of protection encryption provides, for government including law enforcement, for activism, for whistle blowing, for privacy protection as well as for criminal activities.

The key is that either encryption is secure or it is backdoored and so it is not, for any use case. If the backdoor is in the cipher any implementation is unsafe, the same goes for protocol "mistakes". Whether these mistakes are inserted deliberately or not is most often hard to tell (unless that info is leaked). Looking at SSL versions and TLS versions, each upgrade had to do with weaknesses. Maybe it was progression in maturity and understanding, or maybe not.

Malicious backdoors

Malicious backdoors exist as well. They are introduced to have stealth access to systems. The most prevalent types are backdoors introduced in the code of the system, backdoored libraries, and backdoor services.

Backdoors in the code

A backdoor in the code is pretty easy to create. Just make the authentication conditional on some characteristic that the user can influence. It can be a specific userID, a specific pattern in the userID, a special parameter or parameter value, an environment variable that must be set to a certain value, a specific registry setting, a specific entry in the configuration file, etc. It helps to stay hidden if the backdoor is actually hidden in the generic authentication code that is just reused and never checked again.

While it is simple it is also pretty exposed, and anyone looking at the code is likely to spot it. In general, obfuscation may hide the malicious code, yet, obfuscated code itself may be a signal to check more in depth what is happening.

For backdoored privilege checks life can be difficult. A classical way to check privileges is to use code like:

If userInRole("admin") {

admin action

}

A backdoor may be implemented by "forgetting" that check in places where it is required. As a sidenote, it also is a nightmare to audit such programs and spot missing or wrong checks.

A variation is to change the code into two pieces not close together, like in different code files:

File 1:

Function eCheck() : return userID.startsWith("a"+"n"+"d")

File 2:

If userInRole("admin") || eCheck() {

admin actions

}

Signs for code needing review are the use of large number calculations, or that some data is highly random. These are indications of RSA usage or may signal cryptographic keys.

Backdoor libraries

Most libraries are dynamically linked to the application at start up. An old trick is to influence which library is linked in, changing it to find a backdoored version first. If the malicious library is not present in test, the correct one is linked, so the problem is not uncovered.

Libraries are rarely retested or reviewed.

Backdoor services

Backdoor services are mentioned for completeness. The term backdoor service is used to indicate the presence of malicious services on a system allowing remote access. These backdoors are an essential part of Advanced Persistent Threats (ATP). They deviate from the type of backdoors we discussed in this paper.

Conclusion

Handle backdoors with care

Backdoors are a possible solution to many special access related requirements. While it is certainly possible to reduce abuse to an acceptable level, the secrecy requirements may not be compatible with security of the solution.

All too often, the backdoor use is not limited to the intended users, and it just undermines the security for all users, who have no idea about the risk they run.

What is possible via the backdoor may be exceeding largely the use case justifying the backdoor. Given the secrecy there is also no control over the functionality they offer and whether it is proportional to the goals.

A small anecdote to finish

A company got caught using a hard coded full access admin password and this was published. When the backdoor was exposed they reacted very fast. They changed the password …