In the early days of computing, attacks against computers consisted primarily of individuals exceeding their authority. Audit trails were generally used to track down the sources of these attacks. As defenses and attacks got more sophisticated, the Trojan horse became a popular tool of attack because the attacker could automate elements of the attack, plant those automated elements inside another program, and remain less exposed to the risks of being detected or tracked down. Audit trails could still be used to track down these attackers in many cases, but the task was harder because of the indirection and delays involved.
With the increase in sharing caused by the widespread use of personal computers and floppy disks, computer viruses became viable. Viruses had the advantage of a Trojan horse plus the advantage of unlimited indirection between the source of an attack and the target. Of the many thousands of identified viruses, only a handful of virus writers have been tracked down. The majority of widespread viruses tend to be randomly targeted, which means that they are not coordinated against a particular victim. More recently, the increase in networking and in the use of the Internet, combined with the ability to send documents containing complex programmed macros has led to electronic mail and the Internet becoming a dominant vector for the spread of computer viruses.
In 1994 and 1995, the World Wide Web arose as a prime source of on-line interaction between information services and their clients worldwide and as a new and rapidly growing advertising media. Along with any such technology development, comes new security risks. In the case of the World Wide Web in specific, and the Internet in general, the popularity of Web browsers led to dramatic changes in the way people used computers. In a modern Web browser, individuals who often cannot be reliably traced, load information from service providers who often cannot be reliably traced, and interpret that information, sometimes in a general purpose fashion.
As we have known for some time, in an environment with sharing, programming, and transitive information flow, computer viruses cannot be completely prevented. [Cohen84-2] This makes the evolving Internet an almost ideal viral computing environment [Cohen94] wherein service providers can use the network's computing power to perform highly parallel and widely distributed computations using the facilities of Web browsers all over the world. For example, a Web server could load Java (Java is a language designed by Sun Microsystems to run in Web browsers.) scripts into every visiting browser containing a Java interpreter to perform a brute force attack on a cryptographic key, to perform global searches of databases, or to perform a highly distributed weather forecast. As the reader can imagine, with the great power of highly distributed MIMD computation comes great potential for abuse. When such abuse involves distributed resources coordinated against a particular set of targets, we call it a DCA.
A DCA is informally defined as any attack that uses distributed resources in a coordinated fashion to achieve its goals. As a non-technical example, planting numerous news stories in different publications about slipping delivery dates in a competitors soon-to-be-released product would be a non-automated information-based DCA against a competitor. Since the stories come from distributed sources, they appear to be more credible, and it may be hard for the victim to track the source to an individual, even though one person might ultimately be responsible.
As a more automated example of a DCA, let's suppose that we know of a site victim.org that allows remote logins from over the Internet. If we tried to repeatedly guess passwords of users at victim.org from our site, we would almost certainly be tracked down very quickly by the normal audit trails kept by Unix-based Internet sites. Instead, we might use a programmed DCA in a Web page to launch a series of entry attempts where each attempt in sequence guesses a different (user, password) pair using a browser as the vector for the attempt.
DCA password guessing attack:=
{Display normal Web page;
cause browser to guess next-password for next-user-ID
and command victim.org to email (user-id, password)
to a usenet group via an anonymous email service.
}
Example: DCA password guessing attack
In this attack, instead of sending a copy of the same Web page to each browser, we send a slightly different result on each browser access, the difference being that a different user ID and password pair are tried. If the attempted entry fails, the command to send email is not successful. If the entry succeeds, then the victim sends email via an anonymous remailer to a usenet news group. The whole newsgroup, perhaps 100,000 recipients, gets a message containing something like (jjones ajs78sj). The message could also be marked and encrypted so as to obscure its meaning and make for easy processing by an automatic listener. As soon as the attack succeeds, further attempts against victim.org cease.
Now let's consider what this looks like from victim.org. Assuming that good audit trails and intrusion detection are in place, victim.org will see thousands of failed attempts at login over a fairly short time period. They may come from hundreds of different sites and come in no particular pattern. If victim.org cuts off user accounts after a fixed number of failed login attempts, many or all of the normal users will be unable to use the system, causing widespread and repeated denial of services, and ultimately leading to an alternative security plan. Otherwise, the attacker will eventually find an entry into the system, plant a Trojan horse to permit subsequent reentry, and thus win.
An extension to this attack that plants a more sophisticated Trojan horse on first entry defeats even many one-time authentication systems. Given enough tries, the attacker will eventually succeed in guessing a one-time password, plant the Trojan horse, and use the Trojan horse to originate further malicious actions.
Another example of a DCA is an attempt to exploit known security flaws in network services behind a firewall. In this example, a particular company is targeted using widely known historical sendmail vulnerabilities. Even with a modern firewall in place, this attack will succeed against internal machines because all of the behaviors that would be blocked by the firewall is performed by computers within the firewall.
DCA Sendmail Exploit Against a Company:=
{Display normal Web page;
If the-user is from victim-company
then
cause browser to try next-sendmail-attack
against next-company-IP-address
}
Example: DCA Sendmail Exploit Against a Company
In this example, only browsers within victim-company are exploited and the attack systematically tries every sendmail hole against every IP address within the victim's domain. The exploit code could then notify the attacker of success by a means similar to that in the password guessing attack, after which the browser-based attack would cease.
If detected, from inside the victim's domain, it would appear as if each of several company computers were trying to break into other inside computers. With good enough audit trails, and assuming the defender knows what to look for, a common thread might be found and evidence gathered.
In a widespread DCA attack, one way to conceal the nature of the attack it to eliminate repeatability. To do this, the attacker might create a database of the IP addresses that have been used in the attack and make certain that they aren't used for more than a finite number of attempts per unit time. For example:
A One-per-site Variation:=
{Display normal Web page;
If this-browser was-not-used in allowable-time-frame
then
cause browser to guess next-password for next-user-ID
etc.
}
Example: A One-per-site Variation
In this case, the attacker can force limits on how many times each browser is used to launch an attack. This makes it far harder to track down the source of the attack since fewer systems administrators at remote sites are likely to cooperate in the investigation if only a single attempt was made from their site. Furthermore, any audit detection scheme with a non-zero tolerance on attacks based on their source, will fail to detect this sort of coordinated attack.
In the Internet, a spam is loosely defined as the flooding of a system or, as in the case of a mailing list, systems with unwanted information. Spams in the form of unwanted and off-topic advertisements are regularly posted to newsgroups and mailing lists, but there are many other forms of spamming available in the Internet, and Internet sites rarely have adequate anti-spamming defenses.
A recent series of spams were perpetrated by a party or parties unknown who decided to subscribe the Whitehouse, a Time magazine editor, a New York Times reporter, two 'hacker' publications, MTV, and others to about 1,700 Internet mailing lists. Phillip Elmer-DeWitt, "I've Been Spammed!", Time Magazine, March 18, 1996, page 77. In this case, almost 5,000 new email messages per day were sent into the victim's mail boxes, flooding their systems till they ran out of disk space, and causing a lot of inconvenience. Unless you have an automated unsubscribe program or some other defense, it takes about a week to get unsubscribed. With an automated subscribe program, an attacker can easily subscribe several hundred people per day to each of these lists from a PC at a public library. To provide improved spam removal, we created a free Internet-based mail spam removal program wherein the victim specifies the site where the spam is originating (e.g., netcom.com) and we provide a command script that will automatically remove the user from all of the mailing lists originating from that site.
A different form of spam is the mailing of massive volumes of useless information to a recipient from a single source. For example, one person threatened to email us the complete sources to the GNU Unix system, an activity that would tie up our Internet link for hours and probably run us out of disk space if we didn't have a defense.
A spam of substantial magnitude is a DCA in that it is distributed, perhaps among almost two thousand widely known mailing lists, and coordinated in the sense that it is launched against a single individual - or perhaps another mailing list. A circular spam, where two mailing lists are subscribed to each other, creates an environment in which any mail to either list acts as a computer virus. For examples of this and for deeper understanding, see: [Cohen94-2]
There are some defenses against email-based spams using mailing lists as the vector:
At the core of this example and this issue is the concept of workload. Just as modern cryptography is oriented toward gaining a substantial and quantifiable workload advantage over an enemy cryptanalyst, much, if not all, of modern operating system and network protection is oriented toward finding ways to make the workload for defense smaller and driving up the workload for attack, or in other words, making protection more efficient.
Using the same techniques, it is also possible to launch non-coordinated attacks. For example, to increase the overall noise level of the Internet, the attacker could randomly attack sites or send useless email.
A One-per-site Variation:=
{Display normal Web page;
send email to postmaster@localhost
}
Example: A non-coordinated distributed attack
In this case, the attacker causes each browser to send mail to the host it is being run on. The net effect is one piece of mail sent to each user. Depending on how gullable the user is and how cleaver the mail is, this might be used for advertising, to fool users into doing something inappropriate, or for other similar purposes.
The key difference between this attack and a DCA is that the attacker in this case is not coordinating the activities toward a specific goal, and in this sense, this attack is similar to typical computer viruses. Just as typical viruses are random in their targets, an uncoordinated distributed attack is random, but just as distributed attacks can be coordinated, viruses can attack specific targets.
We have used Web browsers in several examples because of their widespread distribution and the way they automatically run host programs with untrusted arguments, but there are other methods for implementing a DCA. For example, if a widely used service such as the File Transfer Protocol (ftp) has a known defect, (FTP can be caused to use arbitrary ports and send network-specified information to those ports just as the gopher daemon can.) that defect can be exploited to use intermediate sites as springboards for a DCA.
ftp Defect DCA:=
{for each springboard in list-of-springboards
cause springboard to attack victim.org}
Example: A Defect-based DCA
}
In this case, as a prelude to DCA, a large number of sites are chosen for testing, each is tested for the presence of the defect that permits its use in the DCA. Once a list of such sites is known, each is exploited only once against each target system. By combining this attack with one of the Web attacks above, a DCA can be constructed to cause numerous Web browsers to each exploit one of a large number of defective systems as springboards. In this case, it would take the cooperation of administrators of at least three sites to track down the attacks, and each might have only a very small number of audit records reflecting the overall attack.
DCAs don't have to be launched by a single individual. Several examples of multiparty DCAs have occurred wherein a number of individuals combine forces to increase the impact of the attack. In the extreme, a large number of individuals can attack a site or a group of sites in order to achieve a collective goal. By acting in concert, they may be able to achieve far greater success than any of them could individually achieve, and they may make it harder to track the attack because the apparent multiplicity of sources masks the combined nature of their efforts.
Selective masking DCAs are another interesting approach. For example, a DCA could first check to see if the system accessing a Web page has a sendmail capability, and only attack through systems without sendmail ports. The chances of minimal administration are far greater when no mail is accepted by the vector machine and the workload on the defender is far higher if the machine acting as the vector refuses automated attempts at response. As a side benefit, when a typical multiuser machine attempts to access the Web page to see if the attack is present, the attack masks itself.
Probabilistic DCAs can be created to only attack under circumstances that are weighted to favor increased difficulty in tracking them down. For example, a DCA could have a low probability of transmitting attack code to vector machines in the attacking country and very high probabilities for machines in The Netherlands. (There is no reliable and automatic method today for determining where a particular computer in the Internet is actually located, however, most computers can be tracked to a country based on their host name or IP address.) This makes most attempts come through other countries, creating larger delays in administrative communications, making it harder for the defender to find someone willing to look for the attack (it won't appear to be from within their own country), introducing language barriers for cooperating defenders, and exploiting weaknesses in international law and law enforcement.
If an attacker has the ability to access a Domain Name Server (DNS), [RFC1011] the DNS can be used to further confuse tracking by creating fictions about the sources of attacks. A similar attack can be carried out by using IP address forgery to give the appearance of a DCA when the attack actually comes from a single source.
A final note is in order on the implication of DCAs on Information Warfare. (IW) Information Warfare has been previously defined [IW Mailing List] Dec 1995} as Conflict where [information or information technology] is the weapon, the target, the objective, or the method. Clearly, by this definition, DCAs are a form of IW. In a low-intensity DCA such as a simple mail spam, defense without substantial retaliation is feasible. As the intensity increases, it may become more and more difficult to defend without retaliation. For example, in the medium-intensity incident detailed later in this paper, there was repeated contacting of systems administrators at sites where attackers were using high-intensity techniques. In the case of the response to c2.org, an escalated response was used involving sending details of each vector and each attempt to the administrators at c2.org. It could be argued, although that was not the intent, that this was a form of IW in which retaliation was used to cause the attackers to back down.
Consider now, a situation in which two military groups of substantial size attack each others' information infrastructure in force in the guise of DCAs. This might be an all-out war scenario, involving civilian vectors to attack military and industrial targets. It might involve thousands of Web sites spread all over the world, including sites preconfigured by spies to launch based on predefined messages. It might not only impact the victims, but also bring down substantial portions of the information infrastructure. Unlike computer viruses, DCAs may be for more controllable, and their effects may be far easier to measure. They can be made hard to trace, but it is also easy to identify a particular source in order to demonstrate the capability to the enemy. In these senses and others, DCAs are nearly ideal IW weapons.