ReCAPTCHA can be bypassed

If anyone else has this issue, until the plugin is fixed… putting something like this in functions.php should stop this hole:

add_action( 'init', 'recaptcha_init_fix' );
function recaptcha_init_fix() {
    if ($_REQUEST['action'] == 'ctct_process_form') {
        if (strpos($_REQUEST['data'], 'g-recaptcha-response') === false) {
            $aError['status'] = 'named_error';
            $aError['message'] = 'Failed reCAPTCHA check, g-recaptcha-response is missing.';
            wp_send_json($aError);
            exit;
        }
    }
}

Hi @geektome

Very interesting and definitely would be a very targeted, but also still a very valid case. We will get this information and findings logged internally as an issue to work on and we’ll get it further addressed in a future release.

@constantcontact

Please fix this asap. Clients are complaining and want to get rid of Constant Contact altogether because of this. I think it’s safe to assume this is the issue for all of the others complaining about spam here as well.

@geektome and @bburgay Can either of you try the following version of the plugin? The version number hasn’t been changed, but there is a change in place.

https://www.dropbox.com/s/0xel5ipd6ayfrf8/constant-contact-forms-recaptcha-bypass-fix.zip?dl=0

here’s the specific change made, inside of class-process-form.php

if ( $this->plugin->settings->has_recaptcha() && ( empty( $data['g-recaptcha-response'] ) ) ) {
	return array(
		'status' => 'named_error',
		'error'  => __( 'We do no think you are human', 'constant-contact-forms' ),
	);
}

It checks if we should be using reCAPTCHA, and then if we have a response value from the data we’re processing. If we do not, it will reject.

This works, however I think it is actually causing an error and this is why it is working… The response I’m getting is this: “We had trouble processing your submission. Please review your entries and try again.” Not the one posted in your code above. The problem wasn’t ever happening when g-recaptcha-response is empty but when it doesn’t exist at all… wouldn’t you have to use an isset vs an empty? And now that you have an empty check on something that isn’t set, it is probably throwing an error?

Based on https://www.codepunker.com/blog/is-null-vs-empty-vs-isset-one-lesson-all-php-coders-should-learn empty() is the most comprehensive, that said we’re not against adding a little bit more to this check, just in case needed. It should be checking if the $data['g-recaptcha-response'] index exists or not.

The “We had trouble processing your submission. Please review your entries and try again.” error is likely coming from the nonce verification step a couple if statements down.

Out of curiosity and for helping ensure equal testing, how are you doing test requests? For example are you doing cURL requests on the command line with various POST parameters set? Would love to have something we could copy/paste to test with on our side to help more definitively address this topic.

@constantcontact

I haven’t had time to test this but came to see if this was resolved. @geektome said he was using Postman to test: https://www.getpostman.com/. It’s a great free tool which I use as well.

@constantcontact @geektome

I just tried this with Postman and stepped through the code as well. The added if block is entered and I am getting the correct response with “g-recaptcha-response” omitted. I only get the “We had trouble processing your submission.” error when I comment out the new if block and use a value for “ctct_form” which is no longer valid (invalid nonce).

@geektome I have had your temporary fix in for a few days now (also debugged it to make sure it was working) but we are still getting spam. So I’m starting to think this isn’t the only issue with the plugin.

Here is a screenshot showing how I am testing with Postman https://pasteboard.co/HUMVYm6.jpg

Yes, we’re aware of Postman as well.

We’ll use this information provided today to do some more testing and keep kicking the proverbial tires with this. We definitely want to get this pathway isolated and patched up.

We have mimicked all the fields and hidden fields from our test form, as part of an x-www-form-urlencoded POST request in our own Postman, like shown in the screenshot and as demo’d below, with the code edit we highlighted above in place.

email___ecd412e904309dcce66177488240b016=EMAILADDRESSHERE&ctct-id=54&ctct-verify=hCeih5h4WQS08V0beN4a6p6vg&ctct_time=1546562428&ctct-submitted=Sign%20up&ctct_form=21af49bfef

and

email___ecd412e904309dcce66177488240b016=EMAILADDRESSHERE&ctct-id=54&ctct-verify=hCeih5h4WQS08V0beN4a6p6vg&ctct_time=1546562428&ctct-submitted=Sign%20up&ctct_form=21af49bfef&g-recaptcha-response=true

Both times, they exited out early like we would be expecting. The last one was mostly just for some extra testing, and would fail because that’s not an actual Google response value and doesn’t validate.

Unless I’m missing something that is more obvious to others, which I’ll happily admit if pointed out, I’m not sure what this version from us is doing wrong. Let us know more or steps we’re not taking that is showing successful bypass for you.

Hi @constantcontact,

It exited out early as expected for me too. I have taken out the temp fix and put in the plugin change on a live site. I’ll let you know in a few days if the spam has stopped.

Thanks,
Brian

Sounds good. Thanks for being willing to help test and confirm.

No problem. It has been 3 days and we haven’t received any spam submissions so I’d say this fix is good to go. ??

Awesome to have some confirmation from @bburgay.

Chances are we’ll release this fix, and as always, keep trying to stay as spam-secure as we can. We can always add more in the future, and our spam based enhancements internally never fully close.

Pushed it up as part of the 1.4.4 release. If there’s still stuff coming through, let us know and we’ll keep kicking tires ??