Message-ID: <200305121704.h4CH4rnq081634@mailserver3.hushmail.com>
Date: Mon, 12 May 2003 10:04:52 -0700
From: "Vision Through Sound" <echolation@...hmail.com>
To: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com,
	vulnwatch@...nwatch.org
Subject: [VulnDiscuss] Paper: Spamdoors



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release:  May 12, 2003

Spamdoors:  Using Spam As A Vector Of Back Door Communication
by Vision Through Sound <echolation@...hmail.com>

I.	Introduction
II.	Back Doors
III.	Spam
IV.	Combining The Two
V.	Program Design
VI.	Prevention

I.	Introduction

This paper discusses the use of two existing problems, spam and back
doors.  Both problems have existed for some period, though the combination
of these two problems has not been immediately discussed.  This paper
documents a theoretical combination of two technologies, documenting
how these technologies could be used for nefarious purposes.

II.	Back Doors

Back door programs are nothing new.  Good back door programs provide
a stealthy means of unauthorized remote access to systems that have been
compromised.  A good back door program also provides a means of communication
that is obscured from the watchful eye of intrusion detection systems,
 and easily circumvents firewall systems.

The majority of these programs require a combination of factors.  One
such factor is poor security practices, such as the habitual assignment
of administrative privileges to regular users.  Inadequate software,
such as a lack of anti-virus, or anti-virus software that is poorly maintained
and not current on signatures, also plays a role.  When combined with
insecure practices such as the execution of programs from untrusted sources
and infrequent patching of systems, an attacker can very easily gain
access to the private systems of home and business users alike.

There are several good papers available on back door programs.  For more
information on back door programs, see available papers from your favorite
anti-virus vendor.

III.	Spam

Anybody that has used the Internet in the last ten years is familiar
with spam.  The fight against preventing spam is an arms race, with anti-
spam and spammers moving pawns in a never-ending game of chess.  With
each move by one side in the spam war, a counter-move of equal or greater
strategy is made from the opposing side.

Several methods are commonly employed by the anti-spam community with
questionable results and effects.  Of these, the most useful postures
seem to be the use of blacklists and Bayesian filtering.  These two types
of spam filtering work on different premises and in spite of their well
thought-out methodologies, are not one-hundred percent effective.

Blacklists are typically the result of subjective analysis of spam by
mail users.  When spam is received by a user, the user sends this mail
to a spam collection facility which analyzes it, then adds the origin
system to the list of hosts that are black holed.  The black hole list
is typically created using the DNS information or IP address of the mail
server, and disseminated to all systems that receive the blacklist.

Bayesian filters are designed to mathematically evaluate email to determine
the probability of it being spam.  Bayesian filters are built off of
the theories of probability first employed by Reverend Thomas Bayes,
an English Presbyterian minister and mathematician who was responsible
for the Bayes Theorem.  The principle of the theorem is to take existing
knowledge, and from the existing knowledge evaluate whether or not we
should change our beliefs in light of new information.  This theorem
is applied to email to determine whether or not the contents of the email
is in fact spam, based on words and content that is commonly associated
with spam.

IV.	Combining The Two

Until this point, spam and back doors posed separate problems independent
of one another.  However, a point comes where two separate technologies
merge to provide a new, enhanced, improved method of providing the resource
that previously existing technologies only marginally filled.  This is
the case of merging spam with back door programs.

As previously mentioned, back door programs require some means of remote
communication that allows an attacker to carry out instructions through
the back door, and thus through the compromised system.  Communicating
with the back door program presents a different set of obstacles that
must be overcome.  These obstacles are creating sufficiently undetectable
remote communication, and covert remote communication that cannot be
easily blocked.

Remotely communicating with a back door is, at best, easily detectable.
 Primitive back door programs typically use the metaphoric equivalent
of signal flares and marching bands when client-server communications
occur.  Communication is often clear-text, and using an easily identified
protocol and unauthorized ports, all of which are easily detected by
even the most basic of intrusion detection systems.  More advanced back
doors communicate via encrypted sessions, but are still at risk of easy
detection due to the oddity of encrypted traffic flying around the network
between a remote host and local system on ports that are not known to
communicate through such means.

Even in the event of a sound means of covert communication, it is often
difficult, if not impossible, to keep communication with the compromised
host.  This is due to the fact that most means of remote communication
with back door software can be easily tracked and blocked with sufficient
ingress and egress filtering at network boundaries, and stateful traffic
inspection policies implemented at network firewalls.  Covert communication
channels such as those implemented by the first generation of tools such
as Loki, which used a protocol to obscure detection and circumvent traffic
filtering, are now obsolete as roughly all such channels are filtered,
 analyzed by intrusion detection systems, and blocked due to potential
security implications.

Creating a back door system that uses spam for covert communication is
ideal for a number of reasons.  First, the spam problem has reached epidemic
proportions.  Estimates place spam in the range of forty to sixty percent
of all email traffic handled by enterprise networks.  The sheer volume
makes it possible to take advantage of the vector to pass traffic that
appears to be no more suspicious in nature than the norm.

Back door communication via spam also has the benefit of being difficult
to detect because of the means of delivery.  By using keyword or phrase-
based communication with the back door system, the email appears to be
ordinary spam.  This text can be varied by attacker specification.  This
makes detection via standard intrusion detection methods virtually impossible.
 When network anomaly detection matures to the point of being able to
identify abnormal network activity, this means of communication will
still be capable of subverting detection due to the nature of normal
email transactions.

Spam also has the added benefit of being difficult to block because it
uses a well-established mode of transport and widely accepted protocol.
 As previously stated, no means of blocking spam is 100% accurate or
effective.  The only means of completely mitigating the risk of back
door communication through spam would be to prohibit email entirely.

V.	Program Design

a.	Communications Vector

Creating a back door program that uses spam as a communication channel
requires a few deviations from standard back doors to create a successful,
 working model.  The design can be broken into two top-level categories,
 which are communications monitoring, and communications protocol.  Communications
monitoring can be thought of on both the client and server mail systems
as separate topics.  The separation exists because of the different requirements
of each of these types of systems.

One key component of the back door common to all back doors is the communications
monitoring system.  There are a few different methods communications
could be monitored.  Of them, there are the ideas of using a process
that monitors the network interface for incoming and outgoing SMTP requests.
 This approach has the benefit of being able to see email as it arrives
to the system, and being applicable to both the client and server environment.
 This design also circumvents the need to create code designed to monitor
specific mail implementations at a higher level than RFC-specified protocol.
 However, it also has the drawback of being extremely resource-intensive.

The next design of monitoring devised is the parasitic process-type;
a process that attaches to and monitors mail transport and mail user
agents.  This design has the benefit of being able to piggy-back on other
mail software processes when started.  The code requirements would be
much more esoteric, and while having the benefit of again being able
to monitor mail as it arrives, would sacrifice portability across platforms.
 Additionally, coding requirements would be much more intensive, as well
as error-prone.

The choice design of communications monitoring would seem to be mail
file monitoring.  This design has the lowest common denominator among
clients and servers alike, as the majority of email stored on clients
and servers is in one of a few common formats.  Additionally, it requires
far less in terms of resources to monitor plain text files.  The drawback
is that it does not offer the ability to monitor email at one point,
such as a network interface.  Also, it does not offer the simplicity
of monitoring one protocol such as SMTP, which can be applied across
multiple platforms with the maximum of portability.

In the client configuration, UNIX systems store mail in a few common
formats.  Two of the more frequently used formats are mbox, or mail box
format, and mail directory format, or maildir.  The mbox mail spool format
is also used by clients on other platforms, such as Netscape on Microsoft
Windows.  Outlook uses the Personal Folders (pst) format.

In the server configuration, again we see the same type of spooling.
 The same types of spooling exist in most UNIX mail servers, such as
sendmail, postfix, and exim.  The qmail mail transport agent differs
in that is capable of using maildir, though it can also be configured
to use mbox.  These formats are common with mail transport agents on
the Microsoft Windows platform, also.

As we can see, the method selected is a convergence of common denominators
across platforms and architectures.

b.	Communications Protocol

Communication between the client and server through spam can be tricky.
 Communication between these two hosts is generally blind, which is to
say a one-way communication protocol.  Commands sent to the back door
do not generate a response to notify the administrator of successful
receipt, though it may be possible to create a delayed confirmation mechanism
through a means such as file downloads.  However, this means should not
be used, or at least not used frequently, as it is likely to be noticed
as a network anomaly an arouse suspicion.

This policy, though it creates a communication vacuum, is also best for
maintaining the back door.  Confirmation of command receipt is information
leakage that could easily be identified by intrusion detection, or other
monitoring software.  This could lead to discovery of the back door.

c.	Basic Command Functionality

Basic command functionality of the back door program is of importance
of a magnitude equal to or greater than that of the stealth of communication.
 The command set should be simple to provide the most ease of use.  However,
 if the back door is to be of any use, it must be robust enough to provide
a set of commands, or the ability to add command sets that can give the
remote attacker the ability to control the back door and perform desired
activities.

The basic command set should consist minimally of four commands:

1. Download file.
2. Reconfigure.
3. Execute command.
4. Shut down.

The file download feature allows the program to gain access to modules
through the specified download protocol.  This protocol can be configured
on the back door side, but is probably best if configured using HTTP.
 This may allow delivery of executable module code through a vector such
as an image using a concealment tactic such as steganography, and making
the retrieval of the module code appear to be no more anomalous than
a valid web request.

The reconfigure command reloads the back door configuration.  The configuration
is contained in modular code, with each module added giving additional
configuration information to the back door program.  The reconfigure
reloads the modules into the running back door program, and creates a
list of the available commands internally.

The command execution functionality is relatively straightforward.  As
mentioned previously, expanded command functionality is made possible
by modules inserted into the running program.  Commands executed through
the back door are carried out by first an execute instruction, then an
argument to the execution instruction that invokes the desired functionality
within the program.  The functionality is contained within the loaded
command modules.

The shut down command is self-explanatory.  More information about the
interpretation of commands and the method through which commands are
interpreted is discussed in section 5d.

c.	Authentication

The ability of the program to successfully interpret spam with the minimum
of false command interpretation is imperative.  False command interpretation
could lead not only to the back door program performing an unintended
action on behalf of another spam sender, but could lead to the exposure
of the back door program.  At the same time, embedding commands in spam
for the back door program to carry out requires stealth in application.

The possibility of false positive requires that a back door using spam
implement some means of rudimentary authentication protocol.  To design
such a system, we can use two points of reference to create the schema.
 These points of reference are the United States Military challenge and
pass phrasing, and Nigerian 419 scam emails.

When the military goes to the field, sentries are placed at the borders
of the encampment to filter traffic.  These checkpoints are typically
manned by well-armed soldiers, capable of raining down hell on unwelcome
guests.  Additionally, these soldiers typically are in communication
with the Battle Operations Center, or BOC, through either field telephone
or radio.  Upon approaching one of these checkpoints, the challenge phrase
and pass phrase are used.  However, these are in the form of a sentence.

For example, suppose that the challenge word is "Carolina," and the password
is "Panthers."  Upon approaching a sentry, the sentry would issue a challenge
phrase such as "Boy, the Carolina mosquitoes and sun make the swamp unbearable."
 Upon hearing the challenge phrase, the approaching person with knowledge
of the challenge phrase would recognize this individual as a valid sentry,
 and would issue a phrase with the password such as, "Yeah, and I think
the Panthers in Charlotte should move to the state capitol Raleigh."
 This response will tell the sentry that this person knows the password,
 and is permitted to pass.

Nigerian 419 scam email is a common form of spam.  The frequency of receipt
makes these emails a perfect means of communication because of the structure,
 and though communication could be carried out using a different type
of email construction, we will use this type as an example for the rest
of this paper.  Each email typically contains the same content, such
as an apology for emailing one out of the clear blue, an introduction
to who the person is, why the person is emailing you, who their dead
rich relative is, some promise of a percentage of some astronomical amount
of money that belonged to this dead relative, and steps that the recipient
of the email must take to claim their stake in this enticing opportunity.

Below is an example of such a spam:

Date: Thu, 08 May 2003 14:47:50 +0200
From: BASHER MOBUTU <bashermobutu0lame.com@...e.domain>
Reply-To: bashermobutu00@...e.domain
Subject: ASSISTANCE NEEDED

Dear Sir,
You may be surprise to receive this email since you do not know me.
I am the son of the late president of Democratic Republic Of Zaire, President
Mobutu Sese Seko, ( now The Republic of Congo, under the leadership of
the son of Mr. Laurent Kabila).  I presume you are aware there is a financial
dispute between my family ( THEMOBUTUS ) and the present civilian Government.
This is based on what they believe as bad and corrupt governance on my
late father's part. May his soul rest in perfect peace. As you might
have heard how a lot of my father's bank account in Switzerland and North
America have been frozen. Following the above named reasons, I am soliciting
for your humble and confidential assistance to take custody of THIRTY
Million United States Dollars ( US$30,000,000.00 ), also to front for
me in the areas of business you desire profitable.

These funds have secretly been deposited into a confidential Security
Company, where it can easily be withdrawn or paid to a recommended beneficiary.
The funds will be released to you by the Security Company, based on my
recommendations, on that note, you will be presented as my partner who
will be fronting for me and my family in any subsequent ventures. Myself
and my mother have decided to give 20% to you if you are able to help
us claim this consignment. We have also decided to give you any money
spent on phone calls or traveling expenses in the course of this transaction
at the end of the transaction. Please, I need your entire support and
co-operation for the success of this transaction, your utmost confidentiality
and secrecy is highly required, due to my family's present predicament.

I sincerely will appreciate your willingness to assist us as soon as
possible. I am presently in the refugee camp here in the Netherlands
under the united nations refugee camp in Netherlands.All correspondence
must be by the email address bashermobutu@...e.domain I will give you
my Telephone number where you can contact me when I hear from you.for
more information on how we can proceed in this transaction. Please indicate
your interest by sending your telephone and fax number. I sincerely will
appreciate your acknowledgement as soon as possible.

Warmest regards,
Basher Mobutu Sese-Seko

Using a modified form of challenge word-password authentication, we could
present our authentication credentials in the email.  The spam obviously
must be readable and comprehendible to not arouse the suspicion of the
recipient or any parties monitoring communication between the sender
and receiver.

The easiest method for embedding authentication information is to design
the back door to parse the same location of incoming email for authentication
information.  As mentioned before in our summary of Nigerian 419 scam
email, this is usually the second thing mentioned in the spam.  Therefore,
 we could design our back door to search the second sentence, and compare
the contents of the text against an authentication database created for
the back door.

Authentication information could be stored in the form of MD5 hash groups
stored in an additional module.  A minimum of two hashes could be used,
 with three or more hashes grouped together to offer enhanced security.
 Storing hashes in this format makes it easy to remotely change authentication
information, as the process could simply store them in the new module.

When an incoming email is detected, the back door could simply parse
the expected location for each hash individually, and upon successful
discovery of all required hashes for authentication, determine that the
spam is intended to convey communication for the back door.  Additionally,
 there should be multiple challenge word and password pairs used in the
event that string-based blocking is performed on the client side.  A
long list of authentication credentials using several names and keyword
sets to perform authentication with the back door program prevents the
emails from presenting the same authentication credentials consistently.
 This acts as a stealthy means of authentication, and is less likely
to raise the suspicion of users of the compromised system.

d.	Command Interpretation

Spam that has been verified by the back door next must use some means
of command interpretation.  The command interpretation engine first should
be capable of being configured to search incoming spam for commands dynamically.
 Handling of command interpretation could be implemented modularly, allowing
the changing of command structure and interpretation to be reconfigured
on the fly.

Command interpretation should consist of parsing a section of the email
for commands based on hashes.  These hashes are saved in modules loaded
by the back door, and each hash corresponds to a command designed by
the administrator to be carried out by the back door.

For example, the MD5 hash of a sentence such as the following:

"Myself and my mother have decided to give 20% to you if you are able
to help us claim this consignment."

equates to 1dbfee3f4e008dffe0e1fe5e3da6ae86.  Upon parsing this hash
in the mail, this would instruct the back door to perform the command
associated with this hash.

This functionality could also be extended to take portions of the email
as arguments to the commands.  For example, in the situation of desiring
to download a module that provides additional functionality or configuration
to the code, the basic back door command functionality would be able
to recognize the hash of a sentence as a command, and parse the next
sentence for the Internet Address from which to download the new data.
 This data could come in the form of executable code contained within
an image on a web page, which the back door downloads in what looks like
a legitimate request for web resources.

VI.	Prevention

At this point in time, there is little that can be done to prevent spam.
 However, the pre-requisite of placing the back door still exists, which
can, to some extent, be prevented.

Preventing back door placement involves adhering to security industry
best practices.  Some measures that may be beneficial in preventing these
types of back doors from being successfully placed include:

1. Apply security patches to systems in a timely manner.
2. Design networks with security in mind, using DMZs and private networks
with sufficiently strict firewall rule policies.
3. Use network intrusion detection to identify unusual and potentially
dangerous network traffic.
4. Use proxy systems including mail and web gateways that prevent unauthorized
file types from entering networks.
5. Conduct regular security training with staff.

Thank you to all who offered their input on this paper:  you know who
you are.  Working proof of concept code will not be released; don't even
bother asking.

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.2 (Java)
Note: This signature can be verified at https://www.hushtools.com/verify

wl8EARECAB8FAj6/1DQYHGVjaG9sYXRpb25AaHVzaG1haWwuY29tAAoJEKkDTWJ4ilQt
V6wAn1fjRYgZuNb4kbrXMrxMTVRTIQeyAKCl15trDhlt45mrMA+Q9dQoRMbc1Q==
=9otL
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Big $$$ to be made with the HushMail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Powered by blists - more mailing lists