2.8.2 exploited via admin-ajax.php
-
A site I manage with Mailpoet 2.8.2 installed has recently been exploited to flood 3rd party email addresses with signup confirmation requests.
No notification of these signups is sent to the Mailpoet admin address and checking the subscribers panel shows that no lists are specified for these registrations. I only became aware of the signups when the mail server of the unwitting recipients began bouncing due to the overload.
I tried manually confirming the registrations to see if this would prevent them being re-registered, but the hack seems able to repeatedly signup the same recipients regardless of their status. They return to being unconfirmed.
The server logs traced the signups to 2 IPs directly accessing admin-ajax.php (and no other files). Blocking these IPs stopped the malicious signups, but it obviously remains open to any other IP.
Recalling the serious 2014 hack this plugin suffered, I checked to see if it had created any new WP users, but it hasn’t.
Is this a known problem? Is it fixed in Mailpoet 3?
-
Hello @bloog,
Thank you for the issue report. Unfortunate that this issue has affected you.
Indeed, such signup attacks are common on the internet, and some target MailPoet as well.
One common way that helps to combat it is to enable Captcha on subscription forms. Both MailPoet 2 and MailPoet 3 offer integration with ReCaptcha, which you can enable for free in your plugin’s settings.
MailPoet 3 has a few stronger deterrents than MailPoet 2 for such attacks. Even though it’s still not immune (it’s always an uphill battle against spammers), we would still recommend upgrading your site to use MailPoet 3.
Best regards,
MailPoet Team.I’m experiencing the same thing. (for more information, please read my write-up about this.)
With all due respect, I think MailPoet should take this a little more seriously. Captchas are not a good solution in this case because you lose a lot of legitimate signups who just don’t want to be bothered with it. Really there should be some function in MailPoet that checks whether the sign up request was POSTed from a real form on our site. Instead, it’s just letting anyone from the internet POST directly to our admin-ajax.php.
This is impacting a lot of people.
Adding a captcha has so far blocked this particular exploit, but I agree with Programmerbear that Mailpoet seem not to be taking the issue very seriously (it’s not so long since they were asking users to stop requesting recaptcha support…)
The targets of the attack and IPs so far match the first two stated in Programmerbear’s blog post.
Hello,
I am also being attacked and spent countless hours trying to figure out what’s going on. Tried n different approaches but nothing worked. I blocked all four IP addresses mentioned and I really hope things will return to normality.
I’d like to know if MailPoet will do something regarding this issue and if some malicious code was injected into my site as all the scans were clear.Thank you @programmerbear for your writeup. I am also experiencing this problem, and saw the same initial target & IPs. I deleted “My First List” and blocked those IPs, which worked for a while, but now it’s happening again. Please keep us updated!
(And thank you @bloog for reporting the problem in the first place.)
-
This reply was modified 6 years, 8 months ago by
pictureitsolved.
Hello everyone,
Thank you @programmerbear for the in-depth analysis of the attack, the information is helpful.
We are looking into the issue and potential solutions.This attack appears to be not much different than someone filling in a subscription form a bunch of times.
There are measures in MP2 against it, but perhaps they are not covering this particular use case.
This attack is not injecting any code into your site.For affected users:
1) please make sure you are on the latest MailPoet 2.8.2 version
2) and please enable reCAPTCHA from your plugin’s settings (Settings > Advanced > Enable reCAPTCHA).
If you have the option – please consider upgrading to MailPoet 3.We understand that having captchas on subscription forms is not ideal, as others mentioned – we even advocated against it in the past due to convenience implications for your customers.
In this particular case another existing measure should’ve helped, but the next logical step for the attacker would be to use dozens of proxies, making banning IPs less effective.
Which is why we recommend to still enable reCAPTCHA – in the interim it seems to be the most effective tool at stopping such spammers.We will share more as we look into this problem.
Thank you for your patience, and we apologize for any inconveniences this issue has caused you.Best regards,
MailPoet Team.We also experiencing this problem since March 23, we were not sure where the problem was until the writeup from @programmerbear. Thank you for that. Btw also thanx to @bloog
@wysija please solve the issue or remove the plugin from the repo immediately.
We have tried to upgrade to version 3 with some projects (a few premium), but unfortunately all version 2 data can′t continue to be used old sent newsletter as a template. Which is often to be expected after a major update, fair enough.
Please do not @ ping unrelated people in the support forums. Abuse of this feature will lead to your account being blocked from the forums. -moderator
Thanks for the reply @wysija. I know you are no longer officially supporting the 2.x line, but since this seems like a pretty serious security issue I’m glad you are looking into it.
You’re right, banning IPs is not the best solution since the attackers can change them any time they want. I haven’t tried reCAPTCHA, for now I’m basically just using list #1 as a honeypot instead. I don’t use this list anyway, so whenever a request comes in for list #1 I discard it before it can be added. (I added some code to my functions.php to do this automatically… it’s on my blog post now if anyone wants it.)
I think the root problem here is that there’s no nonce checking for ajax requests. MailPoet has a method for checking nonces, but for whatever reason it is not being used for ajax requests. If nonces were required, this attack would be over and the captcha would not be needed. Hopefully this can be implemented.
Unfortunately removing the old plugin from the plugin repository is not helpful.
What it would do is remove a channel for further updates to MailPoet 2.
Thousands of sites still have MailPoet 2, and we could not help anyone after removing MP2 from plugin repository.Unfortunately nonce checking for AJAX requests does not work in this use case.
A new nonce could be fetched just by making another request to the homepage and grabbing it from the form.
If a page is cached – so will the Nonce, breaking functionality on pages that do use cache.
In addition to that, there are different methods for using subscription forms, some of them are expected to work externally (e.g. embed subscription forms).What we do employ is IP based throttling based on the number of subscriptions we see from an IP.
This is why the spammer is able to make only a handful subscriptions per IP address, and this is why he’s using multiple IPs to attack.By default the throttling window is 24 hours, with a starting delay of 1 minute.
You could make the defense more aggressive and increase these limits by adding this code to your theme’s functions.php file, after <?php code:function mp2_increase_subscription_throttling_window($window) { return 3600*24*7; // 7 days } function mp2_increase_subscription_throttling_delay_base($delay) { return 60*2; // 2 minutes } add_filter('wysija_subscription_limit_window', 'mp2_increase_subscription_throttling_window'); add_filter('wysija_subscription_limit_base', 'mp2_increase_subscription_throttling_delay_base');
What this code will do is consider last 7 days worth of subscription data (as opposed to just last day), and will make delays for repeat subscriptions more severe (5 minutes for second subscription, 10 for third, 20 for fourth and so on, growing exponentially).
But this is not the full solution – which is why a captcha is necessary.
So if you haven’t already, there are two steps you can take:
1) Please upgrade to the latest MailPoet 2 – 2.8.2 version
2) Please enable reCAPTCHA from your plugin’s settings (Settings > Advanced > Enable reCAPTCHA).Best regards,
MailPoet Team.@praesidenzfall Please do not @ ping unrelated people in the forums like that again. Thank you.
Hi,
@jiks – thanks a lot for notifying me on this, this issue has been causing a lot of problems for me as well, resulting in the hosting service shutting down the accounts where the plugin was running and in the server IPs getting blacklisted due to the spam caused (this has affected at least two of the sites where MailPoet is installed).
I first had this problem much earlier, going back to at least January 2018, and there is an initial report on the forums about this going back 5 months or so. I was running an earlier version of MailPoet 2 at the time and updating it to a more recent version (2.8.1, I believe) at least seemed to fix the issue for a while but it has come back again in full force in recent weeks. The more recent attacks seem to be less intensive and subscription requests take place every two minutes or so, whereas earlier there would be a flood of tenths of subscriptions within one or two minutes. Probably the IP based throttling is what is preventing the more massive attack.
I know you’re no longer providing support for version 2 yet it would be appreciated if @wysija could advise on the following:
– I have selected ‘Invisible reCAPTCHA’ when signing up, yet after I enable reCaptcha on the site and added the Site and Secret keys I got, I still see the reCAPTCHA form. Is this expected?
– Does changing to MailPoet 3 solve any of the above (that is, prevent mass subscription attacks or use Invisible reCAPTCHA properly)?
Kudos in the meantime to @programmerbear for the workarounds, too.
Thank you,
JMHi,
Update 1
I can confirm that the attack has escalated. Until now it only allowed fake users to be added to the newsletter list. Today, the fake user was added to the newsletter list as well to the WordPress user list with admin privileges.
I will implement CAPTCHA to see if the problem stops but I hope that MailPoet will release a new version to fully eradicate it.@nsqrt no problem ??
Thanks for the heads up @jiks and the great research @programmerbear!
OK MailPoet team (@wysija) – this is a thing, time to get after it. You’re not the only plugin author having to defend against this type of attack. There’s a pretty big non-profit donation plugin out there struggling with the same issue.
I’m still having fake signup attempts and various direct accesses to admin-ajax.php.
Any suggestions?
MailChimp?
I like MailPoet. I like having control over my email lists by keeping them on my own site. I generally try to avoid cloud-based/subscription-based things whenever practical, for this very reason.
I was encouraged by the MailPoet team’s initial reply, thinking that maybe they would do something about this. But here we are, more than a week later, no updates, no fix. This is still a very serious issue, at least to me. But it seems like the “official” answer is just “turn on captchas, we’re not going to do anything else.”
Captchas are not an acceptable solution for me. For people who are trying to build their list, turning on captchas means you’ll lose probably half of your otherwise legitimate sign ups. MailChimp doesn’t require captchas, so why can’t MailPoet figure out a solution?
I’m still confident that nonces are the way to solve this. That’s what they were created for. I understand the caching issue, but with a little ingenuity I believe this could be overcome. I think the truth is they just don’t want to put the effort into MailPoet 2.x — they want everyone to switch to 3.x. But there are legitimate reasons a lot of people want to stay on 2.x.
If the MailPoet team doesn’t want to maintain 2.x, especially with important security issues like this… maybe somebody from the community should fork it. If there was a 100% compatible fork we could all switch to, minus the security holes, I think a lot of people would switch.
-
This reply was modified 6 years, 8 months ago by
- The topic ‘2.8.2 exploited via admin-ajax.php’ is closed to new replies.