WordPress, Yahoo, and MailChimp weirdness

[maxxd]

Hey y'all.

 

I'm having some strange goings-on happening and was wondering if anyone here had come across a similar issue, or heard of a similar issue, or knew of a voodoo ritual I might try - you know, what ever. I'm open.

 

I have a US client on a WordPress site - updated to the most recent version, all plugins updated - using the MailChimp plugin by ibericode. We are using the double opt-in feature so that the user, after filling out their email address on the client site is sent a confirmation email and must click the provided link in the email to be sent to another web page, in order to verify the submitted email before being added to my client's list. Looking at the code, it appears as though the plugin is validating not only a honeypot, but a WordPress nonce before submitting the subscription request and subsequently sending the verification email.

 

However, my client is getting hundreds of verified subscriptions per hour, all apparently from France and using Yahoo.com addresses. Which is weird, right? Especially as Google Analytics shows 1 user from France in the past month.

 

Again, the user has to wait for the confirmation email, open it, and click the provided link to the verification page before the address is added to the list. Personally, I can't think of a way for a bot to handle this, nor can I imagine someone sitting at home in France - or anywhere else, for that matter - and doing this intentionally; my client's cool and all, but they're not that big and they're in a fairly niche market without any online sales.

[QuickOldCar]

They make some really good bots these days, is obviously bypassing the mailchimp check.

 

You can try your own ways before or during the signup form.

 

Here is using stopforumspam and for known bad ip's, it will decrease the spam a lot.

$remote_ip = $_SERVER['REMOTE_ADDR'];
if (strstr($remote_ip, ', ')) {
    $ips = explode(', ', $remote_ip);
    $remote_ip = $ips[0];
}
$spam_ip = "http://api.stopforumspam.org/api?ip=".$remote_ip;
$spamdata = @simplexml_load_file($spam_ip);
if ($spamdata) {
  
    $spamarray = array();
  
    $spamarray = json_decode(json_encode($spamdata), TRUE);

   if($spamarray['appears'] == "yes" ){
   die('spammer');
   }
}

[scootstah]

What makes you think a bot cannot click a link in an email? That is child's play. Your client may be small, but WordPress isn't.

 

If a bot has cracked a popular piece of software, which is what it sounds like, generally you can just implement some other extra custom method for stopping spam. That will probably eliminate a good deal of it, and then they would need a targeted attack.

[maxxd]

Thanks for the advice - we tried a captcha, but that didn't slow it down at all. So we removed that and added Goodbye Captcha, which seems to have done the trick so far.

 

@QuickOldCar: thanks for the code - I'll give that a shot, too. Obviously too much protection isn't enough these days.

 

@scootstah: can a bot actually do that - click a link in a received email?!? I had no idea. Damn, Skynet's getting closer daily...

[scootstah]

@scootstah: can a bot actually do that - click a link in a received email?!? I had no idea. Damn, Skynet's getting closer daily...

Of course, and that's nothing new. It's just parsing text.

[mac_gyver]

if you are getting hundreds per hour, the problem could be in the page that the email link goes to, to verify and finalize the subscription. perhaps it has a code bug that allows empty or special encoded values (i'm thinking a hexadecimal encoded sql injection string combined with php/mysql converting such a value back to the string it contains when it sticks it into a sql query) to match/bypass the check and cause any email address to be verified.

 

it could also be that the email link is attempting to do something tricky, but meaningless from a security standpoint, like doing a base64 encode of the email in the link and someone is just submitting link after link that they have produced, that the software happily accepts, extracts the email from and adds it to the list of verified emails.

 

i would log all the available information that comes with the http requests, both in the sign-up form processing page (to see if that page is even being visited that number of times) and in the link/verify/finalize page.

Edited August 21, 2015 by mac_gyver

[mac_gyver]

i looked a little at the code for this plug-in and the only thing i could see it doing for data storage is using a cookie to hold a plain-text email address. IF that's all it is doing, setting a cookie (the readme implies they previously put the plain-text email in the link) with the email address on the sign-up form processing page, then using that cookie value to subscribe to the mail-chimp list when the linked to page is visited, this provides absolutely no security. anyone can send a cookie with any value they want with a request to a page. i even saw that the code was using $_REQUEST, so, it's not even required to simulate a cookie when making the request, just include the email address in the url being requested.

 

it would help if you posted what the emailed link looks like. does it contain any sort of random/unique token as a get parameter or is it just the url of page?

 

---

 

if this supposition about how this code is doing this is true, the correct way of doing this is to generate a unique and hard to guess token and put the token value in the link that gets emailed. store the token value and the email address on the server. on the page that gets linked to in the email, you use the token that's in the url to retrieve the email address.

 

a less secure method, but better than a plain-text value in a cookie, would be to encrypt the email address the gets stored in the cookie. encryption is NOT encoding. things like hexadecimal and base64 are encoding. if you recognize the encoding method being used, you can simply encode your own values and put them into the cookie. encryption involves an encryption key that you produce/makeup that only your code should know and an encryption algorithm. the key and the data are passed through the encryption algorithm and knowing the key allows you to decrypt the data later. the problem with this, is without having any storage method on the server, the key will be a fixed value (rather than a random value that's different for each visitor) and someone could go through all the encryption algorithms that php has available (there are not that many) and brute-force find a key that successfully decrypts the encrypted cookie value they got when they signed up. this would let them produce their own encrypted value that the code would happily accept and decrypt to get an email address to use.

[scootstah]

Storing the email in a cookie is just a silly idea to begin with. What if they use a different browser, or a different device entirely to click the link in their email?

[maxxd]

I haven't had a chance to take a look at the code for the plug-in yet, so I'm not sure what exactly it's doing. Thanks for taking a look, mac_gyver - I very much appreciate the extra effort and time! I'll dig into it and see how it can be improved upon - if it's really just setting a cookie, I can't imagine it'll take long for bots to figure that one out, too, and then we'll be right back where we were to begin with...

 

Thanks again for the advice and help, y'all!