Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet v3.12 Vulnerability

[Ussr Labs <labs () USSRBACK COM>]

-----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-----