[e2e] Fwd: IP: Comcast man-in-the-middle attack

[David P. Reed]

Earlier we discussed the detection of middleboxes.  It's pretty clear this 
middlebox is detectable because of its bugginess.  It would be interesting 
to develop a collection of middlebox detection protocols, and I'm wondering 
if anyone knows of any systematic middlebox detector that can test for a 
range of known and unknown interceptors.

Another reason that one might want to deploy overlay networks systematically.

>Delivered-To: ip-sub-1-outgoing at admin.listbox.com
>Delivered-To: ip-sub-1 at majordomo.pobox.com
>X-Sender: farber at 127.0.0.1
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Fri, 08 Feb 2002 10:02:04 -0500
>To: ip-sub-1 at majordomo.pobox.com
>From: David Farber <dave at farber.net>
>Subject: IP: Comcast man-in-the-middle attack
>Sender: owner-ip-sub-1 at admin.listbox.com
>Reply-To: farber at cis.upenn.edu
>X-RCPT-TO: <dpreed at reed.com>
>
>
>>>Date: Thu, 7 Feb 2002 20:33:42 -0800 (PST)
>>>From: J Edgar Hoover <zorch at totally.righteous.net>
>>>To: <vuln-dev at securityfocus.com>
>>>Cc: <bugtraq at securityfocus.com>
>>>
>>>
>>>Comcast "transitioned" my city from @home about a month ago. In the past
>>>week, they implimented what appears to be an Inktomi Traffic-Server
>>>transparent cache at 68.34.76.99.
>>>
>>>This allows them to not only log all http requests, but to also log the
>>>response. Maybe they want to profile their customer browsing history for
>>>subsidiaries or resale to marketers. Maybe they want to do their part in
>>>The War on Freedom. Maybe they just want passwords to porn sites.
>>>Apparently they aren't using it to maximize bandwidth, because it's not
>>>configured to serve cached data.
>>>
>>>And yes, they have purchased a lot of the specific, unique hardware that
>>>is required to do all this logging.
>>>
>>>If a comcast victim/customer sends a packet to port 80 at any IP address,
>>>it is intercepted by the Inktomi Traffic-Server, the contents of the
>>>packet are examined for the GET url and the "Host:" field. The Inktomi
>>>Traffic-Server then sends the http request on to your destination from
>>>it's address with modified content and headers. It then caches the
>>>returned data, changes both the header and the content, and sends the
>>>packet to your machine with the spoofed IP of the server you had
>>>requested.
>>>
>>>This allows them to monitor and change (or insert ads into) what
>>>you read.
>>>
>>>Interestingly, regardless of what IP you address the packet to, the
>>>Inktomi Traffic-Server reads the Host: field to determine where to send
>>>the packet. I sent several packets from my home machine to one of my
>>>office machines, inside the packet was "Host: www.comcast.net". Comcast
>>>illegally intercepted, misinterpreted and altered this packet, and sent it
>>>to www.comcast.com. So, you might say there's a bug in this evil Inktomi
>>>Traffic-Server thing.
>>>
>>>Oh,
>>>
>>>
>>>US Code TITLE 18, PART I, CHAPTER 119, Sec. 2511. (2) (a) (i)
>>>
>>>
>>>"...a provider of wire communication service to the public shall not
>>>utilize service observing or random monitoring except for mechanical or
>>>service quality control checks."
>>>
>>>Does federal law only apply when a little guy snoops on a big corporation?
>>>Where are the feds now?
>>
>
>For archives see:
>http://www.interesting-people.org/archives/interesting-people/