5934494 2001-01-09 08:07 -0800 /67 rader/ nealk <nealk@VERINET.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-09 17:20 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: nealk@verinet.com
Mottagare: Bugtraq (import) <14661>
Ärende: New DDoS?
------------------------------------------------------------
From: nealk <nealk@VERINET.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200101090140.f091e4d37756@deimos.frii.com>
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
(5934494) --------------------------------(Ombruten)
5935627 2001-01-09 17:52 +0100 /110 rader/ Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 00:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: sziszi@PETRA.HOS.U-SZEGED.HU
Mottagare: Bugtraq (import) <14682>
Kommentar till text 5934494 av nealk <nealk@VERINET.COM>
Ärende: Re: New DDoS?
------------------------------------------------------------
From: Szilveszter Adam <sziszi@PETRA.HOS.U-SZEGED.HU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010109175235.D12630@petra.hos.u-szeged.hu>
Hello and Happy New Year everybody,
On Tue, Jan 09, 2001 at 08:07:37AM -0800, nealk wrote:
> 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'.
Well, I do not think that this qualifies as a DoS. Denial of Service
is when the site denies service to the clients contacting it. Here,
the clients are attacked, but similar attacks have been around for a
long time. I think of eg DNS poisoning, which will prevent users
from accessing the site they want (although they get something else)
or a whole class of Man-in-the-middle-Attacks. Yet, these all count
as themselves and not as DoS when making categories. But this may
well be an unimportant semantics thing. (On a very important
side-note, although users will not get to the service, this kind of
attack does not incur huge load on the server and the network nodes
and does not cause marginal conditions, much less will it be able to
bring down a server. So you can react to it can be a much more
relaxed manner, and also at least the perpetrators are not
endangering the whole Internet infrastructure with their deeds, but
rather just one particular service. This, of course may be no cause
for joy to the service concerned, but as soon as you discover what's
wrong, you can take quick decisive action and restore access to the
service *without any performance loss* visible to the customer. There
is no rate-limiting problem, no slowdown, nothing. So the danger is a
lot more benign.)
> 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.
Yes, but this not new in the sense that if you can place a corrupt
SWF file there, you can place any other "bad" content as
well. Exploiting scripting bugs, eg. Also, a DoS is IMHO more
sweeping in definition. If a site is DoS-ed than you cannot get at
it, period. While here merely not having or disabling the offending
plugin already gives you access. If this were a DoS, then some
leading portal and other high-profile sites continually are DoS-ing
their users with eg scripts that only work on IE but may crash
Netscape. (At one time microsoft.com came into such suspicion because
a certain page took almost forever to download and render with
Netscape on non-windows platforms and some users experienced browser
hang or crash. However, upon more testing it was found that the page
took longest to display on Win98 and I think IE4. Whoo-whoo:-)
> 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).
Well, this is possible but again, as soon as you disable ads, you get
in. This remains an issue however, but should be named
differently. How about access blockage? Also, scripting "tricks" can
be used similarly. Easy verification in all cases: try a text
browser. If you get in, it is access blockage. (quickly coined
abbreviation: AB)
> What's worse: This is more difficult to identify since local testing
> on the local server may not identify why the clients are crashing.
Well, if local testing involves loading the page with one of the
leading browsers, then it almost surely will:-) Eg with an ad it has
to target your site specifically (and display with every new
download) or else it may not be noticeable.
> Question: How can sites protect themselves from this?
> (I mean: Aside from the obvious, "don't link to ad sites.")
It is equally tricky IMHO than it would be with a real DoS. Just as
with a DoS you can only act on a case-by-case basis and general rules
are hard to make, here it helps only if you react on a case-by-case
basis. After all, we are talking circumstances outside of your
control here.
But you are right, considering that most people use one of the
leading browsers and have all sorts of interesting plugins and have
no notion of to handle them (eg how to disable them) this will become
a problem just as viruses have with the advent of
all-singing-all-dancing, totally-transparent-to-the-user mail clients.
Just my HUF 0.02...
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
(5935627) --------------------------------(Ombruten)
5935710 2001-01-09 10:51 -0800 /44 rader/ Alfred Perlstein <bright@WINTELCOM.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-01-10 00:28 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bright@WINTELCOM.NET
Mottagare: Bugtraq (import) <14684>
Kommentar till text 5934494 av nealk <nealk@VERINET.COM>
Ärende: Re: New DDoS?
------------------------------------------------------------
From: Alfred Perlstein <bright@WINTELCOM.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010109105144.V15744@fw.wintelcom.net>
* nealk <nealk@verinet.com> [010109 10:41] wrote:
> 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.
While this is a possibility, it doesn't make much sense, news would
spread like wildfire and people would drop links to the add service
pretty quickly. Your attack would need either:
a) a suicidal company.
b) a hacked ad server.
c) widespread DNS poisoning.
Ad services can do other nasties like using 302s to redirect hundreds
or thousands of hits to a particularly system intensive service on
a remote site, that's a nasty DoS but also a good way to get yourself
involved in a nasty lawsuit.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
(5935710) ------------------------------------------