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
