Note that a password manager is a partial mitigation here, at least if it's tied into the browser and automatically fills in based on origin, much like WebAuthn is.
-Ekr On Mon, Apr 11, 2022 at 3:13 PM Richard Barnes <r...@ipv.sx> wrote: > Just to be clear: > > * These "picture in picture" attacks have been around for years, as Ben > points out. > * WebAuthn is not vulnerable, because its assertions are bound to the > origin, and a phishing site can't access the correct origin. > * Anything that doesn't involve asymmetric cryptography will be > replayable, and thus perishable, through this attack or others. > > > On Mon, Apr 11, 2022 at 5:21 PM Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > >> Thank you, Ben. Much appreciated. I’ll think about this a bit more and a >> few others now are as well. >> >> Best regards, >> Kathleen >> >> Sent from my mobile device >> >> On Apr 11, 2022, at 5:05 PM, Ben Schwartz <bem...@google.com> wrote: >> >> >> >> >> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty < >> kathleen.moriarty.i...@gmail.com> wrote: >> >>> >>> >>> Sent from my mobile device >>> >>> On Apr 11, 2022, at 3:52 PM, Ben Schwartz <bem...@google.com> wrote: >>> >>> >>> I think there may be a misunderstanding here. According to my >>> understanding, these attack pages do not need to contain any actual >>> subresources from the SSO provider. They simply provide a login UI that >>> matches the appearance of the SSO login, in order to trick the user into >>> entering their SSO credentials into an attacker-controlled tab. >>> >>> This doesn't seem like something that can be fixed by the TLS >>> working group. >>> >>> >>> Right, but maybe by people here who also work on the interfaces to where >>> credentials are stored? >>> >> >> This attack is on password-based security, so the credentials are stored >> in the user's head, and the user types them into an interface that they >> think is the SSO provider, but is in fact the attacker. It's literally >> window-dressing on a standard old-fashioned phishing attack. This page >> explains the technique: >> https://mrd0x.com/browser-in-the-browser-phishing-attack/ >> >> >>> It’s posed as a browser attack as that’s the current mechanism, but is >>> going after credentials to access SSO. I guess that could be replayed later >>> as well if only captured by this and doesn’t access the store, but the >>> article seems to say that the store is accessed. >>> >> >> That article appears to be an attempt to restate the original report on >> Ghostwriter published here: >> https://blog.google/threat-analysis-group/tracking-cyber-activity-eastern-europe/. >> It may be easier to understand the details from the original report. >> >> >>> >>> Thanks for thinking about it, >>> Kathleen >>> >>> >>> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty < >>> kathleen.moriarty.i...@gmail.com> wrote: >>> >>>> This has to be dealt with at the container interface for non-browser >>>> interfaces too, right? >>>> >>>> If there are OASIS and W3C WebAuthn active participants, it would be >>>> helpful to figure out the best place to deal with this issue. >>>> >>>> Thank you and sorry for a second message. >>>> >>>> Best regards, >>>> Kathleen >>>> >>>> On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty < >>>> kathleen.moriarty.i...@gmail.com> wrote: >>>> >>>>> Greetings! >>>>> >>>>> In thinking about the attacks prompting for credentials to access SSO >>>>> credentials in browsers, I am wondering if the fix is in the interface to >>>>> each type of storage container for credentials, e.g. OASIS PKCS#11, W3C >>>>> WebAuthn, and maybe OAuth if that has been hit as well by these attacks, >>>>> called "Browser in the Browser". >>>>> https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/ >>>>> >>>>> >>>>> Is there a way in the browser for an organization to configure (or can >>>>> there be in those interfaces) the only permitted addresses to prompt and >>>>> allow access to the interface, so not just the password is needed? It >>>>> seems like the best place to fix it even though each organization would >>>>> have to enter an allow list. The alternative would be deny lists of all >>>>> the >>>>> malicious sites performing this activity and that won't catch everything. >>>>> >>>>> Is this being discussed already somewhere? Hopefully. Perhaps there >>>>> are other ideas? >>>>> >>>>> Thank you. >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
