Subject: [TLS] SSO Attacks in Browser

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 11 Apr 2022 15:35:16 -0400

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 11 Apr 2022 15:47:18 -0400

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

-- 

Best regards,
Kathleen

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 11 Apr 2022 15:52:24 -0400

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.

On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 11 Apr 2022 16:42:37 -0400

Sent from my mobile device

> On Apr 11, 2022, at 3:52 PM, Ben Schwartz <[email-masked]> 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.
> 

Right, but maybe by people here who also work on the interfaces to where credentials are stored? 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.

Thanks for thinking about it,
Kathleen 

> 
>> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty <[email-masked]> 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.
>> 
>>> On Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty <[email-masked]> 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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 11 Apr 2022 17:05:47 -0400

On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty <
[email-masked]> wrote:

> 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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 11 Apr 2022 17:20:16 -0400

Thank you, Ben.  Much appreciated. I’ll think about this a bit more and a few others now are as well. 

Best regards,
Kathleen 

> On Apr 11, 2022, at 5:05 PM, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> 
>> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty <[email-masked]> wrote:
>> 
>> 
>> 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.
>  
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 11 Apr 2022 18:12:37 -0400

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 <
[email-masked]> wrote:

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Apr 2022 15:30:58 -0700

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 <[email-masked]> wrote:

> * Anything that doesn't involve asymmetric cryptography will be
> replayable, and thus perishable, through this attack or others.
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 Apr 2022 05:34:40 -0400

> On Apr 11, 2022, at 6:31 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 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
> 
> 
>> * 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.
>> 
Thank you. From a different thread, I thought WebAuthn was vulnerable. 

Best regards,
Kathleen 
>> 
>>> On Mon, Apr 11, 2022 at 5:21 PM Kathleen Moriarty <[email-masked]> wrote: