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

[Marc Maiffret <marc () eeye com>]

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