Read the original article here.

---

The Forbidden Code: Underground Programming Techniques They Won’t Teach You in School

Module 1: Bypassing Defenses - Understanding Backdoors

Welcome to the first module of "The Forbidden Code." While mainstream programming education focuses on building systems and securing them according to best practices, there's an entire world of techniques used to bypass those very defenses. Understanding these methods is crucial – not just for offensive capabilities (though that's part of the allure for some), but more importantly, for truly comprehending system vulnerabilities and building robust defenses that anticipate the unseen.

Today, we dive deep into one of the most fundamental and often covert methods of system compromise: the backdoor. Often whispered about but rarely dissected in formal settings, backdoors represent a direct route into a system, bypassing the standard entry points.

What is a Backdoor?

At its core, a backdoor is a hidden entry point into a system. It's a way to gain access that circumvents the intended security mechanisms, such as login prompts, encryption, or other authentication procedures.

Definition: A backdoor is a method, often covert, of bypassing normal authentication, authorization, or encryption within a computer system, software application, embedded device, hardware component, or cryptographic algorithm. It provides unauthorized or hidden access to the system or its data.

Think of a castle with a heavily guarded front gate (authentication/encryption). A backdoor isn't smashing the gate; it's finding a secret tunnel or a hidden loose stone in the wall that allows access without ever interacting with the guards or the main entrance.

Why are Backdoors Used?

Backdoors serve various purposes, depending on who creates or utilizes them:

1. Covert Remote Access: Gaining persistent access to a system for monitoring, control, or data exfiltration without triggering standard alerts or requiring credentials.
2. Access to Protected Data: Obtaining sensitive information, such as passwords, private keys, or plaintext data within an encrypted system.
3. System Manipulation: Modifying, corrupting, or deleting data; changing configurations; or using the compromised system as a launchpad for further attacks (e.g., sending spam, participating in a botnet).
4. System Recovery/Administration (Legitimate or Quasi-Legitimate): In some cases, vendors or developers might intentionally include backdoors for "legitimate" reasons like password recovery or remote maintenance, although this practice is fraught with security risks if discovered or misused.

Where are Backdoors Found?

Backdoors aren't limited to desktop computers. They can exist in:

• Software: Operating systems (like Windows), applications, system utilities, and even custom code.
• Hardware: Embedded devices (routers, IoT devices), chipsets, and specialized hardware components.
• Firmware: The low-level software controlling hardware.
• Cryptographic Systems: Deliberate weaknesses or bypasses built into encryption algorithms or implementations.
• Cloud Infrastructure: Vulnerabilities in one connected system can expose others if security measures are inadequate.

The Genesis: From Trapdoor to Backdoor

The concept of a "trapdoor" entry point in computing security predates modern usage. In the 1960s and 70s, as multi-user and networked systems emerged, researchers like Petersen and Turn were already discussing methods of system subversion. Their 1967 work identified "trapdoor" entry points used to bypass security and access data directly.

The term "trapdoor" itself later acquired a specific meaning in cryptography related to "trapdoor functions" (functions easy to compute in one direction but hard to reverse without secret information). To avoid confusion, the term "backdoor" became the preferred terminology for these security bypass mechanisms. Early reports, such as the 1970 RAND Corporation task force study sponsored by DARPA, further detailed these types of security breaches, highlighting their significance even in the early days of computing.

Manifestations of the Forbidden Path: How Backdoors Appear

Backdoors aren't monolithic; they take many forms, often designed to blend into the system or evade detection.

1. Hidden Code Within Programs: A few lines of code added to a legitimate program that creates an alternative entry point or bypasses authentication checks. This could be as simple as checking for a specific hidden input or bypassing a credential check if a certain flag is set.
2. Separate Malicious Programs: Entire applications designed to run covertly on a system, providing remote access. A classic example is Back Orifice, an infamous remote administration tool from the late 90s (parodying Microsoft BackOffice) that allowed covert control over Windows systems. Often, these separate programs utilize rootkits to hide their presence from standard system monitoring tools.

   Definition: A rootkit is a collection of malicious computer programs, often installed by a Trojan or other malware, designed to enable access to a computer or area of its software that is not otherwise allowed (for example, to an unauthorized user) while simultaneously masking its existence or the existence of other malware.

3. Firmware Modifications: Altering the low-level software that controls a device's hardware. This is particularly difficult to detect and remove, as it persists even if the operating system is reinstalled.
4. Operating System Components: Malicious code integrated into system libraries or services, giving attackers deep access and control.
5. Trojan Horses: Backdoors are frequently installed by Trojan horse programs. A Trojan appears to be legitimate software (a game, a utility, an update) but contains hidden, malicious functionality. When executed, it might silently install a backdoor, often without the user's knowledge.

Underappreciated Backdoor Vectors:

• Default Credentials: Leaving default usernames and passwords unchanged on devices (routers, IoT gadgets, software installations) is a common, often unintentional, backdoor. Anyone knowing the default credentials can gain administrative access.
• Debugging Features: Developers often include debugging hooks or special access modes during development. If these are not properly removed or secured in the final release version, they can function as readily exploitable backdoors for anyone who discovers them.
• Vulnerable Cloud Systems: In complex cloud environments, if one connected system has weak security or a hidden backdoor, attackers might be able to pivot from that system to gain access to other platforms and data connected within the cloud infrastructure.

A notable historical example of an intentional, government-proposed backdoor was the Clipper chip in the US (1993). This encryption chip was designed with a deliberate "key escrow" system, allowing government agencies access to encrypted communications using a master key. Public opposition and security concerns ultimately led to its failure.

Deeper Dives: Advanced Backdoor Techniques

Moving beyond simple code injections, some backdoors are highly sophisticated, targeting fundamental system components or leveraging complex cryptographic principles.

Object Code Backdoors

Most programmers work with source code (human-readable instructions). This is then compiled into object code (machine-readable instructions). Backdoors inserted directly into the object code are significantly harder to detect than those in source code because object code is designed for machines, not easy human inspection.

• The Challenge: Inserting a backdoor directly into the compiled binary is tricky. Even if you manage it, detection is possible by comparing the modified binary to an original (if available), checking its size, or calculating its checksum. Disassembling the code (converting object code back to a form resembling assembly language) can also reveal anomalies, though it's tedious.
• Counter-Countermeasures: To make an object code backdoor persistent and undetectable, an attacker must:
  • Subvert all existing copies of the legitimate binary.
  • Compromise any checksum files or integrity checks that would flag the change.
  • Prevent recompilation from source (by ensuring source is unavailable or compromised).
  • Crucially, the attacker might need to subvert the tools used for detection (checksumming utilities, diff tools, disassemblers) so they report false information when examining the infected binaries. This requires further layers of subversion, infecting the tools that examine the tools!

Asymmetric Backdoors (Kleptography)

Traditional backdoors are symmetric: once discovered, anyone can potentially use them to gain access. An asymmetric backdoor, however, is far more insidious. Introduced by Young and Yung, this type of backdoor is designed so that only the attacker who planted it can use it, even if the details of the backdoor's mechanism become public.

Definition: An asymmetric backdoor is a type of backdoor, often implemented within a cryptographic system or hardware, that allows the attacker who inserted it to compromise the system's security (e.g., recover secret keys or bypass authentication) while making it computationally infeasible for anyone else, including other potential attackers or the system's legitimate users, to exploit the backdoor or even detect its presence through black-box analysis.

This concept is central to the field of kleptography (from the Greek "kleptes" for thief), which studies how to steal secret information, often cryptographic keys, surreptitiously. Kleptographic backdoors can be hidden in software, hardware (like smartcards), or a combination.

• How it Works (Conceptual): Imagine a backdoor in a key generation process. Instead of just creating a key pair (public/private), the compromised process subtly leaks information about the private key during its creation or use, but in a way that only the attacker, using a secret key of their own, can piece together the private key. Anyone else observing the process or the public output would see nothing obviously amiss.
• Notable Example: The Dual EC DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) standard, developed partly by the NSA, was strongly suspected of containing a kleptographic backdoor. It was believed that the NSA possessed a private key that, when used with the public constants embedded in the algorithm, would allow them to predict the output of the random number generator and thus potentially break encryption that relied on it.

The Pinnacle of Deception: Compiler Backdoors ("Reflections on Trusting Trust")

Perhaps the most conceptually challenging and "forbidden" backdoor technique is the compiler backdoor. This attack doesn't just infect a program; it infects the tool used to build programs, specifically the compiler (or assembler, or linker).

Definition: A compiler backdoor is a sophisticated type of backdoor inserted into a compiler program. It is designed to inject a backdoor into other specific programs (like a login program) when they are compiled, and crucially, it can also inject the backdoor-insertion code into future versions of the compiler itself when the compiler's source code is recompiled. This creates a self-replicating, bootstrapped compromise.

The genius and terror of this attack lie in its self-propagation.

1. The Initial Compromise: A modified version of the compiler's source code is created. This modified source includes two key pieces of malicious logic:
   • Code to recognize when a specific target program (e.g., /bin/login) is being compiled and inject a backdoor into its compiled binary.
   • Code to recognize when the compiler's own source code is being compiled and inject both of the malicious code segments into the new compiled compiler binary.
2. Bootstrapping: The attacker compiles this modified compiler source code using a trusted compiler (or perhaps a compromised one, starting the chain). This produces a compiled compiler binary (the object code) that contains the malicious logic.
3. The Trap is Set: Now, the attacker can replace the standard, trusted compiler binary on a system with their malicious one.
4. Execution 1 (Target Program): When a user compiles the original, clean source code of the target program (/bin/login) using the malicious compiler, the compiler detects this and inserts the backdoor into the resulting /bin/login executable. The user sees no errors, and the source code for /bin/login is clean.
5. Execution 2 (Compiler Itself): If the user later gets a newer version of the compiler's source code and compiles it using the malicious compiler, the compiler detects this and inserts the malicious logic (both the target program backdoor inserter and the self-replicating code) into the new compiler binary. Again, the source code is clean.

Why is this so challenging to counter?

Because the malicious logic is in the compiled compiler. The source code of the compiler that gets distributed can be perfectly clean. If you compile that clean source code with a compiler that already has the backdoor, the backdoor is replicated into the new compiler binary. You are forced to trust the binary compiler you use.

This attack was described conceptually in 1974 by Karger and Schell and famously demonstrated and popularized by Ken Thompson in his 1984 Turing Award lecture, "Reflections on Trusting Trust." Thompson built a modified Unix C compiler that could insert a backdoor into the login program and also replicate itself into future compiler versions. He also showed how such a compiler could subvert tools like the disassembler, making binary inspection useless.

Thompson's core message: Trust is relative. You ultimately have to trust the compiled binaries you use, including the tools that build your software. If the chain of trust is broken at the compiler level, even compiling seemingly clean source code cannot guarantee a clean final executable.

Historical Occurrences (Alleged and Confirmed):

• Thompson's Proof-of-Concept: While Thompson's specific version was reportedly not widely released, anecdotal reports suggest it was distributed to BBN and potentially used.
• W32/Induc-A Virus (2009): This virus infected the Delphi programming compiler, modifying a standard library source file and thus injecting itself into every program compiled by that infected Delphi installation. This led many software vendors to unknowingly distribute infected executables.
• XcodeGhost (2015): Malicious versions of Apple's Xcode IDE were circulated, primarily in China. When developers used this compromised Xcode to build iOS apps, the resulting apps were infected with malware that could steal user data. While not a pure "Trusting Trust" attack (it didn't necessarily infect the compiler itself to replicate), it demonstrated the devastating impact of poisoning the software development toolchain.
• XZ Utils Backdoor (2024): A highly sophisticated backdoor was discovered in the XZ Utils library, a widely used data compression tool on Linux. This backdoor was injected into the library's build process, targeting the SSH daemon to allow remote code execution by an attacker possessing a specific cryptographic key. The attacker had meticulously worked their way into the project as a maintainer over several years.

Politics, Attribution, and the Invisible Hand

Identifying the source and purpose of covert backdoors is often incredibly difficult, mired in technical complexity, plausible deniability, and geopolitical considerations.

• Intentional vs. Accidental: Was a vulnerability left unfixed deliberately as a backdoor, or was it a genuine programming bug? The technical difference can be subtle (like the assignment vs. equality check in the Linux kernel example).
• Rogue Insiders vs. External Agents: Was the backdoor inserted by a disgruntled employee, a malicious insider, or an external nation-state actor?
• Supply Chain Compromise: In today's complex technological ecosystem, hardware components, software libraries, or even manufacturing equipment can be compromised before reaching the end user or vendor. A sophisticated attacker might compromise a supplier of photomasks used to produce chipsets, subtly altering the chip design to include a backdoor, undetectable by the chip manufacturer. The long dependency chains make tracing the origin incredibly challenging.
• Plausible Deniability: Covert backdoors are often designed to look like mistakes or standard functionality to provide the creator with a way to deny intentional malicious activity if discovered.

The intersection of backdoors and national security is clear. The US CALEA act forcing telcos to provide wiretapping capabilities essentially mandated government backdoors into communication infrastructure. The 2024 revelation that China had allegedly exploited this (or similar infrastructure) to tap US communications highlights the dual-edged nature of such capabilities – they can be used by those they were intended for, but also potentially by adversaries who discover or compromise them.

Countering the Covert: Defenses Against Backdoors

Detecting and removing a sophisticated backdoor, especially one that has infected build tools or hardware, is one of the most challenging tasks in cybersecurity.

• Rebuilding from Trust: The most fundamental defense against deeply embedded or compiler backdoors is often to abandon the potentially compromised system and rebuild from known-good, trusted sources and clean hardware. This means compiling software on a verified clean machine using a verified clean compiler, and installing on hardware whose firmware and components are also verified.
• Diverse Double-Compiling: A theoretical and highly complex method specifically designed to counter compiler backdoors (like the "Trusting Trust" attack). It involves compiling the source code of the compiler-under-test using two different, independently verified compilers. By comparing the resulting binaries at various stages, one can gain a high degree of confidence (under certain assumptions) that the source code matches the executable and that the compiler is not compromised in the "Trusting Trust" manner. This is technically demanding and rarely performed outside of high-security environments or academic research.
• Code and Binary Auditing: Painstakingly reviewing source code (if available) and disassembling/analyzing compiled binaries. This is time-consuming, requires significant expertise, and can be thwarted if the analysis tools themselves are compromised.
• Integrity Checks: Using checksums, hashes, and digital signatures to verify that installed software and system files haven't been altered. This is effective against simple modifications but can be bypassed if the verification tools or the process itself is compromised.
• Advanced Detection Techniques: Research explores using methods like neural networks to analyze code or system behavior patterns for anomalies that might indicate the presence of a backdoor.

In practice, for most users and organizations, detecting state-sponsored or deeply embedded backdoors is extremely difficult. Relying on trusted vendors (though even they can be compromised, as seen with XZ Utils), maintaining strong security hygiene, and isolating critical systems are the primary lines of defense.

Notable Backdoors in History (A Rogues' Gallery)

Here are a few examples of confirmed or highly suspected backdoors that have come to light:

• Back Orifice (1998): A tool explicitly designed as a remote administration backdoor for Windows systems.
• Dual EC DRBG (Suspected NSA Backdoor): A cryptographic random number generator standard widely believed to contain a kleptographic backdoor only exploitable by the NSA.
• Borland Interbase (Discovered 2001): Database software versions 4.0-6.0 contained a hardcoded, compiled-in administrator account (politically/correct) accessible over the network.
• Juniper ScreenOS (Discovered 2015): Firmware for Juniper network devices contained a backdoor master password granting administrative access, believed to have been inserted via compromised code.
• WordPress/Joomla Plugin Backdoors (2014): Backdoors found in unlicensed copies of web plugins, often creating hidden admin accounts or injecting malicious JavaScript.
• C-DATA OLT Devices (2024): Backdoors discovered in networking equipment, suspected to be intentionally placed by the vendor for remote access.
• XZ Utils Backdoor (2024): A sophisticated backdoor inserted into a widely used open-source library, targeting SSH access.

Conclusion

Understanding backdoors moves you beyond surface-level security. It reveals how adversaries can bypass the front door entirely, sometimes through subtle, deeply embedded, or self-replicating techniques. From simple hardcoded passwords to complex compiler compromises and cryptographic weaknesses, backdoors represent a persistent, often hidden, threat vector. Mastering "The Forbidden Code" requires acknowledging these dark corners of system design and implementation, enabling you to spot potential vulnerabilities and build systems with a more comprehensive awareness of the threats they face.

In the next module, we'll explore another aspect of underground programming: techniques for obfuscation and stealth...