How many scanners do I need?

>I know that at least with past versions of ZA port 53 is under certain circumstances/certain
>operating systems not blocked, because DNS doesn't work on some computers if it is blocked. I
>don't remember, but I think it was only for UDP port 53, and I think it was only for inbound (as I
>say, I don't remember for sure, but it was a fairly limited set of circumstances). However, given
>that what the vast majority of users have listening on port 53 is their operating system's DNS
>client, I fail to see how this translates into a way to circumvent ZA. Are you saying there is en
>exploitable bug in the Windows DNS client?

Nope. Tested it. Using windows 2000 sp3 with a za 3.x version (doesn't know which exact - maybe its outdated) and did a connect to a computer with remote port 53. There was no warning.

>Also, as you imply, with ZA Pro and ZA Plus, you can configure the firewall to block port 53 as well.

but then you can not solve domain names i think ).

>The socket layer is but *one piece* of ZA's security. If you "kick out" this layer to try to initiate a
>new connection, ZA will block you.

Ok. I tried it. Coded a simple service application, start it, terminate all za stuff in memory and kicked the layer out. Not problem to connect ). Maybe this is fixed.

>>Third za can be circumwent using its own protocol stack.
>

Sorry, bad english. If you use an own protocoll stack you can circumwent ZA. Tested it a few time ago. But i am not sure if 2.x or 3.x - sorry.

>Here I confess my own ignorance. I have heard this phrase before, and I'm not sure if it refers to
>loading of a bad dll (which ZAP can protect against by notifying the user when a new or changed dll
>loads), or something else. I know I've heard the developers here (Zone Labs) talk about this, so I
>suspect you are talking about something else.

Nope - doesn't mean a "bad dll". I mean something diffrent ;o). Patching the process directly.

>Where did you get the idea that ZA doesn't do stateful packet inspection or monitor other protocols
>besides TCP or UDP?

Sorry, bad english ;o). I mean ZA doesn't monitor ACK Packets, Echo Replys and so on that can be used for a communication ).

>>Sixth za doesn't check if the user realy clicks on the "permit" button ;o).
>Is this the same thing as the "process injection" you were mentioning before?

Nope. Every button, window, label and so on of an application has a so called handle. Events like keystrokes, mouse clicks are send by so called messages. You can emulate such messages using PostMessage/SendMessage. So you can emulate a click on the permit button of ZA. ZA doesn't check if the user did a real click or if the click was emulated.

I will redid a test using a new za 3.x version with all updates if you want. Or i will code a "new leak test" if the people are interested in. Started one a few time before - the next generation leak test - but never finished it.

 

Thanks for the additional detail. I haven't been actively involved in reporting exploits and exploit attempts in quite some time, so I'm kind of out of the loop on a lot of this. I know that much of this is either actively under investigation or fixed -- but I don't know what might be news to our developers, so I've forwarded this to them.

If you do retest with the latest ZA or ZAP, I'd appreciate knowing the results. However, I don't spend much time on newsgroups and similar fora (I'm only here now because someone notified me of this thread and notified me again whern there was a response to my post), so I'd appreciate it if you could e-mail me with any additional information.

Thanks again,

Rebeccah

 

Sorry, the DG UI asked for my e-mail address, but I didn't realize it's not displayed on the message.

If you don't know it already, it's rprastein@zonelabs.com.

Oh, and Hi Jan, thanks for the welcome.

Rebeccah

 

I'm all ears and eyes on this one !

bill