t byfield on Sun, 14 May 2000 19:08:06 +0200 (CEST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> (fwd) Worst Nightmares Come Alive

Worst Nightmares Come Alive

   Before we start
   This document has been written with great care. I urge you to read the
   complete document before commenting on it. Furthermore, I urge you to
   think about it for a while before commenting on it. If you have
   constructive comments please send it to:
   You may replicate this document at will - but please do not butcher it
   - copy the *whole* document, and give me credit. I would also
   appreciate it if you let me know where you publish it - just to keep
   track of it.
   Roelof Temmingh
   South Africa.
   Part I: Background
   Part II: Overview
   Part III: Detail design
   Part IV: QWRNA (Questions We Rather Not Ask)
   Part I: Introduction to your worst nightmare
   "I guess it was bound to happen someday - please spread the word".
   This message was posted to a computer mailing list by Gene Spafford on
   03 November 1988 - back in the days when the Internet, still in its
   infancy, was a tool for academics and a toy for geeks. Spafford is
   referring to an Internet-born computer worm (a type of self-sustained
   virus) that eventually managed to effect more then 10% of the 60,000
   hosts then connected to the Internet. Despite the fact most of the
   world hadn't heard of the Internet or email before, and the fact that
   the Dukakis-Bush election was just days way, the incident made it to
   the front page of most major newspapers. This was not because the worm
   was particularly viscous - it was actually quite benign - but because
   people recognized the potential for large-scale damage the worm
   represented. Were it not for a small programming error in the worm's
   code it may never even have been discovered. Ten years ago the "Morris
   Worm" shocked the world into realizing the fragility of Internet.
   Today, very little has changed. Despite ten years of new knowledge and
   experience the Internet today is as least as vulnerable to Morris-type
   attacks as it was ten years ago. In fact, even more so. Consider the
   1. Ten years ago the Morris worm used weaknesses common to a number of
   different UNIX systems to take control of the computers and propagate
   itself. Today the same operating system is installed on 90% of all
   desktop computers. A single program could attack all these machines.
   2. Ten years ago the Internet belonged to an elite group of
   specialists and professionals. They understood their computers
   intimately and managed them closely. Today every home has a computer
   and a connection to the Internet. The average computer user can't tell
   "email" from "mpeg".
   3. Ten years ago the Internet was used primarily by scientists,
   researchers and academics. Today it is a major business conduit.
   Billions of dollars are moved over the Internet daily in various forms
   and most companies would simply not be able to ANY business without
   their IT computer systems.
   The widespread use of firewalls on computer systems does little to
   alleviate the risk. The threat here is not an attack from some hacker
   on the Internet, but a program run unwittingly on a computer already
   inside the protected network. The sections that follow show exactly
   just how feasible such a program is. While reading you will note the
   following frightening truths:
   - Just how relatively easy such a program is to write. Similar
   programs already exist and are widely known.
   - Just how easy such a program is to spread. The Internet is the
   perfect mass distribution system and its strength is also its
   - Just how easy such a program is to hide. The average user doesn't
   understand half the processes running on the system legitimately, let
   alone a program doing its utmost to conceal itself.
   - Just how hard such a program is to stop. The program can spread at
   the speed of light, take any form, hide itself and mutate with every
   new installation. Immeasurable damage could be done before it is
   eventually stopped.
   - Just how ugly such a program could be. This kind of software could
   bring entire sectors of industry to their knees. A well-planned
   infection with malicious intent would make the Morris Virus of '88
   look like a mild case of the flu.
   So what can be done to prevent this from happening? Not too much I'm
   afraid. Like the citizens of a volcanic island we need to be aware,
   stay alert and hope we spot the eruption early enough to prevent a
   disaster. Here are some precautions a company can take:
   1. Policy. The use of any unauthorized software should be prohibited.
   2. User education, user education, user education. Make your users
   aware of the dangers of running software from untrusted sources.
   3. Audits. Perform regular checks to see what's installed and running
   on your PCs.
   4. Operating systems. A strong operating system with proper multi-user
   support can minimize the damage done by a worm. Install Microsoft NT
   rather then Windows 95 or 98. Consider using other operating systems,
   like Line or BSD.
   5. Diversity. By mixing a number of operating systems one can minimize
   the amount of damage a virus or worm could do. This, however,
   introduces added complexity in the management of the all the different
   systems. Your call...
   6. Network security. Firewalls, file encryption, operating system
   security, etc. all make it more difficult for the would be worm. In
   particular virus scanners and HTML, FTP and SMTP content scanners help
   us weed out these kinds of threats. Consider stripping executable
   attachments and other active content completely.
   7. Host-based IDS. Intrusion detection systems may detect attacks
   either on the network or the computers themselves.
   8. Assume the worst. Plan for disasters with disaster recovery sites,
   backups, and business continuity plans. Test and practice with these
   As you read the description that follows, imagine the consequences of
   the release of such an animal and ask yourself how long it will be
   before we are again saying to ourselves "I guess it was bound to
   happen someday..."

   Part II: The bare bone basics
   This is the part of the document that will try to give a very basic
   understanding of the Trojan/virus. It is *suppose* to raise questions
   - these questions will be dealt with in the third section. It will
   only give the reader an idea of the dynamics of the virus. It the
   "press release" part of it.
   The Package
   The package is a single executable. The executable contains two parts,
   a normal functional program, and the Active Ingredient (AI). The
   normal program can be anything, but should be of interest for the
   Internet community. Examples could include: screensavers. auto playing
   AVI,MPEGs, flash movies, anti virus software, a new hacking tool or
   even an anti virus solution.
   The type of package could be customized to suit the way of
   Initial infection
   The package will be distributed on the Internet. This is done by
   "robots". These "robots" will upload the infected package to FTP
   servers, mass mail the package to users, repackage existing software
   to contain the AI, and DCC the package at random to users connected to
   IRC servers. The 'net should be flooded by infected programs, all
   different in size and apparent functionality.
   Conventional virus spreading methods can also be used. Initial
   infection could last in the order of 2 months.
   Upon first execution on client machine
   A user will obtain the package, and execute it.
   - Settle in.
   AI will rename itself to a non-suspect filename. The AI will take the
   necessary precautions to ensure that it will be executed every time
   the host is restarted.
   - Registration on server
   AI should wait until it detects the possibility to connect to a server
   on the Internet. When this happens, the AI should contact a predefined
   web server(s), uploading information to this site. It will save a file
   on this site containing detailed information of the host. Each AI will
   save the file with a unique name / serial number.
   Day to day activity of AI
   The AI will monitor activity, and if it detects traffic to the WWW, it
   will periodically check for instructions, posted on the predefined web
   server. These commands will be downloaded from the WWW, and executed
   on the host. The commands are to be found in a file that match the
   serial number that the AI registered in the initial contact. The AI
   will execute all commands found in the command file. If the AI cannot
   find the command file, it will fall back to a general command file. If
   it cannot find this file it will proceed with preprogrammed
   Spreading further
   Every host that is infected "reports" to one of the predefined
   servers. It will update a counter file. Every host that is infected
   with the initial spread will increment a number stored in the
   "infection count" file. When this file reach a critical mass, all AIs
   will begin secondary infection procedure:
   The AI will extract all email addresses contained within the address
   book of popular mailers (Outlook, Netscape, Eudora). The AI will start
   sending email with attachments to addresses harvested from the
   mailers. The attachment will be the package. The rate at which the AI
   will send mail can be controlled via command files.

   Part III: Inner workings
   This section will try to explain consideration that should be taken,
   technical specifications etc. It is aimed at people who understand the
   underlying technology. It is mainly aimed at programmers that know
   their stuff.
   Initial infection
   - Repackage bots
   Robots that will download executables from frequently visited sites
   (Tucows etc.), and repackage it to contain the package. These bots
   could be instructed to visit certain sites more frequent than others
   and to target certain files. These bots should have the ability the
   decompress distributions, repackage, and compress it as well.
   - DCCsend bot
   Robots on multiple IRC channels that will at random DCC the package to
   clients that are detected running the de facto standard Windows client
   (Mirc). Robots could be written with intelligence to con users to
   accept the DCC. Bots could be situated in "Warez" channels, spreading
   the repackaged commercial software.
   - FTP put bot
   Robots that will search the Internet for FTP servers with writable
   /pub and /incoming directories, and drop the package in those
   - Mail bot
   These bots will be not unlike the mass mailer programs, mailing the
   package to many individuals, posing as representatives from various
   organizations such as Hotmail, Geocities etc, with package as free
   "gift". This "gift" can be something like a new screensaver or HTML
   Note that all transport mechanism implies that the receiver is
   connected to the Internet on some way or another.
   The AI itself can be coded in different forms, so that there will be
   hundreds of different code signatures - this will make it difficult
   for anti virus vendors to develop a program that will search for code
   First contact
   When the user downloaded the package, he/she will execute it. The
   package will run the normal program, and the AI will also execute. The
   AI will install itself within the system, in such a way that it will
   always execute at startup. It will also disguise itself, by renaming
   itself to a non-suspect filename. This name will contain random
   letters, and should not be longer than 6 letters. At every restart, it
   will rename itself again (and modify the startup correctly). It could
   also modify the startup method -e.g. modifying the registry, or the
   The AI must be able to detect itself. This will ensure that the AI
   will not be installed every time the package is executed. This can be
   done by "marking" the host - it will not reveal where the AI is
   located, just that it has been infected. This "marking" will
   furthermore hamper the detection process later on, as this mark has to
   be removed before the host can be re-infected for lab purposes.
   The AI will proceed to determine if it is situated in an online
   environment (it can open a session to a machine on the Internet). If
   direct connection is not possible, it will determine if a proxy is
   present (registry), and use the proxy to connect to the Internet.
   Ideally, the AI will monitor network traffic with destination port 80,
   and determine the best path out - be that direct, or via a proxy. As
   this could involve installing a custom packet driver, the AI could
   monitor CPU load across different applications, and register an online
   situation when a browser (IE or Netscape) uses CPU load.
   The AI will only try to make a connection if it can safely determine
   that there is an already open connection to the 'net.
   The AI will contain a list of web servers that will be ready to accept
   the registration. For every AI, this list will contain random
   preferences. The AI will try to contact the web server with higher
   preference and send a report to the web server. The AI will send the
   report in the same way that browsers upload files to web servers. This
   list could typical contain up to 75 different locations.
   The initial report that the AI will send to the web server should
   -Self generated serial number
   -DNS name / IP
   -Firewalled Y/N
   -DHCP Y/N
   -Interface information (type, speed etc)
   -Platform (e.g. CPU, memory)
   -Browser support (Netscape / IE)
   -Mail support (Outlook, Eudora etc)
   -Registered programs
   -Real name
   -Email address
   Most of this information can be extracted from the registry. The AI
   will save this report in a file with the same name as the self
   generated serial number.
   The AI will try to download a file called "counter". This file will
   contain a number. It will increment this number, and upload the file,
   with the same filename. This file is thus a counter of the number of
   infected hosts that could reach the server(s). A "counter.lock" file
   can be used to ensure that two hosts do not access the file at the
   same time. A host that encounters a lock file will wait for a
   predefined period of time, and retry.
   It is *very* important that the virus is not discovered during the
   initial infection stage. Care should be take that the AI should under
   no circumstances reveal itself. It should rather end its life than
   reveal itself.
   Using different spreading mechanism, and different "host programs"
   should ensure that the AI could still reproduce. The packages will
   still contain the AI, and infection can spread along with it.
   The web servers
   These are the web servers where the AIs will register, and receive
   commands from. The web servers should all be public accessible web
   servers, where free webspace can be obtained - e.g. Geocities, Iname,
   Yahoo, to name a few. Multiple accounts should be registered on every
   Commands "dropped" for the AIs should be replicated between the
   servers. This means that all commands should be present on all
   servers, so that a certain AI can pick up commands from different
   servers (in the case that one server might be down, blocked, or
   administratively taken down).
   Replicating the data can be easily automated if the web server accepts
   FTP connections. If the sever does not, a PERL script can be build to
   interrogate web interfaces. As it is envisaged that this virus will be
   controlled by a group of people, a CRC checksum of all command files
   could be stored on the web server. Replication will only happen when
   CRC checksums between web servers does not match.
   To hamper detection, fake web servers can be included in the list. The
   AI will know that these sites does not contain a "drop zone", and will
   not attempt to retrieve commands or drop reports to it. The only
   purpose of these fake sites will be to cause confusion to anti virus
   vendors once the AI is detected.
   More information on the format and distribution of "dropped" commands
   will follow.
   Day to day activity of the AI
   When the AI detects that it can open a pipe to its web server of
   choice (as explained in the "First Contact" section), it will try to
   download a file called ".cmd.". Failing this, it will try to download
   a file named "general.cmd.". The first file is a file containing
   specific commands for the AI. The AI will internally keep count of
   command files that was received and executed and will only act on
   command files with counters larger than its saved counter. The second
   file is a file that is used for sending commands to be executed by all
   AIs. It is envisaged that this will be the default action, unless the
   controller have something specific in mind for a particular host.
   Both these files contain commands for the AI(s). After downloading the
   command file, the AI will execute the commands. If the AI acts on
   general commands it will increment a counter within a file called "".
   By doing this, the controller can see how many AIs have already
   executed the general command. Access to the command counter file can
   also be regulated by a lock file.
   An instruction set could contain the following commands:
   Remove the AI from memory, hard drives and IP stack.
   - mass_destruct()
   Erase all data, and reboot.
   - sync (time)
   Will command AI to periodical fetch new command file every "time"
   minute. The AI will still only contact the server when it can do so
   - batch begin, batch end
   All commands between batch begin and batch end will be executed as a
   batch job. Commands between "begin" and "end" should be chosen to
   redirect its output to files - see the example.
   -download (filename, local name)
   Downloads from web server, and save it as on the host's hard drive.
   - upload (local file,remote file)
   Uploads to web server, saving it as on the server.
   -update (local file)
   The AI will download and update itself. This could be useful when anti
   virus vendors start to realize the threat.
   -spread (count, rate)
   See section on secondary infection.
   -default begin (count), default end.
   Commands between default begin and default end will be executed if the
   AI cannot connect to servers in succession. (it will still only try to
   reach these servers when it detects that it is in an online
   The command set can obviously be expanded to include typical BO
   commands. An example of an AI command file could be:
   default begin 4
   default end
   sync 15
   batch begin
    dir c:\*.doc /s > c:\dirall.docs
     upload c:\dirall.docs 16643dhas13.all_docs
     del c:\dirall.docs
     download bo.exe c:\winnt\system32\taskbar.exe
   batch end
   spread 25000,5
   In this example the AI will erase all data on all drives when contact
   are lost with its top 4 servers. It will try to download command files
   every 15 minutes. It will upload a file called 16643dhas13.all_docs
   containing a listing of all .DOC files on the C: drive. It will
   download and install Back Orifice. The "spread" command will be
   discussed in the next section.
   Note the "END" at the end of the command file. If the AI cannot find
   "END" at the end of the command file, it must regards the command file
   as incomplete, and not execute any commands.
   With minimal effort, command file and reports can be encrypted.
   Encrypting the data should make it much more difficult to determine
   the mechanics of this virus. It will also help to ensure that anti
   virus vendors cannot send commands to the web servers to automatically
   erase the AI - such as "remove()".
   Combining encryption with the "default begin default end" command
   makes for a powerful concept. If the host is left on the 'net, it can
   be remotely controlled. If the sites that the AI is visiting is taken
   down, the host goes down with the AI. Anti virus vendors, security
   exports cannot talk to the AI, because communication is encrypted. The
   only way to be totaly safe is to disconnect the host permanently from
   the Internet.
   Secondary infection
   Every AI that registers will increment the "counter" file. The
   "spread" command act on the number contained in the "counter" file. If
   the counter exceeds , secondary infection procedures are executed at
   rate :
   The AI will "farm" email addresses from known mail clients - e.g.
   Outlook, Eudora and Netscape mail. It will extract mailer information
   (SMTP gateway, local email address owner etc.) from the registry, or
   directly from the mail client. The AI will disregard email addresses
   that is within the same domain as the host (that is - it will never
   send email to bob@bobby.com, if the local domain is bobby.com). This
   is to minimize the chance that the virus will be discovered by
   inter-human contact.
   The AI will start sending out packages (see Part II) to number of
   persons per day. Each message sent out will contain different subject
   lines - e.g. "check this out", "have a look", "for your information"
   etc. If the host contains less than email addresses, it will send it
   to the maximum number of recipients, given that they are not within
   the same domain. Note that via the command file, the rate of infection
   can be controlled.
   Let's assume that we have an initial install base of 10000 (which is
   pretty conservative). If we send a spread index of 7 the virus/Trojan
   will spread like this (assuming that the receiver is not yet
   1st iteration: 70,000
   2nd iteration: 490,000
   3rd iteration: 3,430,000
   4th iteration: 24,010,000
   If we assume that only 75% of receivers will have an OS that is
   susceptible for this virus/Trojan, and that only 50% of those will
   execute the attachment we are still looking at:
   1st iteration: 26,250
   2nd iteration: 68,906
   3rd iteration: 180,878
   4th iteration: 475,807
   at which time it will become difficult for the web servers to keep up.
   Keep in mind that the 4th iteration can be reached within hours, where
   after a mass_destruct() signal could possibly be issued.

   Part IV: Now think about this...
   Ask yourselves these questions:
   -Can this really be done? The answer is yes. Yes yes yes. It has been
   done to a much smaller extent. Think of Melissa, think of the '88
   worm. All of them were minor threats in comparison with this.
   -Why is this then different from what we have seen before?
   The major difference here is that this Trojan/virus will initiate
   communication. This means it can bypass firewalls, as firewalls are
   generally build to block incoming traffic, while allowing (some)
   outgoing traffic. This Trojan/virus will also have the ability to
   communicate with its controller (and even inter-virus communication is
   possible). The virus/Trojan is basically a streamlined, neatly
   packaged combination of all the bad things that are floating around
   the 'net today.
   -how much "smarter" can this thing be made?
   Much smarter. I am not the brightest person on earth, and I can come
   up with something like this. There are many of us out there, smarter,
   and brighter...and with the resources to create this monster.
   -what would be the implications of this?
   It could mean that the Internet would change, to such an extent that
   it will no longer be possible for companies to use it as a commercial
   tool. Back to the old days of vast open, purely academic networks.
   -Is the IT security world ready to handle such an onslaught?
   Not really. When this Trojan/virus reaches secondary infection phase,
   it can spread to millions of hosts within hours, and disconnection of
   hosts could lead to disaster. Remember that the rate at which the anti
   virus could spread is just as fast, or slower than that of the virus.
   -what would happen if this were wired into an existing stable
   reputable product?
   I rather not think of it...
   -How do we know that there is not something like this out there?
   We don't. Isn't it strange that our friends at cDc and L0pht haven't
   released something like this? Or have they? Hmmm?
   -why have you written this?
   I think that a monster the likes of this is about to be released. It
   will be only a question of time before a thing like this will happen.
   The only thing keeping it from happening is that the people with
   skills to write such an application is not willing to do so, since
   they, as experts, know the implications.
   Taking it one step further (the really nasty angle)
   Now lets see...what would happen if the AI was to encrypt *.DOC *.CPP,
   *.C files and store the keys on the web servers (encrypted under a
   masterkey)? I can see it now - "buy your code & documents back at our
   special discount price"...
   Last words & thanks
   And you thought all we do in South Africa is dodge the elephants... My
   sincere thanks goes out to Charl for his ideas and for writing part I.

      These pages are Copyright  1999 Hacker News Network All Rights

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net