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
