This site uses advanced css techniques
We've spent quite a bit of time researching a bug in ZoneAlarm 5.0.x where it incorrectly believes our computer is using a proxy server, and we have created some tools that help us do that research. We're making them public to all others to play too.
A short description is that when ZoneAlarm observes this send/response sequence, it believe that a proxy server is being used:
POST /zatest HTTP/1.0 Host: www.unixwiz.net POST x
HTTP/1.1 200 HTTP/1.1
Subsequent checks for updates (manual or automatic) will be done via www.unixwiz.net instead of a ZoneLabs site.
Zone Alarm 5.0.590.015 attempts to figure out if you're using a proxy server or not, and if it detects this, it will use that proxy server when it checks for updates. We have found that it sometimes guesses wrongly, so will start asking an unrelated webserver whether updates are available (this shows up the the server logs).
The response expected is of the form (and expected from update.zonelabs.com):
UpdateAvailable=no UpdateURL=http://update.zonelabs.com/ UpdateNotice=Your Internet security is up to date.
We have not done any real research to see what happens if ZoneAlarm gets a response other than this, but we're really curious if there are ways to make ZoneAlarm behave badly if given "surprising" inputs. If a website is able to fool ZoneAlarm into believing it's a proxy server, there might be opportunities for malicious behavior. We may look into this yet.
Note that ZoneAlarm doesn't actually fetch the updates from the proxy site, it only checks to see if any are available. The user is invited to an update site via a regular browser session that would not use the false proxy.
Zone Labs is very much aware of this issue and has been working closely with us and DSLReports where this problem first surfaced. To date there have been two forum threads on this topic:
When ZoneAlarm detects a proxy (correctly or otherwise), it updates a few registry values to reflect this, and it's helpful to know exactly when this happens. We've written a tool that watches these registry values and reports when they change.
This is always run on the same machine as ZoneAlarm, and it can be left minimized in the task bar while it watches. Full instructions are given on the page, and we'll assume this is installed.
The zaclient and zalistener programs both require a perl interpreter, and we did all our testing with the outstanding ActivePerl from ActiveState. We've found this to be a fantastic implementation of perl, and we use it every day for system administrative purposes.
All of our research is done in an MS-DOS window - sorry, no GUI tools here - which is reached with Start » Run » "cmd" + RETURN. You'll probably need two of these windows, one for the client and one for the listener.
This "client" is a simulated web browser that makes an HTTP request to a server, and this can be a real server (default is DSLReports) or a simulated one (the zalistener program), and the data stream exchanged is designed to provoke a false proxy detection while Zone Alarm sniffs the data. If this happens, ZAWatch will provide this notification in real time.
zaclient normally requires no command-line parameters, though a few are supported to alter its behavior. By default, it makes a connection to www.dslreports.com and submits some data and collects the response (both are reported to the user). We're watching for the notification by ZAWatch as shown here:
Here, we're running zaclient, and it's making a connection to the DSLReports website with some very minimal data, and the combination of the sent and received data provokes a false-proxy detection as shown by the ZAWatch popup.
The file zaclient is text (a perl program), and the data we're sending can be edited to repeatedly try different data patterns. Simply look for the section:
from zaclient:my $rawdata = <<EOF; POST /zatest HTTP/1.0 Host: $proxyhost POST x EOF
The EOF tokens are delimiters for the text that lies between (shown here in red), and individual lines can be commented out with a #.
This program takes a few command-line parameters:
Though zaclient offers full control over what's sent to the webserver, it doesn't directly control the response. Since that response helps contribute to false-proxy detection, we'd like to manage both ends of the conversation.
zalistener is a perl program that acts as a webserver simulator: it accepts a connection from a client, receives and logs (but does not interpret) its data, then sends a canned response. In this manner we are responsible for every byte of the conversation and can fine tune it very highly: what breaks? what doesn't?
This program can run on the same machine with ZoneAlarm, ZAWatch, and zaclient, making any single machine a research workstation.
This screenshot (click for larger image) shows the whole group working together. ZAWatch is running in the background looking for registry value changes, zalistener is running in the leftmost console window waiting for connections, and zaclient is running to localhost in the foreground console window.
Regardless of what it receives, zalistener responds only with fixed data that can be tuned while experimenting with patterns that cause false-proxy detection. As with zaclient, the fixed data is found in the perl source code:
from zalistener:my $rawdata = <<EOF; HTTP/1.1 200 HTTP/1.1 EOF
Remember that once a false-proxy detection has been made, that selection remains in effect until ZoneAlarm is restarted. We don't believe that it will attempt to re-detect a proxy once one has been discovered, so one must make a point of restarting ZoneAlarm after each detection.
With ZoneAlarm misdetecting these proxies, it's just a matter of time before it actually tries to use one while checking for an update. It's expecting a few lines of text from the server, and by writing a custom CGI for a webserver pointed to by --proxy=host, it's possible to say anything we like to ZoneAlarm. We can anticipate at least two avenues of exploitation by a malicious false proxy.
NOTE BENE - These are only speculations, and there is positively no evidence (or even hints) that any of these approaches would actually work. We want to be careful that "thinking out loud" and "brainstorming" is not misread as "ZoneAlarm is vulnerable". As far as we know, it's not.
We'd like to be particularly clear about one matter that seems to be causing some confusion. ZoneAlarm does not attempt to fetch updates from the false proxy - it only checks if they are available or not, relying on a standard browser session for the download.
It's not possible for a false proxy to directly feed malware to ZoneAlarm
First, directly causing ZoneAlarm to fault by sending bad data. If ZA is expecting a few, short lines, what happens if we send a lot of really long ones? Though we'd expect Zone Labs to do proper buffer management, considering that they're expecting to talk to a "trusted" machine, it's conceivable that it hasn't been tested as strenuously as other modules.
Second, if the response from our fake proxy says that an update is available, it also provides a URL. If this URL "looks like" a Zone Labs download site but actually isn't, it may be possible to convince at least some portion of the user base to download malware thinking it was coming from a trusted site.
We've done a bit of toying with a fake checkupdate.asp CGI, and we can get ZoneAlarm to prompt this way:
... and clicking "Update now" points to this Tech Tip.
Zone Labs has been exceptionally responsive about this matter, and it's obvious that they are taking it seriously. We've seen what appears to be substantial engineering resources devoted to tracking this down, and we hope that our tools will make it easier to reproduce and fix it.