9. Remote shell trojan

9.1. Three years later

"Remote Shell Trojan: Threat, Origin and Solution" [2] is dated 10/9/2001.

Perhaps they had to cut out all interesting details to protect their source. But what I read on that page makes little sense to me. Supposedly script kiddies [3] got hold of experimental back door code and planted it on sites they had access to. No names, dates, sites or legal consequences given. No details on the method used by intruders to gain access.

Well, how does it spread? There is no reference to a root exploit, either local or remote. It is explained that if root starts an infected program owned by another user, a virus can pollute the whole system. But how many people really do this? [4] And the question on how the virus spreads to other machines remains.

It is plausible that script kiddies copy root kits (including viral back doors) wholesale to cracked machines. It is possible to combine a remote exploit with such a virus to build a persistent worm, though creative work of this extent is by definition out of reach for script kiddies. But in both cases the problem is the used exploit, not the qualities of the installed back door.

Anyway, the concluding remark is strange: [5]

I am certain that Scanners would detect RST. If I had a copy (add collecting to my list of incompetencies). And that a deactivated infection with Segment padding infection has the same effect as the immunizer on that site.

Anyway, the code checks whether the entry point is exactly 4096 from the end of the code segment. If not, the executable is considered immune. This gets fooled by both the simple alignment in target_copy_and_infect #1 (which makes the distance less than 4096) and the improvements made in The entry point[ABC].

psize = (textseg.p_vaddr + textseg.p_filesz) - ehdr.e_entry;
poffset = (textseg.p_offset + textseg.p_filesz) - psize;
if (psize != 4096)
  return 0; /* Binary already cleaned */

The code also tries to clean infected executables by restoring the entry point. I don't trust that part, however:

// read original entry point, that according to my reverse engineering
// is stored on the parasite at offset 1
if (fseek(fp, poffset+1, SEEK_SET)!=0) goto err;
if (fread(&oldentry, 4, 1, fp) != 1) goto err;
  
// restore the binary's entry point to point to the real program again,
// avoiding the execution of the parasite code.
// this pernamently disables the parasite code and makes the binary immune
// to further infection attempts.
ehdr.e_entry = oldentry;
if (fseek(fp, 0, SEEK_SET) != 0) goto err;
if (fwrite(&ehdr, sizeof(ehdr), 1, fp) != 1) goto err;

I can't see any attempt to verify the retrieved address. Silvio Cesare's classic pieces stored the original entry point at a non-intuitive address in the middle of infective code.

9.2. The lighter side

Above code contains everything to build an infector. Obviously it is written from reverse angle. Posted on a HTML page without <pre> or <tt> tags. And there are no references to preceding works and authors. But these are all inevitable constraints of trojan source code (term invented by me, right now). By delivering a good show it is possible to trick unsuspicious high-bandwidth sites into hosting educational material of the guild.

9.3. Another three months later

"New Linux Backdoor Virus Gains Smarts" [6] is dated 05 Jan 2002.

What does the title mean? I feel very illiterate. Does it really fit this text?

If the virus cannot gain root on it's own devices, left alone reach other machines, how does it propagate at all? If this is just a fancy kind of back door then it must have been planted after a successful attack. What type of attack? What vulnerability? On what distributions? Are there updates available? What does CERT [7] say about it?

The first sentence is funny. Do they really say that an exploit is a useful program? Or does this just mean that "Remote Shell Trojan" is not a trojan according to my definition?

To me it summarizes like this: On some cracked machines a new kind of back door was found. Period.

9.4. The serious side

There is a lot of documentation in the net. For example the Security-HOWTO [8] tells this in section "10. What To Do During and After a Breakin": [9]

[…] Re-installation should be considered mandatory upon an intruder obtaining root access. […]

There is a Unix-FAQ [10] which explains trivia like "What's wrong with having '.' in your $PATH?" [11] More specific information is the FAQ of comp.security.misc, comp.security.unix and related groups. [12] Another interesting piece is "Steps for Recovering from a UNIX or NT System Compromise". [13] Finally we have the suicide methods FAQ. [14]

News sites seem to avoid the topic of prevention like the plague. For some yet unknown reason readers are given no hint to educate themselves, or question the sanity of day-to-day behavior. Security incidences are described as act of evil forces beyond mortal control. Instead I detect a strange appeal for magic tools that can cure disease after contagion [15]

There might come the time of a completely brain washed user base taking incredible risks every day. This could be a major opportunity for the folks coding trojans. And perhaps, if dumbed down customers exert enough pressure on vendors, the security concepts implemented today might be rendered inactive on a default installation. [16]

9.5. Another theory

"Rare Linux virus on the loose" [17] is dated 03-01-2002.

Most other software is downloaded from a specific site. Either a central repository like http://www.sourceforge.net/ or registered on a place like http://freshmeat.net/. Should such a download site ever get infected by a virus there is just a single place to shut down.

Some sites are mirrored to share bandwidth demands. But most mirrors are set up to automatically take over changes on a daily or weekly base. So I guess that all "official" sources of infected software will dry up fast. Something similar actually happened. See the story of the irssi 0.8.4 back door. [18]

On the other hand 0-day exploits are traded in secrecy. From one hand to the other. Without authoritative origin. And little incentive to raise public attention. But then I doubt that script kiddies [3] called in security consultants after infecting their own machines. It might be possible that white hat administrators tested such an exploit on their own production machines. I agree with the citation that this is a stupid thing to do. But in that case the administrators would still have the original binary they executed. Which would clarify the issue beyond doubt. To me "is likely to be" means that someone might have installed the virus without knowing it, but on a machine already rooted. Big deal.

9.6. Intrusion detection systems

Most package systems maintain some kind of verification database including intended file owner, file permissions, file size and a checksum. This facility can be used to check for modifications to system files. The platform specific chapter Verifying installed packages[ABC] shows actual examples. "Rute User's Tutorial and Exposition" [19] includes a nice task based comparison of rpm(1) and dpkg(1)/debsums(1). Both package formats provide checksums based on md5sum(1). Feature-wise the only difference between them is the fact that checksums are optional for deb(5). A typical installation of Debian includes a lot packages without checksums.

A possible counter attack is to patch the database after infection. This is distribution dependent and requires root permissions. But it can be done. If you are serious about this issue you should use a real IDS and store the checksums offline. There is a FAQ [20] hosted by SANS Institute. [21] And a brief introduction to products is "Talisker's Intrusion Detection System List". [22] tripwire [23] has achieved a big name, but there is other free software: snort, [24] aide, [25] and lids. [26]

A poor man's approach to this problem is to use the checksums as they are stored in in the package files, e.g. on the installation CDs. Anyway, the real challenge for every kind of system verification is to limit the amount of false positives. Package based checksums are very bad in this regard, since they compare files with the initial state after installation. But then configuration files need to be modified to get the system running, so they will always be reported as messed up. A quick fix is to ignore a large number of files, either because their name matches a pattern or an exclusion list, or because they are marked as being somehow special in the package database. But then some of these files, e.g. /etc/crontab, can be used to install back doors. Still worse, putting a new file into a directory like /etc/cron.d or /etc/rc2.d can serve the same purpose. [27] Real IDS handle these problems by taking snapshots of the system and doing smarter tests.

Another possible attack is to hide the original (uninfected) executable on the file system, and patch the kernel via an inserted module to fake calculation of the checksum. A common name for this concept is "Loadable Kernel Module (LKM) Rootkits". [28] And if the kernel is compiled without module-support, there is still direct access to /dev/kmem to install a kernel-patch. [29] But that's not the end of the story … [30] [31]

Really reliable checksum verification requires a clean boot (e.g. from CD-ROM) and comparison with a clean snapshot stored offline (e.g. written to CD). On this road lies madness.