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>] [thread-next>] [day] [month] [year] [list]
From: dan at losangelescomputerhelp.com (Daniel H. Renner)
Subject: Multiple Backdoors found in eEye Products
	(IRIS and SecureIIS)

I recall an interview with a highly placed security executive back in
the later '90s.  In this interview he lamented being in the security
business in the United States with a line similar to:

"If you create and announce a security product in the United States, you
will very shortly have the NSA entering your premises and demanding 'Ok,
where is our backdoor?'"

And remember, eEye was started after one of it's co-founders woke up to
federal guns pointed at his head one fine morning, having been mistaken
as someone who had penetrated somewhere he shouldn't have.

Not to bash my own country here but, this leads to a question: How can
any security product, sub-product or service created in the U.S. hold
credibility even with the good intentions that the creators may have
originally had?
-- 
Cheers,

Dan
Los Angeles Computerhelp
http://losangelescomputerhelp.com
818.352.8700


Original message:
----------------------------------------------------------------------

> Date: Wed, 29 Dec 2004 04:11:30 +0000
> From: "Lance Gusto" <thegusto22@...mail.com>
> Subject: [Full-Disclosure] Multiple Backdoors found in eEye Products
> 	(IRIS	and SecureIIS)
> To: vuln-dev@...urityfocus.com, ntbugtraq@...tserv.ntbugtraq.com,
> 	bugs@...uritytracker.com, full-disclosure@...ts.netsys.com,
> 	news-editor@...urityfocus.com, press@...-security.org
> Message-ID: <BAY2-F402493B090143E12AE0E88CC9B0@....gbl>
> Content-Type: text/plain; format=flowed
> 
> 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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ