CVE-2000-0138

• BUGTRAQ:19991206 Analysis of Tribe Flood Network
• BUGTRAQ:19991206 Analysis of trin00
• BUGTRAQ:19991229 Analysis of "stacheldraht"
• BUGTRAQ:20000211 A DDOS proposal.
• BUGTRAQ:20000211 DDOS Attack Mitigation
• BUGTRAQ:20000211 TFN2K - An Analysis
• BUGTRAQ:20000429 Source code to mstream, a DDoS tool
• URL:http://marc.info/?l=bugtraq&m=95715370208598&w=2
• BUGTRAQ:20000501 Re: Source code to mstream, a DDoS tool
• URL:http://marc.info/?l=bugtraq&m=95722093124322&w=2
• CERT:CA-2000-01
• CERT:IN-99-04
• ISS:20000209 Denial of Service Attack using the TFN2K and Stacheldraht programs
• ISS:20000502 "mstream" Distributed Denial of Service Tool
• URL:http://xforce.iss.net/alerts/advise48.php3 (Obsolete source - check if archived by the Wayback Machine)
• SUN:00193

 Christey> **********************************************************
   THIS CANDIDATE HAS GENERATED A LONG THREAD.  SEE THE 
   EDITORIAL BOARD ARCHIVES FOR DETAILS, BEGINNING AT
   
   http://cve.mitre.org/Board_Sponsors/archives/msg00590.html
   
   **********************************************************
 Ziese>  
   I suggest we I'd like to suggest that we consider not tying
   specifically to a DDOS tool.  Instead, since we are at at higher
   abstraction level, that we make the class include those master/slave
   tool combinations that are used for malicious purposes (i.e. DDOS,
   data exfiltration, or whatever the appropriate classes of effect are).
   
   My concern is that (1) we treat all distributed attacks at the same
   abstract level; not just the DDOS ones.  Second, if it is at a higher
   abstraction level then it seems right to unlimit it (by including
   master/slave combinations in general; not just the DDOS asect).
 Meunier> I think that trinoo etc... are very similar to smurf attacks
   (CVE-1999-0513 ) in the sense that a third party allows itself to be
   used.  Also, there is an  obvious solution that can only be done by
   that third party.
   
   As for the CVE entry, I am considering whether the common entry point
   could be reduced to "egress filtering has not been implemented or has
   been disabled, allowing the sending of spoofed IP packets".
   Incidentally, this would prevent the use of decoys in port scans,
   etc...  This single CVE entry would be very powerful. We could use
   the dot notation to list the DDoS tools and attacks that rely on the
   absence of egress filtering based on the argument that if you have
   egress filtering, nobody will bother to put or use DDoS tools on your
   computers.
   
   The weakness of this is that one could in theory still use DDoS tools
   even if you have egress filtering -- only they will be one shot guns,
   almost completely eliminating their appeal and effectiveness.  One
   use, and they will be blocked, tracked down and destroyed
   efficiently.
   
   Pascal
   
   P.S.: I am attracted by the idea of starting an internet (fire)wall
   of shame, for people who haven't implemented egress filtering.  It
   worked pretty well against sites allowing themselves to be used for
   smurf attacks (http://www.powertech.no/smurf/).  Why not use the same
   strategy for egress filtering?  Of course it's hard to know who is
   the source of IP spoofed  packets.  However the consistent detection
   of crud originating from a server is a sure sign that they haven't
   implemented egress filtering.  For example (my first candidate to
   this wall of shame), this weekend the Linux suse ftp server sent many
   packets with an illegal ip address as source, one reserved for local
   area networks, upon making an ftp connection (it may still be doing
   it, I haven't checked since -- the suse ftp admin mentioned that they
   were aware of it).  It was easy to figure out it was them by
   repeating the ftp connections and observing the 100% reproducibility
   and time correlation of the extraneous packets.  In addition, the
   suse servers kept sending me crud for *hours* after a failed attempt
   to download their PPC beta.
   
   The cost of egress filtering is easily justified.  The argument is
   similar to those relating to pollution, excepted that people don't
   try to break into your car if you have removed the catalytic
   converter.
 Bishop> I need to think about the exact meaning of MP. I suspect I
   will agree with the classification, on an operational basis
   (meaning I may want to revisit it), but I want to think on it
   some more.
 Blake> I don't agree with Pascal that this is a filtering problem analogous to
   smurf.  Rootkit is a better analogy.  The DDoS software doesn't exploit
   any unique vulnerability directly.  It's presence is entirely predicated
   on the existence of at least one other, easily exploited vulnerability.
  > From the perspective of the system owner, this is just one of several
   backdoors that could be installed.  Seems to me that the presence of a
   known backdoor package should be considered a vulnerability (or at least
   an exposure).
   
   I'm really torn on whether or not to split them out, though.  My
   inclination is to group master and slave by package; i.e., trinoo
   master/slave, tfn master/slave, etc.
   
 Wall>  
   Just to be consistent, you may add Trinoo (trin00) and does it matter
   if it is Tribal or Tribe?  The original internal c program says Tribe Flood
   Network.
 Meunier> What they have in common is the use of an amplification mechanism.
   They are broadcasting (multicasting) to a (virtual private) network,
   which then amplifies the messages.  In both cases, the amplification
   is done by the third party victim hosts.  The difference is just that
   the network is virtual instead of physical.
   
   
   Scott, you are assuming that the people who have the tools installed
   are unwilling.  Let's say theoretically speaking that there is an
   underground hacker group (or student association) who is hooked up to
   DSL lines (like in university residences) and who thinks that it
   would be "cool" to form an "army".  How about a popular civil
   movement protesting something, like the WTO last summer?  I think
   some people would voluntarily "enlist" their computers in a cause
   that would use DDoS attacks.  The rootkit analogy does not hold, yet
   the DDoS attacks could be just as effective.  However, if the
   university or ISPs implemented egress filtering, the DDoS attacks
   could be easily stopped because the people could be held accountable.
   The crux of the matter is the anonymity provided by IP spoofing.
   
   You are correct that in most cases, having a DDoS tool installed on
   your system is an exposure like rootkit.  Maybe that deserves a CVE
   entry.  However, I think that does not capture the nature of the
   DDoS, and that an entry about egress filtering is of utmost
   importance because it patches a fundamental vulnerability of IPv4.
 Blake> Excellent response, Pascal, thanks.  I hadn't thought of people
   volunteering, but that's certainly a plausible scenario.  Part of my
   motivation/thinking was a desire to stay away from making this into only
   yet another use for spoofed IP packets.  I wholeheartedly agree that
   egress filtering essential, but am reluctant to single out the recent DDoS
   events as the reason for it.
   
   I'd prefer to split out egress filtering as a seperate CVE entry (on the
   theory that not using egress filtering constitutes an exposure -- at least
   to liability), rather than tying it to these entries.
 Levy> I agree with Scott for no other reason that there needs to be a CVE
   ID so that IDS systems can report this things.
   
   Are we going to start handing out CVE ids for low level design faults?
   E.g. lack of encryption at the IPv4 packet level? lack of resource
   allocation protocols? the used of DES instead of Triple DES? etc
 Shostack> Both excellent points, however, I'd like to add that even if people
   volunteer to host the tools, Trinoo and company allow the controlling
   attacker to hide activities, which counts as an exposure under
   http://cve.mitre.org/About_CVE/About/definition.html
 Cole> Even with all of the debate i accept this one.
 Christey> With respect to inclusion of design flaws in CVE, review
   http://cve.mitre.org/Board_Sponsors/archives/msg00602.html
   
   Other design flaws that have already been added to CVE
   include Smurf (CVE-1999-0513), Fraggle (CVE-1999-0514)
   and TCP sequence number prediction (CVE-1999-0077), although
   this last one may need to be RECAST to a lower level of
   abstraction.
 CHANGE> [Meunier changed vote from REVIEWING to RECAST]
 Meunier> In the sense that this is like a rootkit, then it is a
   duplicate of CVE-1999-0660, "A hacker utility or Trojan Horse is
   installed on a system, e.g. NetBus, Back Orifice, Rootkit, etc..."
   
   It should be recast as CVE-1999-0660.1 DDoS tools
   Other dot notations could indicate different effects of the tools.
 Dik> There doesn't seem to be much to add to the
   discussion.
 Baker> Concur that this is a hacker utility, and should be recast and merged with other backdoor programs that allow a hacker to control the activities of the system.