-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Release: May 12, 2003 Spamdoors: Using Spam As A Vector Of Back Door Communication by Vision Through Sound <echolationat_private> 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.comat_private> Reply-To: bashermobutu00at_private 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 bashermobutuat_private 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Mon May 12 2003 - 11:31:08 PDT