Notes :

During my discussions with MrCorp, he indicated that I should clearly indicate the definitions of "worm" and "virus. I have used these terms interchangeably in the essay. The purists will be more happy by this distinction - worms spread but don"t multiply within the host while viruses may or may not multiply (i.e. infect more files). You maybe more comfortable classifying them as "malware". Malware can be defined as programs written with harmful and deliberate intent.

Text from original documentation is italicized.

This document is strictly meant to be a snapshot indicating the various developments in the area of virus research.

I strongly advice the readers to explore this topic strictly from a research point of view and refrain from releasing harmful code. This warning is not to be taken lightly as I speak from personal experience and interaction with many people. History teaches us that both in h/v scenes, things turn nasty for the creators once it"s out of control.

This text is dedicated to all @ SWG.

" I"ll take you
Right into the Danger Zone "
-- Kenny Loggins

The troubling aspect about the current wave of malware is the return of one element - intelligence. The last such effort was in 1988 in the form of the Morris worm. It was a piece of beauty with structural foundations that reflected a brilliant mind. The deployment was shoddy and accidental leading to the worm and it"s originator"s quick arrest.

Now after more than 10 years, a group of people have done some impressive work in this gray area. They also demonstrated responsibility by not releasing working versions of their efforts.

In a rather lighthearted article, Michal Zalewski along with his team outlines a working prototype of a next generation virus structure. The project was called "Samhain". The group wanted to check out how tough it would be to write a truly dangerous I-worm (something like Morris ver 2.0).

Before we make an effort at understanding Samhain, a basic concept introduced by them needs to be evaluated. It"s called Wormnet and refers to a network established by the instances of the worm. This helps in varied issues like communication, updating and learning (intelligence, adaptability.. call it what you want to)

Now let"s take a look at the project goals:

Portability

" worm must be architecture-independent, and should work on different operating systems (in fact, we focused on Unix/Unix-alikes, but developed even DOS/Win code). "

An old mission statement. The difference this time is the choice of platforms. The combo of Unix and Windows make a target playing field of almost whole of the networked world. For those of you who think Linux (Unix) is having some kind of immunity to viruses, please take a look at viruses like VIT (an experimental prototype by the author Silvio Cesare given along with his 1998 article - Unix elf virus and Parasites). Several underground zines now have detailed tutorials on malware construction for "nix environments.

There have been earlier efforts to construct multi-processor and true multiplatform viruses, one of the most technically interesting was that of Esperanto written by Mister Sandman.

This virus is interesting for the following reasons:

i) It is written entirely in assembly and C. It"s not a pseudo effort like macro viruses (which take the benefit of the scripting environments provided by Microsoft)

ii) The sheer complexity of the project is impressive for a single individual to handle. This shows the kind of people involved in virus writing.

iii) It is highly modularized with the final target being a single cohesive module

Fortunately, this remained a zoo virus effort. No further practical efforts (read enhancements that would have made it work) have been made in this direction.

The virus writer Jacky with his virus Win32.Cabanas demonstrated a more practical and very effective demonstration of multi OS infection in 1997. This virus is compatible with Win2K, NT, Win9x, and Win32s (Extension to Windows 3.x to run 32-bit applications. It is still used by many people with old systems).

Another factor that helps in virus writing for Win 9x/2k/NT environments is the PE (Portable Executable) format, which is used by all system and third party applications.

Now, getting back to Samhain. The team basically decided on distributing in the source form with the decryptor (detonator) written in shell script. The problem that the required compiler for the platform may not be available at the host is solved by the wormnet structure.

The structure helps solving the problem in the following manner:

" But wait, some (not much) systems don"t have C compiler. What can we do? Using wormnet, worm during infection might ask other wormnet members for compiled binary for given platform… Anyway, binary will contain appended source code, to make further infections possible within standard procedure. "

The first version of the team on writing a decryptor used a simple ("per-byte increments") encryption scheme for masking the worm source. This module itself changed in each new instance of the worm using a polymorphic engine to avoid the possibility of constant strings. This aids in evading signature based detection (which is still is being applied in case of the various new script viruses, even by the so called intelligent virus scanners).

The dependency on various utilities and commands in the shell script or the whole binary module sent to the host was solved again via the wormnet structure. Incase the child sent won"t connect back to the parent and report itself, the wormnet is queried for a pre-compiled binary for the given architecture (this principle works under the assumption that the virus has infected a similar machine somewhere else).

Invisibility

Is equal to invincibility. The art of remaining unseen remains the most elusive and difficult to learn or implement. Sometimes, the very modules or code written to provide this reveals the presence of the rogue program.

Most stealth systems are also highly platform dependent. In the case of Samhain, the team knew that even after the worm attaches to the host successfully, it may not have high enough privileges (read root) to go into godmode.

Techniques that can hide, feint and generally aid in making the worm hard to kill were needed. The assumption of encountering an environment that operates on access restrictions may look silly to the Win 9x based folks but most future operating systems even for standalone workstations would be stripped down versions of network operating systems (for example Win 2k). They will also have lot of features based on principles of file integrity checking (Eg. SFC of Windows, Tripwire for "nix), unauthorized network activity detection etc. to detect the presence of rogue programs.

Hence the most important thing for a virus is to remain hidden till it can be in a position to override all these. Samhain details a "non-privledged process masquerading" unit which consists of the following parts:

Masquerading
The process name of the worm would be such that it is similar to a chosen set of common process names.

Cyclic changes
" change your name (and executable name) as well as pid frequently; while doing it, always keep "mirror" process, in case parent or child get killed by walking skill-alike programs."

The documentation also points us to an excellent source of information on architecture neutral, non-root process hiding techniques. It is in the archive http://lcamtuf.na.export.pl/pliki/libworm.tgz

Though effective, these routines are useful only for a short period of time and the worm should aim to gain root ASAP. After doing that, advanced process hiding can be deployed. The Samhain team developed source for some test platforms based on well-known kernel file and process hiding modules.

Invisibility was also an issue with old DOS viruses like preservation of file date and time, no change in file sizes when stealth module was in memory, bypassing online virus scanners, maintaining compatibility with the loaded modules of the system etc.

In Win 9x/2k/NT environments, the issue becomes more complex due to the more sophisticated and larger executable formats. We saw a return to old techniques like cavity infection (this is a technique by which the virus takes up empty portions in the host file) and the building of new ones like installation archives/ZIP file infection, E-mail attachments, using new mediums like IRC, ICQ etc. for spreading. Further obstacles for the virus writer are the checks performed by the OS for possible file corruption by comparing the image size in the PE header.

Another dimension of invisibility is to destroy those who try to see you. This is demonstrated by new techniques that deactivate or nullify the virus scanner"s attempt to catch the bug at say the e-mail gateway. A few interesting ideas include distribution in ZIP files (encrypted), using some properties to DoS (launch a Denial of Service attack) well-known virus scanners. A simple example would be the one suggested by the British virus writer Rajaat. It involves construction of a malformed ZIP archive, which would disable most anti virus solutions at the time of scanning. This is basically old trick of putting a reserved device name in one of the filenames (eg. Replace blah.txt in blah.zip with CON).

Independence and learning

Most conventional computer viruses rely on some kind of user interaction to infect the host. For eg. Running executables, opening/previewing attachments etc.

The Samhain team formulated another postulate that worries me the most,

" worm must be able to spread automatically with no user interaction, using built-in exploit database "

According to the team members, the wormnet structure can easily be used to provide this functionality. The structure is used to:

• Distribute upgraded Samhain modules (i.e. new exploits/functionality) across the members of the wormnet.
• Query other worms for compiled binaries incase the one sent is not working

The communication scheme used by the proposed wormnet structure is based on a simple TCP stream and connections established are persistent. This is unlike programs like BO2K which use UDP.

In the Win 32 world, one virus which show the early inklings of a communication system is the complex Win32.Babylonia written by the virus author who goes by the name Vecna. It demonstrated how a virus can update itself via plugins. Another interesting feature was the fact that it was also a very efficient e-mail worm.

Let"s now evaluate how the wormnet deals with various events in the host environment:

Infection confirmation
This is done simply by the worm connecting back to the parent from which it originated. If the infection was not successful, no connection is made.

Updation
Incase new "improved" versions of the whole worm or some features are made, all the members of the wormnet can get updated by "re-infecting" the system.

The Samhain team demonstrates that how security measures are needed even in malware to ensure it"s survival. They made a scheme by which the replacement/updation takes place only after the already installed worm verifies the new one by a signature. This scheme can be replaced by any asymmetric cryptographic technique in future worms.

Now two cases can occur:

I) The already installed worm has an older timestamp. In this case, the approach would be to send back a "confirmation" and download the new code via the same tcp stream. Proper error checking and verification should be done throughout the process. After the new module has been downloaded, its code signature has to be verified and finally "install".

II) We find that the already installed worm has a newer timestamp. In that case, the wormnet segment from which the worm placed a request for updation will itself get updated with the new version.

This scheme ensures that the whole wormnet gets updated with a new version ASAP.

Requesting for new platform
Before understanding how this is implemented, I should explain the term TTL. It expands as "Time to Live" and stands for an 8 bit field in the IP header of a datagram. TTL limits the life of a datagram by setting an upper limit to the number of points (routers) through which it passes.

Suppose a worm instance is about to infect a new platform and it finds that the concerned platform is not compatible to itself. Incase this happens, it places a request to every connected worm describing system specifications, as well as IP and port specification. This is relayed with a decreased TTL to other connected objects causing a "broadcast". The first worm that can provide the binary will respond connecting to the IP (and port) immediately. Any further connects which occur within till TTL expiry should be refused (I had a small addendum to this idea.. incase the new connect responds with a newer timestamp, request for updation should be the next logical step).

The documentation again leaves the selection of the TTL and number of retries to us. Packets transmitted via the wormnet structure are to be encrypted. The connection structure is arbitrary and is only limited by limits defined in the specifications. Connections are initiated from child to parent bypassing firewall and other monitoring software. Each child is equipped with a short "wormnet history" list that allows it to connect to alternative parents. This is necessary, as the original parent may have reached a saturation limit with respect to the number of connections.

An example wormnet:

P1 ..................... C1 --- P2
| \                              |
|   \                            |
|     \                          |
|       \                        |
C2     C3                       C4

Practicality Issues
The worm has a database of exploits organised according to:

1) The success rate - The exploits that succeed most frequently are applied first.

2) Local and Remote - Helps to form both a pre and post infection strategy for the worm.

Actual victims chosen for attack are decided by monitoring active network connections. The server to be targeted are picked from this list randomly and incase it is successfully infected, the server is marked as infected.

Integrity

The wormnet"s integrity is critical to its survival. If someone wants to neutralize the structure, he could hypothetically introduce false code into the structure. To prevent from people other than the originator from doing this, a proper cryptographic signing mechanism is built into every aspect of the worm.

Other features have to be built to prevent reverse engineering of the worm body, the protocols used for communication and detection techniques used by the worms to check for themselves.

Polymorphism

Virus writers have used the technology of polymorphism for quite a while now. It essentially defeats conventional scanning based on identifying repetetive code structures. The poly engine used in Samhain was simple and it"s objective was to make sure that the decryptor (detonator) would be different in each case.

Surprisingly with respect to the above, things are more exciting in the Win 9x/NT/2K world.

Welcome to Metamorphism

This is the latest development in the Win 32 world. Incase of poly engines, only the decryptor (or a part of the code) changed. A meta engine would work in this fashion:

Input code -> Engine -> output code completely mutated but similar in functionality.

This technology has now been implemented in actual working viruses (Eg. Win32.Evol)

Bugs having this kind of capability would have to have a complete disassembler built into them. They would be extremely resistant to analysis and would cause great problems to remove. This technology is now in the infancy stage. Many virus writers are working on it.

Usability

This part of the Samhain blueprint is only limited by one"s own imagination. The wormnet can be used to setup a distributed computer working to crack passwords, install backdoors etc.

An interesting idea given by the team is to first test target system with a blank. It means that instead of sending the actual worm with say a payload or something, we should first test if the environment is safe for the actual worm. This again ensures that incase of a "mishap" (say the sysadmin comes to know of our efforts), the wormnet can recover.

A few months back, a virus called I-Worm.Hybris was released
by Vecna. Eugene Kaspersky (the author of AVP antivirus) has said that Hybris is the most complex windows virus written ever. The virus again features a plugin-based upgradation of its abilities and is extremely resistant to reverse engineering. The plugins for I-worm.hybris can be created and introduced into the worm"s network after getting electronically "signed" by the controller (Vecna).

A strong RSA based algorithm is used for the encryption wrapper. The virus writer has given out a full development kit (he calls it the Muazzin SDK ;-) for people to develop plugins.

Hybris is totally different from the current wave of worms like the Code.Blue/Red etc and Nimda.. which are fast burning and
usually don"t last much.

Read more about it at
http://www.avp.ch/avpve/worms/email/hybris.stm

Well that"s it for this time. I wish to thank a friend who provided valuable inputs to this document. He wishes to remain anonymous.

Some interesting links

http://lcamtuf.na.export.pl/worm.txt

(Link to the Samhain document)

http://www.big.net.au/~silvio/

(Homepage of Silvio Cesare, lot of information on Linux viruses)

http://www.ioccc.org

Mentioned in the documentation of Samhain, it is one of the best resources for "extremely ugly code that can run in DOS, [ba]sh, csh, perl etc and can be compiled with C in the same time "

http://www.win2000mag.com/Articles/Index.cfm?ArticleID=8773
(An excellent article on Win 32 viruses by Eugene Kaspersky et.al)

http://www.coderz.net/29A
(Check out the zines. 29A needs no introduction ;-)

http://www.vtc.cjb.net
(A master repository of vx related links)

http://www.humancapitall.com/arunkoshy/art_tunnel.htm

(My article about the technique of tunneling which could be used both by viruses and anti-viruses. Though not relevant to the Win32 world, It"s interesting reading for those trying to understand the old school.)

http://ayanthegreat.port5.com/gupt/

(Written by my good friend, Ayan Chakrabarti, Guptachar is a full remote adminstration tool. The package comes w/ source code for your study and analysis. It"s much easier to follow than stuff like BO2k, offers client side independence. This means that you can access the server from any platform that has a webbrowser)