[16476] in bugtraq
Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet
daemon@ATHENA.MIT.EDU (Dino Amato)
Thu Aug 31 20:35:30 2000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.GSO.4.10.10008311643380.10488-100000@junior.apk.net>
Date: Thu, 31 Aug 2000 16:44:52 -0400
Reply-To: Dino Amato <slayer67@APK.NET>
From: Dino Amato <slayer67@APK.NET>
X-To: Ussr Labs <labs@USSRBACK.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <NCBBKFKDOLAGKIAPMILPGEODCGAA.labs@ussrback.com>
just run IRIS and then portscan yourself, this will also cause the same
problem. You dont need and special binary to do a DoS in this case.
I saw this when I first go the beta, but as it says - its Beta.
Dino
On Thu, 31 Aug 2000, Ussr Labs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You forgot say you already know this problem and you write this in a
> mail to me the same day Thursday, August 24, 2000 8:47 AM of you
> "Send me the advisory if you want, otherwise your wasting my fucking
> time."
>
> To anyone of want the mail write to us to see who are rigth or not,
> are signed digitaly so no change is posibly.
> this is a dos not a remote buffer overlow the dos is caused by one
> heap overflow in one of the 13 thread that use the retina 1.01.
>
> anyway i no know ONE. vendors angry with us
>
> u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c
> h
> http://www.ussrback.com
>
>
>
> - -----Original Message-----
> From: Marc Maiffret [mailto:marc@eeye.com]
> Sent: Thursday, August 31, 2000 7:58 AM
> To: Ussr Labs; win2k
> Cc: BUGTRAQ; EEYE; net-security.org; nTBUGTRAQ; Pure-security.net;
> packet storm; TECHNOTRONIC
> Subject: RE: Remote DoS Attack in Eeye Iris 1.01 and SpyNet
> CaptureNet
> v3.12 Vulnerability
>
>
> One thing USSR forgot to mention in their advisory is that Iris 1.01
> is
> _BETA_. With that out of the way lets proceed...
>
> Our response should hopefully clear up most of the inaccuracies and
> technical blunders found within USSR's advisory.
>
> | Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12
> | Vulnerability
> |
> | USSR Advisory Code: USSR-2000052
> |
> | Release Date:
> | August 31, 2000
> |
> | Systems Affected:
> | Eeye Iris 1.01
> | SpyNet CaptureNet v3.12
>
> First thing to mention is that SpyNet was purchased by eEye Digital
> Security
> a few months back. SpyNet is no longer supported and all SpyNet
> customers
> should contact us for a free upgrade to Iris.
>
> | THE PROBLEM:
> |
> | The Ussr Team has found a problem in Eeye IRIS 1.01, There is a
> | heap memory buffer o
> | verflow in IRIS 1.01 that causes not only this network sniffing
>
> Some might read "buffer overflow" and think that Iris has a remotely
> exploitable buffer overflow. This is not true...
>
> | program to crash,
> | but also to take system resources up to 100% usage, until it
> | crashes.
>
> Indeed the system resources go up to 100% usage. That is because your
> "DoS"
> program goes into a sendto() loop and sends thousands of packets that
> Iris
> has to redraw on screen. If any program in Windows has to redraw
> massive
> ammounts of information very quickly then it is going to end up
> taking a lot
> of processing power. Just as your "exploit" program will consume 100%
> of the
> attackers system resources when it goes into its sendto() loop.
>
> | The vulnerability arises after sending multiple udp connection to
> | random ports
> | on the host that IRIS or SpyNet CaptureNet is running.
>
> It does not matter what protocol you use nor what port. It just
> matters that
> you send a massive amount of information across a network that has
> Iris
> running on it. I understand why you used UDP because sendto() loops
> are much
> easier to create using UDP but that really has no technical bearing
> on the
> "bug."
>
> | SPECIAL NOTE:
> | That we take no responsibility for this code it is for educational
> | purposes only.
> |
> | D.O.S Code:
> | Binary or source (console win32)
> |
> | http://www.ussrback.com/iris101d.zip
>
> This program, as noted above, is a simple sendto() flooder. The way
> it works
> is by sending massive amounts of UDP packets destined to a computer
> running
> Iris.
>
> | Vendor Status:
> | Send me the advisory if you want, otherwise your wasting my fucking
> | time.
> |
> | Signed,
> | Marc Maiffret
> | Chief Hacking Officer
> | eCompany / eEye
> | T.949.349.9062
> | F.949.349.9538
> | http://eEye.com
>
> The above "quote" was taken completely out of context. This quote was
> after
> numerous eMails between myself and USSR in which I never received ANY
> details about the hole. I finally received "technical detailed
> information"
> in the form of this advisory only 2 hours before USSR posted it today
> to
> various mailing lists. I now more than ever can understand why so
> many
> vendors have been angry at USSR because of how they handle the
> "vulnerabilities" they find. All in all though I definitely did say
> "otherwise your wasting my fucking time" because that is exactly what
> was
> going on.
>
> | SOLUTION:
> | Install Free Ethereal for win32, Ethereal is Open Source software
> | released under the GNU
> | General Public License. and it does the same thing
> | http://ethereal.zing.org/ ,or wait untill
> | Eeye fix this kind of attack.
>
> We tested USSR's "DoS" program against our test network here. The
> setup was
> as follows:
> Attack Machine: dual 250 Pentium 2 processor NT4 machine with a
> Netgear
> 100mbit card running the my.exe "DoS" program.
> Victim Machine 1: 128megs of ram Single processor AMD 700mhz Win2k
> machine
> with an Intel 100mbit card running Iris 1.01 _!!BETA!!_
> Victim Machine 2: 96megs of ram Single processor Pentium 300mhz NT4
> machine
> with a Linksys 100mbit card running Iris 1.01 _!!BETA!!_
>
> Attack Test 1:
> One hub with all machines connected to it.
> my.exe was run against Attack Machine 2 and both Victim
> machines(1/2),
> running Iris 1.01 _beta_.
>
> Attack Result 1:
> Both machines did not crash after running my.exe against them for
> more than
> 5 minutes. Both machines were using heavy resources as was the
> attacking
> machine which was sitting at 100% cpu processing. However, neither of
> the
> two victim machines were left unusable. In fact victim 1 was
> compiling
> Retina in the background with no trouble... and that's not easy on
> the
> processor ;-]
>
> Attack Test 2:
> We figured maybe the hub was limiting the flow of packets due to
> collisions.
> So we connected a cross over cable between Attacker and Victim 1 at
> full
> duplex 100mbit.
> We then loaded my.exe on the Attacker machine and made it flood
> Victim 1.
>
> Attack Result 2:
> After about 15 minutes of leaving it flooding Victim 1, which was
> running
> Iris, Victim 1 was still running fine. Processor usage was higher but
> the
> machine was still responsive. The attacking machine was also using
> 100% of
> its cpu.
>
> Attack Test 3:
> For the next test we connected the Attacker machine to Victim 2 via a
> cross
> over cable at 100mbit full duplex. We then loaded my.exe on the
> Attacker
> machine and made it flood Victim 2.
>
> Attack Result 3:
> Iris used 100% cpu utilization on Victim 2 but did not generate any
> memory
> errors. The attacking machine's processor also sat at 100% cpu
> utilization
> while running the "DoS" program my.exe.
>
> Analysis of the problem:
> USSR kindly left out the fact that their "attack" was done over a
> local area
> network. This "DoS" is not possible over the Internet unless the
> attacking
> machine and the target machine have better then a DS3.
>
> While we do not discount the fact that Iris might crash when flooded
> with
> thousands of packets, we think it will be rare for any modern system
> (I.E.
> Our recommended hardware configuration, 400mhz, 128megs of ram, or
> better)
> to be vulnerable to this "bug."
>
> USSR most likely ran across this bug when testing their "DoS" tool
> against
> an older, slower, system (One other technical fact their advisory did
> not
> cover, was the system they were testing with and against; this is an
> important fact in a resource depletion based "DoS" attack.)
>
> The problem triggered by this "DoS" seems to result from filling
> packet
> buffers faster than Windows can paint them to the screen.
>
> If you are really worried about this, until Iris is out of beta and
> fixes
> the "problem", then we recommend you turn off Iris's Capture packet
> display
> feature and use Iris's decode view instead.
>
> | Vendor Url: http://www.eeye.com
> | Program Url: http://www.eeye.com/html/Products/Iris/overview.html
> | Download Url: http://www.eeye.com/iris/iris101.exe
> | SpyNet Url:
> | http://packetstorm.securify.com/sniffers/spynet/spynet312.exe
>
> SpyNet is no longer supported. If your a registered SpyNet then
> please
> contact iris@eeye.com to received your free copy of Iris.
>
> If anyone has any questions or problems then feel free to email
> myself or
> iris@eeye.com. Any new information we learn about this "hole" will be
> summarized and posted to Bugtraq.
>
> Signed,
> Marc Maiffret
> Chief Hacking Officer
> eCompany / eEye
> T.949.349.9062
> F.949.349.9538
> http://eEye.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOa6vN63JcbWNj6DDEQLgdQCePC+L+DahQZ7IMndRkGefLUe8ezsAoMR0
> s0XL5ysvlqh5SC7PCUqFcXUc
> =bNfb
> -----END PGP SIGNATURE-----
>
