Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]

[Fernando Gont <[e-mail]>]

Hi, Brian,

(It looks like this is a spin-off thread from another thread, so my 
apologies if I'm missing something)

If the address you are trying to test is assumed to be that of a CE 
router, an attacker would probably try:
fe80::  and/or
PREFIX::

instead.

works as charm in my dual-stack home scenario :)

P.S.: not to mention the obvious ff02::1 and ff02::2 -- but these might 
or might not work with JS.

Thanks,
Fernando




On 29/6/22 20:02, Brian E Carpenter wrote:
> One more item about scripting attacks on link-local literal URLs:
> 
> I spent a little time investigating this, using LL addresses
> without a zone ID, but with current browsers on Windows 10,
> where a default (null) zone ID is supported.
> 
> I won't give details here, but it is quite possible to test
> whether a specific LL address is present or absent on the local
> link, in fewer than 20 lines of Javascript embedded in an
> HTML document. However, it takes about 3500 milliseconds,
> because I could not time out the HTTP request sooner than that
> and still detect an active address. (The target that I tested
> was my CE router, the browser was FireFox. The result for
> Chrome was similar.)
> 
> That means that a full search of the 64-bit IID space would
> take 2^64 x 3500 ms, or about 2047 billion years.
> 
> Even a full search of the 24-bit low order bits of a Modified EUI
> identifier would take 2^24 x 3500 ms, or about 1.9 years.
> (We can assume that a smart attacker would know the possible
> manufacturer ID values for popular CE routers, so would only need
> to brute-force search the low order bits: see RFC7707.)
> 
> I don't think we should put these numbers in the draft, but I
> think they illustrate (a) that a successful exploit is probably
> not practical today and (b) using Modified EUI identifiers
> is a really bad idea (which we knew, of course).
> 
> Regards
>     Brian
> 
> On 22-Jun-22 20:28, Philipp S. Tiesel wrote:
>> Hi Brian,
>>
>>> On 21. Jun 2022, at 22:32, Brian E Carpenter 
>>> <[e-mail] <mailto:[e-mail]>> 
>>> wrote:
>>>
>>> On 21-Jun-22 22:07, Philipp S. Tiesel wrote:
>>>> Hi Brian,
>>>>> On 17. Jun 2022, at 06:27, Brian E Carpenter 
>>>>> <[e-mail] <mailto:[e-mail]>> 
>>>>> wrote:
>>>>>
>>>>> Philipp,
>>>>>
>>>>> First, thanks for taking the time to read the draft. Some comments 
>>>>> in line:
>>>>>
>>>>> On 15-Jun-22 01:54, Philipp S. Tiesel wrote:
>>>>>> Dear authors and WG,
>>>>>> based on this WG last call, I reviewed the document. Overall, it 
>>>>>> is well written and mostly ready to publish,
>>>>>> but I have a) one issue with the Security considerations section 
>>>>>> and b) a possibly stupid question on usefulness in web context:
>>>>>> a) The Security Considerations Section states:
>>>>>>> It is conceivable that this format could be misused to probe a local
>>>>>>> network configuration in some way. However, that would only be
>>>>>>> possible for an attacker that had already gained sufficient control
>>>>>>> of a host to originate HTTP messages. Such an attacker could more
>>>>>>> easily probe using basic mechanisms such as the "ping" command.
>>>>>> Is this true? What prevents an attack from embedding scoped IPv6 
>>>>>> addresses in HTML documents, e.g., as part of an AD.
>>>>>
>>>>> Nothing, except that the attacker has no way of knowing a 
>>>>> link-local address in advance, and the search space for interface 
>>>>> identifiers is 2^64 (since we abandoned Modified EUI64).
>>>> The CPEs I used recently, e.g,, products from AVM, still do EUI64 
>>>> for link-local, secured IIDs are only used for GUAs.
>>>
>>> I have a FritzBox and indeed it uses EUI64, both for link-local (its 
>>> address as the default router) and for its address as a DNS server 
>>> (GUA or ULA).
>>>
>>>> Assuming an attacker who wants to use this as a 
>>>> fingerprinting-attack and has some idea which CPEs are used from 
>>>> which provider, this dramatically reduces the search space and may 
>>>> make fingerprinting feasible.
>>>
>>> Indeed. However, I am not sure that the browser itself supporting the 
>>> link-local zone ID will change that, especially on hosts that support 
>>> a default zone for link-local, where RFC6874[bis] is not even required.
>>
>> I guess the problem is rather exposing Link-Local networking as an URL 
>> that the Zone-ID itself.
>> Adding the Zone-ID is just moving it from “something broken no-one 
>> really implemented” to “something that has a fair chance getting 
>> implemented.
>>
>> So, I agreed that the attack vector is not new and not really changed 
>> by draft-ietf-6man-rfc6874bis. Still I would prefer mentioning it in 
>> the security considerations and being less optimistic about EUI64 (and 
>> other schemes that enable fingerprinting) going away.
>>
>> AVE!
>>     Philipp
>>
>>> Brian
>>>
>>>>>
>>>>> So, as I realised while reading Ted Lemon's comment, the only 
>>>>> available mechanism seems to be Javascript that would search the 
>>>>> fe80::/64 space for a valid address. I just don't know enough about 
>>>>> what JS can do to investigate this. Any further input would be very 
>>>>> welcome.
>>>>>
>>>>>> While the security model of the browser/device should prevent 
>>>>>> abusing it from taking action REST calls to your home router, 
>>>>>> including a well-known image from such a device should be possible 
>>>>>> and could be used to verify an identity by linking to the EUI64 
>>>>>> address of your home router and verifying the image was loaded. 
>>>>>> This is far easier than “pinging” the router.
>>>>>
>>>>> I suppose there are many old home routers still using Modified 
>>>>> EUI64, but even so, the Interface ID contains 48 arbitrary bits 
>>>>> (even the OUI bits have to be guessed). So there is quite a 
>>>>> guessing game, and by the way, guessing the IPv4 address of the 
>>>>> home router should be *much* easier. Is this an exploit that anyone 
>>>>> will find useful?
>>>> Based on the experience in the cookie and tracker wars, this seems 
>>>> not too far-fetched to assume someone tries to use CPE IIDs as 
>>>> super-cookie.
>>>> Still, this kind of attack seems relatively easy to mitigate by 
>>>> restricting the usage of IPv6 literals with zone-identifiers.
>>>>>
>>>>>> b) Assuming a device has only link-local connectivity and a web 
>>>>>> interface, is there a way to reference “same interface as used for 
>>>>>> this connection”?
>>>>>
>>>>> Not that I can think of. In an o/s that assumes a default zone 
>>>>> (recommended by RFC 4007, but not always implemented) the same 
>>>>> effect might be possible, but that is true today, at least on Windows.
>>>>>
>>>>>> If not, such a web interface could only use relative links and 
>>>>>> things like re-direction to https will become hard.
>>>>>
>>>>> Thanks again. I think we need to ask for an early security review 
>>>>> to get this right.
>>>>>
>>>>> Brian
>>>>>
>>>>>> AVE!
>>>>>> Philipp
>>>>>>> On 11. Jun 2022, at 03:56, Brian E Carpenter 
>>>>>>> <[e-mail] 
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>> Dear 6man-chairs (especially Jen),
>>>>>>>
>>>>>>> The authors believe that this draft is now stable and we request 
>>>>>>> a WG Last Call. It would be nice to get this done before the IETF 
>>>>>>> meeting.
>>>>>>>
>>>>>>> Regards
>>>>>>> Brian Carpenter
>>>>>>>
>>>>>>> On 19-May-22 12:52, Brian E Carpenter wrote:
>>>>>>>> There's been no more discussion for several weeks. Can we move
>>>>>>>> on to a WG Last Call?
>>>>>>>> Regards
>>>>>>>> Brian Carpenter
>>>>>>>> On 08-Apr-22 14:29, Brian E Carpenter wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This version reflects comments at the IETF and on the list.
>>>>>>>>> Change log:
>>>>>>>>> * Extended use cases (added Microsoft WSD)
>>>>>>>>> * Clarified relationship with RFC3986 language
>>>>>>>>> * Allow for legacy use of RFC6874 format
>>>>>>>>> * Augmented security considerations
>>>>>>>>> * Editorial and reference improvements
>>>>>>>>>
>>>>>>>>> Note that some of the text about RFC3986 that Shang Ye
>>>>>>>>> suggested to remove has been retained, but modified. Further
>>>>>>>>> comments about this, or any other aspect, are very welcome.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Brian + co-authors
>>>>>>>>>
>>>>>>>>> On 08-Apr-22 14:13, [e-mail] 
>>>>>>>>> <mailto:[e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>> A New Internet-Draft is available from the on-line 
>>>>>>>>>> Internet-Drafts directories.
>>>>>>>>>> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>>>>>>>>>>
>>>>>>>>>> Title : Representing IPv6 Zone Identifiers in Address Literals 
>>>>>>>>>> and Uniform Resource Identifiers
>>>>>>>>>> Authors : Brian Carpenter
>>>>>>>>>> Stuart Cheshire
>>>>>>>>>> Robert M. Hinden
>>>>>>>>>> Filename : draft-ietf-6man-rfc6874bis-01.txt
>>>>>>>>>> Pages : 13
>>>>>>>>>> Date : 2022-04-07
>>>>>>>>>>
>>>>>>>>>> Abstract:
>>>>>>>>>> This document describes how the zone identifier of an IPv6 scoped
>>>>>>>>>> address, defined as <zone_id> in the IPv6 Scoped Address 
>>>>>>>>>> Architecture
>>>>>>>>>> (RFC 4007), can be represented in a literal IPv6 address and in a
>>>>>>>>>> Uniform Resource Identifier that includes such a literal 
>>>>>>>>>> address. It
>>>>>>>>>> updates the URI Generic Syntax and Internationalized Resource
>>>>>>>>>> Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>>>>>>>>>> obsoletes RFC 6874.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ 
>>>>>>>>>> <https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/>
>>>>>>>>>>
>>>>>>>>>> There is also an HTML version available at:
>>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Internet-Drafts are also available by rsync at 
>>>>>>>>>> rsync.ietf.org::internet-drafts
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> I-D-Announce mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>>>
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>>>>>> -- 
>>>>>> Philipp S. Tiesel
>>>>>> https://philipp.tiesel.net/ <https://philipp.tiesel.net/>
>>>>>> .
>>>> AVE!
>>>> Philipp S. Tiesel
>>>> -- 
>>>> Philipp S. Tiesel
>>>> https://philipp.tiesel.net/ <https://philipp.tiesel.net/>
>>
>> AVE!
>>    Philipp S. Tiesel / phils…
>> -- 
>>     {phils}--->---([e-mail] 
>> <mailto:[e-mail]>)--->---(http://phils.in-panik.de 
>> <http://phils.in-panik.de>)----,
>>        wenn w eine   aube ist dn      man au dran dre en               
>>     |
>>             o     Schr        an muss     hc         h   (Kurt 
>> Schwitters) |
>> :wq!  <----(phone: [phone])---<---(jabber: [e-mail] 
>> <mailto:[e-mail]>)----'
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492