The way in which the Phorm system works (see yesterday’s blog post) creates an interesting, and possibly unexpected, risk for the ISPs that decide to go ahead and deploy the system.
Quite clearly, web browsing from within these ISPs now depends on the correct functioning of the “Layer 7 switch” and Phorm’s “Anonymiser” machine. This should not be too much of a concern. Network engineers are used to designing out “single points of failure“. Thus, for example, the BT schematics obtained by The Register show parallel systems and cross-coupling of components, so that a single failure will not take out the system. Add in the fact that what are apparently single machines will almost certainly be clusters fronted by intelligent load-balancing devices, and the system is expensive, but extremely resilient.
However, there’s another rather less obvious issue that needs to be addressed.
The bouncing of all web requests back and forth with HTTP 307 redirections means that the system is critically dependent upon the correct resolving of the webwise.net domain. If, for whatever reason, the domain name system (DNS) didn’t return the correct answer when asked for the IP address of webwise.net, then everyone at that ISP would find that their browsing was seriously affected.
If the incorrect address came back as 127.0.0.1 then the customers wouldn’t be able to reach any websites at all — if it came back as the IP address of a machine in downtown St Petersburg, then that site could redirect their web sessions at will — and there’s likely some criminals in that city with some innovative ideas of what could happen next.
So the webwise.net domain has suddenly been promoted to become part of the Critical National Infrastructure (CNI).
The domain is currently hosted at GoDaddy, an american registrar. Last summer the rock-phish gang spent a week running phishing attacks not just against banks, as they usually do, but also against GoDaddy. The immediate reaction was that the criminals wanted to use captured credentials to purchase domain names for free — but wiser heads pointed out that with the login details for a GoDaddy account you were in full control of any domain names that had already been bought : the security of the websites of thousands of major companies (and a great many banks) was resting on the security of eight-character registrar login passwords.
However, firms that have considered the risk don’t buy $10 domain names, but spend rather more, and their registrar will insist on rigorous security checks before altering any details. We must obviously assume that webwise.net is not at risk from registrar phishing in this simplistic way.
The more likely way of subverting what webwise.net resolves to is called “DNS cache poisoning”. There are several ways of doing this (this Wikipedia article provides a helpful summary), most of which shouldn’t work if the ISP has configured their DNS server correctly.
However fundamental weaknesses in the DNS protocol (relying on 16bit values matching to show authenticity) means that DNS forgery attacks can only be made harder, not prevented altogether. Making it harder may currently be sufficient to make phishing attackers use simpler methods — but if the prize is the disruption of web browsing for millions of people…?
There are things that the ISPs can do to improve security — such as each of them making themselves authoritative for webwise.net, which should address the DNS forgery issue. Let’s hope that they haven’t overlooked this.
[[with acknowledgments to Matt Johnson and others involved in understanding this particular design risk]]
Richard,
To respond to your scenario above and to give reassurance that we have walked around, examined, checked, double checked and addressed all potential security issues in great detail…
There is no possibility of hijacking requests or re-routing them to St Petersburg (as per your example) using DNS.
Requests to any IP address sent out by users will be handled by the L7 device on the basis of the Host: header and correctly routed from there.
The only form of DNS misdirection that could affect the system is resolving webwise.net to 127.0.0.1 i.e. ‘localhost’.
However, in addition to steps to protect the DNS system, Phorm and the ISP’s monitoring ensures that any systemic problem with the ‘binding’ process is detected and the system set to passthrough until it is resolved.
And on a wider matter of protocol, if you have security concerns, could you follow the current Internet convention of reporting them to the vendor prior to publication? We find that there’s been a lot of unhelpful posting of pretty wild untruths (I see someone has posted a link on LBT to Startup Earth– an article which no one could accuse of being accurate or unbiased).
As you know, and have acknowledged on ukcrypto we have been open and are keen to continue that openness. We’re happy to give you all the answers you need but do ask that security issues come to us first so that inaccuracies don’t get replicated across the blogosphere.
Thanks
Radha / Marc
Richard,
I’d have pointed out the dependency upon a single network provider for the authoritative DNS for webwise.net (ev1/the-planet) as well. If you look at the path to the two dns servers (at least they are on different subnets…) they appear to pass through the same network device before hitting some filtering device… they are at the very least in the same facility (ivhou).
Not having this ‘close’ to the userbase (uk for some parts) and in a single facility seems negligent.
-Chris
@phorm
And on a wider matter of protocol, if you have security concerns, could you follow the current Internet convention of reporting them to the vendor prior to publication?
This isn’t a deployed system at present, but a paper design that will be beta-tested some time in the future. The convention is designed to protect users of fielded systems.
That said, I’m pleased to hear that you have addressed all security issues.
“That said, I’m pleased to hear that you have addressed all security issues”
shouldnt that be currently known security Issues?
by the way, given the wider http://www.theinquirer.net/gb/inquirer/news/2008/04/04/uk-numer-two-cyber-crime-chart
report yesterday.
might it be wise to look at the proposed layer7 Phorm gifted hardware and it’s currently known security issues ?
not to mention its new interactions with the 3rd party Phorm software that may or not reveal new 0day exploits.
they are using tryed and trusted Layer7 kit and not some new untested hardware, alongside this newest untested Phorm software version i assume?
thanks richard for your good work and highlighting this most important security aspect.
Given where they sit in the architecture, there is potential for Phorm’s L7 interceptor to introduce XSS vulnerabilities into most web sites that a user visits.
Charles Reis has done some research in this area:
http://www.cs.washington.edu/research/security/webtripwires.html
“To respond to your scenario above and to give reassurance that we have walked around, examined, checked, double checked and addressed all potential security issues in great detail…”
Presumably all that process is shown in your ISO 27001 registration scope document?
As your report (16) says, it makes sense for the “webwise.net” requests to be handled by the L7 switch at the ISP. So it doesn’t matter what IP address the DNS returns.
Then again, as has been said, if the DNS were to break entirely, the request won’t leave the user’s computer. So potential for DoS.
re comment 7 Phorm
Radha/Marc
Many users do resolve unwanted hosts to 127.0.0.1 in order that no information is exchanged with those hosts.
I have thousands of unwanted sites including several Phorm related sites such as webwise.net that I ensure are resolved to 127.0.0.1.
If the Phorm system is implemented by my ISP, it sounds like my internet connection will effectively be broken or degraded. This is totally unacceptable.
Tim
Is Phorm’s ISO 27001 registration document open yet for public inspection?
Also, apart from the word of a PR representative, how do we ‘know’ what due diligence has been applied to the software that Phorm will be supplying in their ‘black boxes’
Colin
Radha / Marc
You talk about conventions, but Phorm is by your own press releases still in the pre-deployment phase. It is not a live system, therefore to discuss potential weaknesses in the open could not directly help attackers. Trials are planned for April, and you’ll just have to delay them if you consider this as a risk.
Furthermore there is a convention on the internet to follow established protocols and document new additions in an RFC – your rather severe use of edge-of-protocols methods (THREE UNWARRANTED 307 REDIRECTS IN ALL MY BROWSING).
I rather trust Dr Richard and his colleagues a damned site more than a company who is promoting their own wares.
“Is Phorm’s ISO 27001 registration document open yet for public inspection?
Also, apart from the word of a PR representative, how do we ‘know’ what due diligence has been applied to the software that Phorm will be supplying in their ‘black boxes’
Colin”
what Phorm ISO 27001 might that be ?
is it another case of not registering until someone mentions it?, such as was the case with the
http://www.ico.gov.uk/ESDWebPages/Search.asp?EC=1 (search onphorm and you get)
“Date Registered: 30 January 2008 Registration Expires: 29 January 2009
Data Controller: PHORM UK INC”
it seems clear as late as March 10th Phorm didnt have a ISO 27001 registration.
http://www.piglet-net.net/pigblog/?p=861
“Phorm Comms team Says:
March 10th, 2008 at 3:24 pm
Hello CB,
No need for sarcasm! Google alerts alerted us. Google knows all. No we are not ISO 27001 certified.”
I’ve been catching up on this Phorm saga and reading with great interest.
One thing that has struck me is the “engagement” approach taken by Phorm to deal with negative publicity. This idea of going out and undergoing PR combat in the blogosphere, and maintaining a frequent blog of their own (6 posts already in nine days of April)… I wonder if it is fanning the flames?
In the UK when there is a banking security story, which LBT has plenty of experience of, the information content and engagement from the banks is absolutely minimal. And it sinks stories pretty quickly, not permitting them two sides. Now of course the big five banks are well established companies — here today, here tomorrow (except Northern Rock!), and Phorm is new and just getting started, so of course they may be justified in adopting different tactics, but still, is this level of engagement likely to be a successful tactic? My gut tells me no, better sometimes to be sheepish and suffer a little unrebutted criticsm.
Undertaking a thought experiment… put yourself in Phorm’s situation, and suppose also that you had no ethical or legal scruples at all, what would be the optimal tactic to ride out this negative publicity storm?
Mike
http://www.theregister.co.uk/2008/04/08/phorm_censors_wikipedia/
Re: If, for whatever reason, the domain name system (DNS) didn’t return the correct answer when asked for the IP address of webwise.net, then everyone at that ISP would find that their browsing was seriously affected. If the incorrect address came back as 127.0.0.1 then the customers wouldn’t be able to reach any websites at all
A standard ad-blocking technique is to use a hosts file that maps advert serving domains to 127.0.0.1, see eg:
http://www.mvps.org/winhelp2002/hosts.htm
An interesting (deliberate?) side-effect of the way that phorm works is that blocking their adverts will be more difficult.
As I understand the Phorm system, there needs to be an individual webwise.net at each ISP that implements Phorm.
So with BT, VM and TT on board there would be three webwise.nets out there. (Or rather in there, as the webwise.net server for each ISP would need to be at the ISP).
This being so, the DNS resolution of webwise.net, for clients of those ISPs, must be done in the Level 7 equipment and not by the usual Internet DNS servers at all. Though I expect these will all resolve yet a further webwise.net, for access by users of non-Phorm ISPs.
Hmmm. Does this Level 7 interception and forced resolution of webwise.net break any RFCs, I wonder?
The Leaked 2006 Trial Report indicated the Software in the Profiler can be updated “on the fly” probably with the permission of BT; but this does indicate if the BT System is compromised or tricked into allowing an Update “Authorized or NOT” then this indeed could be an issue with regard to CNI?