Open Bug 1564176 Opened 4 months ago Updated 4 months ago

Thunderbird 60.7.2 misbehaving after token expiration on monitor.firefox.com

Categories

(Thunderbird :: Security, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: bobm, Unassigned)

References

Details

Clients with a user agent string of "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Lightning/6.2.7.2" occasionally get into a state that causes them to make the following type of request several times a second until blocked:

GET /user/verify?token=XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&utm_source=fx-monitor-emails&utm_medium=email&utm_campaign=verified-subscribers&utm_content=account-verification-email HTTP/1.1

Component: Untriaged → Security

Could someone please provide more background?

Which events typically trigger those requests? Is this something coming from the Gecko browser engine, or from the Thunderbird code? Or is supposed to be based on a manual click by the user, on a link in an email, only?

Flags: needinfo?(bobm)

(In reply to Kai Engert (:kaie:) from comment #1)

Could someone please provide more background?

Not much to provide, we are spotting this traffic in our logs with a Thunderbird user-agent string. It's not obviously malicious traffic but it is triggering our fraudulent traffic alerts. Beyond the user-agent string, which I don't have any reason to believe is being spoofed, I have no proof that this is Thunderbird. Similar traffic has been observed in our accounts infrastructure with Thunderbird UAs sending anomalous but not necessarily malicious traffic.

Which events typically trigger those requests? Is this something coming from the Gecko browser engine, or from the Thunderbird code? Or is supposed to be based on a manual click by the user, on a link in an email, only?

Because we are identifying this based on server traffic we have no way of knowing what triggers this issue. It looks consistent, to me, with a retry bug that is triggered by an expired token. I filed the bug in the spirit of "If you see something, file something".

Flags: needinfo?(bobm)

I appreciate you filed the bug! I had simply hoped you know the answer, no problem, I'll try to ask around!

Bob, let me try to ask you differently:

You said, you have access to the logs of monitor.firefox.com so I conclude you understand how that service works.

The link that you cited looks like a verification link from your service, is that correct?
Is your service creating those links, and sending them out to by email?

If yes, can you please explain what events trigger creation of those links and sending them out?

You mention "expired tokens". I don't understand how tokens work in the context of monitor.firefox.com
I'm guessing, you are talking about an "email address verification token" that your service created?

Is my understanding correct, that the following sequence of events could create one log entry in your logs?

  • user requests your service
  • you send out a verification email with a link containing a verification token
  • the user waits until after the token expires
  • the user clicks the link

If yes, we know that old emails could be related to triggering those entries.

We don't know yet why you'd get many of the same links in your log.
Is my analysis correct?

Flags: needinfo?(bobm)

(In reply to Kai Engert (:kaie:) from comment #4)

Bob, let me try to ask you differently:

You said, you have access to the logs of monitor.firefox.com so I conclude you understand how that service works.

The link that you cited looks like a verification link from your service, is that correct?

Yes.

Is your service creating those links, and sending them out to by email?

Yes.

If yes, can you please explain what events trigger creation of those links and sending them out?

When a user adds an email address to their Firefox Monitor account/subscription.

You mention "expired tokens". I don't understand how tokens work in the context of monitor.firefox.com
I'm guessing, you are talking about an "email address verification token" that your service created?

Yes, we generate a uuidv4 token for the verification link.

Is my understanding correct, that the following sequence of events could create one log entry in your logs?

  • user requests your service
  • you send out a verification email with a link containing a verification token
  • the user waits until after the token expires
  • the user clicks the link

If yes, we know that old emails could be related to triggering those entries.

Yes, this seems like the most likely explanation.

We don't know yet why you'd get many of the same links in your log.
Is my analysis correct?

Yes, you have everything correct.

Is it possible a thunderbird client may have an extension or plugin that tries to automatically click links?

Flags: needinfo?(bobm)

(In reply to Luke Crouch [:groovecoder] from comment #5)

Is it possible a thunderbird client may have an extension or plugin that tries to automatically click links?

I hope that Thunderbird never automatically follows links in emails without user request, I think that would be considered a privacy issue.

@Jörg, @Wayne, do you know of any scenario why Thunderbird could automatically access URLs that it finds in emails?

Do you know of any Add-on that might do that?

(In reply to Kai Engert (:kaie:) from comment #6)

(In reply to Luke Crouch [:groovecoder] from comment #5)

Is it possible a thunderbird client may have an extension or plugin that tries to automatically click links?

I hope that Thunderbird never automatically follows links in emails without user request, I think that would be considered a privacy issue.

@Jörg, @Wayne, do you know of any scenario why Thunderbird could automatically access URLs that it finds in emails?

Do you know of any Add-on that might do that?

I'm not familiar with this area of the world. Ben may know. Or Magnus.

Flags: needinfo?(ben.bucksch)

Had to block another IP address today due to this bug. Any progress?

This reminded me of bug 1134635, which I now tested and can reproduce. I'd bet this is a duplicate.

Flags: needinfo?(ben.bucksch)
See Also: → 1134635
You need to log in before you can comment on or make changes to this bug.