Jetpack: Lock down the 'Email' sharing option to decrease utility to spammers.

[georgestephanis]

https://github.com/Automattic/jetpack/blob/master/modules/sharedaddy/sharing-sources.php#L196-L324

It's possible to stuff too much data into the sender name. Let's give the email sharing module a once over and add some sane limits.

[Update from @designsimply 4-Apr-2018]

Confirming this still appears to be an issue based on recent reports in the following summary:

• 2014-07-31 - WP Engine disables email sharing. (https://github.com/Automattic/jetpack/issues/448#issuecomment-50784872)
• 2014-09-23 - issue closed with: character limit, honeypot, uses Akismet (if enabled). (#1053)
• 2015-01-31 - WP Engine re-enables email sharing. (https://github.com/Automattic/jetpack/issues/448#issuecomment-72352961)
• 2016-11-04 - issue reopened. (https://github.com/Automattic/jetpack/issues/448#issuecomment-258566916)
• 2017-02-01 - 34sp.com host reports the problem. (3251872-t)
• 2017-06-08 - 1&1 host reports the problem. (3251872-t)
• 2017-06-26 - disabled email sharing as a default. (#7329)
• 2017-07-04 - latest public user report I could find via links above. (wporg forums)
• 2017-11-01 - latest private user report noted on this issue. (767682-zen)

What to do with new issues reported where Akismet is confirmed enabled:

It would be more effective to post these tickets to the internal Akismet P2 for review.

Source: https://github.com/Automattic/jetpack/issues/448#issuecomment-294254795

[blobaugh]

Currently the email sharing feature uses the email service provided by the wporg site server.

See: https://github.com/Automattic/jetpack/blob/700eecf051ecab2be511d1f308617f1b2a257025/modules/sharedaddy/sharedaddy.php#L13-L22

If an endpoint was created for sending the email through the Jetpack servers it would allow WordPress.com to keep and monitor a blacklist of IPs not allowed to use the service due to abuse. (Akismet anyone?) Because all Jetpack powered sites would then utilize this service the servers would be able to see botnet attacks happening and lock them down across all sites using the service instantly.

Incidentally this would also solve the issue of hosts that do not provide email server services to the web server, of which there are many that lock it down.

[georgestephanis]

Maybe as an enhancement but only if there is a wpcom connection. Gracefully degrade in debug/local mode. Would need feedback from akismet.

[blobaugh]

Thinking about this some more, if we had a single object in Jetpack that we could send an IP or whatever to that would be awesome. It could tap into Akismet possibly. We would need to interface with the Akismet team more to figure out how to pull it off. It would mean that either a very limited version of Akismet would come pre-activated in Jetpack or that users would have to have Akismet active to utilize the service, in which case we would have to provide fallbacks but that would not be too difficult. I am leaning towards the first idea of a limited version coming pre-activated.

This limited version could just be for internal Jetpack usage and not tap into the traditional usage of Akismet until the user activates Akismet with their API key.

Maybe @cfinke could shed light on how realistic that scenario could be.

[tellyworth]

What data would be available for sending to Akismet? I assume IP, UA, headers, the provided email address(es?), anything else?

My hunch is that most abuse is incidental, from scattergun spambots that hit any form. Some countermeasures like extra fields or JS might be more efficient - a deliberate spambot would work around them, but if this is a mere side effect then they wouldn't bother.

[kraftbj]

Note: WP Engine is proactively disabling Share by E-mail for sites managed via their service per e-mail to customers sent today.

[blobaugh]

Example of email in question https://cloudup.com/cj45SypExq1

[georgestephanis]

@heydonovan -- can you guys confirm what you're using to shut down only the email button? Just to confirm in case it's doing it in a funky way that could cause problems.

[boogah]

@georgestephanis Here's the code we're using:

function wpe_kill_sharedaddy_email ( $services ) {
    if( class_exists( 'Jetpack' ) ) {
        unset( $services['email'] );
        return $services;
    }
}
add_filter( 'sharing_services', 'wpe_kill_sharedaddy_email' );

[georgestephanis]

@boogah You should probably drop the class_exists() check in the function, as that's a filter that only we use. Also, if someone else starts to use the same filter name in a plugin, and Jetpack itself isn't installed, your function would obliterate the array being passed in. But yeah, that's the best way to drop it. Thanks for confirming!

[BFTrick]

I like the idea of sending this information through Akismet or some other service to thwart bot nets but shouldn't we start with the basics?

Adding a maximum character limit to the name would be helpful. If it's over 300 or something ludicrously high then throw it out all together.

[enejb]

Trying to fix this issue in https://github.com/Automattic/jetpack/tree/fix-issue-448 fix-issue-448 branch.
So far I implemented

• A character limit on the name ( 200 characters )
• Honeypot ( an empty field that might be field out by bots. ) humans should not fill it out.
• Check that the email that is being sent is not spam using akismet if enabled.

Would love some help testing this.

[BFTrick]

Didn't see that branch. You guys are awesome!

I think this might be too clever:

<input type="text" id="jetpack-source_f_name" name="source_f_name" class="input" value="hello" size="25" autocomplete="off" />
<script> document.getElementById('jetpack-source_f_name').value = ''; </script>

You've now prevented someone without JS from submitting the form at all.

If you're going for a honeypot field I'd leave it blank for the bot to fill in and users without JS can still use the form.

[blobaugh]

Agreed on the honeypot

[enejb]

I am not sure if the honeypot is the right way to go. Since it might not catch anything. And some edge cases a user might fill in input with text. (resulting in a false positive) The js line above just makes sure that browsers don't populate it with some sort of default text. It is only once.

Ups. The 'hello' was there for testing. Will remove it now.

[blobaugh]

Make the field hidden and users cannot fill it in.

[jeherve]

Make the field hidden and users cannot fill it in.

You should just make sure you take screenreaders into account. The form has to remain accessible, so if the field is just hidden folks accessing the folks through a screenreader might not know it's a fake field.

[kraftbj]

display: none; should account for screenreaders (e.g. by not announcing that content). Ref: http://css-tricks.com/places-its-tempting-to-use-display-none-but-dont/

[blobaugh]

Created the pull request at https://github.com/Automattic/jetpack/pull/1053

@enejb could you make the updates we were talking about re the honeypot?

[georgestephanis]

Enej is out for the next two weeks.

[georgestephanis]

@enejb I thought I saw elsewhere that you'd patched this? Or is my memory playing tricks on me?

[enejb]

Yes this should be closed now I merged the branch that fixed it in https://github.com/Automattic/jetpack/pull/1053

[jeherve]

@boogah Since this was fixed with the latest Jetpack release, do you think you could enable the Email sharing button again on WPEngine?

Thanks!

[kraftbj]

Per WP Engine support ticket 313781, this feature should be re-enabled on their platform "next week".

[boogah]

Sorry about the delay on this! WPE had an internal code freeze over the holidays and this fix was deemed "non-critical". We're in the process of thawing out right now, but I'm doing everything I can to make this happen ASAP.

[richardmtl]

@boogah Hi! We were wondering if this was enabled yet; could you let us know? Thanks!!

[boogah]

@richardmtl It was supposed to go out as part of a deploy late last week. That deploy was halted and pushed back because of an issue with unrelated code during testing.

I'm really pushing hard to get this out ASAP. If we run into any other snags getting it out this week, I'll let you know!

[boogah]

I'm sitting in an internal chat room where the change is supposed to go out today. If it doesn't, I'll make sure to drop an update here.

[boogah]

The deploy had to be briefly halted, but is still running. I'm going to check back in on this in the morning and will update here once I know what's up.

[richardmtl]

THanks @boogah !

[boogah]

@richardmtl Here's where we are right now...

The phased deploy we've been running since Wednesday required some pretty intensive server-side jobs to be run. In some cases — depending on the size & scope of sites on the server — the server side jobs are running _very_ slowly.

Because of how the deploy last week failed, we're actually okay with things taking a little longer. But this means that the rollout is still going. So we're breaking with our "No deploys on Friday" rule to monitor the most recent phase tonight, sniff out any potential issues — we're hopeful that there will be none — and finish the last little bit of this deploy tomorrow.

So what does this mean for Jetpack? Well, at this point the majority of our customers — outside of a large handful of accounts — should be able to use email sharing again without any issues.

As soon as we hit 100% on the deploy tomorrow, I'll update you one last time.

[richardmtl]

Thanks for the update, @boogah ! There was no real rush for things on our end, it was more a matter of keeping tabs on where things are with this. I appreciate the candor! :)

[boogah]

The deploy finished after I had left for the day on Friday, but it appears to be done now.

Let me know if you see anyone still reporting issues!

[paulprins]

Sorry to reopen but when using Jetpack with Autoptimize this fix breaks. it is throwing an element not found error when the JS is loaded in the header and agregating inline JS. Not a major issue but there is a simple fix that can be implemented.

The fix is to wrap the javascript request in a jquery ready event handler ala:
<script>jQuery( document ).ready( function(){ document.getElementById('jetpack-source_f_name').value = ''; });</script>

This .ready() approach is used elsewhere in the same sharedaddy/sharing-sources.php file. Implementing this fix will resolve a number of fringe issues using sharedaddy while keeping the honeypot functional.

[jeherve]

@paulprins Thanks for the report. I created #5291 with your patch.

[jeherve]

Reopening this, as it seems some spammers found a way around the honey pot.

Reported here:
https://wordpress.org/support/topic/spam-attack-by-jetpack-share-e-mail/

[jeherve]

Another report here:
https://wordpress.org/support/topic/email-sharing-button-recaptcha/

[jeherve]

Another report here:
https://wordpress.org/support/topic/jetpack-hacked/#post-8398136

[jeherve]

Also reported here:
https://wordpress.org/support/topic/jetpack-sharing-email-can-be-abused-for-spam/#post-8160632

[jenhooks]

Report here: 2903871-t

[alexjgustafson]

2912663-t

[alexjgustafson]

2906649-t

[grappler]

I can open a seperate issue if need be but there is an issue with "jQuery is not a function" in the JS snippet when jQuery is loaded in the footer.
<script>jQuery( document ).ready( function(){ document.getElementById('jetpack-source_f_name').value = ''; });</script>

It may be better to use wp_add_inline_script() instead where the dependency on jQuery can be defined.

[jeherve]

@grappler This issue is logged in #1223

[richardmtl]

Report from a host (with log details) in 3038290-t

[chaselivingston]

More share by email spam reported in 3035121-t

[csonnek]

Also happening in 3070308-t

[kraftbj]

3152833-t with over 12k emails in a month. For users who are offloading SMTP to a service like SendGrid, this is costing our customers/users real money.

[macmanx2]

Also reported in 3162551-t, "the spam emails are causing us to hit our website database’s query limit, then I’m boxed out for 1-2 hours until my query limit resets. I only get a few minutes of digging and investigating in before the site (and my wp-admin access) is suspended again."

[cfinke]

If the sharing module is passing these to Akismet (as it appears to be, based on the code), and spammers still aren't being caught, it would be more effective to post these tickets to the internal Akismet P2 for review.

[kraftbj]

AK would only be used on sites with AK enabled and on a plan, so not sure if that's enough globally. I'll check with my ticket above if they're using AK and get info for you @cfinke if applicable.

[richardmtl]

We used the share buttons option on our website, but yesterday this part was
hacked. We received hundreds of emails on our server which were sent through the
share buttons option of the Jetpack plugin

3203234-t

[aheckler]

3235509-t

[lamdayap]

two reports here:

https://wordpress.org/support/topic/jetpack-sharing-email-can-be-abused-for-spam/page/3/#post-9205849
https://wordpress.org/support/topic/jetpack-sharing-email-can-be-abused-for-spam/page/3/#post-9206841

[csonnek]

Requested by someone from 1&1 Hosting here: 3251872-t

[lamdayap]

reported again here: https://wordpress.org/support/topic/jetpack-sharing-email-can-be-abused-for-spam/page/3/#post-9229524

User included their findings.

[lamdayap]

reported here: https://wordpress.org/support/topic/email-share-button-abused-for-spamming/

[rickybanister]

also 3291588-t

[kraftbj]

NB: As of JP 5.1, E-Mail Sharing will be disabled unless Akismet is active or the site owner specifically adds it via a filter.

[aheckler]

A report of this in 649683-zen, but user has disabled Email sharing button and has Akismet installed. Digging for more info.

[richardmtl]

in 767682-zen the user does not have Akismet yet they said they were having spam sent from the email button. Digging some more.

[designsimply]

bug-scrub

I tested email sharing with the following steps on a site hosted at WP Engine running WordPress 4.9.5 and Jetpack 6.0:

1. Go to WP Admin > Jetpack > Settings > Sharing > Sharing buttons > "Configure your sharing buttons".
2. Click "Edit sharing buttons".
3. Add the email sharing option and save changes.
4. Open a post on the front-end or a page on the site where social sharing buttons are displayed.
5. Try sending a post via the email social sharing button.

Result: I was able to share via email normally. There is no reCaptcha (but I understand that may be something I would need to install separately). I am not sure what else to check/report beyond this in terms of testing steps 🙂 and I may turn off email sharing since it is a known risk for spam (but would be happy to test further with more guidance about what to look for!).

[jeherve]

There is no reCaptcha (but I understand that may be something I would need to install separately)

Yes, here is how:
https://jetpack.com/support/sharing/#captcha

I am not sure what else to check/report beyond this in terms of testing steps

There is not much you can test for, short of looking at your logs for repeated direct requests to ?share=email&nb=1, and outgoing emails.

[jeherve]

Also in 1097573-zen

[brbrr]

Fixed in #9585