<<< Previous |  | Next >>>

# Remote shell trojan (RST)

| The superior man understands what is right; the inferior man understands what will sell.
| Confucius

On Silvio Cesare's site is a text file named `elf-pv.txt`. Complete title is "Unix ELF Parasites And Virus", dated October 1998. It gives some background and then describes the gap between code and data segment, as illustrated in readelf (for some strange reason he does not mention that command anywhere).

At the end of the text is an uuencoded file `unix-linux-pv-src.tgz` containing sources. The package is also available as plain `vit-src.tgz`. This is explained on the first page of http://www.big.net.au/~silvio:

> […] The name of this virus by curiosity was given by the people at F-Prot who noticed the virus created a temp file using the letters VIT.

In another text he calls the concept "the text segment padding virus (padding infection)".

Anyway, the code is hard to read as he started development with a piece of plain C and applied several transformations. It seems that he released the stuff the very second it produced results.

## Three years later

Remote Shell Trojan: Threat, Origin and Solution on http://www.securiteam.com 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 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.

> […] From this point, the virus seemed to spread in the wild.

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? (a poll on slashdot.org might give answer) 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:

> […] Again, it is strongly recommend that anybody running Linux run the detector to see if their system is infected. Even if they do not expect anything, they can always optionally immunize their system. This is the only way we can fight the further spread of this virus.

We should make another poll on slashdot.org about how many people used the detector. It must have been all of them. Or is there another explanation that the predicted catastrophe did not occur?

Attached to the article is Perl and C code that detects and vaccinates against RST. Though I never encountered the culprit, seeing the antidote makes me sure it is a variation of Silvio Cesare's concept.

I am certain that my shabby piece of Perl would detect RST, if I had a copy (add collecting to my list of incompetencies). And that a deactivated infection with One step closer to the edge has the same effect as the immunizer on that site.

Anyway, the code is fooled by the improvements made in The entry point. It checks whether the entry point is exactly 4096 from the end of the code segments. If not, the executable is considered immune.

    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.

## 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.

## Another three months later

New Linux Backdoor Virus Gains Smarts on http://www.newsbytes.com is dated 05 Jan 2002.

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

> […] To date there have been "limited" reports of the new RST variant in the wild, according to Eschelbeck. To replicate, the virus requires users to run an infected program from an account with "root" permissions. Upon execution, the infected program will attempt to spread the virus to all ELF files on the local system, he said.

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 successful attack. What type of attack? What vulnerability? On what distributions? Are there updates available? What does http://www.cert.org say about it?

> […] However, Russell said it would be "dead simple" to attach the virus to a useful program, such as a tool that exploits a security hole, and beguile some users into running it.

The first sentence is really 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.

## The serious side

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

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

There is a Unix-FAQ which explains trivia like What's wrong with having '.' in your $PATH? More specific information is the FAQ of comp.security.unix and comp.security.misc. Another interesting piece is Unix System Security which confronts you with

> The best place to start is by reading articles, such as:

> - Guide to Cracking Unix article

> - Usenet computer-security FAQ files

> - Compromise FAQ

Finally we have the suicide methods FAQ.

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 (the second article links to http://www.qualys.com, which even seems to sell them).

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 dumped down customers exert enough pressure on vendors, the security concepts implemented today might be rendered inactive on a default installation.

## Another theory

Rare Linux virus on the loose on http://www.vnunet.com is dated 03-01-2002.

> […] The researchers warned that the culprit carrying the virus is likely to be "some exploit being passed around, possibly a Secure Shell one". Linux users are advised not to run exploits from unknown sources. […]

The article does not back this up with facts. But the idea itself is interesting.

One of the strongest obstacles to virus spread is the distribution concept of Linux. Typical installation method is a set of CDs from a single vendor. Probably a lot of people don't buy the disks but copy them. However, it is really difficult to infect ISO-9660 images. Even more if the CDs are copied on the fly using two drives.

Most other software is downloaded from a specific site. Either a central repository like http://www.sourceforge.org or registered on a place like http://www.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.

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 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.

<<< Previous | Home | Next >>>
The entry point |  | Additional code segments