Aladdin response regarding eSafe

[Ofer Elzam]

In-Reply-To: <18610004519.20040724152743@SECURITY.NNOV.RU>

eSafe Gateway uses a default value of 80% file download before first inspection of executable files from HTTP servers. This value can be changed to as low as 5% if desired.
We feel that the 80% gives a good balance between user experience and security needs. Customers would usually want to see a fast moving download progress bar. If we set the value to 5% - the progress bar will move just a little bit (5%) when downloading
and the remaining 95% very fast as eSafe finishes the inspection. This annoys users.

The customer has a choice - better security or better user experience (let's also remember that currently there are no real viruses in the wild that have used such methods).
Testing this technique with EICAR is very specific as EICAR is not like typical real viruses; it is only a few bytes in length.

In any case, if a future virus that can cause damage even when only a few bytes are downloaded is discovered, eSafe has the right technology to identify and block it. We can even automatically change customer configuration to do so if needed.

eSafe is known for innovative security features so this subject will be further investigated in search of even more security enhancements.

Regards,
Ofer Elzam, CISSP
eSafe Product Manager






Dear Hugo van der Kooij,

--Friday, July 23, 2004, 10:21:22 PM, you wrote to bugtraq securityfocus com:

HvdK> Both as NitroEngine or CVP server they will push as much of 80% to the
HvdK> end-user before they stop a virus. Then they rely on the adding of the
HvdK> exact URL so that URL can be blocked in all next requests.

It depends on how antiviral check is actually implemented. If connection
is broken immediately after signature is detected - there is no way to
download infected file, because signature will not pass to client and
client will not be able to use "Range:" header to resume partially
downloaded file.

If antiviral filter checks data _after_ all data received from client
with 20% buffering yes, it's possible to bypass this check for HTTP,
because there is no way (at least for HTTP/1.0 and FTP) to indicate
error to client and make him to delete partially downloaded data.

You can check it, by sending EICAR with some additional data: if you can
find EICAR signature on the client after connection is broken by
antiviral filter you can bypass it's protection.


--
~/ZARAZA
Ìàøèíà îêàçàëàñü ñïîñîáíîé ê åäèíñòâåííîìó äåéñòâèþ,
à èìåííî óìíîæåíèþ 2x2, äà è òî ïðè ýòîì îøèáàÿñü. (Ëåì)

[3APA3A]

Dear Ofer Elzam,

Of cause, this approach makes no problems in catching, for example,
known ITW worms as executables or archives. Problems begin if you're
trying to catch, lets say sites with Internet Explorer trojans. Remember
Scob? Imagine what happens if Scob added to a page as a header instead
of a footer. 80% and even 5% of the page have a good chance to contain
fully working version of Scob before connection is terminated by filter.

I know this problem it not eSafe specific. In fact, I don't know
antiviral engine capable to catch signature in the stream of data
immediately after signature is arrived in the stream. All antiviral
engines I tested (KAV, ClamAV and others) are file-oriented. It makes it
impossible to code good antiviral protection for proxy server with this
engines.


--Wednesday, July 28, 2004, 7:52:14 PM, you wrote to bugtraq@securityfocus.com:

OE> In-Reply-To: <18610004519.20040724152743@SECURITY.NNOV.RU>

OE> eSafe Gateway uses a default value of 80% file download before
OE> first inspection of executable files from HTTP servers. This value
OE> can be changed to as low as 5% if desired.
OE> We feel that the 80% gives a good balance between user
OE> experience and security needs. Customers would usually want to see a
OE> fast moving download progress bar. If we set the value to 5% - the
OE> progress bar will move just a little bit (5%) when downloading and
OE> the remaining 95% very fast as eSafe finishes the inspection. This
OE> annoys users.


OE> If antiviral filter checks data _after_ all data received from client
OE> with 20% buffering yes, it's possible to bypass this check for HTTP,
OE> because there is no way (at least for HTTP/1.0 and FTP) to indicate
OE> error to client and make him to delete partially downloaded data.

--
~/ZARAZA
Ïîêà âû âî âëàñòè ïðîâèäåíèÿ, âàì íå óäàñòñÿ óìåðåòü ðàíüøå ñðîêà. (Òâåí)