Mark Maunder

Thanks all, this kind of data is very valuable to us. Elise, sorry we doubted you – thanks for bearing with us on this. Hopefully you’ve opened a ticket and Tim, Colette or another member of our team is taking priority care of you.

Regards,

Mark.

Hi Elise,

Just wanted to reiterate what Tim said. The message you received is not related to a bug we just fixed with the newest release as far as I can tell.

We’re most certainly not accusing you of anything. Just trying to help by giving you some data on what we think could be causing the issue.

We actually have a pretty good QA process in place and our developers also write unit tests to test the output of individual functions. However (and again I should note this is unrelated) but the bug yesterday’s release introduced was missed by our QA process, so we’re taking steps to improve the process to avoid that in future.

Let us know if we can help further – we’re happy to work the issue with you if you’d like.

Regards,

Mark.

Hey guys,

Just echoing what Tim said. Sorry about the delay in posting here, we’ve had our CS folks busy in our priority ticketing system this morning.

We put out a release within the last hour that fixes this issue. Unfortunately there is no way for us to revert settings that were affected, so you’re going to have to review your Wordfence config and make sure you’re happy with the settings there.

As Tim’s post said, this affected checkboxes that were unchecked and that are normally checked by default in Wordfence. So if you have (for example) a setting that Wordfence comes with enabled, that you unchecked yourself, you’ll need to go in and uncheck those again.

Once again, we’re sorry about the inconvenience caused by this. We’ve been discussing this extensively this morning and I’ve just come out of a dev meeting where we discussed our process and how it can be improved to avoid this in future.

Regards,

Mark Maunder
Founder & CEO.

Hi Ben,

Sounds like it might be file permissions on our site as the error says. Can you manually install the newest Wordfence by deleting the wp-content/plugins/wordfence directory and unzipping the newest Wordfence.zip into your plugins directory?

Regards,

Mark.

Hi Steve,

We have the higher sensitivity scan options because they often yield false positives. It’s a compromise between reducing false positives and improving scan sensitivity.

I think at this point Wordfence has done it’s job and identified that you’ve been hacked somehow. You need to figure out how they got into your site, because it appears that you’re continually being reinfected.

Suggestions:

Your WP installation may be up-to-date, but check all other applications, especially old versions of WP lying around and anything else like phpmyadmin. Make sure they’re up-to-date. Change all passwords. Work with your hosting provider to try and identify the source of the infection and close that hole. Then the rest of the job is easy – you just need to remove the malicious files.

Thanks for sharing those samples with us. As Matt mentioned, we’re going to use them to improve our detection.

Regards,

Mark.

Hi,

My customer service team alerted me to this post, I thought I’d respond personally. I’m the founder/CEO.

Can you please give us technical details of the DDoS? Post them here and you’re welcome to obfuscate the last octet of any IP’s. I”d like to know how many IP’s were involved and what exactly they were doing to your site.

Your description of how we didn’t handle the attack is fairly damning, but you don’t give us or the other customers that read this any technical detail of what was actually going on.

There are absolutely certain kinds of DDoS that we can’t protect you against. But that applies to any firewall product. For example, if your local router is attacked, you don’t have any visibility on the attack even at the kernel IP-stack level so there’s really nothing a firewall product can do about it and you’d need to work with your upstream providers to mitigate the attack.

You mentioned your provider saw the attack in logs. Please tell me which logs. e.g. The apache log? Kernel logs? Or router logs?

Did they have to work with an upstream provider to stop the attack? Or if they blocked the attack, where specifically did they block it. You won’t be giving away any sensitive details by sharing that info with us here.

This sounds serious and we’d very much like to work with you to help prevent this from reoccurring in future.

Regards,

Mark Maunder
Wordfence Founder & CEO.
PS: One of our customer service folks: Tim Cantrell, Brian, Matt R or Collette will respond to you here and they’ll keep me in the loop and I’ll weigh in as needed. Please share as much data as you can so we can work with you on this.

I’m seeing liberal use of the ob_ functions in the InfiniteWP code here:

http://plugins.svn.wordpress.org/iwp-client/trunk/init.php

So I suspect that’s causing an issue with our buffering/caching, so recommend the customer disables Falcon (and basic caching) if they want to use InfiniteWP to immediately resolve the conflict. This conflict will probably arise with any other caching plugin for WP.

Note, I haven’t fully examined the InfiniteWP code – just searched it for ob_ related functions and this is my suspicion.

Mark.