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

[Brian E Carpenter <[e-mail]>]

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]>)----'
>