Re: [arch-d] Treating "private" address ranges specially

[Christian Huitema <[e-mail]>]

On 3/31/2021 8:57 PM, Martin Thomson wrote:

> On Thu, Apr 1, 2021, at 14:33, Christian Huitema wrote:
>> Do you have a description of the type of attacks you are thinking off?
> This is a general problem of which I have only a handful of concrete examples.
>
> The proposal mentions SOHO Pharming, though the link is broken.  In essence, that attack abused default passwords and poorly secured routers to allow DNS configuration on those routers to be hijacked.  This sort of thing is fixed by any of a bunch of things (HTTPS, better passwords, changes to local topology, DoH), but it was still shockingly effective.
>
> The other example I'm aware of is the Zoom problem (last year?  seems longer ago) where they ran a server on loopback that took instruction from 
random websites.  That was poorly secured and could be exploited.
>
> I'm not clear on whether this particular proposal aims to address this (it might not) but enumeration of servers on local networks could be another target.  (It doesn't appear to attempt to block the timing side channels that are typically used for this, but it could.)

I found a copy of the SOHO Pharming paper at 
http://courses.isi.jhu.edu/netsec/papers/Driveby_Pharming.pdf. The 
attack required a combination of Java Applet or ActiveX, javascript, and 
routers configured with the default password. AFAIK, ActiveX is mostly 
gone. The two suggested mitigations were to (1) uninstall Java and (2) 
change the router password. Of course, not everybody will do that.

If I remember correctly, at the end of the discussion of request forgery 
attacks in the QUIC WG, most implementers concluded that the best we 
could do was "protect loopback", precisely because the definition of 
"private networks" is way to fuzzy to make defense practical. How is 
this different?

-- Christian Huitema