1280307 - Updating newsletters preferences for any email address

Status: RESOLVED DUPLICATE of bug 1273757

(Websites :: Basket, defect)

Description

[Daniel Bakker]

Hello!

I'd like to report the following security vulnerability: it is possible to change the newsletter subscriptions for any email address. Normally a user can change his preferences by clicking a link on the bottom of every newsletter mail. This link has the following format: https://www.mozilla.org/en-US/newsletter/existing/{some-long-id}/. This "id" in the URL will make it very difficult (but not unlikely) to brute-force a valid number. However there is also another way to update a user's newsletter preferences:

http://basket.mozilla.org/news/subscribe/ can be used to change the newsletter subscriptions for any email-address.

Example: 
Send a POST request to http://basket.mozilla.org/news/subscribe/ with the following data:
newsletters=mozilla-foundation,firefox-friends,webmaker,connected-devices&email=[e-mail]

This will give a {"status": "ok"} response. Now if you check your email you will that you are now subscribed to 4 newsletters. If you check your subscriptions (the normal way, via the link in every email) you will see that you are actually subscribed now.

Comment 1

[Daniel Bakker]

Additionally: it is also not required to confirm a subscription (which normally is when subscribing via mozilla.org). Furthermore a complete list of valid newsletters can be found here: http://basket.mozilla.org/news/

Comment 2

[April King [:April]]

I would also add in my investigations that users don't even need to be subscribed to any newsletters in the first place.  You can take a list of random email address and easily subscribe them to every newsletter we have.

Comment 3

[April King [:April]]

Although I am rating this sec-moderate, I am concerned that this might put us in violation of laws regarding email marketing opt-ins. As such, it should probably be fixed at a faster speed than its risk level of moderate might indicate.

Comment 4

[Paul [:pmac] McLanahan]

It depends on which newsletter you subscribe to as far as whether you're required to confirm your email address before being subscribed. I'm unclear on how it's a problem that you can subscribe to any of our newsletters, as that is the point of having newsletters to which one can subscribe.

The IDs in the emails for managing the subscriptions of a specific email are generated randomly by UUID4 which would make it extremely unlikely for a valid one to be guessed, much less one for a specific email address.

In short what you've described is how the system is supposed to work. If we need to change it we'll have to involve the email marketing team (CCd).

Comment 5

[Daniel Bakker]

The problem here is that it is not needed to guess the UUID4. It is possible to change/manage subscriptions just by passing a valid email address.

Comment 6

[Daniel Bakker]

Additionally: if this is the way it is supposed to work I would at least expect some sort of rate-limiting measures. Now it is possible for someone to execute this request for a large email database, which will subscribe all of these addresses.

Comment 7

[Paul [:pmac] McLanahan]

> The problem here is that it is not needed to guess the UUID4. It is possible to change/manage subscriptions just by passing a valid email address.

Just like every newsletter signup form ever. You can enter random email addresses into newsletter forms all over the internet. You can't unsubscribe via email address only, and you can't confirm by email address, you can only subscribe because all anyone needs in order to subscribe to any mailing list is an email address. I could be missing something here but it seems like you're saying that the way email newsletters work everywhere is flawed?

> Additionally: if this is the way it is supposed to work I would at least expect some sort of rate-limiting measures. Now it is possible for someone to execute this request for a large email database, which will subscribe all of these addresses.

That would be indistinguishable from just people signing up for newsletters. We get thousands of subscriptions, and already have millions of subscribers. We could rate limit some, but it would be difficult to have it set at a meaningful level while not hitting a lot of false negatives. We could limit a naive action by IP but that's easily defeated. And what would be gained by subscribing random emails? Use of our resources? Making us look bad? I guess it could do that, but it doesn't seem a likely attack, and the very nature of newsletter signups is that they are unauthenticated.

Comment 8

[Daniel Bakker]

Okay, maybe rate-limiting is a bit too much. But why is there no CSRF protection?

Comment 9

[Paul [:pmac] McLanahan]

(In reply to Daniel Bakker from comment #8)
> Okay, maybe rate-limiting is a bit too much. But why is there no CSRF
> protection?

There's no request to forge. There is no auth and no session, and nearly all interaction with the basket API is not via browsers.

Comment 10

[April King [:April]]

Mailing lists should use double opt-ins, especially for the initial subscription, which this doesn't do.

> And what would be gained by subscribing random emails? Use of our resources? Making us look bad? I guess it could do that, but it doesn't seem a likely attack, and the very nature of newsletter signups is that they are unauthenticated.

Or getting our emails get marked as spam by enough users that we get blacklisted and/or spam blocked automatically.

Comment 11

[Jessilyn Davis]

(In reply to April King [:April] from comment #10)
> Mailing lists should use double opt-ins, especially for the initial
> subscription, which this doesn't do.

Our newsletters, upon initial subscription, are double opt-in for this very reason. Once you're confirmed and in our system, other newsletter subscriptions are single opt-in - including subscribing to newsletters via the email preference center.

If you've just signed up for a newsletter, you can access your email preference center and unsubscribe/subscribe without confirming - but you won't receive any newsletters until you confirm your subscription.

Comment 12

[Daniel Bakker]

Attachment: mozilla_mailing.png

I still don't understand how the confirmation is working then. Yesterday I created a new email address and subscribed myself for some newsletters using the scenario in this ticket/issue. After that I received 4 emails (see attachment) telling me that I'm subscribed now. I don't see any confirmation link/mechanism in here.

Comment 13

[April King [:April]]

I agree with the bug reporter, and I commented so a couple weeks ago.  You definitely _don't_ need to opt-in at all to end up being subscribed to all these newspapers.  I've subscribed brand new email addresses to all the newsletters at once.

Comment 14

[Jessilyn Davis]

I'm investigating Daniel's subscription history for the exact details. From the first look, it appears he signed up first via Test Pilot. Test Pilot is a single opt-in list since you have to log in with your Firefox Account to sign up for the program. Logging in with your verified Firefox Account means that you have told us that you have control over your email address, so we accept the opt-in without additional confirmation.

Once you are in our system for a single opt-in list, or have confirmed your subscription for a double opt-in list, when you subscribe to any other list, it is single opt-in. We have a global one-and-done double opt-in process for our system. 

This is why if you go to your email preference center (which you should only be able to access from a link in your email inbox) and you subscribe to other newsletters, you get welcome emails to those lists vs. confirmation emails for each individual email list.

April, if you let me know the email address you used and the steps you took, I can see if there is a bug to our system or if it's working as designed.

We want people to have full control over their subscriptions with us - and make sure that other people can't sign them up for newsletter - but we also want to make sure that we aren't putting in unnecessary barriers to people being able to opt-into an email relationship with us.

Comment 15

[Daniel Bakker]

I also used another (newly created) email address for which I did not create an account yet. This email address is [e-mail]. It looks like I'm receiving newsletters on this address as well, but I never used it to create an account nor have I confirmed any subscription.

Comment 16

[Jessilyn Davis]

Thanks Daniel. It looks like that user is subscribed to Webmaker - another single-opt-in list. This newsletter list hasn't made the migration to be a double-opt-in list. I'll flag this to the Webmaker team to update appropriately.

If you'd like to see what the double opt-in process should look like, you can sign up with a new-to-our-system email address with the signup form here: https://www.mozilla.org/en-US/ or https://www.mozilla.org/en-US/newsletter/

Comment 17

[Daniel Bakker]

OK, so this means that if I use the scenario that I described in the initial report (which is subscribing to Webmaker) this bypasses the double-opt-in for all other Mozilla newsletters?

Comment 18

[Jessilyn Davis]

Correct.  We have a global one-and-done double opt-in process for our system. 

Once you are in our system for a single opt-in list, or have confirmed your subscription for a double opt-in list, when you subscribe to any other list, it is then single opt-in.

It's important to note that double opt-in is not legally required. It is a best practice and we've made major strides to make our main newsletter signups be double opt-in. There are some smaller newsletters that we haven't made these changes to yet.

Comment 19

[Daniel Bakker]

Any update already on the progress of this issue?

Comment 20

[Daniel Veditz [:dveditz]]

see also bug 808566 (wontfix) and bug 823987 comment 14 where this appears to be desired behavior?

For good or ill this is known and thus ineligible for a bug bounty.

Comment 21

[Daniel Veditz [:dveditz]]

Also bug 1271414 and bug 1262893