Lecture
Backdoor, secret entrance (from the English back door, literally "rear door") is a defect in an algorithm that is deliberately built into it by the developer and allows unauthorized access to data or remote control of the operating system and of the computer as a whole .
The main purpose of a backdoor is covert and fast access to data, in most cases encrypted and protected data. For example, a backdoor may be built into an encryption algorithm so that an attacker can later eavesdrop on a protected channel.
A backdoor is usually a hidden method of bypassing authentication or encryption in a computer, a product, an embedded device (for example, a home router), or its implementation (for example, part of a cryptosystem, an algorithm, a chipset, or even a "homunculus computer", a tiny computer inside a computer, as in Intel AMT technology). Backdoors are most often used to secure remote access to a computer or to gain access to plaintext in cryptographic systems. From there it can be used to gain access to confidential information such as passwords, to corrupt or delete data on hard drives, and to transfer information over automated networks.
A backdoor can take the form of a hidden part of a program, a separate program (for example, Back Orifice can subvert a system through a rootkit), code in the hardware firmware, or parts of an operating system such as Windows. Trojan horses can be used to create vulnerabilities in a device. A Trojan horse may look like a perfectly legitimate program, but when run it triggers an action that may install a backdoor. Although some are installed secretly, other backdoors are deliberate and widely known. Backdoors of this type are used for "legitimate" purposes, for example, to give the manufacturer the ability to recover users' passwords.
Many systems that store information in the cloud cannot provide precise security measures. If many systems are connected in the cloud, hackers can gain access to all the other platforms through the most vulnerable system.
Default passwords (or other default credentials) can work as backdoors if they are not changed by the user. Some debugging features can also act as backdoors if they are not removed in the release version. [10]
In 1993 the United States government attempted to deploy an encryption system, the Clipper chip, with an explicit backdoor for access by law enforcement and national security agencies. The chip proved to be a failure.
This generator was developed at the NSA and standardized as a cryptographically secure pseudorandom number generator by the U.S. National Institute of Standards and Technology (NIST) in 2006. However, as early as 2007 independent researchers suggested that a backdoor might have been built into this algorithm.
Illustration of the algorithm's operation according to the NSA specification:
This algorithm uses elliptic curves. 
is the generator of the group of points on the elliptic curve, 
is a point on the elliptic curve, a constant defined by the standard; how it was chosen is unknown. The parameters of the curve itself are also set by the standard.
Principle of operation:
The equation of the curve
can be rewritten as 
and the following expressions can be written for the operation of the algorithm:
, 
, 
is the internal state of the generator at the current step
is the internal state of the generator at the next step
is the output of the generator at the current step
The suspected backdoor:
Since 
is a prime number, there exists a number 
such that 
. Finding is the computationally hard problem of the discrete logarithm on an elliptic curve, for which no efficient algorithms currently exist. But if we assume that the attacker knows , the following attack results: If 
is the next output of the generator, and if there exists a 
such that 
, then the point 
, lies on the curve and the following equality holds for it: 
. Knowing the number one can compute: 
. Thus, an attacker who knows the number can not only compute the next output of the generator, but also quickly enumerate all possible internal states of the generator and recover its initial internal state. According to independent studies , given knowledge of , just 30 bytes of the generator's output sequence are enough to recover its initial internal state by simple brute-force search over 
values. In the researchers' opinion, such a vulnerability can be regarded as a backdoor.
Researchers at Yandex discovered a vulnerability in the implementation of the TLS protocol in one of Apple's software products . In their opinion, this error may well be a backdoor deliberately built into the algorithm by one of the developers.
The section of code containing the error:
static DSStatus SSLVerifySignedServerKeyExchnge(....)
{
DSStatus err;
....
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((SSHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
....
fail:
....
return err;
}
As can be seen, the first if statement is followed by two goto fail lines, and the second line is always executed, regardless of the result of the if. As a result, the certificate verification procedure is not carried out in full. An attacker who knows about this vulnerability can forge a certificate and pass the authenticity check. This would allow them to carry out a "man-in-the-middle" attack and thereby interfere with the secure connection between the client and the server. The researchers who discovered this implementation error cannot say for certain whether it was made deliberately or by accident. It is quite possible that it is a backdoor built into the algorithm by one of the developers.
Very many modern cryptographic algorithms use a certain set of internal constants in their operation. As a rule, these constants are set by the standard and are chosen with a view to cryptographic resistance to the types of cryptanalysis known at the time. But the choice of constants during the standardization of an algorithm can, in theory, also be used by developers with malicious intent: for example, to create particular vulnerabilities and backdoors in the algorithm.
An example of such use of constants is provided by recent research on so-called "malicious hashing" , in which the authors managed to construct collisions for the SHA1 cryptographic hash function by modifying its round constants. Note that the attack proposed by the authors of the study is not an attack on the SHA1 hash function itself; it only makes it possible to find collisions provided that the round constants can be changed, and only for certain types of files.
A brief description of SHA1:
SHA1 is a modern iterated hash function. The hashing algorithm is as follows:
are initialized
or 
used for each stage
, which are added to the result: 
after the last message block has been processed.Constructing collisions:
The goal of the attack under consideration is to find such constants 
and such messages 
and 
, that 
. This attack modifies only the first 512 bits (the 1st block) of the messages for which a collision must be constructed. The algorithm is based on the already known differential attack on SHA1, proposed in 2005 and having a complexity of the order of 
operations, which makes it hard to carry out in practice. That is why, to this day, no real collision for SHA1 has been found.
However, if a malicious variant of SHA1 is created, the attacker can vary not only the message blocks and , but also the round constants . According to the research , this greatly reduces the complexity of the attack to the order of 
operations and makes constructing such collisions a realistic task that can be carried out on a few computers. In this way, the authors of the study managed to construct single-block collisions for many well-known file types.
Single-block collision:
and are the first message blocks (512 bits), which differ from each other but give the same hash sum
is the remaining content, which is identical for both files
Using the described attack, two sh scripts were created which, when 
is chosen, give the same SHA1 hash sum but behave differently.
As can be seen, the difference between these two scripts lies only in the first 512-bit blocks, which are commented-out garbage. But the content of these blocks is then used in the if condition, so the scripts behave differently when run. Such files can be used by a creator with malicious intent.
Backdoors can be built not only into software but also into hardware. Such backdoors can be used by hardware manufacturers to embed malicious functions into it at the production stage.
Hardware backdoors have a number of advantages over software ones:
An example of a hardware backdoor is malicious BIOS firmware. According to research, such firmware can be built on the basis of the free firmware projects Coreboot[13] and SeaBIOS. Coreboot is not a full-fledged BIOS: it is responsible only for detecting the hardware present on the machine and handing control over to the actual "BIOS payload", for which SeaBIOS, modified by an attacker for their own needs, can be used.
The principle of operation of the malicious firmware can be briefly described as follows: immediately after the infected computer is switched on, even before the operating system loads, it attempts to establish a connection with the attacker's server over the internet. If the attempt succeeds, some bootkit is downloaded remotely, which in turn gives the attacker the ability to carry out malicious actions on the infected computer: data theft or remote control. If the attempt to connect to the internet fails, the operating system boots normally. An undoubted advantage for the attacker is that the modified firmware itself contains no malicious code, while bootkits are hard to detect.
A sophisticated form of black-box backdoor is the compiler backdoor , in which not only is the compiler subverted (to insert a backdoor into some other program, such as a login program), but it is additionally modified to detect when it is compiling itself, and then inserts both the backdoor insertion code (targeting the other program) and the self-compiling code that modifies it, much like the mechanism by which retroviruses infect their host. This can be done by modifying the source code, and the resulting compromised compiler (object code) can compile the original (unmodified) source code and insert itself: the exploit has been bootstrapped.
This attack was originally presented in Karger & Schell (1974 , p. 52, section 3.4.5: "Trap Door Insertion"), which was a security analysis of the US Air Force's Multics , where they described such an attack on a PL/I compiler and called it a "compiler trap door"; they also mention a variant in which the system initialization code is modified to insert a backdoor during booting , as this is complex and poorly understood, and call it an "initialization trap door"; this is now known as a boot sector virus .
This attack was then actually implemented and popularized by Ken Thompson in his Turing Award acceptance speech in 1983 (published in 1984), "Reflections on Trusting Trust" in which he points out that trust is relative, and that the only software one can truly trust is code where every step of the bootstrapping has been inspected. This backdoor mechanism is based on the fact that people only review source (human-written) code, and not compiled machine code ( object code ). A program called a compiler is used to create the second from the first, and the compiler is usually trusted to do an honest job.
Thompson's paper describes a modified version of the Unix C compiler that would:
Because the compiler itself was a compiled program, users would be extremely unlikely to notice the machine code instructions that performed these tasks. (Because of the second task, the compiler's source code would appear "clean".) What is worse, in Thompson's proof of concept implementation , the subverted compiler also subverted the analysis program ( disassembler ), so that anyone who examined the binaries in the usual way would not actually see the real code that was running, but something else instead.
An updated analysis of the original exploit is given in Karger & Schell (2002 , section 3.2.4: Compiler trap doors), and a historical overview and literature survey is given in Wheeler (2009 , section 2: Background and related work ). .
Thompson's version was officially never released into the wild. However, it is believed that the version was distributed to BBN and at least one use of the backdoor was recorded. There are scattered anecdotal reports of such backdoors in subsequent years.
In August 2009, a similar attack was discovered by Sophos labs. The W32/Induc-A virus infected the program compiler for Delphi , a Windows programming language. The virus introduced its own code into the compilation of new Delphi programs, allowing it to infect and propagate to many systems without the knowledge of the software programmer. An attack that propagates by building its own Trojan horse can be especially hard to discover. It is believed that the Induc-A virus had been propagating for at least a year before it was discovered.
Once a system has been compromised with a backdoor or Trojan horse, such as the Trusting Trust compiler, it is very hard for the "rightful" user to regain control of the system - typically one should rebuild a clean system and transfer data (but not executables) over. However, several practical weaknesses in the Trusting Trust scheme have been suggested. For example, a sufficiently motivated user could painstakingly review the machine code of the untrusted compiler before using it. As mentioned above, there are ways to hide the Trojan horse, such as subverting the disassembler; but there are ways to counter that defense, too, such as writing your own disassembler from scratch.
A generic method to counter trusting trust attacks is called Diverse Double-Compiling (DDC). The method requires a different compiler and the source code of the compiler-under-test. That source, compiled with both compilers, results in two different stage-1 compilers, which, however, should have the same behavior. Thus the same source compiled with both stage-1 compilers must then result in two identical stage-2 compilers. A formal proof is given that the latter comparison guarantees that the purported source code and executable of the compiler-under-test correspond, under some assumptions. This method was applied by its author to verify that the C compiler of the GCC suite (v. 3.0.4) contained no trojan, using icc (v. 11.0) as the different compiler.
In practice such verifications are not done by end users, except in extreme circumstances of intrusion detection and analysis, due to the rarity of such sophisticated attacks, and because programs are typically distributed in binary form. Removing backdoors (including compiler backdoors) is typically done by simply rebuilding a clean system. However, the sophisticated verifications are of interest to operating system vendors, to ensure that they are not distributing a compromised system, and in high-security settings, where such attacks are a realistic concern.
Comments