[18505] in bugtraq
Re: New DDoS?
daemon@ATHENA.MIT.EDU (Mailing List)
Tue Jan 9 18:19:58 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <019b01c07a69$289ff420$05c1fea9@zentekgroup>
Date: Wed, 10 Jan 2001 02:22:43 +0800
Reply-To: Mailing List <maillist@jasonlim.com>
From: Mailing List <maillist@jasonlim.com>
X-To: nealk <nealk@verinet.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Interesting... but all the big ad agencies like Doubleclick screen the ads
that they allow into their system.
If the person that was authorizing ads had his browser hang when they went
to view a particular ad, don't you think they would be suspicious?
Of course, this does not solve the problem, but the situation you described
probably wouldn't happen in real life.
The situation I can imagine in which this MIGHT happen is with the
LinkExchanges, but 99.999% of them only allow gif/jpg pictures, and not
flash or any other formats.
Another situation I can see is with the email programs. Many of them open up
in the INBOX folder. Now, if a person receives an email formatted with html
and has a 'bad' flash file in it, the person's email would crash instantly,
denying access to any mail functions. The person could theoritically press
delete before the flash file crashes the email program, but as you can see
this would already deny access at least a few times till the person catches
on.
Any ideas?
Jason.
----- Original Message -----
From: "nealk" <nealk@VERINET.COM>
To: <BUGTRAQ@SECURITYFOCUS.COM>
Sent: Wednesday, 10 January, 2001 12:07 AM
Subject: New DDoS?
> I think I have stumbled across a new category of distributed denial
> of service (DDoS). (If this is old news, I'm sure I'll be corrected;
> it's new to me.)
>
> Traditional DDoS have the follow flow:
> - A host (or few hosts) controls a large number of clients.
> - The clients are directed by the host to attack a single site/server.
> The attack can either be network or service oriented.
>
>
> Alternate (New) DDoS model:
> - Server 'A' directly prevents all clients from accessing server 'B'.
>
>
> Here's an example of how it could work:
> I recently posted about a Flash plugin risk that can crash or hang a
browser.
>
> Let's say that someone placed a corrupt Flash (SWF) file on a web server.
> All clients that access the web server and that view the Flash file
> (about 90% of all browsers can, so this is a good assumption) will
> have their browsers crash or hang.
>
> This is a DoS against the site, but it attacks the clients rather than
> the server.
>
> Now, let's take it one step further.
> Doubleclick, adtegrity.spinbox.net, and Akamai are linked by most
> large web sites. (Amazon, eBay, AltaVista, etc.)
> I have observed these sites returning banner ads written as jpeg,
> gif, and SWF.
> Let's say that one of the SWF files is corrupted.
> The single ad site can effectively deny all client access to the host
> site by crashing/hanging all client browsers.
>
> Server 'A' (the ad site) can directly prevent all clients from
> accessing server 'B' (the host web site).
>
> What's worse: This is more difficult to identify since local testing
> on the local server may not identify why the clients are crashing.
> The local server does not know what information was sent to the clients
> by the ad sites.
>
> In this example, I used ad sites and SWF files. It can be done with
> any third-party site (remember all the Web Bugs discussions?).
> Although SWF can do it today, I'm sure there will be more technologies
> that can do it tomorrow.
>
>
> Question: How can sites protect themselves from this?
> (I mean: Aside from the obvious, "don't link to ad sites.")
>
>
> Finally, I'm sure there are some script kiddies just dying to be "the
> first one to pull this off". Please don't. Accidents happen all by
> themselves and it's only a matter of time before this is seen in the
> wild and by accident. Why bother implementing something this trivial?
>
>
> Thoughts?
>
> -Neal
>
