Detecting Symantec Client Firewall
Today is the first day I’m playing with my new laptop. It’s a Lenovo (very cool). Anyway, here I was messing with some environmental variables, as I am known to do and I notice something odd. Symantec’s Client Firewall actually modified headers in a very strange way that makes it very capable of being detected.
For some reason that completely escapes me, they attempt to mask the HTTP_ACCEPT_ENCODING variable. Again, the reason completely escapes me as there are way way scarier variables passed. Here is what it normally looks like for Firefox:
HTTP_ACCEPT_ENCODING = gzip,deflate
And here is what it looks like when masked by Symantec’s Client Firewall:
HTTP________________ = ————
The ultra strange part is that instead of just making it some random amount of blanks it is the exact number of characters that the normal header is. I completely don’t get it. Now let’s look at Internet Explorer:
HTTP_ACCEPT_ENCODING = gzip, deflate
Now masked:
HTTP________________ = —– ——-
Notice the space? I guess spaces don’t count as characters that need to be obfuscated. You should see the expression on my face as I type this. So, let’s see, assuming there is a lot of underscores that fits exactly with a header that is usually there but currently missing I think we can safely assume that that variable is always going to be HTTP_ACCEPT_ENCODING and given the fact that there is a comma and there is a set number of characters for the most common encoding types, I think it’s a safe assumption to say I can guess what the encoding methods the browser accepts. Talk about some crazy obfuscation.
I’m not even sure what it’s good for other than detecting users with this particular software installed. Go to my JavaScript Environmental Variables API to see your own HTTP_ACCEPT_ENCODING or detect it remotely. Weird.
November 27th, 2006 at 11:50 pm
Lenovo, hein? Nice piece of hardware. Which one did you got? I recently bought myself a X41. I’m very happy with it!
November 28th, 2006 at 3:08 am
I guess the reason for masking/removing the ACCEPT header is to ensure browsers are not using packed encodings. Therefore it is easier for the firewall to scan for patterns.
(Just a guess…)
November 28th, 2006 at 9:48 am
gouki, I got a T60. It’s awesome. Great machine for haX0ring.
Stefan, you very well be right, but here are my problems with that. Firstly, that doesn’t actually stop the user from downloading compressed files. Hopefully the Anti-virus isn’t ignoring compressed data so my guess is they have the ability to look inside compressed files anyway so this technique doesn’t actually save them any programming. Secondly, it slows download performance tremendously to turn off compression. What would you rather have, slow downloads or higher CPU upon downloading? I’d prefer the higher CPU personally. Lastly, it’s a huge signature that the user has this software installed. The tradeoff just doesn’t seem worth it to me.
November 28th, 2006 at 10:14 am
Yeah, the firewall wants the response to be as plain as possible.
The reason for not removing the header entirely is probably similar to why Amazon still returns something like “nnCoection: close” or “Cneonction: close” in its responses, as speculated here:
http://blog.nella.org/archives/000077.html
November 29th, 2006 at 5:05 am
Well the problem is if you want to support compression or want to replace the header completely you need to speak HTTP.
By just killing the header it is not necessary to implement a HTTP parser to pattern scan.
Same for removing the header: You have to speak basic HTTP to kill it, which is a lot more implementation work than just pattern scanning and on the fly modification.