 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5
4 edits | reply to Steve
Re: The ZoneAlarm/BBR research threadOK, I have this mostly figured out. I managed to capture a failure with tcpdump on my Linux box, and I wrote a bit of perl to parse the traces into what was sent to the BBR servers. I trimmed down the 3542 bytes of data into 48 bytes, and this send/response sequence will confuse ZoneAlarm every time:
POST /zatest HTTP/1.0
Host: unixwiz.net
POST x
HTTP/1.1 302 Found
Date: Sun, 20 Jun 2004 05:00:08 GMT
Server: Apache/1.3.29 (Unix) mod_perl/1.29
Location: /
Content-Type: text/html
X-Cache: MISS from www.dslreports.com
Connection: close
Redirected /
HTTP/1.1 302 Found
Date: Sun, 20 Jun 2004 05:00:08 GMT
Server: Apache/1.3.29 (Unix) mod_perl/1.29
Location: /
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="/">here</A>.<P>
</BODY></HTML>
My program runs on Windows and is written in perl, and anybody can download ActivePerl from »www.activestate.com (this is a fantastic free implementation of perl) and run it directly. On my system (Win2000) it causes ZoneAlarm to falsely detect a proxy every time as identified by ZAWatch.
At this point I have done all I can do, so Zone Labs should be able to reproduce this in house. I heard a rumor that they are considering a special debug build to help track this down, but I think I beat them to it :-)
The perl code is at zatest.txt (named .txt for easy download). Instructions are in the comments. When run, it sets the ZA proxy to unixwiz.net, so be sure to restart ZoneAlarm after :-)
Time to take the rest of the evening off - it's been a long day.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
 skjWelcome to the far side of realityPremium,Mod
join:2002-04-04
Gone South | Great job Steve! 
You really need to consider being a security consultant. You would make an excellent one.  |
|
 novaflareThe Dragon Was HerePremium
join:2002-01-24
Barberton, OH | reply to Steve
said by Steve:
The perl code is at zatest.txt (named .txt for easy download). Instructions are in the comments. When run, it sets the ZA proxy to unixwiz.net, so be sure to restart ZoneAlarm after
Err this is bad realy bad if zonealarm can be so easly fooled in to changing its settings whats to stop a script kiddie from writeing a peral script and putting it on a web site that allows a given ip to have un restricted access to say port 139?
--
new 3d chat comunity at »planetvirtuel.com my site »spellbound.valshea.com/news.php |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5
1 edit | said by novaflare:
Err this is bad realy bad if zonealarm can be so easly fooled in to changing its settings whats to stop a script kiddie from writeing a peral script and putting it on a web site that allows a given ip to have un restricted access to say port 139?
It's not that simple: the perl code has to run on the client, not on the server, and if the bad guy can run stuff on the client, he can do a lot worse than fool ZoneAlarm.
And as far as we know, the only thing that ZoneAlarm is doing with this proxy is checking for updates. It's not actually getting the updates (that's done through your browser), so the only thing one could do is delay a genuine check for updates for a while. ZoneAlarm resets its proxy settings when it restarts - it's not a "sticky" setting.
I have been toying with the idea of seeing if it's possible to buffer-overflow ZoneAlarm with a carefully-crafted reply from the dummy checkupdate.asp CGI script, but I have run out of time to do testing on this.
Edit - if anybody else can reproduce this with zatest.txt (the perl program), please post here; I've only run it from my own network.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| reply to Steve
Your post shows HTTP header:
Transfer-Encoding: chunked
|
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | said by inTulsa:
Transfer-Encoding: chunked
That's the reply from the BBR servers (which I have no control over); I have no idea if that's got anything to do with it.
I really should set up a dummy CGI on my webserver to tune the replies as well as what I sent.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| If that was the real reply, I suspect it may have something to do with it. Chunked responses are blocks of content prefixed by a count of #characters, and terminated with a zero count. If ZA isn't properly accounting for the invalid content chunk it could be having an adverse effect on their buffers.
Since chunked encoding is a standard part of HTTP/1.1 (rarely mis-formatted by servers), this would be something "unique" to our site. |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | Well, that reply is not representative of a "regular" BBR session. I'm not sending any cookies, and the URL is for a request that's known not to be valid: if I try it to "look like a real post", the reply is much, much larger. I don't recall if it had the chunked stuff or not.
Dammit, now I gotta go and fire it up on my own server to test it out
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| I know it's not representative of BBR. I've been trying to locate a similar invalid response from this site - no luck yet. |
|
BPremium,MVM
join:2000-10-28 | reply to Steve
What nice work!
Not only did you bitch about the problem but you got your hands filthy and practically figured the whole thing out for ZoneLabs.
Now if ZoneAlarm were open source I'm sure you would have fixed the code now too...
-- B
--
In a realm outside causality and function |
|
|
|
 McSummationMmmm, Zeebas Are Tastee.Premium,MVM
join:2003-08-13
Round Rock, TX
kudos:2 | If it were open source, we would have figured it out days ago. |
|
BPremium,MVM
join:2000-10-28 | Maybe, but the program wouldn't have existed either, so...
-- B
--
In a realm outside causality and function |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5
2 edits | reply to Steve
ZoneAlarm False-Proxy Detection said by Steve:
Dammit, now I gotta go and fire it up on my own server to test it out
I decided that integrating some custom CGI into my webserver would be too much trouble (Apache mucks with the headers), so I just wrote a simple webserver simulator. It accepts a connection on port 80/tcp, receives (and ignores) the data submitted from the remote client, and sends a canned response.
I started with the full response from BBR above, but it didn't take long to whittle it down to this minimal exchange that fools ZoneAlarm every time:
Remote sends:POST /zatest HTTP/1.0
Host: www.unixwiz.net
POST x
Server replies:Subsequent manual or automatic "check for updates" will then go through my webserver. I guess at this point it's about as small as I can make it - no real point in trying to shave a byte or two off.
Those who care to try this for themselves on their own machine are free to do so: I've created a set of tools that anybody can use to investigate.
And considering I have been the lead researcher on this, I think I get to name it: I've decided to call this ZoneAlarm False-Proxy Detection, and I summarized the background, tools, and instructions in a Tech Tip:
Unixwiz.net Tech Tip - Researching ZoneAlarm False-Proxy Detection
Anybody with a Windows machine should be able to research this on his own by installing both client and server components on the desktop. Full source is available for everything except ZoneAlarm :-)
I should note that there is one more level of research: what happens if ZoneAlarm actually uses the false proxy, checks for updates, and gets an "unexpected" response. I have positively zero evidence that any shenanigans are possible with a malicious response, but it begs to be investigated.
Promising area #1 is to get ZoneAlarm to fault directly on the downloaded data (perhaps a buffer overflow even?)
Promising area #2 is providing a response that says "yes, an update is available", but do so to a website that's not actually ZoneLabs: by making it look "just like a ZoneAlarm update page", it might be possible to do phishing or convince a user to download badware.
I'm looking into both of these.
Feedback and discussion welcome.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| So, sadly, there appears to be NO particular trigger mechanism? ZA just occasionally plugs a site name into its own proxy registry entry? They just have to find & fix that problem soon.
You've done great work on the issue, Steve! |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5
1 edit | Yes, there is a trigger mechanism: when there are two "POST" are seen in the request and two "HTTP/1.1" are seen in the reply, that seems to provoke it. BBR does have some kind of front-end proxy service, so I suppose it's possible that ZoneAlarm is confusing a server proxy (used only on the "other end") with a user proxy (used for all requests).
And yes, ZoneLabs has to get right on this, but I'll note that they have been extremely responsive during all of this, including a chat I had yesterday (Saturday) with johnlacour  , the pleasant Zone Labs fellow. But because I have "no life", I worked on this all weekend.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| But how does the 2nd POST (within content) exist in the real world? Below is a portion of the content transmitted with POSTing a preview of this reply:
-----------------------------7d42dabcac
Content-Disposition: form-data; name="title"
Re: ZoneAlarm False-Proxy Detection
-----------------------------7d42dabcac
Content-Disposition: form-data; name="MsgIcon"
0
-----------------------------7d42dabcac
Content-Disposition: form-data; name="notes"
But how does the 2nd POST (contained within content) exist in the real world?
-----------------------------7d42dabcac
(and thanks for clarifying the 'no trigger' misconception) |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | said by inTulsa:
You're saying word "POST" can occur anywhere in the stream to be a trigger?
I'm sure it's not that cut and dried, but that smells like it's in the neighborhood. Only ZoneLabs can really know this once they look at the source.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
| I'm not fully convinced about the 2 "POST" thing. The format tested is not quite valid, not what the other people experiencing the ZA problem would be generating. There is no Content-Type header accompanying the POST, no discernible content boundary, and no Content-Length. That kind of stream will not be encountered with any regularity.
RFC 2616 section 3.7.2 mentions the Multipart types, and notes:
The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request method, as described in RFC 1867 [15].
Something's been throwing ZA out of whack while scanning through HTTP content. It's hard to accept that any valid HTTP content could trigger the failure yet other forum sites haven't seen a lot of ZA proxy hits.
I was expecting / hoping that it's the processing of certain kinds of invalid HTTP content that is triggering the problem in ZA. "Invalid" being the format of POST content, improper Chunked response mentioned earlier, or something peculiar to this site.
Hopefully tomorrow the ZA staff will use your discoveries, docs & programs to isolate the cause. Thanks to You, they can't possibly NOT find something to fix. Too bad you won't get $1 for every ZA user that will benefit |
|
BPremium,MVM
join:2000-10-28 | said by inTulsa:
Thanks to You, they can't possibly NOT find something to fix. Too bad you won't get $1 for every ZA user that will benefit
Wow, that's $30,225,077 from CNET traffic alone! Nice haul.
-- B
--
In a realm outside causality and function |
|
| said by B:
Wow, that's $30,225,077 from CNET traffic alone! Nice haul.
Hope he gets that. Hope more that he shares it with us. |
|
