Zonealarm security ahhahaahaha

[iNViCTuS]

Like I said in the previous post....please give more details about the attack so those of us who want to try it can. Just do a quick step-by-step that would get us all on the same page.

And no!! If you plant a backdoor on your own system...that is NOT a hack. I could install BO2K or Sub7 or any lame trojan, on my system and break into it and call it a hack. But $hit...if I really wanted to get into my own system (that I have admin access to) I would just create a user account. What did you do, send yourself an email and double click server.exe?

I am very skeptical until I see some proof, or you give me enough information to recreate the attack.

Don't get me wrong...I am not saying you are a lying...just the way you explained things here are not very good. The few brief steps you mentioned don't add up if you ask me (maybe because you need to explain )

[Chippunk]

i've had a few problems with tiny and now i am using sygate

[FullySaturate]

Well I have ZA and I have not had to many problems, its not the best firewall but it is good for a lockdown even though others offer that same option. I did run black ice but it just tells you if someone accesses a port on your system but I don’t think it blocks it, please tell me if I’m wrong. If someone would like to test the strength of ZA let me know and we can set up a time where I will be running it on one of my computers and you can attempt access.

[I am a cracker]

THIS IS HOW I DID IT!

how to open arbitrary ports against a client

*Send a HTML email to an HTML - enabled mail reader containing the tag <img src="Anywhere u want.com/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa {Lots of A} aaaPORT 1,2,3,4,25,79,80,110, etc...> I also conceivably plant a web page somewhere on a server containing this link.

*I made sure I balanced the number of A so that the PORT command will begin on a new packet boundary. This may also be done by having the server use a low TCP MSS to decrease the number of A's that one has to add.

*The firewall in question will incorrectly parse the resulting RETR/aaaaaaaaaaaaaaaaaaaaaaaa[....] aaaaaaaaPORT 1,2,3,4,25,79,80,110 etc as first a RETR command then a PORT command and open port 139 <--fro example against your address.

*Now the server Anywhere u want.com can connect to the client on port 139 (it can be any port)

(You have to know the IP address of the client in order to fool the firewall into opening the port.)

THE JAVASCRIPT code below works on MSIE

vartool=java.awt.toolkit.gettoolkit ( );
addr=java.net.InetAddress.getLocalHost ( );
ip=addr.getHostAddress ( );

This will work in a browser.

The firewall sees this as 2 seperate commands:

RETR aaaaaaaaaaaaaaaaetc...
PORT 1,2,3,4,25 ETC

This works on implemented proxies are vulnerable aswell

There is a lot more detail than I put on here!

And the reason people do not know about this because the company suffered damage and are embarrassed to make the breach public

[iNViCTuS]

Ok....where do I begin with this one...lol

*point #1: Even if this would work, you are still dependant on a user on the other end to open the email and the browser would have to be HTML based. Ok...not that hard

*point #2: So exactly how many A's does it take. Also, what would happen if you use B's instead. If it looks to the firewall like to separate requests, why would you not just send the PORT command on the first packet? Actually...let me answer that one, it is because the PORT command is used in FTP, not HTTP.

*Point #3: Again, even if this did work, the firewall would not inspect the contents of the packet beyond the TCP header anyway. Therefore it would not care about the size of the packet or how many A's it contained. what you are trying to explain here is a buffer overflow I believe, and this is not an attack against a firewall. Even if an application or service was vulnerable to a buffer overflow, it would not be the firewall's fault. So how can you say it is ZoneAlarm that has the problem?

*point #4: "You have to know the IP address of the client in order to fool the firewall into opening the port."
That is interesting...the firewall has nothing to do with opening port. The application or service would open a port. The firewall just has rules which tells the firewall which ports to leave open. ZA cannot dynamically allocate ports, unless the port is left open by the admin. AGAIN..not ZA's fault if this even was the case.

*point #5: A proxy server cannot proxy netbios through port 139 without some type of socket, so no...this will not work with a proxy server either.

*point #6: In your first post you said that it was done with SOURCE ROUTING and ICMP COMMANDS. Neither of which you mentioned here, nor did they make any sense in the first place.

Would you like me to go on?

This was enough evidence to for me to believe you are full of $hit

[iNViCTuS]

What happened Cracker....where did you go?

I was just beginning to have some fun

[KorpDeath]

I've been laughing for hours.

Yoooooohooooooo. Wait!!! He's probably thinkin' up a really witty rejoinder........

[Ennis]

Maybe take a peek at this...

ZoneAlarm and ZoneAlarm Pro can be stopped from loading by creating a memory-resident Mutex (using a call to the CreateMutex API). Uninstalling\reinstalling ZoneAlarm in a different path has no effect.
The impact of this vulnerability is that a Trojan running on a victim's machine can prevent ZoneAlarm from loading, and thus leave the victim open for attack.

Zone Labs "ZoneAlarm" and "ZoneAlarm Pro" programs both use a Mutex - an event synchronization memory object - to determine if it has already loaded (to prevent loading a second instance of the firewall).
By design, ZoneAlarm\ZoneAlarm Pro has no way of determining which program actually set the Mutex, thus allowing a Trojan to use the Mutex and block both ZoneAlarm and ZoneAlarm Pro from loading.

Exploit:
A Trojan can easily set this Mutex ("Zone Alarm Mutex") with one simple call to the CreateMutex API (see msdn.microsoft.com for more information on Mutexes). ZoneAlarm and ZoneAlarm Pro are then prevented from loading as long as the Trojan is alive. If ZoneAlarm is running, all the Trojan has to do is terminate the processes of zonealarm.exe, vsmon.exe and minilog.exe first before creating the Mutex. Despite being services, vsmon.exe and minilog.exe can both be killed by any program by setting its local process token privileges to SeDebugPrivilege, giving it the power to kill any process/service.

Demonstration:
A harmless, simple, working executable to demonstrate the vulnerability, is available at:
http://www.diamondcs.com.au/alerts/zonemutx.exe (16kb).
While the demo program is running, you will not be able to load ZoneAlarm or ZoneAlarm Pro, and if it finds that ZoneAlarm\ZoneAlarm Pro is running, it will terminate the ZoneAlarm processes and services first using SeDebugPrivilege before stealing the ZoneAlarm Mutex. The demo also opens an echo server socket to listen on TCP 7, allowing you to test socket connectivity/data transfer (try telnetting to 127.0.0.1 on port 7 and saying hello).

it's a "resource hog"...running both BlackICE & NeoWatch together take less resources than running one ZoneAlarm

[pvck]

Can anyone reccomend a url to a source I can point users to that outlines the specific issues with ZoneAlarm? I have some fairly technical people to convince of this, so details are good too.

Thnx,
--pvck

[iNViCTuS]

Very nice Ennis....now that is what I call a good explanation of a vulnerability/exploit. Although it is still trojan based...it at least has a concept that could work.

Hey...Cracker....maybe you should go to this link and learn about a real exploit so you know what one is next time, instead of making up some BS story about how you "hacked" your system in 11 mins that nobody believes....