Let me count the ways.
If you think Phorm – the evil advert-spooking system practically all the UK’s eyeball ISPs want to force on you – isn’t so bad, I’ve got news for you. First of all, let’s have a look at this Grauniad Tech article.
BT’s 2006 trials certainly involved some sort of interception, because the data streams had extra Javascript inserted into them – which puzzled a number of people at the time. Two examples can be seen at the forums of raisingkids.co.uk and progarchives.com. In both, the Javascript and other tags inserted by the 121Media system are clearly visible, with one showing the referring page and possibly “interests” of the member. Both contain links to sysip.net – the 121Media-owned site through which BT sent browser requests during the 2006 trials and later ones in summer 2007.
OK. So not only were they snooping, but Phorm actually injects not just data – like a cookie – but code into your URL requests, so their customer websites react differently as a result. It’s especially worrying that what they are adding is JavaScript; it’s not just data, it’s program logic. It does things. And, as any user of modern Web 2.0 services should realise, you can do all kinds of things with it – for example, you can call other web servers from within a web page without reloading. There is no way for you – the person whose BT, Virgin or Carphone Warehouse billing record stands behind the IP address that stands behind the identifier Phorm assigned – to know what such code does until after the fact.
Now, consider this; the good people of F-Secure unpicking the latest trend in security threats, the iFrame injection. It works like this – a lot of websites catch the search requests they receive and cache them, either to speed up the search process or to provide suggestions with the search results. This means that the search string…appears in a web page on their servers. So, if you fire enough popular search terms (which you can get from their website…) in, and append your attack code, there’s a chance it’ll get cached. And then, a visitor who uses the same search terms will get a page that contains the attack code; JavaScript is executed in the client side – i.e on the visitor’s computer – so you’re in.
So, let’s put them together; if you’re a Phorm customer, you can get the interests and web habits (and billing data?) of everyone in the UK delivered to your dodgy website in real time, and then you can reload anything you damn well like in their browser based on that information. Suddenly – let’s back off here. It’ll be someone unpopular. At first. So bnp.co.uk or alghuraabah.co.uk sends you to www.sweeticklekiddiesandtentacles.203vggngh65t7.biz.cn; and there’s fuck all you can do about it, except try to explain the concepts of “deep packet inspection”, “iFRAME SEO injection”, and the like to a court of law.
Paranoia, right? Not so much.
You think that’s scary? Here’s some more F-Secure for you. There is at least one exploit out there, which could be delivered through the lines we just discussed, that writes dubious code to the BIOS – the low-level insect brain of a computer, the bit that lights up the screen, spins up the hard drive, and explains how to read the boot sector and start the operating system. The only fix there, I think, would be to format the fucking lot and install something completely different – or throw the damn thing in the sea.
But here’s where it gets bad; the thing nicks your online banking passwords. And then what does it do? It puts money into your bank account. Feel free to speculate.
Update: Now that’s what I call an April Fool from F-Secure. A cracker. This is of course without prejudice to the rest of the post, but I should have realised there would be no way they’d have included a live link to the exploit if it was real. If you were brave enough to follow it, well…you’d get the joke.
Um, isn’t that last one an April Fools?
So it is…
The iFrame injection is normally just done by hacking the website (or even by insiders). The point about it is that its hard to detect unless you’re actively looking. This means it stands a good chance of remaining undetected for a long period of time.
This doesn’t make a lot of sense to me:
“It works like this – a lot of websites catch the search requests they receive and cache them, either to speed up the search process or to provide suggestions with the search results. This means that the search string…appears in a web page on their servers. So, if you fire enough popular search terms (which you can get from their website…) in, and append your attack code, there’s a chance it’ll get cached. And then, a visitor who uses the same search terms will get a page that contains the attack code; JavaScript is executed in the client side – i.e on the visitor’s computer – so you’re in.”
But those search terms would have to include the Javascript. The only way that I can see this working is if you work out a way to trick a server into creating a page with your malicious javascript, and then somehow direct unsuspecting people to amazon.com (or whoever), where it will run in the same zone. Can’t imagine that’s possible at many sites, though.
“I should have realised there would be no way they’d have included a live link to the exploit if it was real.”
Well there was also this: “the banking trojan uses PCMCIA to inject code into the VGA”, not to mention its unusual payload… đ
But those search terms would have to include the Javascript. The only way that I can see this working is if you work out a way to trick a server into creating a page with your malicious javascript, and then somehow direct unsuspecting people to amazon.com (or whoever), where it will run in the same zone.
Yes. That’s the exploit; the target site is caching search queries and using them to dynamically generate a page including them, so you push the obfuscated JavaScript at it with popular search terms, until they cache it.
Then Google does the rest.
cian – also, the list of banking institutions you’d have to visit. “Terminal5.uk”? “national-bank-of-north-korea.iq”? V. amusing!
The quip about online banking passwords is particularly apt given this current article in The Register:
http://www.theregister.co.uk/2008/04/04/banking_code_2008/
Where the banking industry are introducing new rules making online banking customers responsible for any losses they incur if they don’t keep their PC security software up to date.
Quite how online banking customers who are tied into BT, Virgin or Talk Talk will manage that feat with a man in the middle phishing and spyware company having monitoring and intercepting equipment hardwired into the broadband network they are using should be interesting.
As should the legal cases against these three broadband providers from any online bank customers who suffer losses arising from any security breaches caused by this equipment.
And then of course there is the question of security from third party interception on BT desktops and lap tops used by their own staff – a breach of which is punishable by disciplinary action up to and including dismissal. Customer and other sensitive data on BT computers being something taken very seriously by the company.
Quite how this is going to be protected is going to be fascinating – unless of course the computers used by BT staff are not going to be linked to this kit from Phorm/121 media. Which begs the question as to why that should be? If it is security the company leaves itself open to the operation of double standards if it is not allowing its own computers to be linked up to this kit for security reasons but feels it OK to compromise the security of its own customers home and business PC’s.