Risks associated with HTTP content injection?

Question

I'm curious about the risks associated with HTTP content injection, where an ISP injects content to pages accessed over non HTTPS connections.

Some examples:

1. http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/

2. http://m.theregister.co.uk/2015/01/06/gogo_ssl/2

I'm specifically asking about situations where:

1. The injection is only carried out against HTTP connections. The ISP is not spoofing SSL certificates.

2. The injected content is non malicious. For example, a banner listing your remaining free minutes on a hotel WiFi connection.

Does the act of introducing this content introduce any additional attack vectors other than those normally associated with using HTTP?

Answer 1

Considering that the code they inject can be anything, one would have to assume that there are risks. Perhaps their code has a vulnerability in it that allows injection. Perhaps it obscures important items on the page. Perhaps it references an external resource (eg: JavaScript) of less security. Who knows? It certainly seems a risk to me.

There are other risks that you are exposed to independent of the injection. For example, they are probably providing a custom DNS of unknown behavior. So you're at their risk for DNS security.

In fact, how do you actually know you're using the hotel's WiFi router? In general you can't.

It is considered bad to use open WiFi routers.

Using a VPN (I use PIA) is generally considered a secure strategy.

Answer 2

An active attacker who positioned to alter your network traffic can do anything your ISP can do to your HTTP traffic. In that sense, one MITM (your ISP) injecting content into a page isn't going to alter the ability of another MTIM (an attacker) to read or write your traffic.

However, the main concern seems to be with passive attacks that are minigated by the service by client-side mechanisms. From your first article:

Even if Comcast doesn't have any malicious intent, and even if hackers don't access the JavaScript, the interaction of the JavaScript with websites could "create" security vulnerabilities in websites, Schoen said. "Their code, or the interaction of code with other things, could potentially create new security vulnerabilities in sites that didn't have them," Schoen said in a telephone interview.

As a trivial example, suppose a site consumes JSON supplied as a URL parameter like http://example.com/show?json={"foo":5,...}. The site uses the JavaScript function JSON.parse to parse the JSON. Meanwhile, a thoughtless developer at the ISP has included the line JSON.parse = function(e){return eval("("+e+")")}; in their MITM script (because JSON.parse isn't supported in older browsers, and its behavior is basically a subset of eval anyway).

This would obviously allow an attacker to send you a link like http://example.com/show?json=sendToBadGuys(document.cookie) to potentially disastrous result. The attacker doesn't need to be in a position to intercept your traffic; the attacker only needs to be in a position to get you to click on a link. The site was given a new security vulnerability by your ISP.

Of course, no one is foolish enough to completely overwrite JSON.parse with eval (or, that's the dream, anyway), but this example demonstrates that a MITM's ability to muck around with the JavaScript environment is clearly a dangerous thing, even when well-intentioned.

Also, as a completely separate concern, any information the well-intentioned MITM includes could be read by a malicious MITM. For example, if your hotel banner adds personal information like a "Time remaining for John Smith in Room 123: ten minutes" to all your HTTP web pages, that's obviously a concern as well.

Answer 3

risks associated with HTTP content injection ...I'm specifically asking about situations where ...the injected content is non malicious

So you are asking in effect if anything bad can happen when injecting content which is not malicious by itself. The most obvious things are:

• Broken injections, which are not intended to be malicious but unintentionally introduce new vectors for XSS attacks or similar. I'm not aware of an actual example for HTML injections but some ISP do similar "content adaption" when the user tries to access non-existent sites and this actually led to exploits.
• Injection of 3rd party trackers and ads can cause the problems ads and trackers have without injection, i.e. Malvertising etc.

Less obvious is that injection might simply go wrong or interact badly with the site and thus cause a change in the behavior of the site. Some examples are redefining Javascript functions used by the user, redefining id's of HTML elements which cause unintended interaction with CSS or Javascript etc. And then there are fragile sites which are kind of broken already but which get processed by the (far to tolerant) browsers anyway. These sites might then unexpectedly behave in a different way.