I thought I'd have a quick look at one of Phorm's rivals, Nebuad.
Apparently much like Phorm, Nebuad uses a cookie based opt-out. Opting out or back-in is achieved by requesting a URL, in response to which Nebuad's server sends your browser its opt-out, or opt-in cookies...
Surprisingly, the opt-in /opt-out pages are indexed by google: http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optin&meta=.
The above search no longer works try http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optout+OR+optin_done&btnG=Search&meta=.
Also cookie "h" is no longer set.
WARNING: if your ISP uses Nebuad and you've already opted-out, then opening the second search result shown in google (www.nebuad.com/privacy/optin_done.php) will almost certainly opt you back in.
WARNING: I've just noticed that Firefox has a page pre-fetch feature which might result in the opt-in page being accessed and the cookie changed just by clicking on the google search above (depends on which link appears first I think)- if you click on the link above, please make sure you opt-out afterwards.
Nebuad's opt-in/opt page can be found here:- www.nebuad.com/company/optout.php
Opting in creates 2 sets of 5 cookies, "o","u","c","h","w", one set in "a.faireagle.com", and the other in the "b.faireagle.com" subdomain. Opting out sets "o"="9" and deletes the other cookies.
o = 0 appears to indicate opted in.
o = 9 indicates opted out.
My guess is "o" might be a set of binary flags eg
bit #0 = 1 - don't track
bit #3 = 1 - don't show targetted adverts.
'c' is the name of an adserver.
'h' and 'u' are set to matching 14 digit numbers.
'w' is another 14 digit number, which appears to count upwards (could be a date and time perhaps?).
Different sets of numbers are generated for the a and b subdomains.
If you look at the bottom of the opt-in page you'll see the actual opt-in urls passed using a couple of <script> tags right at the very bottom after the closing html tag, the browser will request these urls and the server will set the cookies in the response and close the connection (no actual javascript is returned by the response).
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=yes&noads=none"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=yes&noads=none"></script>
And for the opt-out page.
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=no&noads=all"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=no&noads=all"></script>
There does not appear to be any measures in place to prevent an "evil" website from opting you back-in using the same method - try clicking on Google's cached optin_done link and check for faireagle.com cookies.
Friday, 16 May 2008
Thursday, 24 April 2008
Phorm Webwise diagram
 |
Phorm's system will intercept requests that don't contain their "webwise" tracking cookie and send them through a series of redirects to access and transfer the unique identity number they allocate to you from your webwise.net master cookie to a tracking cookie they'll create for each site you visit.
This cookie will expire after three days, until then your browser will send this cookie with future requests for the site and their system will strip the cookie from each request and use it to identify your profile as it analyses your http traffic - including the search parameters you enter into major search engines, and the content of the pages you view.
Dr Richard Clayton has updated his paper on Phorm webwise, after Phorm managed to recall more of the detail of their system twisty-little-passages-all-alike.
It now seem that an additonal redirect will occur if a webwise.net cookie isn't present to determine if the user is blocking webwise.net cookies, in which case the user's IP address will be blacklisted for 30 minutes to avoid infinite loops.
It seems logical to me that they would use a similar approach to determine if the user is blocking cookies for the actual site he is visiting, either by setting a test cookie with the first redirect if no cookies are present in the initial request, or by using an additional redirect.
A poster on Badphorm has pointed out that because phorm's system redirects the browser to a third party domain (webwise.net), the webwise.net cookie is in fact a third party cookie.
As reported in that thread Opera will correctly (according to rfc2965) block (neither send not accept) all cookies after a redirect to a third party domain occurs if the "accept only cookies from the site I visit" option has been enabled by the user. It will continue to block cookies until a user action occurs where the user can verify the domain requested -such as clicking on a link on the page (even if subsequently redirected back to the original URL).
This will also result in the genuine website not being sent its cookies after a Phorm redirect, which will cause problems for users of Opera that block third party cookies.
Sunday, 20 April 2008
Sky Netgear DG834GT-1skuk
These "tweaks" are currently only compatible with Firefox and Internet Explorer, unless otherwise indicated.
DG834GT Detailed Stats alternate version. (This version should also work in Opera and Safari)
Enable telnet Open telnet console to disable type "killall utelnetd" in the console. (Enable telnet should also work in Opera and Safari)
Extract ADSL Password and Username (Should work in Opera)
PPP debug mode logs PPP authentication attempts and LCP echo requests. Note this will cause your PPP connection to drop and reconnect. The PPP log can get very large if you leave it enabled.
View PPP log file (note that the PPP log contains your username and a hash of your password)
Delete PPP log file and cease PPP logging
Override Target Noise Margin % of default target margin 86%=6dB, 100%=7dB(default), 114%= 8db, 180%=12.6db... (also works in Opera)
Force G.DMT (ADSL1)
Reboot the Router, or restart the PPP connection for DNS changes to take effect. If you input invalid DNS servers, you will be unable to access the internet - to restore the original setting click the "use ISP allocated Domain Name Servers (default)" button above. This change can also be cleared by resetting the router to factory settings using the reset button in the back
This page must be downloaded and opened locally for these options to be enabled.
These settings are not particularily useful unless your connection is 100% stable as the Netgear's host file & its dns server will be reset every time the PPP connection is re-established after a drop.
Enter IP address <space> hostname (eg. 192.168.0.10 mel.lan)
(doesn't survive connection drop or reboot)
Reset DNS Server
If you think poor speeds are caused by your PC or wireless link - This will download a file to the router and time the download (if this test fails to work choose a download file with a shorter URL) Results are only a very rough estimate.
Input the URL of a file to download and its filesize (url must be quite short).
Please be patient, the page will only open once the file download has completed.
Download url
Filesize
(also works in Opera)
Alternative test: Downloads and displays the start and end times so that you can calculate the speed more accurately
Download url {44668/(end-start) Kbps}
DG834GT Detailed Stats alternate version. (This version should also work in Opera and Safari)
|
Enable telnet Open telnet console to disable type "killall utelnetd" in the console. (Enable telnet should also work in Opera and Safari)
Extract ADSL Password and Username (Should work in Opera)
PPP debug mode logs PPP authentication attempts and LCP echo requests. Note this will cause your PPP connection to drop and reconnect. The PPP log can get very large if you leave it enabled.
View PPP log file (note that the PPP log contains your username and a hash of your password)
Delete PPP log file and cease PPP logging
Target Noise Margin
Override Target Noise Margin % of default target margin 86%=6dB, 100%=7dB(default), 114%= 8db, 180%=12.6db... (also works in Opera)
Force G.DMT (ADSL1)
Connection Table (ip_conntrack)
DNS Settings
Reboot the Router, or restart the PPP connection for DNS changes to take effect. If you input invalid DNS servers, you will be unable to access the internet - to restore the original setting click the "use ISP allocated Domain Name Servers (default)" button above. This change can also be cleared by resetting the router to factory settings using the reset button in the back
This page must be downloaded and opened locally for these options to be enabled.
Add entries to router's hosts file
These settings are not particularily useful unless your connection is 100% stable as the Netgear's host file & its dns server will be reset every time the PPP connection is re-established after a drop.
Enter IP address <space> hostname (eg. 192.168.0.10 mel.lan)
(doesn't survive connection drop or reboot)
Reset DNS Server
Router based "speed test"
If you think poor speeds are caused by your PC or wireless link - This will download a file to the router and time the download (if this test fails to work choose a download file with a shorter URL) Results are only a very rough estimate.
Input the URL of a file to download and its filesize (url must be quite short).
Please be patient, the page will only open once the file download has completed.
Download url
Filesize
(also works in Opera)
Alternative test: Downloads and displays the start and end times so that you can calculate the speed more accurately
Download url {44668/(end-start) Kbps}
Thursday, 17 April 2008
WebWise? Phorming An Opinion
Are cookies a wise way to handle an opt-out?
I happened to see this javascript about a month ago and almost immediately noticed a potential problem with the way the opt-in works. As the issue would be blinding obvious to anyone with a minimal knowledge of web design and security, and the system isn't live, and the issue does not represent a security risk, and because the difference in opting in or out is questionable, I posted about it in a forum that was being frequented by PhormUKTechTeam at the time.
Contained within this javascript is the URL to enable or disable webwise, which is called with a single parameter which requests either an opt-in cookie with an unique ID, or an opt-out cookie from the webwise.net server. It seemed fairly likely that just by embedding a hidden image or iframe on a webpage, it would be possible to remotely enable targeted advertising for visitors to that webpage from a "phorming" isp without their knowledge, let alone consent.
All that would be required is an image tag with the source pointing to the opt-in URL, something like this:-
"<img src="Webwise_opt_in_URL" width=1 height=1>"
Now this opt-in method was no doubt "just a test" and I expect this will be fixed by the time Phorm's webwise system finally goes live, but for me it raises concerns about the quality of the design and coding.
I don't expect it to work for long, but for the time being here are a couple of buttons to opt-in or out of webwise. They do nothing more than use javascript to open the opt-in or opt-out URL in a hidden iframe. Opting in will create a cookie in the a.webwise.net domain UID=xxxxxxxxxxxx|| where xxxxxxxxxxx is a 22 character (128 bit base64 encoded unique ID) and if present remove the webwise.net OPTED_OUT cookie (and vice versa).
Leaking Webwise UID
Richard Clayton notes in point 24 of his analysis of the Phorm "webwise" system that the webwise UID of visitors to a website will be visible to that website if any subsequent accesses to it use "https" protocol (also see points 20 to 26). He also reports that the Layer 7 switch only inspects traffic on port 80, this would suggest that the webwise UID will also be visible to a website if it uses a port other than 80 for a subsequent access.
Richard Clayton notes in point 24 of his analysis of the Phorm "webwise" system that the webwise UID of visitors to a website will be visible to that website if any subsequent accesses to it use "https" protocol (also see points 20 to 26). He also reports that the Layer 7 switch only inspects traffic on port 80, this would suggest that the webwise UID will also be visible to a website if it uses a port other than 80 for a subsequent access.
Linking email addresses to webwise UID by spamming?
The email itself could purport to have been sent by a major retailer and to contain a printable £10 discount voucher, it might prove incentive enough to encourage recipients to view it, but I'm sure spammers could devise even better inducements.
Spammers could also capture the webwise UID and associate it with the user's email address by tricking the Phorm user into clicking on a link within the email (which contains the email address it was sent to encoded/obfusticated within the link). This wouldn't be limited to webmail.
The Phorm user's browser would attempt to open the page, phorm would intercept it and add its UID cookie to the domain, the spammers website would redirect the request to an https: page, and the phorm user's browser would re-request the https: page, passing the phorm webwise cookie to the site.
Phorm's selling point to users is anti-phisishing protection, so the users who might benefit from Phorm (if they didn't already have anti-phisihing protection), would be the same users who would be likely to click on the link.
Please sign the petition against ISPs monitoring your browsing activity for advertising purposes
Do any modern email clients still share cookies with a browser? Hmm, I guess webmail services.
Only it occurred to me that by spamming everybody @a_phorming_isp.com with an html email that contained a webbug designed to capture the UID, it might be possible for a spammer to compile a database of UIDs linked to email addresses.
The webbug could be an http: image link containing the email address it was sent to (ie your email address) suitably encoded eg:-
"http://Spammer.con/phormbug_YourEmailAddressHere.jpg"
If you view the email, your email client would request the image.
Phorm would use its triple redirect jiggery-pokery to intercept this request and copy the webwise.net UID to a webwise cookie in the "Spammer.con" domain, and redirect the client so that it resends the original request.
The spammer's server would then reply with a redirect to a php script with an https: URL in the same domain. eg
"https://Spammer.con/phormbug_YourEmailAddressHere.php"
The email client automatically requests this https: url sending the webwise UID cookie.
Using https: encryption bypasses phorm's intercept of the UID cookie, delivering the UID (cookie) and email address (encoded in the URL) to the spammer.
The spammer then sells a service to websites that allows them to email targeted spam to visitors to their website.
Only it occurred to me that by spamming everybody @a_phorming_isp.com with an html email that contained a webbug designed to capture the UID, it might be possible for a spammer to compile a database of UIDs linked to email addresses.
The webbug could be an http: image link containing the email address it was sent to (ie your email address) suitably encoded eg:-
"http://Spammer.con/phormbug_YourEmailAddressHere.jpg"
If you view the email, your email client would request the image.
Phorm would use its triple redirect jiggery-pokery to intercept this request and copy the webwise.net UID to a webwise cookie in the "Spammer.con" domain, and redirect the client so that it resends the original request.
The spammer's server would then reply with a redirect to a php script with an https: URL in the same domain. eg
"https://Spammer.con/phormbug_YourEmailAddressHere.php"
The email client automatically requests this https: url sending the webwise UID cookie.
Using https: encryption bypasses phorm's intercept of the UID cookie, delivering the UID (cookie) and email address (encoded in the URL) to the spammer.
The spammer then sells a service to websites that allows them to email targeted spam to visitors to their website.
The email itself could purport to have been sent by a major retailer and to contain a printable £10 discount voucher, it might prove incentive enough to encourage recipients to view it, but I'm sure spammers could devise even better inducements.
Spammers could also capture the webwise UID and associate it with the user's email address by tricking the Phorm user into clicking on a link within the email (which contains the email address it was sent to encoded/obfusticated within the link). This wouldn't be limited to webmail.
The Phorm user's browser would attempt to open the page, phorm would intercept it and add its UID cookie to the domain, the spammers website would redirect the request to an https: page, and the phorm user's browser would re-request the https: page, passing the phorm webwise cookie to the site.
Phorm's selling point to users is anti-phisishing protection, so the users who might benefit from Phorm (if they didn't already have anti-phisihing protection), would be the same users who would be likely to click on the link.
Please sign the petition against ISPs monitoring your browsing activity for advertising purposes
Using the webwise UID with a third party tracking system?
Tracking cookies are used by "data mining" companies to collect data as your visit partner websites. Some people consider them a privacy issue, and programs such as Ad-Aware identify and remove a large number of tracking cookies.
A leaking webwise UID could be captured by such a tracking system and by doing so, should its own Unique ID cookie be deleted, it could use the webwise UID to re-identify the visitor and restore its original UID cookie.
If a user opts out of webwise and subsequently opts back in, it would be possible for the third party tracking system to associate the new UID to the user's old UID, something webwise claim not to be able to do themselves.
Only by deleting both the tracking cookie and ALL webwise created cookies, including those stored in other domains, would it be possible for a user to ensure that they could not be re-identified by a third party tracking system.
Tuesday, 15 April 2008
Phorm Rant
Why I'm happy to use Google, but wouldn't countenance phorm.
In response to a post by Alex in www.badphorm.co.uk.
Well I know you didn't ask me, but if I might answer anyway.
Search engine provide me with a valuable service. Phorm's webwise is a disservice I can do without.
I can control what information search engines get to see about me, I don't have to use them at all if I don't want to, and so I don't have to be confident that I can trust them, or worry too much if they are secure.
I can't avoid all my traffic passing though my ISP's network except by moving ISP, but I trust my ISP primarily because I know it would be ILLEGAL for them to intercept my communications, and also to a lesser extent because I know that the shear bulk of other customer's communications make it highly unlikely that they would intercept mine unless they had a very good reason to want to target me.
Now phorm on the other hand, has the potential to intercept all my non-encrypted communications, and I'm expected to trust them and I'm expected to trust a Phorming ISP that has installed equipment designed to be able to analyse all of its customers browsing traffic en-mass, and apparently claims it is no longer bound by the legal requirement not to intercept my communications, because it has supposedly got my permission by using Man-In-The-Middle techniques to check for an opt-out cookie!
I'm also expected to trust that the level of detail of the information you collect and the extent to which you share it will never expand, even when advertisers start increasingly demanding more useful data and your competitors offer phorming ISPs superior systems that collect more detailed data that advertisers will pay more to exploit.
I'm also expected to trust that your system is secure, and that a hacker could never break in to it and find a way to subvert it into collecting the sort of data hackers are interested in. However small you might claim it is, why the hell would I take the risk!
In short, no I would not be comfortable using any ISP that had such a system connected to its network and I'd question the wisdom of anyone that is.
In response to a post by Alex in www.badphorm.co.uk.
Well I know you didn't ask me, but if I might answer anyway.
Search engine provide me with a valuable service. Phorm's webwise is a disservice I can do without.
I can control what information search engines get to see about me, I don't have to use them at all if I don't want to, and so I don't have to be confident that I can trust them, or worry too much if they are secure.
I can't avoid all my traffic passing though my ISP's network except by moving ISP, but I trust my ISP primarily because I know it would be ILLEGAL for them to intercept my communications, and also to a lesser extent because I know that the shear bulk of other customer's communications make it highly unlikely that they would intercept mine unless they had a very good reason to want to target me.
Now phorm on the other hand, has the potential to intercept all my non-encrypted communications, and I'm expected to trust them and I'm expected to trust a Phorming ISP that has installed equipment designed to be able to analyse all of its customers browsing traffic en-mass, and apparently claims it is no longer bound by the legal requirement not to intercept my communications, because it has supposedly got my permission by using Man-In-The-Middle techniques to check for an opt-out cookie!
I'm also expected to trust that the level of detail of the information you collect and the extent to which you share it will never expand, even when advertisers start increasingly demanding more useful data and your competitors offer phorming ISPs superior systems that collect more detailed data that advertisers will pay more to exploit.
I'm also expected to trust that your system is secure, and that a hacker could never break in to it and find a way to subvert it into collecting the sort of data hackers are interested in. However small you might claim it is, why the hell would I take the risk!
In short, no I would not be comfortable using any ISP that had such a system connected to its network and I'd question the wisdom of anyone that is.
Friday, 11 January 2008
Netgear DG834G
Detailed Stats
"Trained Path:" appears to indicate if your connection is interleaved.
Trained Path: 0 = Fast path. Trained Path: 1 = Interleaved. ip_contrack Routing table.
To enable telnet access on a Netgear DG834(G)
http://192.168.0.1/setup.cgi?todo=debug - this launches utelnetd -d
There is no root password so while enabled, everyone on the lan will have telnet access. Disable in the terminal by typing "killall utelnetd"
To enable ppp debugging
http://192.168.0.1/setup.cgi?todo=ppp_debug This puts pppd in debug mode and logs the establishment of the connection - LCP traffic to /tmp/ppp_log NB the output includes username and encrypted password.
http://192.168.0.1/ppp_log To view ppp_log
Delete ppp_log
To enable VPN debugging
http://192.168.0.1/setup.cgi?todo=vpn_debug
Select between Modem Only Mode (PPPoE bridge) and Router Mode
http://192.168.0.1/mode.htm
Disable Configuration Assistant
http://www.routerlogin.com/CA_HiddenPage.htm use this if you get stuck in the smart wizard (configuration assistant).
connect to speedtest@speedtest_domain- to reconnect to you ISP disconnect and reconnect using the router interface.
Show Command lines
Show nvram
This is not particularily useful unless your connection is 100% stable as the Netgear's host file will be reset every time the PPP connection is re-established after a drop.
Enter IP address <space> hostname (eg. 192.168.0.10 mel.lan)
Add Entries to DNS Server
Reset DNS Server
Subscribe to:
Posts (Atom)