Forums / Tech Talk / Simple server-side-only Phorm detection - BadPhorm

Forums

BadPhorm - When good ISPs go bad! :: Forums :: Phorm Discussion :: Tech Talk		<< Previous thread \| Next thread >>
Simple server-side-only Phorm detection


Moderators: Jim Murray, narcosis, felixcatuk, Sammy, revrob

Author

Post

Fanjita

Thu Nov 06 2008, 11:55PM

Registered Member #555

Joined: Fri Oct 03 2008, 12:50AM
Posts: 36

So, it occurred to me today that there may be a simpler, server-side-only way to detect Phorm cookie-mangling.

As I understand it, we can expect that setting a cookie with the phorm cookie name should result in us never seeing that cookie back again. In theory, that could be enough to detect phorm - always set the cookie, and if it's not seen on a request then we know phorm is active. But that falls down on 2 fronts:

The first time someone visits our page / domain, we won't have had a chance to set the cookie, and so we'd get a false positive.
Some clients block all cookies, so we'd get a false positive there - and there's no way to tell the difference between client blocks and phorm blocks.

But what if we always set 2 cookies : the phorm-named one, and a 'canary' cookie? If the canary is present on a request, but not the phorm one, then we know that the client isn't blocking cookies, but something else is. That's enough to be reasonably positive that it's phorm.

If the canary isn't present, then we just have to assume that it's either the client's first visit, or they're blocking all our cookies. In that case, we assume a clean connection.

Am I missing something that makes it not as simple as this?

Of course, we'd want to make the canary pseudo-random in some way, so it can't just be interfered with as a matter of course by phorm.

One other thing I've been looking into recently is whether it's possible to simulate Phorm's cookie behaviour via a proxy. It looks like Privoxy can probably be set up to do something roughly equivalent, over the next few days I'll be trying to get a Privoxy configuration set up that triggers some of the code at Dephormation etc.

felixcatuk

Fri Nov 07 2008, 09:46AM

felixcatuk

Registered Member #95

Joined: Wed Mar 05 2008, 12:03AM
Posts: 2593

Two Cookies

A two cookie solution has been discussed a few times, I really ought to get it coded up and published.

Setting the canary to be random is easy; you can pick a truly random name/value combination (all you need to know is that the same name/value are returned with the next request). It wouldn't necessarily require sessions either, you could use a date dependent value (eg, calculate a daily name/value based on number of days since the epoch).

Privoxy

If you look at the vanilla wafer configuration of Privoxy, you'll find you can force an opt out cookie to be set. The downside is that you will trigger false detections on web sites (because it will appear that all your requests are infected by Phorm cookies).

That's the one reason I've held off publishing such a solution.

I guess there's a risk that if people consider you are infected by Phorm, your ISP might be running a trial... so its probably not wise to do it just yet.

What would be better is a way to strip Phorm cookies using privoxy (but the problem with that solution is that genuinely Phormed users will be immediately redirected to an invitation page with every request if a cookie isn't found).

Rather than using Privoxy it is simpler to get your MAC code and leave BT.

Phorm must be stopped.

[ Edited Fri Nov 07 2008, 09:54AM ]

Fanjita

Fri Nov 07 2008, 09:57AM

Registered Member #555

Joined: Fri Oct 03 2008, 12:50AM
Posts: 36

I plan to bang out a 2-cookie PHP solution this weekend, assuming it can work then it's certainly by far the simplest way for servers that are able to run some code.

The privoxy idea was not so much to block Phorm, but to provide a testing proxy that can be used to simulate it. I find that the hardest thing about working on Phorm detection is not so much designing the code, but FV-testing it in the absence of any cooperative live-triallers.

I think the vanilla Privoxy cookie support is not quite sufficient to model Phorm (although it's probably capable of stripping the UID cookie from the server request), but I'm hoping it should be possible to use the header rewrite facilities to at least insert content cookies out to the client. If need be I'll just hack the code - it is at least open source.

Midnight_Voice

Fri Nov 07 2008, 01:45PM

Registered Member #180

Joined: Thu Mar 13 2008, 08:51PM
Posts: 756

Get the Phorm cookie served up, by https, or using a different port, etc. rewrite it as a Phorm opt-out cookie with a long expiry time, and deliver it back to the user.

Doesn't affect his/her use of Phorm elsewhere on the 'Net, and doesn't cause them redirects. But it stops Phorm stealing your content, and it means that whatever interest the user shows in your site, Phorm won't be able to profile this to have your competitors serving up ads for those things.

madslug

Sat Nov 08 2008, 03:30PM

Registered Member #266

Joined: Tue Apr 01 2008, 12:11PM
Posts: 772

I am wondering if sites writing cookies will put visitors into a loop.
If I recall there is some timer between requesting the original webwise cookie and forged site cookies with site cookies getting preference to take the load off the DPI proxy.
If there is no cookie then the forged cookie is written but with only a 3 day life.

The test cookie would need to be a short life cookie so that there is no risk that after having dephormed the forged cookie it then gets reset by the DPI proxy for someone who spends more than a few minutes on the site.

Fanjita

Sun Nov 09 2008, 12:05AM

Registered Member #555

Joined: Fri Oct 03 2008, 12:50AM
Posts: 36

Here's a bit of sample PHP code that seems to work, at least if I edit my cookies client-side:

----

# Names of distinctive spyware cookies
$PHORM_COOKIE_NAMES = array("webwise-uid", "nebuad");

# Name to use for a 'canary' cookie. This should be a random word or phrase,
# if you use the default then there's a chance that Phorm will be able to
# detect and neutralise these countermeasures.
$CANARY_COOKIE_NAME = 'canary';

#################################################################
# Write phorm detection cookies. This should be done before any HTML
# is sent.
#################################################################
function phormcheck_write_cookies()
{
global $PHORM_COOKIE_NAMES, $CANARY_COOKIE_NAME;

foreach ($PHORM_COOKIE_NAMES as $cookie_name)
{
setcookie($cookie_name, "Antiphorm Test Cookie", time() + 120, '/');
}

# Canary cookie
setcookie($CANARY_COOKIE_NAME, md5(time()), time() + 120, '/');
}

#################################################################
# Check phorm detection cookies. This should be done before any HTML
# is sent if we plan to perform redirects based on the result.
# Returns true if Phorm has been detected.
#################################################################
function phormcheck_check_cookies()
{
global $PHORM_COOKIE_NAMES, $CANARY_COOKIE_NAME;

# If we have no cookies present, then we must assume that the client is
# a first-time visitor, or is blocking all cookies. In either case, we
# won't be able to detect Phorm this time around.
if (empty($_COOKIE))
{
return false;
}

# Similarly if our canary cookie is not present, then we can't assume
# anything too fishy.
if (empty($_COOKIE[$CANARY_COOKIE_NAME]))
{
return false;
}

# So we have our canary cookie. If any of the phorm cookies is not present,
# then we can assume foul play.
foreach ($PHORM_COOKIE_NAMES as $cookie_name)
{
if (empty($_COOKIE[$cookie_name]))
{
return true;
}
}

return false;
}

---

The choice of the canary cookie name is left up to the local site, that way it should be difficult for phorm to detect and counteract any particular pattern.

To use it you would call phormcheck_write_cookies() before any HTML has been output, then whenever you want to check if Phorm appears to be active, call phormcheck_check_cookies() - a true return value indicates that something suspicious was detected.

madslug

Sun Nov 09 2008, 12:28AM

Registered Member #266

Joined: Tue Apr 01 2008, 12:11PM
Posts: 772

There is also a simple php function to test whether or not the browser is accepting cookies

Setting a Basic Cookie

The PHP function for setting cookies is called:

setcookie()

It is a PHP function which can be used without returning a value (for example you can simply execute a setcookie()) command, or you can take the return value and use it. The setcookie() function returns a boolean (true or false) value depending on whether it is successful. So you could execute:

if(setcookie())
{
echo "Cookie set";
}
else
{
echo "Cookie not set";
}

http://www.freewebmasterhelp.com/tutorials/cookies/2

Mel

Sun Nov 09 2008, 12:40AM

Registered Member #137

Joined: Sat Mar 08 2008, 06:00PM
Posts: 322

felixcatuk wrote ...

Privoxy

If you look at the vanilla wafer configuration of Privoxy, you'll find you can force an opt out cookie to be set. The downside is that you will trigger false detections on web sites (because it will appear that all your requests are infected by Phorm cookies).

That's the one reason I've held off publishing such a solution.

Sending specious webwise-uid cookies will also break the odd website.

Webwise detection scripts ought not to be triggered if webwise-uid cookies are present on port 80, as this would indicate that the user's connection currently isn't phormed - the user may be currently using their laptop on a non-phormed work connection for example, but are phormed at home, or hopefully have recently changed to an non-phormed ISP.

The approach I used in firephorm was to send webwise-uid cookies only on port 80 which shouldn't trigger detection scripts if phorm is not there to strip them and have the default option to only send a webwise-uid cookie after 3 redirects have occured as I figured some people would enable faking cookies before webwise is active - which would prevent firephorm warning the user that webwise was live as there would be no webwise redirects to detect.

[ Edited Sun Nov 09 2008, 12:41AM ]

Fanjita

Sun Nov 09 2008, 10:28AM

Registered Member #555

Joined: Fri Oct 03 2008, 12:50AM
Posts: 36

madslug: As I understand it, that won't detect whether or not the client is accepting cookies, just whether the server was able to set a response header for it. (See official PHP manual here: http://uk3.php.net/setcookie).


Jump: Back to top

BadPhorm - When good ISPs go bad!

Navigation

Adjust font size:

Forums

Discover more