The term backdoors is a misnomer. This threat is more like a hidden passage. Backdoors are short-cut entries into applications that aren’t readily visible to users, programmers, or even the vulnerability scanners that try to keep applications water-tight. Often these backdoors have been left there on purpose by programmers.
For whatever reason they’re there, they’re a vulnerability. “We had many CSOs and security folks asking us if we could scan for backdoors,” says Chris Wysopal of the vendor Veracode. “We didn’t have scans at the time. So I just started looking around. I went to papers, mailing lists, just looking for anything I could find. It turns out there was very little real academic research on backdoors.” So Wysopal took on the research.
The threat, of course, is that if the backdoor becomes public knowledge, then bad actors can slip into the application unnoticed. And as Wysopal notes, the more critical the software is, and the higher the value of the target, the more likely it is that the development process could be compromised by an insider--a rogue programmer who puts a backdoor in without anyone’s knowledge. Wysopal says that national security types assume that malicious programmers and ones who are offered bribes are part of any software development for state and nation-state level use. “The question of why wouldn’t the CIA or NSA do this was almost rhetorical,” he says.
Wysopal’s research categorizes three types of backdoors:
1. Crypto backdoors. Portals that are lightly encrypted and easy to break through; these are used often in the hacking world.
2. System backdoors. The rootkit phenomenon. Using a vulnerability to establish ongoing root access to a system.
3. Application backdoor. The back door inserted when someone subverts the development process. Types include:
a. Special credential backdoor--the most common, a privileged account known only to those who designed it and those whom they share it with.
b. Malicious backdoors--ones planted by programmers who intend to do harm or are paid by those who intend to do harm.
c. Support backdoors--one left intentionally for support staff to gain easy access to an application for troubleshooting.
Wysopal’s research focused mostly on the third type. What he found was that backdoors were far more common than he expected, which means it’s time for companies to think about closing them up. Also, he discovered that closed-source software backdoors’ existence was measured in years, while open-source software backdoors seemed to be open and closed in months. “When we looked at special credential backdoors, the four biggest were all closed source products.”
Unfortunately, Wysopal believes backdoors could devolve into a cat-and-mouse game of detection and evasion, not unlike any other software scourge like viruses or botnets or spam. In the meantime, do you know who developed your application? Really?
Executive Editor Scott Berinato can be reached at email@example.com.
Defending Against Backdoors
1. Running background checks on programmers who work on software that will be critical or involve significant transactions--in other words, “high-value targets.”
2. Scanning applications for the most common and easiest-to-find back doors, understanding that this process won’t detect all backdoors
3. Asking your vendors what they do to prevent backdoors from getting planted in their software.
Learn more about backdoors in this interview with Chris Wysopal, "Is the Backdoor Threat the Next Big Threat to Applications?"