Spam to "-request" address generating backscatter spam
My mail server has been blacklisted by several major e-mail providers because of backscatter spam generated by my Mailman installation:
(1) Spammers harvest the "listname-request@domain.com" address from a
public Web page (presumably the Mailman admin page).
(2) Spam with forged "From:" headers is sent to "listname-request@domain.com".
(3) Mailman sends "subscribe confirmation" messages to the addressees in the forged "From" fields.
How can I stop this? I am willing to give up "subscribe to this list by e-mail", and require all subscriptions to be via the Web.
I used to use, and manage, mailing lists that handled all subscribe and unsubscribe requests by e-mail. But now almost all genuine subscription requests to my lists are made through the Web interface.
(I also used to run e-mail auto-responders, for example to send an FAQ in response to any e-mail message sent to a special e-mail address. I have stopped them all, for similar reasons -- they were attracting spam with forged "from" addresses, thus generating spam to those "from" addresses.)
I have found several discussions of variants of this issue on this list, going back at least 10 years. But so far as I can tell, there is not yet a simple option in the Web admin (or a config file) for each Mailman list, "Accept subscription requests by e-mail? Yes/No".
I understand that this may take time to implement, but this problem has been known for a very long time. I would like to see this put on the feature request list, however that is done. In the meantime, I need a workaround if I am to continue using Mailman at all.
I would still prefer to have e-mail confirmation of new subscriptions, but I don't think that would cause as much of a backscatter problem: The "-request" address can be harvested form the public Web, but the "-confirm" address would be much less likely to do so.
But if it is simpler to implement, it would be OK to require new subscriptions to be confirmed through the Web interface.
Temporarily, I have completely disabled the list that was attracting spam to its "-request" address. This isn't a viable long-term option.
Is there any workaround, either through the Web interface or by editing Mailman configuration files, to disable the "-request" address or cause all mail to that address to be dropped without generating a reply?
FWIW, I am using Mailman through Plesk, which offers it as an option. Plesk knows that "-request" is already in use by Mailman, and won't let me create that address or alias or manage it except through Mailman.
Thanks in advance for any advice you can offer,
Edward Hasbrouck
Edward Hasbrouck edward@hasbrouck.org https://hasbrouck.org https://twitter.com/ehasbrouck +1-415-824-0214
"The Practical Nomad: How to Travel Around the World" (5th ed., 2011) https://hasbrouck.org/PN
Consultant to The Identity Project: https://papersplease.org
GnuPG/PGP public key: https://hasbrouck.org/ehasbrouck.asc fingerprint: 0B0B 8F74 CEA3 83AB 97B3 F6AF BB7E F636 165C 22F5
Edward Hasbrouck writes:
(2) Spam with forged "From:" headers is sent to "listname-request@domain.com".
How can I stop this? I am willing to give up "subscribe to this list by e-mail", and require all subscriptions to be via the Web.
Set Privacy Options | subscribe_policy to "Require approval".
If you don't like that because of lots of subscribes, the easiest thing to do if you actually have control over your installation is to remove the alias in the MTA. How to do that in Plesk, I don't know. Probably can't, then you have to talk to your hosting service.
Everything else I can think of requires changing code or access to the Mailman config files. Again you'll have to talk to your host.
I understand that this may take time to implement, but this problem has been known for a very long time. I would like to see this put on the feature request list, however that is done.
There is no feature request list for Mailman 2 any more. If Mark has time and thinks it's not too invasive, it might happen, but he's getting more and more involved with Mailman 3. For Mailman 3, it would be
http://gitlab.com/mailman/mailman/issues
Use tags "wishlist" and "security" I think. (Note, AFAIK "security" doesn't mean "privileged info" on Gitlab's tracker, it's just a tag for any issue with our privacy or malware mitigation stuff.)
Is there any workaround, either through the Web interface or by editing Mailman configuration files, to disable the "-request" address or cause all mail to that address to be dropped without generating a reply?
This really is something that should be done in the MTA. I understand that you probably don't have access to your MTA's configs, but that's not our fault. From our point of view, making this change adds to the complexity of Mailman configuration for all our users (site admins, list owners, and subscribers). It's already quite confusing, and only going to get worse as we add DKIM, SPF, DMARC, ARC, ....
FWIW, I am using Mailman through Plesk, which offers it as an option.
Consider changing to a service that's more expensive but doesn't make you unreasonable for making a support request. Plesk (and cPanel) are a good idea in principle, but unfortunately the spammers, phishers, and other miscreants, malefactors, and felons put paid to that. It doesn't really matter what you do, if you take input from the Internet, you need to be able to reconfigure quickly and flexibly in response to exploits. Those "control panels" don't offer that, and probably cannot.
On 12/13/2016 03:54 AM, Stephen J. Turnbull wrote:
Edward Hasbrouck writes:
How can I stop this? I am willing to give up "subscribe to this list by e-mail", and require all subscriptions to be via the Web.
Set Privacy Options | subscribe_policy to "Require approval".
That won't work. The From: address still gets a 'results of your email commands' message.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/12/2016 03:07 PM, Edward Hasbrouck wrote:
How can I stop this? I am willing to give up "subscribe to this list by e-mail", and require all subscriptions to be via the Web.
Steve has answered most of this. I just want to add a couple of things. With respect to web subscribes, several sites including python.org have seen mail bomb attacks via the web subscribe interface.
These are subscribes via the web UI by distributed bots that are "smart" enough to GET the form and delay tens of seconds before POSTing it. The most recent attacks have been multiple subscribes to multiple lists of some gmail.com address with various permutations of dots (ignored by gmail) interspersed in the local part. The most recent attack on mail.python.org subscribed addresses that matched
'^.*s\.*u\.*n\.*i\.*b\.*e\.*e\.*s\.*t\.*a\.*r\.*s.*@gmail\.com
During the first 17 hours (before I noticed it in the daily status report) there were 7896 pending subscribes waiting user confirmation and 417 held subscriptions waiting moderator approval (There is a script at https://www.msapiro.net/scripts/erase to remove these).
At that point I added the above pattern to the GLOBAL_BAN_LIST (recently implemented because of attacks like this). During the next 30+ hours until the attacks stopped there were 4631 banned subscription attempts.
The banned attempts and held subscriptions don't send emails, but there were still almost 8000 email confirmation requests sent to the gmail address.
The bottom line here is that web subscribes are also vulnerable to exploitation.
I would still prefer to have e-mail confirmation of new subscriptions, but I don't think that would cause as much of a backscatter problem: The "-request" address can be harvested form the public Web, but the "-confirm" address would be much less likely to do so.
But if it is simpler to implement, it would be OK to require new subscriptions to be confirmed through the Web interface.
The whole point of confirmation is to verify that the entity generating the subscribe request can actually receive and comprehend an email message sent to that address, i.e. is the actual user whose address that is. I don't see how that can be done without sending an email to the address.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Dec 13, 2016 at 12:35 PM, Mark Sapiro mark@msapiro.net wrote:
Steve has answered most of this. I just want to add a couple of things. With respect to web subscribes, several sites including python.org have seen mail bomb attacks via the web subscribe interface.
These are subscribes via the web UI by distributed bots that are "smart" enough to GET the form and delay tens of seconds before POSTing it. The most recent attacks have been multiple subscribes to multiple lists of some gmail.com address with various permutations of dots (ignored by gmail) interspersed in the local part. The most recent attack on mail.python.org subscribed addresses that matched
'^.*s\.*u\.*n\.*i\.*b\.*e\.*e\.*s\.*t\.*a\.*r\.*s.*@gmail\.com
I know the GLOBAL_BAN_LIST is for email addrs, but what would it take to implement the same (or some field validation logic) for the "fullname" field of the subscription page. I'm still seeing a ton of subscribe spam attempts, and the fullname field is consistently not a text name.
From nginx log:
...sales@apexgolfcarts.com&fullname=58562fbb70e22... ...ellenv3@hotmail.com&fullname=5856315b5b695... ...scottpickup2000@gmail.com&fullname=5856372a4e2f1... ...vanessae@live.com&fullname=58563aa6664bf... ...meagan@meaganlucyphoto.con&fullname=58563ab925ac7... ...saramardambey@gmail.com&fullname=58564566dc31b... ...dotthomas717@yahoo.com&fullname=5856456df0b96... ...scottpickup2000@gmail.com&fullname=58564b85ccf98...
-Jim P.
On Thu, Dec 22, 2016 at 4:53 PM, Jim Popovitch jimpop@gmail.com wrote:
On Tue, Dec 13, 2016 at 12:35 PM, Mark Sapiro mark@msapiro.net wrote:
Steve has answered most of this. I just want to add a couple of things. With respect to web subscribes, several sites including python.org have seen mail bomb attacks via the web subscribe interface.
These are subscribes via the web UI by distributed bots that are "smart" enough to GET the form and delay tens of seconds before POSTing it. The most recent attacks have been multiple subscribes to multiple lists of some gmail.com address with various permutations of dots (ignored by gmail) interspersed in the local part. The most recent attack on mail.python.org subscribed addresses that matched
'^.*s\.*u\.*n\.*i\.*b\.*e\.*e\.*s\.*t\.*a\.*r\.*s.*@gmail\.com
I know the GLOBAL_BAN_LIST is for email addrs, but what would it take to implement the same (or some field validation logic) for the "fullname" field of the subscription page. I'm still seeing a ton of subscribe spam attempts, and the fullname field is consistently not a text name.
I think i have a better solution, (but I'm not so sure how to do this in Apache). In Nginx you can use "limit_except PUT { deny all; }" to deny the spambot GET attempts.
-Jim P.
On 12/22/2016 03:01 PM, Jim Popovitch wrote:
I think i have a better solution, (but I'm not so sure how to do this in Apache). In Nginx you can use "limit_except PUT { deny all; }" to deny the spambot GET attempts.
in apache 2.4 you would do
<LimitExcept PUT>
Require all denied
</LimitExcept>
Require all grantedbut how does this help? No one, including bots GETs the subscribe CGI, and subscription is via POST, not PUT.
The scenario is the same for bots and humans. GET the listinfo CGI with the hidden token and then POST the form to the subscribe CGI. I don't see how you can block one without blocking the other.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, Dec 22, 2016 at 6:26 PM, Mark Sapiro mark@msapiro.net wrote:
On 12/22/2016 03:01 PM, Jim Popovitch wrote:
I think i have a better solution, (but I'm not so sure how to do this in Apache). In Nginx you can use "limit_except PUT { deny all; }" to deny the spambot GET attempts.
in apache 2.4 you would do
<LimitExcept PUT> Require all denied </LimitExcept> Require all grantedbut how does this help? No one, including bots GETs the subscribe CGI, and subscription is via POST, not PUT.
Indeed, POST, not PUT. I have POST in my config, but the docs that I saw (which I copied to here) used PUT.
The scenario is the same for bots and humans. GET the listinfo CGI with the hidden token and then POST the form to the subscribe CGI. I don't see how you can block one without blocking the other.
I'm seeing GET attempts like this:
77.247.181.165 - - [22/Dec/2016:23:30:10 +0000] "GET /subscribe/users?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&&sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en& HTTP/1.1" 404 162 "http://netcoolusers.org/" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
Although those are failing because they are hitting /subscribe, but if they ever tweak the bots it could get ugly fast without some mitigation.
-Jim P.
On 12/22/2016 03:38 PM, Jim Popovitch wrote:
I'm seeing GET attempts like this:
77.247.181.165 - - [22/Dec/2016:23:30:10 +0000] "GET /subscribe/users?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&&sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en& HTTP/1.1" 404 162 "http://netcoolusers.org/" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
OK. I see how limiting the subscribe CGI to POST requests would stop these, but I haven't seen any attacks like this. In the ones I've seen, the bot GETs the form via listinfo and then delays and POSTs to subscribe as described in the part of my post in this thread you didn't quote.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, Dec 22, 2016 at 6:55 PM, Mark Sapiro mark@msapiro.net wrote:
On 12/22/2016 03:38 PM, Jim Popovitch wrote:
I'm seeing GET attempts like this:
77.247.181.165 - - [22/Dec/2016:23:30:10 +0000] "GET /subscribe/users?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&?sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en&&sub_form_token=1527449307%3A44440ca6e66379d0e6e9c45b66d93d5864da4621&email=jconno2215%40gmail.com&fullname=585c61c234d98&pw=&pw-conf=&digest=1&email-button=jconno2215%40gmail.com&language=en& HTTP/1.1" 404 162 "http://netcoolusers.org/" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
OK. I see how limiting the subscribe CGI to POST requests would stop these, but I haven't seen any attacks like this. In the ones I've seen, the bot GETs the form via listinfo and then delays and POSTs to subscribe as described in the part of my post in this thread you didn't quote.
Just to be clear, the bots are doing a GET of the listinfo page, extracting the token, and then (mis)forming the GET URL like this:
89.32.127.178 - - [22/Dec/2016:23:53:29 +0000] "GET /mailman/listinfo/users HTTP/1.1" 200 2866 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" 89.32.127.178 - - [22/Dec/2016:23:53:32 +0000] "GET /subscribe/users?sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en&?sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en&&sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en& HTTP/1.1" 404 162 "http://netcoolusers.org/" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
I suspect, the bot is requesting ../subscribe and that nginx is just striping the leading dots off the request (totally not sure about this though).
-Jim P.
On 12/22/2016 04:05 PM, Jim Popovitch wrote:
Just to be clear, the bots are doing a GET of the listinfo page, extracting the token, and then (mis)forming the GET URL like this:
89.32.127.178 - - [22/Dec/2016:23:53:29 +0000] "GET /mailman/listinfo/users HTTP/1.1" 200 2866 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" 89.32.127.178 - - [22/Dec/2016:23:53:32 +0000] "GET /subscribe/users?sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en&?sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en&&sub_form_token=2351250719%3A8d5271a8d26c4cdd37040d7a7f37efb977e93d07&email=candice.cheng%40gmail.com&fullname=585c673c4eaac&pw=&pw-conf=&digest=1&email-button=candice.cheng%40gmail.com&language=en& HTTP/1.1" 404 162 "http://netcoolusers.org/" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
I suspect, the bot is requesting ../subscribe and that nginx is just striping the leading dots off the request (totally not sure about this though).
I suspect that's correct. The bottom line however is that there are already botnets out there that are smart enough the do the right things to get past the checks of GETting the form first with the hidden token and delaying sufficiently before POSTing to the right URL.
I can see that if your attackers get smarter, the real name check could be useful, but I'm not ready to add that as a feature. That could change if they successfully attack me, but that hasn't happened yet.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
I can see that if your attackers get smarter, the real name check could be useful, but I'm not ready to add that as a feature. That could change if they successfully attack me, but that hasn't happened yet.
Based on past experience, by "me" Mark means "you, too". He's that kinda guy. :-)
I see Mark's point, though. Basically, these attacks amount to a DoS on his development time, and also on real users. Restrictions on automated subscription as well as other list actions (posting) are going to be list-specific, or you are going to end up denying service to people, elves and dwarves as well as to orcs and trolls. We don't really know how to make those distinctions yet, let alone do it well.
On 12/22/2016 01:53 PM, Jim Popovitch wrote:
I know the GLOBAL_BAN_LIST is for email addrs, but what would it take to implement the same (or some field validation logic) for the "fullname" field of the subscription page. I'm still seeing a ton of subscribe spam attempts, and the fullname field is consistently not a text name.
From nginx log:
...sales@apexgolfcarts.com&fullname=58562fbb70e22... ...ellenv3@hotmail.com&fullname=5856315b5b695... ...scottpickup2000@gmail.com&fullname=5856372a4e2f1... ...vanessae@live.com&fullname=58563aa6664bf... ...meagan@meaganlucyphoto.con&fullname=58563ab925ac7... ...saramardambey@gmail.com&fullname=58564566dc31b... ...dotthomas717@yahoo.com&fullname=5856456df0b96... ...scottpickup2000@gmail.com&fullname=58564b85ccf98...
If you only want to target user subscribes and not things like admin mass subscribes and invitations, you could modify Mailman/MailList.py in the AddMember() method around line 894
pattern = self.GetBannedPattern(email)change that to
pattern = (self.GetBannedPattern(email) or
self.GetBannedPattern(realname))Then you could add patterns like, e.g., '^[0-9af]{10,}' to the GLOBAL_BAN_LIST to match those real names.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Edward Hasbrouck -
Jim Popovitch -
Mark Sapiro -
Stephen J. Turnbull