 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to inTulsa
Re: The ZoneAlarm/BBR research thread 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. |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to inTulsa
said by inTulsa:
I'm not fully convinced about the 2 "POST" thing.
Well, the tools are available for you to test your own theories.
First, the snippet posted is obviously not valid HTTP, but I don't expect that ZoneAlarm has a webserver simulator built in; it's probably just some kind of state machine that looks for patterns that "look" like proxies without validating well-formed-ness (if it did so, we probably wouldn't be having this problem).
Second, if I remove the second POST, it fails to get confused. This POST can either be at the start of a line, or prefixed with whitespace, but if it's missing it won't recognize it. But if I replace POST #2 with GET, it does detect a false proxy. It's clearly looking for keywords here. quote:
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.
Well it is happening, and it's not for lack of trying that I have been unable to find any others beyond the overclocker site mentioned in the first thread on this subject. quote:
Too bad you won't get $1 for every ZA user that will benefit
Indeed, but I get to demonstrate my "kung fu grip" on security problem solving - that has some value too.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5
1 edit | 
"You have updates" :-) |
One thing I want to make really clear:ZoneAlarm will never try to fetch an update directly from a false proxy This would present all kinds of fun potential for the bad guys, but it doesn't work that way. Clicking "Update now" brings up a standard web browser where the user must navigate the usual download process.
Steve
--
Stephen J. Friedl * Security Consultant * Tustin, California USA * my web site |
|
