| Iluvatar |
| Nov 18 2018, 8:46 PM |
| F27269545: T209794-2.patch |
| Nov 21 2018, 5:08 PM |
| F27269421: T209794.patch |
| Nov 21 2018, 4:18 PM |
Description
Problem:
A spammer can do the following:
- Register an account with a spam message in the username. For example, [[User:Follow the link and win $ 1000 - example.com]]
- Use [[Special:ChangeEmail]] to change the email address associated with that account to a "victim" address.
- The victim address will be sent a mail, from Wikimedia servers and a Wikimedia sender, with text like "Someone, probably you, from IP address xxx.xxx, has changed the email address of the account "Follow the link and win $ 1000 - example.com" to this address on Wikipedia."
- Use [[Special:ChangeEmail]] to remove the address from that account.
- The victim address will be sent another mail, from Wikimedia servers and a Wikimedia sender, with text like "Someone, probably you from IP address xxx.xxx, has removed the address of the account "Follow the link and win $ 1000 - example.com" on Wikipedia"
- The spammer can then repeat steps 2-3 for further victim addresses without delay. Alternatively, the spammer can skip step 3, which will result in a slightly different message (including the next victim's email address) being sent for the second message.
Proposed solution:
Apply a rate limit to Special:ChangeEmail, as legitimate users are unlikely to need to change email addresses so frequently.
While use of TitleBlacklist and AbuseFilter to prevent creation of accounts with names appropriate for this attack can help mitigate the issue, they do not directly prevent it.
Incidents:
- [[ru:User:Vash mail pobedil, vam nachisleno 14131p. Polushite po ssilke - www.p1oob.derg.pro 1]]
- The reaction of the victims: ticket of OTRS 2018111810004051, 2018111810002535, 2018111710004697.
Details
Related Objects
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | dancy | T302086 Set scap minimum python version to 3.7 | |||
| Resolved | None | T247045 Migrate all of production metal and VMs to Buster or later | |||
| Resolved | akosiaris | T249724 Track and remove jessie based container images from production | |||
| Resolved | Jdforrester-WMF | T224908 Drop jessie testing support | |||
| Resolved | Jdforrester-WMF | T224907 Drop php55 testing support | |||
| Resolved | Reedy | T205039 Release MediaWiki 1.27.6/1.30.2/1.31.2/1.32.2 | |||
| Resolved | Reedy | T205041 Tracking bug for 1.27.6/1.30.2/1.31.2/1.32.2 security release | |||
| Resolved | Bawolff | T209794 Need to make a limit of count of attempts to change email address |
- Mentioned In
- T225872: not possible to set email when email blocked
T224499: RELEASE-NOTES for 1.27.6/1.30.2/1.31.2/1.32.2
T205041: Tracking bug for 1.27.6/1.30.2/1.31.2/1.32.2 security release
T205048: Obtain CVEs for 1.27.6/1.30.2/1.31.2/1.32.2 security releases - Mentioned Here
- T197279: Direct POST to Special:ChangeEmail will bypass reauth check
Event Timeline
When you try to attach mail to an account, server sent to that email asking confirm the action:
Someone, probably you, from IP address xxx.xxx, has changed the email address of the account "%SPAM%" to this address on Wikipedia.
To confirm that this account really does belong to you...
And the second letter comes after you change mail to following address:
Someone, probably you from IP address xxx.xxx, has removed the address of the account "% SPAM%" on Wikipedia
There is no limit for changing mail. I was able to change the email 22 times per 3 minutes. Need to make limit 3 times per 10 minutes or 10 times per hour or something like that.
Otherwise, we will continue to receive letters from surprised random users of Internet who have become "victims" of a smart spammer.
I think I understand the issue here, but I'm not certain a solution would exist aside from reactively creating new AbuseFilter rules to match the new, spammy usernames. There are some existing anti-spam rules in place for AbuseFilter, including one that seems related to this issue - 499 on this list - but it's private. Perhaps you could leave a talk page note for the user who created that rule and inquire if said rule could be expanded.
In T209794#4763476, @sbassett wrote:including one that seems related to this issue - 499 on this list
That rule does not seem related to this task.
This task is requesting a rate limit apply to Special:ChangeEmail. I don't think AbuseFilter does anything for that special page.
@Anomie I was thinking of a way to proactively filter spammy usernames at step 1 "Register an account [[User:Follow the link and win $ 1000 - example.com]]". Apologies if that's unhelpful here.
It could help, but writing filters that would catch every possible spammy username is likely to be difficult.
At minimum, there must be a throttle for ChangeEmail. Perhaps restrict it to 1 change every 5 minutes, which should be enough for any reasonable use. Then further restrict it if already done more than eg. 10 times.
We should probably restrict it not only per account, but also per triggering IP address, to avoid the creation of N spammy accounts, and then having the same user rotating between them, albeit in such case the account creation limit should have kicked in much earlier.
Such spammers can not be stopped. Of course account block useless. Right now, the spammer blocked 3 days ago sends spam (otrs 2018112110002672).
Maybe a captcha would also be useful here. Especially for busy ip ranges.
In T209794#4765209, @Iluvatar wrote:Such spammers can not be stopped. Of course account block useless. Right now, the spammer blocked 3 days ago sends spam (otrs 2018112110002672).
Are you saying that we should urgently prioritize this due to someone abusing this?
Are you saying that we should urgently prioritize this due to someone abusing this?
Yes. The abuse is doing right now, and we have no way to stop it.
In T209794#4766081, @Bawolff wrote:T209794.patch1 KBDownload
Code-Review+1: Seems sane, haven't tested.
[16:37] bawolff !log deploy patch T209794
So as of right now:
- People who have been blocked from sending emails cannot change their email
- Users cannot change their email more than 4 times in a day [except they can always remove their email]
- All users from a specific IP cannot change their email more than 10 times in an hour [except they can always remove their email]
Hopefully this will curtail some of the issues. I'm not sure if these limits are the best choice, but it stops the immediate problem and we can more leisurely discuss the best approach.
So looking at the logs, I also see a lot of email changes from a chinese username too (e.g. like: 特邀您加徽信19665757在家即可零成本十尃采彡免去澳門舟车劳顿 ). [In english, translates to: Invited you to add Huixin to 19665757 at home to get a zero-cost pick-up and remove the Macau boat]
In total there was about 332,000 email changes in the last 7 days (!)
In T209794#4766166, @Bawolff wrote:So looking at the logs, I also see a lot of email changes from a chinese username too (e.g. like: 特邀您加徽信19665757在家即可零成本十尃采彡免去澳門舟车劳顿 ).
According to Google Translate, "Invited you to add Huixin to 19665757 at home to get a zero-cost pick-up and remove the Macau boat". Not extremely clear, but adding something "to get a zero-cost pick-up" sounds pretty spammy so probably another instance of this problem.
I realized i used 'ip' as the rate limit type, where really we want 'ip-all' I think -
In T209794#4766187, @Bawolff wrote:I realized i used 'ip' as the rate limit type, where really we want 'ip-all' I think -
T209794-2.patch1 KBDownload
I deployed updated version
Ok, looking at logstash - it definitely looks like this stuff started around noon nov 15.
Not counting the usernames with Vash mail pobedil in them, the top email changers are:
特邀您加徽信19665757在家即可零成本十尃采彡免去澳門舟车劳顿 23,692 特邀您加徽信号5136377在家即可零成本十尃采彡免去澳門舟车劳顿 319 Bugtesr 59 Bam 23765p tyt - www.tyt66.tk 8 DamirZaripovTest 7 Iluvatar 6
In T209794#4766239, @Bawolff wrote:Ok, looking at logstash - it definitely looks like this stuff started around noon nov 15.
Not counting the usernames with Vash mail pobedil in them, the top email changers are:
特邀您加徽信19665757在家即可零成本十尃采彡免去澳門舟车劳顿 23,692 特邀您加徽信号5136377在家即可零成本十尃采彡免去澳門舟车劳顿 319 Bugtesr 59 Bam 23765p tyt - www.tyt66.tk 8 DamirZaripovTest 7 Iluvatar 6
Should probably get these four locked?:
特邀您加徽信19665757在家即可零成本十尃采彡免去澳門舟车劳顿
特邀您加徽信号5136377在家即可零成本十尃采彡免去澳門舟车劳顿
Bam 23765p tyt - www.tyt66.tk
"Bugtesr" seemed a pretty suspicious username to me, too, but it is not (see below) ;)
Bugtesr (t) it's my account for test that bug (no rate limit).
In T209794#4766518, @Iluvatar wrote:Bugtesr (t) it's my account for test that bug (no rate limit).
Ah, gotcha. :) Kind of sounded like pre-testing for something like this. Glad to hear it is not!
Is https://phabricator.wikimedia.org/T211477 the same issue? The time frame seems to be the same, and it states that Wikimedia is now blacklisted by .
ugh, I spoke too soon. The users blocked from sending mail part of the patch looks to work ok, but appearently the rate limits get overridden in InitialiseSettings.php. Sorry, my bad, I should have tested this better.
Ok, rate limit added additionally to the wmf specific config file https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/478440/
Note, the current rate limit is now 4 per user per day, and 10 per IP address (even if logged in) per day.
People with "noratelimit" rights can override this (On enwiki that is: Bots, AccountCreators, Crats, Stewards, Event coordinators). Maybe this should be the type of thing where the noratelimit does not apply.
In T209794#4807919, @Aklapper wrote:Is https://phabricator.wikimedia.org/T211477 the same issue? The time frame seems to be the same, and it states that Wikimedia is now blacklisted by .
Mail.ru has problems receiving emails from non-russian servers. Not all email reach. This problem is already more than 10 years old.
Discussion about the last incident on the forum ruwiki[1]. Mail.ru Support asked the user ([[user:Polonoid]]) to provide some data from sending server: "Full Non-Delivery Report or full log of SMTP session of sending mail to your adress".
You can write to user and send the requested information.
[1]: https://ru.wikipedia.org/wiki/ВП:Форум/Технический#Электронная_почта_на_mail.ru
Change 514764 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_27] SECURITY: rate-limit and prevent blocked users from changing email
Change 514764 merged by Reedy:
[mediawiki/core@REL1_27] SECURITY: rate-limit and prevent blocked users from changing email
Change 514775 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_30] SECURITY: rate-limit and prevent blocked users from changing email
Change 514775 merged by Reedy:
[mediawiki/core@REL1_30] SECURITY: rate-limit and prevent blocked users from changing email
Change 514755 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: rate-limit and prevent blocked users from changing email
Change 514851 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_31] SECURITY: rate-limit and prevent blocked users from changing email
Change 514851 merged by jenkins-bot:
[mediawiki/core@REL1_31] SECURITY: rate-limit and prevent blocked users from changing email
Change 514951 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_32] SECURITY: rate-limit and prevent blocked users from changing email
Change 514951 merged by jenkins-bot:
[mediawiki/core@REL1_32] SECURITY: rate-limit and prevent blocked users from changing email
Change 514975 had a related patch set uploaded (by Reedy; owner: Brian Wolff):
[mediawiki/core@REL1_33] SECURITY: rate-limit and prevent blocked users from changing email
Change 514975 merged by jenkins-bot:
[mediawiki/core@REL1_33] SECURITY: rate-limit and prevent blocked users from changing email