Site hosted by Angelfire.com: Build your free website today!
Windows Backdoors: Greatest Security Breach Ever?

by Doctor Electron

Updated: Aug 7, 2004

The Buffer Overflows Scam

Net Census first reported the "long history of built-in backdoors in Microsoft Windows" and the complete lack of evidence supporting the official explanation that these covert remote access mechansims are merely "buffer overflow bugs".

If backdoors are intentional Windows features, the companion product would be software tools for "insiders" to conduct covert snooping. Spying by "insiders" may have compromised security much more than any efforts by "outsiders" who, as late-comers, discovered the existence of this buffer overflow remote access mechanism in recent years and whose snooping software would be much less effective.

The demonstrated clandestine remote access features included in Microsoft Windows software for many years may represent the greatest breach of security of all time. For national security of the United States government and military and other countries using this software. Ditto for corporate security. Not to mention the security and privacy of individuals.

The enormous implications of Windows backdoors by design contrasts the continuing lack of investigation in any public reports seen by the author. We have a 911 Commission and its report, but no Windows Backdoors Commission or report.

In over eight months, Net Census has received no evidence to contradict the Windows backdoors thesis, from Microsoft Corporation or anyone else.

This includes (1) no evidence to support the existence of "buffer overflow bugs" and (2) no evidence contrary to the rather obvious theory of Windows backdoors by design.

So much for the "overflow bugs are lamentable" publicists who pretend to be, or are presented as, computer experts. Covert snooping mechanisms packaged in Microsoft Windows are demonstrated facts. No evidence has been presented showing that these mechanisms are merely software bugs.

One might conclude that there is no such evidence -- only evidence supporting the original Net Census report that these backdoors represent a huge security breach and that the "buffer overflow bug" story is a coverup scam.

If there is no contrary evidence, one might think that there would be a complete lock-down of Microsoft Corporation so that supporting evidence is not destoyed.

But the maxim appears to be: "Investigate small-to-moderate security breaches, not the big ones". Therefore, only in cases of lesser security threats would computers, hard-drives and documentation be seized by investigators, not in major security threat cases.

Meanwhile, major media attention has focussed on "critical" security flaws which might be exploited by mischievous "outsiders", not on whether these so-called flaws were in fact built-in mechanisms enabling covert snooping which may have been conducted by "insiders" over many years.

The Most Feared Investigation

Let us accept the apparent lack of interest in major security risks. Nonetheless, we can speculate on what might be found if there were some interest.

1. Revealing comments in source code.

2. The original software backdoor (or bug?) source code before patches.

3. What exactly were the patches?

4. Other "data copy" code written by the same programmer in the same time period.

5. Do #2 to #4 above pass even elementary "reality tests" by experienced programmers in an investigative team? Does the evidence seem consistent with a mere "mistake" or "oversight" in coding? For each instance, is the progammer a relative novice or a veteran Microsoft ace? The section on snooping client programs below suggests that backdoor code might be written by more, rather than less, experienced coders. However, writing backdoor functionality into the Windows operating system is a more simple and a different task than writing the "insider" snooping client programs described below.

6. Testimony with source code and other supporting documentation by the programmers who wrote each instance of a Windows backdoor (or bug?) under oath, televised gavel-to-gavel. "Greatest security risk ever" makes good TV and the public and other experts can respond.

7. Complete investigation of other activities, including financial dealings, of these individuals and all of their associates.

8. Search among "insiders" for the client software which may have been used to gain unauthorized access to computer data. Who is selling it? Who is buying it? What crimes have been committed with it?

These might be in the mega-crime category -- and according to our maxim, of no interest to prosecutors and national security officials.

Insider-only Windows Backdoor Client Software

The original demonstration of Windows backdoor mechanisms was presented as a "bug report". [If a reader can help, I would like to cite and give credit to the original author(s).] This report documented the existence of Windows backdoors and ironically, described them as a software bug in Windows. Apparently, Microsoft picked up the ball and has run with the "It's a bug" smokescreen ever since.

Windows backdoor demonstrations by "outsiders" serve their purpose, but no doubt fall far short of what "insider" backdoor client writers could do.

Let us define some terms and look at how slick snooping software by "insiders" might be.

First, millions of computers running a Windows system and connected to the internet have had built-in remote access features not documented by the vendor in the Windows version releases. In short, a computer running Windows on the net may be a "server" allowing unknown parties complete access to its files and activities.

Second, given these backdoor "server" mechanisms, anyone with an appropriate client program could gain clandestine access. Such client programs may have been produced for, distributed to and used by selected "insiders" well before any public knowledge by "outsiders" of any "buffer overflow" covert remote access Windows feature.

Our shopping list might include:

1. Since Microsoft "insider" programmers have access to all sorts of data on internal Windows functionality, such as data structures, offsets and security mechanisms, one might assume that "insider" client programs could be extremely compact and powerful. The entire running code may be only one or two kilobytes resident on the victim machine.

2. It is very important that no large data transfers over the net occur in a short interval; this might be detected.

3. Probably a first order of business would be to determine the Windows version and to "phone home" so the client program will send (a) code to restore the over-written code to "normal" and (b) the snooping code best suited to that version.

4. These clients no doubt immediately replace over-written instructions in the buffer overflow backdoor mechanism used, so no sign of computer malfunction will ever be seen. The "setup code" of the client program may give itself highest CPU priority for one network cycle needed to get the "replacement bytes" to restore the over-written code.

5. Since brief snippets of information transfer to the snooping client are all that is needed, probably some "unusual" packets are used that are (a) known to be reliably routed by "garden variety" routers and (b) unlikely to be monitored or detected by known security software. For example, using TCP or UDP protocols is out of the question. ICMP might be doable; or we can be even more imaginative.

6. Each tiny client module would specialize in one kind of task -- for example, scanning directories, search files for keyword text, etc.

7. All of these things would be done very slowly and probably run at lowest CPU priority to avoid detection of spikes in CPU usage. If one is committing the "crime of the century", (a) what's the rush? and (b) best not to blow it.

8. If the snooping target machine goes down for whatever reason -- say, it's quitting time, we don't care because our client has access at any time the target computer is running.

9. Such client programs may be privy to internal offsets in Windows modules to do "amazing feats" of snooping in the most efficient possible manner. In brief, whatever authentication or security features one may have in place, these "insider" clients could "go above their heads" and address and manipulate internal data completely independently of the "normal channels" or API mechanisms. Therefore, any security software which monitors process API calls would be null and void. Code from the client running on the target machine does not need to make API calls. It can go straight to the meat.

Nine client design features may be enough for now. After all, nobody cares about big security breaches.

Further investigative steps for snooping clients include:

1. Bring one in for questioning: Obtaining and analyzing a hypothesized Microsoft insider-produced snooping client program, designed, as described in part above, to behave as a "part of the operating system" rather than as an "application process".

2. Detect one in action: Developing security software that might detect a visit from such a spy client -- which, on the victim machine, alters no files, has no process ID or ram allocations detectable by application API calls (used by security software), uses only 4k to 16k memory for both code and data since tiny modules are swapped in from the network, has very low-level access to incoming and outgoing packets, and so forth.

Copyright © 2004 Global Services
Original publication: Aug 4, 2004

Back to Net Census