It seems that Mailman instances are being abused to harrass people
with subscribe spam. If some random people complain to you that they
"never wanted to subscribe to your mailing list", you may be a victim
to that attack, even if you run the latest Mailman 2.
TL;DR: IKR! HOW DO I FIX THIS!?
Make sure you have SUBSCRIBE_FORM_SECRET set in your mailman configuration:
SECRET=$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 30)'
echo "SUBSCRIBE_FORM_SECRET = '$SECRET'" >> /etc/mailman/mm.cfg
This will add a magic token to all forms in the Mailman web forms that
will force the attacker to at least get a token before asking for
registration. There are, of course, other ways of performing the
attack then, but it's more expensive than a single request for the
attacker and keeps most of the junk out.
Other solutions
I originally deployed a different fix, using referrer checks and an IP
block list:
RewriteMap hosts-deny txt:/etc/apache2/blocklist.txt
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond %{HTTP_REFERER} !^https://lists.torproject.org/$ [NC]
RewriteRule ^/cgi-bin/mailman/subscribe/ - [F]
# see also https://www.w3.org/TR/referrer-policy/#referrer-policy-origin
Header always set Referrer-Policy "origin"
I kept those restrictions in place because it keeps the spammers from
even hitting the Mailman CGI, which is useful to preserve our server
resources. But if "they" escalate with smarter crawlers, the block
list will still be useful.
You can use this query to extract the top 10 IP addresses used for
subscription attempts:
awk '{ print $NF }' /var/log/mailman/subscribe | sort | uniq -c | sort -n | tail -10 | awk '{ print $2 " " $1 }'
Note that this might include email-based registration, but in our logs
those are extremely rare: only two in three weeks, out of over
73,000 requests. I also use this to keep an eye on the logs:
tail -f /var/log/mailman/subscribe /var/log/apache2/lists.torproject.org-access.log | grep -v 'GET /pipermail/'
The server-side mitigations might also be useful if you happen to run
an extremely old version of Mailman, that is pre-2.1.18, but it's now
over 6 years old and part of every supported Debian release out there
(all the way back to Debian 8 jessie).
Why does that attack work?
Because Mailman 2 doesn't have CSRF tokens in its forms by default,
anyone can send a POST request to /mailman/subscribe/LISTNAME to
have Mailman send an email to the user. In the old "Internet is for
nice people" universe, that wasn't a problem: all it does is ask the
victim if they want to subscribe to LISTNAME. Innocuous, right?
But in the brave, new, post-Eternal-September, "Internet is for
stupid" universe, some assholes think it's a good idea to make a form
that collects hundreds of mailing list URLs and spam them through an
iframe. To see what that looks like, you can look at the rendered
source code behind samedyfreeday.co.uk (not linking to avoid
promoting it). That site does what is basically a distributed
cross-site scripting attack against Mailman servers.
Obviously, CSRF protection should be enabled by default in Mailman,
but there you go. Hopefully this will help some folks...
(The latest Mailman 3 release doesn't suffer from such idiotic
defaults and ships with proper CSRF protection out of the box.)
...
