Is there a standard for labeling a vulnerability as an intentional backdoor?

Question

US concerns of intentional vulnerabilities placed in foreign manufactured equipment has lit up headlines. Is there a standard that sorts (differentiates) poor-designs from intentionally placed vulnerabilities?

Example: An undocumented backdoor vulnerability is found in a system.What is the thought process to decide whether the vulnerability is intentionally placed for remote access or is a result of poor design?

Update: there may be more than one definition for backdoor. That being said, for our purposes, a backdoor is any undocumented remote access to the system. All responses have been thoughtful and are appreciated.

Answer 1

If you browse through a CISSP manual you will find that this high level security course actually touches on back doors for systems. Universally, it states that such back doors are of poor design, even if they are made with the best of intentions. Any backdoor can be discovered and executed against a known entity and is therefor a major security risk. As such, creating a "standard" for this bad practice would be equivalent to saying there's a minimum approved number of malwares you can have on your computer before you need to take action.

That said, there have been many attempts by NSA, NIST, and other government entities (around the globe I might add) to influence developers to leave such backdoor. The consistent feedback from the security community is that backdoors have no method to learn the intent of the user and prevent malicious individuals from coming through. This is especially apparent when you look at industries such as healthcare where 65% of there attackers are internal threats. The only standard, then is to not have back doors.

Answer 2

What is required for a backdoor

By definition, a backdoor is created by someone with access to the system or code in question in order to facilitate future access.

A backdoor is software functionality built or installed by someone intentionally. In contrast, a typical vulnerability has no purpose. A typical vulnerability is the result of an accident or oversight by a developer, integrator, or administrator.

How to identify one

There is no definitive standard for identifying a backdoor. This is usually judged by considering the method by which it operates as well as whether it appears to be designed rather than accidental.

The overriding concern is whether the party who created it would also be the one to use it (or, perhaps, to sell access to it).

Examples

E.g., if a login utility always accepts a specific undocumented username/password, then it is likely a backdoor. It is quite reasonable to assume that a developer coded that functionality specifically to allow him access.

On the other hand, it could be a simple truncation bug or "performance" tweak if a login utility is built so that it only uses the first 8 characters of a password to generate a hash. Obviously, this makes the system vulnerable to brute forcing or rainbow table attacks, but there is no clear basis to presume that the developer would exploit it.

Answer 3

Note that this answer was written before the question was narrowed down (one month of this answer was written) to only include intentional backdoors.

---

I don't think there is such "standard" and I don't think there can be one. It is hard or impossible to find out if a vulnerability was accidentally added as a byproduct of bad design or bad development process, slipped through even though both design and development process were fine or was intentionally added to a good design but well hidden to look harmless as in The Underhanded C Contest etc. There are probably some cases where a specific issue can be traced back to malicious intend but in most cases this is not possible.

Answer 4

The answer is no, there is not a standard for this because the usage of the term 'Backdoor' to refer to 'accidental vulnerabilities' is incorrect. Therefore differentiating between intentional and unintentional backdoors is not something you can do, let alone standardise.

Anyone who says otherwise clearly has not been in the security game long enough to remember the ways in which the language and terminology in this space has evolved over time. Pick up any dusty book or 90's whitepaper on computer viruses and you'll see it plain as day... a backdoor is a method of malicious persistence.

I think the media are generally to blame for this one... us techies do our best to convey terminology to them in a way that can be consumed by the general public, and over time they seem to create their own media-jargon and/or warp the general public's idea of what a term means. For that reason I can 100% see how people can believe a vulnerability is/can-be a backdoor, likewise I can just about grasp how most people can't differentiate encryption from encoding.

In terms of a standardisation of the various sub-categories of backdoors, the closest 'global' method (sorry USA, but the whole World isn't listening to NSA/NIST/CERT guidelines) was created by the anti-virus vendors of the early 90's. Technically speaking, a backdoor is a type of virus.

I'd encourage you to go to https://www.virustotal.com/ and search for 'backdoor'. Check out any of the millions of uploaded virus samples and look at the different names that anti-virus vendors have given them. There are obvious naming conventions that appear and there is clearly some degree of naming standardisation going on, at-least within each vendor. Typical trends:

A backdoor thats only seen as a windows 32-bit binary? 'W32/Backdoor'.

How about a Backdoor, thats a windows 32-bit binary, that has its own cool name 'DoubleAgent'? Easy: 'Backdoor.Win32.DoubleAgent.c'.