6Scan

Good day,

We would be glad to work on this problem together.
Our .htaccess code has been always wrapped by the “# Created by 6Scan plugin” and “# End of 6Scan plugin” decorators.
We see that BulletProof checks the position of its .htaccess rules, and if not present in the beginning – shows warning message.

Can we change something to make it easier for the integration?
Perhaps you could add an exception for our code? (Our tags will not be changed anytime soon)

Hi Dbo111,

It’s strange that 6Scan does not appear in your WordPress plugin list. Uninstalling the plugin through the WordPress interface is the best way to make sure all changes made to your site (including any fixes) are undone.

However, the plugin’s files live in wp-content/plugins, inside a directory named ‘6scan-protection’, and you can also uninstall the plugin by deleting this directory. If this directory does not exist for you, then the plugin was probably previously deleted, and in any case is not active on your site anymore.

Note that if you do not uninstall the plugin using WordPress, our servers will not know you did, and hence will continue scanning your site for a while before they realize the plugin is not there. If you’d like the scanning to stop right away, but cannot uninstall through WordPress, send off an email to [email protected] with your site URL, and we can take care of that.

Hope that answers your question clearly!

Hey Rajat –

Sorry about that. There is indeed an issue with warnings for manual fixes. We initially didn’t warn for vulnerabilities once they were marked as manually fixed, but then we had a few manual fixes that were applied incorrectly, causing a few sites to get hacked. The problem is that when the fix is applied manually we can’t (yet) detect whether it was done 100% correctly since it wasn’t done by our software.

We will be releasing a new version shortly which will address this, and will also allow you to hide the warning message once you’ve performed the fix.

Good point, a1wsn! We’ve added it to that article.

cscottb –

Sorry to hear you feel that way.

Remember that our software gives you full technical details on the vulnerabilities found, and also provides you with full fix instructions (including code patches where relevant). You are welcome to review these instructions, which are available on your dashboard (and do not require any kind of payment). If you still feel the vulnerabilities shown are incorrect, please contact us at [email protected] with the specific vulnerabilities in question, and we will provide you with proof of concept code where possible.

Hey nima1981,

This issue was fixed in a recent release of the plugin. You are welcome to try again with the latest version and it should activate just fine.

Of course, let us know if you run into any further trouble.

Hi Miz,

That’s a legitimate 6scan address, it’s our scanner in the cloud that make sure your website is safe and clean from all security vulnerabilities we find.

6Scan Support Team

Yes, the plugin will work correctly on IIS if it supports .htaccess files. There are ISAPI extensions for IIS that add this support — these would be required anyway for you to to take advantage of WordPress’ URL rewriting features.

Good day birons,

We have checked the 6scan.php, and what you describe is rather peculiar. The error presented shows, that something is wrong at line 148, while the file is much smaller than this.

Could you please e-mail us the 6scan.php file from your /home…../plugins/6scan-backup/ directory to [email protected]?

Thank you

Hey itpixie,

The vulnerability in question hasn’t been patched as of the latest WordPress release (3.4.1). We just retested it to make 100% sure. So yes, you should still follow the instructions to patch it yourself.

We’d be interested in hearing where you got the information that it was patched, so if you could send that over it would be great.

Brian,

I entirely understand your concern that something may go wrong if you try again. If you are interested in finding the problem nonetheless, do you by any chance have a backup of the site you could provide us with, so we can try to reproduce the problem (on our own test servers of course)?

Thanks for your feedback in any case.

Hey Otto,

I see your point; however, that isn’t exactly how the attack we’re trying to prevent works.

Imagine the following scenario: I’m a hacker who’s managed to take over one site (say pwnd.com). I can now add code to pwnd.com to make not myself, but pwnd.com’s visitors, perform comment spam on some other vulnerable site. In this case, since I don’t control pwnd.com’s visitors (I can’t make them send any specific referrer that I choose, for example), the fix suggested will in fact close the hole.

A dedicated comment spam solution such as Akismet helps – two layers are always better than one – but this does help mitigate the problem.

I hope that made the issue clearer.

Hi brianclegg,

Are you sure the problem is related to 6Scan and not something else you might have installed in the same session?

Is the problem still there now? I just tried to access both links above and all looks okay. If you continue having any kind of trouble, please send us a screenshot so we can take a more detailed look.

If you can please send any reply to us by email at [email protected], we can give you a much faster response time than here on the WordPress forums.

Thanks,
Nitzan

Hi dukejames27,

When you disable the 6Scan plugin, we aren’t always able to detect this, so yes, we may continue scanning your site for vulnerabilities.

However, if you uninstall (delete) the 6Scan plugin from your WordPress admin panel, this will automatically stop any scans on your site.

I’m happy to answer any further questions.

Nitzan

AANC,

I can’t tell you the exact line number as that may change between installations, but the code before the change should look something like this:

if ( 'POST' != $_SERVER['REQUEST_METHOD'] ) {
	header('Allow: POST');
	header('HTTP/1.1 405 Method Not Allowed');
	header('Content-Type: text/plain');
	exit;
}

/** Sets up the WordPress Environment. */
require( dirname(__FILE__) . '/wp-load.php' );

What you have to do is insert the block of code you mentioned between the two “paragraphs” you see above (right where the blank line is).

Hope that clears up any confusion.