Mailing List Archive

Gmail confidential mode
Hi,

What do you know about "Gmail confidential mode" emails? I'm starting to
see a few of these come in to users now, and not sure how to treat them.
They are sent through gmail, but require a one-time passcode sent to the
recipient, so any potential threat is not transferred through the same
email (or any email at all).

The messages I've received were all tagged as spam due to bayes, but they
otherwise have no other spam indicators.

This doesn't appear to be anything new, but it's the first time I'm seeing
it. Just thought I'd share and see if anyone had any input on how they're
managing them.
Re: Gmail confidential mode [ In reply to ]
Alex <mysqlstudent@gmail.com> writes:

> What do you know about "Gmail confidential mode" emails? I'm starting to
> see a few of these come in to users now, and not sure how to treat them.
> They are sent through gmail, but require a one-time passcode sent to the
> recipient,

Did you actually look at them? What do they look like? What does the
recipient have to do to actually get the mail? Does this only work
gmail to gmail?

> so any potential threat is not transferred through the same
> email (or any email at all).

huh? I don't follow this at all.

It is a longstanding tradition to send malware through zip or encryption
to avoid scanning. I would view these with extreme suspicion as if you
are communicating with people you know and want privacy, the obvious
first step is to avoid gmail and use Matrix/Signal or OpenPGP mail, and
if it's from someone you don't know, well...n

> otherwise have no other spam indicators.

When you looked at the raw bytes in the mailspool, what was in it? What
does the SA debug output look like? It doesn't make sense that wouldn't
have done these things before posting, but you didn't explain.
Re: Gmail confidential mode [ In reply to ]
>
>
> > What do you know about "Gmail confidential mode" emails? I'm starting to
> > see a few of these come in to users now, and not sure how to treat them.
> > They are sent through gmail, but require a one-time passcode sent to the
> > recipient,
>
> Did you actually look at them? What do they look like? What does the
> recipient have to do to actually get the mail? Does this only work
> gmail to gmail?
>

Some of those questions I was hoping others could help me to answer. This
is a legitimate email service provided by gmail. It was routed through
google's servers only. It passed DKIM and SPF, but not DMARC. I don't think
it's only gmail-to-gmail, as the recipient is not a gmail account.

You can experiment with this by composing a new message in Gmail, then
clicking the "toggle confidential mode" lock/timer icon in the same tray as
where fonts and attachments are controlled.

The email includes a link to "view the email" where the user is then
directed to https://confidential-mail.google.com/ with a prompt to get a
one-time passcode to the same email address that apparently authorizes the
recipient to reveal the contents of the "secure" email. I didn't "send
passcode" on that URL because it would then send it to the real recipient
as well. It requires the passcode only if it's necessary to authenticate as
the recipient - if you're not already logged in as that recipient, for
example.

It's definitely suspect, as the subject is just "Fwd: Information" and
there are no details in the body as to its contents. The email is base64
encoded.

> so any potential threat is not transferred through the same
> > email (or any email at all).
>
> huh? I don't follow this at all.
>

Once you've authenticated yourself, the email is displayed there, at the
confidential-mail.google.com URL directly, not through some follow-up email.

> otherwise have no other spam indicators.
>
> When you looked at the raw bytes in the mailspool, what was in it? What
> does the SA debug output look like? It doesn't make sense that wouldn't
> have done these things before posting, but you didn't explain.
>

Yes, the initial email is relatively benign - it is a legitimate gmail
email sent through their servers and signed by them.

The spample I'm looking at now was quarantined only because their domain (
pcfixpos.com) is apparently blocklisted. It also hit BAYES_99.

* 1.0 DKIMWL_BULKMAILER_LOW ASKDNS: DKIMwl.org - Low scoring bulkmailer
* [pcfixpos-com.20210112.gappssmtp.com.lookup.dkimwl.org A:127.0.2.1]
* 1.5 DKIMWL_BL ASKDNS: DKIMwl.org - Low trust sender
* [pcfixpos-com.20210112.gappssmtp.com.lookup.dkimwl.org A:127.0.2.1]

Given that, I suspect this one is spam, but this is an interesting way to
distribute malicious links.
Re: Gmail confidential mode [ In reply to ]
On 10/16/22 8:14 AM, Alex wrote:
> Hi,

Hi,

> What do you know about "Gmail confidential mode" emails?

Not much.

> I'm starting to see a few of these come in to users now, and not
> sure how to treat them.

I think the /notification/ emails that Gmail sends for confidential
messages are /probably/ benign.

My understanding is that the actual confidential message is retained on
Google's system and that users navigate there using a web browser to see
the confidential message.

As such, the /notification/ message that comes through your system is
probably largely opaque.

> They are sent through gmail, but require a one-time passcode sent
> to the recipient, so any potential threat is not transferred through
> the same email (or any email at all).

Yep.

So there's nothing that your filtering system will have to detect and
react to.

IMHO this is no different than a "Come check out my new fancy website!"
email linking to a web page laden with malware. -- Eliding detection
of suspect URLs.

> The messages I've received were all tagged as spam due to bayes, but
> they otherwise have no other spam indicators.

I expect that the /notification/ emails will be fairly, if not quite,
benign.

> This doesn't appear to be anything new, but it's the first time I'm
> seeing it. Just thought I'd share and see if anyone had any input on how
> they're managing them.

:-)



--
Grant. . . .
unix || die
Re: Gmail confidential mode [ In reply to ]
On 2022-10-16 10:38, Alex wrote:
>
> > What do you know about "Gmail confidential mode" emails? I'm
> starting to
> > see a few of these come in to users now, and not sure how to
> treat them.
> > They are sent through gmail, but require a one-time passcode sent
> to the
> > recipient,
>
> Did you actually look at them?  What do they look like?  What does the
> recipient have to do to actually get the mail?  Does this only work
> gmail to gmail?
>
>
> Some of those questions I was hoping others could help me to answer.
> This is a legitimate email service provided by gmail. It was routed
> through google's servers only. It passed DKIM and SPF, but not DMARC. I
> don't think it's only gmail-to-gmail, as the recipient is not a gmail
> account.

I neglected to send my reply and found it in drafts, sorry for the late
reply.

This isn't e-mail, it's a hosted text document and a link sent by email.
It is functionally the same as putting something on a (vaguely) private
PasteBin and telling your recipient where to go look at it.

ProtonMail has their own thing, when you send an "encrypted" message to
someone not on ProtonMail...

Luckily these things don't usually take off since most people use email
because they want email.

Google is completely unable to address their outbound spam problem so it
is unlikely they'll manage to address their
spam-via-online-documents-that-bypass-spam-filters either and spammers
are good at finding ways to send messages that hide within something
otherwise legit looking.
Re: Gmail confidential mode [ In reply to ]
On 11/17/22 10:13 PM, Dave Warren wrote:
> This isn't e-mail, it's a hosted text document and a link sent by email.
> It is functionally the same as putting something on a (vaguely) private
> PasteBin and telling your recipient where to go look at it.

Agreed.

I have read about some email encryption methods that do send the
encrypted message but don't provide the key with the cipher text.
Rather the client has to get the key from the sender (or their host)
upon disposition.

This is germane as it means that the sender can refuse to give out the
key after a certain point. Thereby expiring the encrypted message
contents. (Assuming that the message encryption is sufficiently
advanced that it effectively can't be read without the key.)

N.B. message expiry is subject to the recipient saving the key for later
re-use and / or screen shot and / or over the shoulder security holes.



--
Grant. . . .
unix || die