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

[Marc Maiffret <marc () eeye com>]

We have _never_ had a report of Iris crashing from a port scan. If you could
please give us a little bit more technical information. I.E. Did you run the
port scan locally? What program did you use to port scan? What beta of iris
was this? Does this work on the current Iris beta?

Signed,
Marc Maiffret
Chief Hacking Officer
eCompany / eEye
T.949.349.9062
F.949.349.9538
http://eEye.com


| -----Original Message-----
| From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of Dino
| Amato
| Sent: Thursday, August 31, 2000 9:45 PM
| To: BUGTRAQ () SECURITYFOCUS COM
| Subject: Re: Remote DoS Attack in Eeye Iris 1.01 and SpyNet CaptureNet
| v3.12 Vulnerability
|
|
| 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-----
| >
|