Onderwerp: eSafe: Could this be exploited?

Hi,

I had a bit of a chat with Aladdin support regarding the odd results I had
with their network virusscanner (aka: eSafe). (see also:
http://www.ealaddin.com/esafe/default.asp)

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

If it is a first time hit you can get as much as 80% of the payload on
your machine and while they may reset the tcp stream at least IE does
store the 80% chunk as if the file was transfered correctly. (This part I
tested with over 30 different virus files.)

First off this is extremely confusing to the user who just thinks (s)he
just had a virus passing their scanner. (And they are about 80% right.)

Then the chunk may contain enough to trigger another scanner which may
reside on the desktop of said user adding further to the belief this is
not a good product.

But what if I were to write a really small harmfull virus (say less then 2
ethernet packets)? Or create it in such way that the last 20 to 25% is
expendible without loosing it's sting?

Is someone able to verify such a virus may work? (I am not a programmer so
I can think of the potential breach but I can't verify it is exploitable.)

I have a felling it is just a matter of time before such a scanner will be
bypassed.

Hugo.

--
All email sent to me is bound to the rules described on my homepage.
hvdkooij@vanderkooij.org http://hvdkooij.xs4all.nl/
Don't meddle in the affairs of sysadmins,
for they are subtle and quick to anger.

Hugo van der Kooij wrote:

> I had a bit of a chat with Aladdin support regarding the odd results I had
> with their network virusscanner (aka: eSafe). (see also:
> http://www.ealaddin.com/esafe/default.asp)
>
> Both as NitroEngine or CVP server they will push as much of 80% to the
> end-user before they stop a virus. ...

This is the common (and obvious as soon as you decide to try to
implement something like this) "how do we keep the client from timing
out" problem? After all, unlike SMTP with its inherently "store and
forward" mechanisms introducing several natural "pauses" during the
transport of content, HTTP (like most other Internet protocols) is
considerably more "real time"...

Another approach to solving this problem involves the use of some kind
of agent at the client end. Of course, that requires a greater degree
of management and reduces the utility of the scanning service to those
machines that are running the agent and otherwise properly
configured...

> ... Then they rely on the adding of the
> exact URL so that URL can be blocked in all next requests.
>
> If it is a first time hit you can get as much as 80% of the payload on
> your machine and while they may reset the tcp stream at least IE does
> store the 80% chunk as if the file was transfered correctly. (This part I
> tested with over 30 different virus files.)
>
> First off this is extremely confusing to the user who just thinks (s)he
> just had a virus passing their scanner. (And they are about 80% right.)
>
> Then the chunk may contain enough to trigger another scanner which may
> reside on the desktop of said user adding further to the belief this is
> not a good product.
>
> But what if I were to write a really small harmfull virus (say less then 2
> ethernet packets)? Or create it in such way that the last 20 to 25% is
> expendible without loosing it's sting?
>
> Is someone able to verify such a virus may work? (I am not a programmer so
> I can think of the potential breach but I can't verify it is exploitable.)

In the Windows malware world there are some very small downloaders --
Windows executables around the 4-5KB size range (and a few even
smaller).

Also, there are several quite widespread viruses that pad their .EXE
files out with random amounts of random junk. The Windows PE loader
simply ignores additional "junk" on the end of a file ("extra" as
judged by what the PE headers say should be there). Whether any of
these use as much as 20-25% padding I'm not sure (but suspect _not_) --
for now it seems that this technique is used because the virus writers
seem to believe they'll bypass some useful proportion of content
blocking gateways because the attachments of these viruses do not have
constant CRC/MD5/etc (any gateway that is fooled by such a simple trick
really should not be in production, so I guess there are probably only
a few thousand such gateways out there...).

> I have a felling it is just a matter of time before such a scanner will be
> bypassed.

All scanners will always be (able to be) bypassed by something. When
you look at all the tricks the malware writers can use and that a
scanner has to work around, you quickly realize that scanning is
inherently inefficient. To beat this the scanner developers implement
all kinds of heuristics and shortcuts and imperfect "optimizations" to
get performance back to acceptable levels. Each scanner is chock full
of tons of really, really fugly stuff you'd have kittens over if you
knew. The reason the scanner developers "get away with it" is because
each does it differently -- the fuglies in NAV are mostly entirely
different fuglies from those in the McAfee products which in turn are
entirely different from those in all the other products. (BTW, this is
the primary reason why MS entering the AV market -- at least with an
"integrated" or "built-in" virus scanner -- is a chronically stupid
idea as then one set of AV stupidities will be really, really
widespread and common, so researching and targeting just those
weaknesses will be especially worthwhile for the VXers. And, if that
happens, MS will have to remove more and more of the shortcuts in its
scanner, making it slower and slower and slower...)

So, all scanners are bypassable, but this seems a rather obvious bypass
for this general approach to "web scanning".


--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

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, äà è òî ïðè ýòîì îøèáàÿñü. (Ëåì)

Hugo van der Kooij wrote:

>Hi,
>
>I had a bit of a chat with Aladdin support regarding the odd results I had
>with their network virusscanner (aka: eSafe). (see also:
>http://www.ealaddin.com/esafe/default.asp)
>
>Both as NitroEngine or CVP server they will push as much of 80% to the
>end-user before they stop a virus. Then they rely on the adding of the
>exact URL so that URL can be blocked in all next requests.
>
>If it is a first time hit you can get as much as 80% of the payload on
>your machine and while they may reset the tcp stream at least IE does
>store the 80% chunk as if the file was transfered correctly. (This part I
>tested with over 30 different virus files.)
>
>First off this is extremely confusing to the user who just thinks (s)he
>just had a virus passing their scanner. (And they are about 80% right.)
>
>Then the chunk may contain enough to trigger another scanner which may
>reside on the desktop of said user adding further to the belief this is
>not a good product.
>
>But what if I were to write a really small harmfull virus (say less then 2
>ethernet packets)? Or create it in such way that the last 20 to 25% is
>expendible without loosing it's sting?
>
>Is someone able to verify such a virus may work? (I am not a programmer so
>I can think of the potential breach but I can't verify it is exploitable.)
>
>I have a felling it is just a matter of time before such a scanner will be
>bypassed.
>
>Hugo.
>
>
>
Hi, i saw this "feature" already on other vendors AV-proxes, where this
80% thing is a side effect of http-comforting of the proxy-software.
Comforting is, that the http-client is not running into an timeout.
I think it is possible to generate an exefile, and attach some random
data. Whereby the exe file is about 80% and the random data 20%.
And also i think, the problem is, that the AV does not exactly stop at
80%. So you have to generate multiple "infected" files with 80/20,
81/19, 82/18 and so on.
In Addition you have to test if for example a scripting host file or a
binary is still executable, if the last
few bytes at the end are garbage. AFAIK does the PE-header on windows
..exe files also include a checksum/lof of the file..... if i remember
right, this checksum is not utilizised by
Win95/Win98, but by W2K/NT- Windows OS. So, there are many circumstances
to take care for, but i think it is possible in some cases..... lets try
it

ok, just some ideas late at night....

I have tested it out, and esafe blocked the hole email that contains
the eicar virus.
Of course I have configure esafe to block virus infected emails
instead of modifying them and removing the virus.

MegaHz
www.megahz.org
megahz@megahz.org


On Sat, 24 Jul 2004 15:27:43 +0400, 3APA3A <3apa3a@security.nnov.ru> wrote:
> Dear Hugo van der Kooij,
>=20
> --Friday, July 23, 2004, 10:21:22 PM, you wrote to bugtraq@securityfocus.=
com:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> --
> ~/ZARAZA
> =D0=9C=D0=B0=D1=88=D0=B8=D0=BD=D0=B0 =D0=BE=D0=BA=D0=B0=D0=B7=D0=B0=D0=BB=
=D0=B0=D1=81=D1=8C =D1=81=D0=BF=D0=BE=D1=81=D0=BE=D0=B1=D0=BD=D0=BE=D 0=B9 =
=D0=BA =D0=B5=D0=B4=D0=B8=D0=BD=D1=81=D1=82=D0=B2=D0=B5=D 0=BD=D0=BD=D0=BE=
=D0=BC=D1=83 =D0=B4=D0=B5=D0=B9=D1=81=D1=82=D0=B2=D0=B8=D1=8E,
> =D0=B0 =D0=B8=D0=BC=D0=B5=D0=BD=D0=BD=D0=BE =D1=83=D0=BC=D0=BD=D0=BE=D0=
=B6=D0=B5=D0=BD=D0=B8=D1=8E 2x2, =D0=B4=D0=B0 =D0=B8 =D1=82=D0=BE =D0=BF=D1=
=80=D0=B8 =D1=8D=D1=82=D0=BE=D0=BC =D0=BE=D1=88=D0=B8=D0=B1=D0=B0=D1=8F=D1=
=81=D1=8C. (=D0=9B=D0=B5=D0=BC)
>=20
>

which version of eSafe are we talking about? 3 or 4 ?

On Sat, 2004-07-24 at 14:27, 3APA3A wrote:
> 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.
>

On Mon, 26 Jul 2004, MegaHz wrote:

> I have tested it out, and esafe blocked the hole email that contains
> the eicar virus.
> Of course I have configure esafe to block virus infected emails
> instead of modifying them and removing the virus.

SMTP (or SMTP via CVP) is handled as a store and forward mechanisme. Hence
the 80% rule does not apply.

The issue was seen with both v3.5 in CVP mode as well as v4 in bridging
mode. No further labtest were done to see if a full live EICAR version
could be passed along.

If someone is able to create a test executable based on the EICAR string
the point might be proven. Unfortunatly I am not a programmer and lack
window compiler tools all together. But if someone thinks (s)he can create
a sample binary that may run when the last bit is shot to pieces and still
contain a valid EICAR definition to show to the screen the issue might be
proven.

Putting it on a webserver and posting the URL would allow anyone who wants
to to verify the issue themselves.

Hugo.

--
All email sent to me is bound to the rules described on my homepage.
hvdkooij@vanderkooij.org http://hvdkooij.xs4all.nl/
Don't meddle in the affairs of sysadmins,
for they are subtle and quick to anger.

On 26 Jul 2004, at 21:26, Hugo van der Kooij wrote:
>
> If someone is able to create a test executable based on the EICAR
> string
> the point might be proven. Unfortunatly I am not a programmer and lack
> window compiler tools all together. But if someone thinks (s)he can
> create
> a sample binary that may run when the last bit is shot to pieces and
> still
> contain a valid EICAR definition to show to the screen the issue might
> be
> proven.
>
Just an idle thought, but what about scripting? Would it be possible to
get some simple scripts through simply by making a large portion of the
end of the message useless comment fields? Maybe even a worm that
rewrites this 'noise' every time to make a moving target?