full-disclosure - Multiple Backdoors found in eEye Products (IRIS and SecureIIS)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: thegusto22 at hotmail.com (Lance Gusto)
Subject: Multiple Backdoors found in eEye Products (IRIS
	and SecureIIS)

Multiple Backdoors found in eEye Products (IRIS and SecureIIS)
L. Gusto <thegusto22@...mail.com>

Summary:

During meticulous testing of both eEye's IRIS and SecureIIS products,
we (my testing team) have discovered multiple backdoors in the latest of
both mentioned products and some older versions we could acquire.

These backdoors are very cleverly hidden (kudos to the authors), I
personally don't condone illegally backdooring commercial products,
and personally I don't think much of eEye but I must give credit to
where credit is due.

We have tested IRIS 3.7 and up they all appear to have a backdoor.
We have verified the IRIS backdoor doesn't exist in versions prior
to 3.0

We have tested SecureIIS 2.0 and up they all appear to have a backdoor.
We have verified that SecureIIS 1.x series does not have this specific
backdoor.

Bringing the backdoors to light:

After long testing we discovered the exact sequences used to active
the backdoor. Unfortunately, we can't release the "exploits" publically
due to the severity of these flaws. But incomplete examples will
be given.

The IRIS Backdoor:

This one is quite interesting. We have discovered that sending a
specifically crafted UDP datagram to a IRIS host *directly* (not
through the wire or to host on the network segment) with certain IP
options set and a certain magic value at a undisclosed offset in the
payload will bind a shell to the source port specified in the UDP datagram.

[snip]

The SecureIIS Backdoor:

The SecureIIS backdoor was alot easier to discover but very well
placed. The SecureIIS backdoor is triggered by a specifically
crafted HTTP HEAD request. Here is a incomplete layout of how
to exploit this:

HEAD /<24 byte constant string>/PORT_ADDRESS.ASP HTTP/1.1

PORT 		- Will be the port to bind a shell.
ADDRESS		- Address for priority binding (0 - For any).

[snip]

Local Deduction:

There are a two possiblilites here, either eEye's code has been
altered by some attacker or this has been sanctioned by the
company (or at least the developers were fully aware of this).

Conclusion:

It is very very shameful that a somewhat reputable like eEye is acting
in a very childish, unprofessional manner. I figure that is why the
code is closed source. There are several active exploits available that I
(the author of this advisory) didn't create floating around. The only
logical solution will be to not use the mentioned eEye products for the
time being or at least downgrade to the non-backdoored versions.

We will be investigation eEye's Blink Product for any clandestine backdoors.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/