|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PROPOSAL] DDOS - Distributed DoS (1 candidate)
With only one candidate, this "cluster" shatters the previous record for smallest proposed cluster, which was 4. But it's an interesting candidate. Given all the attention that has been paid to distributed denial of service attacks from tools such as Trinoo, Tribe Flood Network, and stacheldraht, and the extensive damage that has been done, there has to be a vulnerability or exposure *somewhere*. It has been a challenge to couch this type of problem within CVE, which is the reason that no Trinoo-related candidates were proposed before today. On the one hand, how do you describe the problem in terms of a state within a computing system or systems? (See http://cve.mitre.org/About_CVE/About/definition.html for a refresher on the informal definitions that are being used). Secondly, where is the vulnerability - in the software? (and what software?) In the fundamental design of the Internet protocols? Or is the vulnerability that there are only finite resources available to handle high volumes of traffic? Or maybe there isn't a real "vulnerability" with DDOS - rather, each agent/slave/zombie had to have been compromised using *another* vulnerability, in order to act as valid users in such attacks. (This makes an assumption that the agents are not all owned by the attacker.) The candidate that is proposed below is at a higher level of abstraction than most other CVE candidates or entries. It's effectively a catch-all for Trinoo, TFN, and their siblings. Here's why. Informally within CVE, there is a category of "Malicious Presence" (MP) which deals with the presence of malicious software on a system, such as a Trojan Horse. See the following messages posted to the Board last summer: http://cve.mitre.org/Board_Sponsors/archives/msg00343.html http://cve.mitre.org/Board_Sponsors/archives/msg00344.html DDOS utilities can be described in MP terms - namely, a master or slave is running a DDOS utility. The problem with Malicious Presence entries is one of scale. Every Trojan Horse that's out there constitutes a malicious presence. Having a separate entry for each instance of MP would cause an explosion in the size of CVE, significantly reducing its maintainability as well as its use for most purposes. The MP category has a very high cardinality. When you think of Trinoo and other DDOS utilities, we may be able to identify all or most of them at this point in time. But I doubt we will be able to do so for long, as various hybrids and enhancements are introduced. Having a very high-level MP candidate seems "wrong" in that it "feels" like it's at a different level of abstraction than other CVE entries. The CD:HIGHCARD content decision suggests that in these cases, the level of abstraction should be fixed at a higher level of abstraction. While CD:HIGHCARD was voted for approval by the Board last summer, I believe that it needs further discussion before a final decision is made to use it. See the following for more discussion: http://cve.mitre.org/Board_Sponsors/archives/msg00258.html http://cve.mitre.org/Board_Sponsors/archives/msg00263.html http://cve.mitre.org/Board_Sponsors/archives/msg00271.html http://cve.mitre.org/Board_Sponsors/archives/msg00275.html http://cve.mitre.org/Board_Sponsors/archives/msg00380.html The last link includes a writeup on CD:HIGHCARD. Because of CD:HIGHCARD, the following candidate is proposed at a higher level of abstraction than most. But is the DDOS "class" described in this candidate sufficiently distinguished by other MP candidates? See CAN-1999-0660 and CAN-1999-0661, which are also affected by CD:HIGHCARD at: http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-1999-0660 http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-1999-0661 Is there enough of a difference between a DDOS master and slave to merit splitting this candidate? Given that the language to describe these types of entities is still evolving, what are the appropriate terms to use? - Steve Summary of votes to use (in ascending order of "severity") ---------------------------------------------------------- ACCEPT - voter accepts the candidate as proposed NOOP - voter has no opinion on the candidate MODIFY - voter wants to change some MINOR detail (e.g. reference/description) REVIEWING - voter is reviewing/researching the candidate, or needs more info RECAST - candidate must be significantly modified, e.g. split or merged REJECT - candidate is "not a vulnerability", or a duplicate, etc. 1) Please write your vote on the line that starts with "VOTE: ". If you want to add comments or details, add them to lines after the VOTE: line. 2) If you see any missing references, please mention them so that they can be included. References help greatly during mapping. 3) Note that a "MODIFY" is treated as an "ACCEPT" when counting votes. So if you don't have sufficient information for a candidate but you don't want to NOOP, use a REVIEWING. ********** NOTE ********** NOTE ********** NOTE ********** NOTE ********** Please keep in mind that your vote and comments will be recorded and publicly viewable in the mailing list archives or in other formats. ================================= Candidate: CAN-2000-0138 Published: Final-Decision: Interim-Decision: Modified: Proposed: 20000215 Assigned: 20000209 Category: MP Reference: CERT:CA-2000-01 Reference: CERT:IN-99-04 Reference: SUN:00193 Reference: ISS:20000209 Denial of Service Attack using the TFN2K and Stacheldraht programs Reference: BUGTRAQ:19991206 Analysis of trin00 Reference: BUGTRAQ:19991206 Analysis of Tribe Flood Network Reference: BUGTRAQ:19991229 Analysis of "stacheldraht" Reference: BUGTRAQ:20000211 DDOS Attack Mitigation Reference: BUGTRAQ:20000211 TFN2K - An Analysis Reference: BUGTRAQ:20000211 A DDOS proposal. A system has a distributed denial of service (DDOS) attack master or agent installed, such as Trinoo, Tribal Flood Network (TFN), Tribal Flood Network 2000 (TFN2K), or stacheldraht. VOTE:
|
||||
