On Sunday, July 12, 2015 11:38 AM, Ted Lemon wrote:
On 07/11/2015 05:28 PM, Christian Huitema wrote:
OK, you are probably correct that this is just one of the many attacks
possible when
connecting to insecure networks. Then, of course, there is the whole idea of
letting an untrusted
DHCP server direct one's browser to an arbitrary web page. Looks like an
ideal setup for zero
days and phishing tools. Ideally, we should only process the redirected page
into a fairly tight sandbox...
This is just one example of the "everything is broken" problem. In
point of fact, if you can inject packets on the local wire and sniff packets
off of the local wire, you can easily
send malware to the host simply by providing it with mostly correct
information, and then once the hotspot
detector has been bypassed, hack the next http query that goes by, stuffing
your malware, or instructions
to fetch your malware, into the HTML.
Except that local attackers cannot do that if the host is programmed to only
query using HTTPS, or if the host sends all its traffic through a VPN. The "web
capture" hack is special, because it forces the host to read a web page
programmed by the untrusted local admin. As such, it opens a vulnerability
window. My point is that the draft should recognize that window, and the three
attack vectors: malicious hot spot admin, DHCP response spoofing, and in the
case of clear text network packet injection in the capture portal web page.
My advice to implementers would be to consider the capture portal web page as
fundamentally untrusted, and for example not allow it to run scripts. Then
system administrators could consider "white listing" some of these pages,
provided of course that the connection could be authenticated and protected
through HTTPS.
-- Christian Huitema