6Scan is warning about a comment posting forgery ?

Hey Dave,

Yes, this is a real vulnerability that was recently discovered in WordPress 3.3.1. As the description states, it could allow malicious users to post unauthorized comments on any of your blog posts (for example, spam comments). It was classified as high severity because although it can’t be used to steal your data, excessive off-topic comments could be used to deface your site and reduce its credibility.

The reason no further data is available is because we don’t want to make it too easy for malicious users to exploit the vulnerability by giving too many details. Of course, as soon as WordPress fix it and release a new version, full details will be published. We’ve been conferring with the group that originally found the vulnerability, and they’re in the process of notifying WordPress about it (if they haven’t already done so). WordPress is usually very good about fixing vulnerabilities such as these, so we expect a quick release of version 3.3.2 or similar once they have it fixed.

In the meantime, you can of course upgrade the 6Scan plugin to get the vulnerability fixed.

Cheers, thanks for the quick update!
Dave

Hello! 6Scan notified me about this too, so I will Manually Scan this.
But I don’t know a lot about coding (I don?t actually know anything about coding) so I need to know, where should I put the code?
It says that it should be added in the wp-comments-post.php, prepending the line /** Sets up the WordPress Environment. */ with this:

if ( ! isset( $_SERVER[ "HTTP_REFERER" ] ) )
			die();

		$referrer_url = $_SERVER[ "HTTP_REFERER" ];
		$server_name = str_replace( "." , "\." , $_SERVER[ "HTTP_HOST" ] );	/*	Escape the dots for following regexp search */
		$server_name = str_replace( '/' , '\/' , $server_name );	/*	Escape the '/' for following regexp search */

		$referr_pattern = "/^((http(s)?):\/\/)?(www.)?$server_name/";		

		if ( ! preg_match( $referr_pattern, $referrer_url ) )
			die();

So I would like to know how exactly to put this, where and how. If you can tell me the lines that come before and after so I can get located on this, better.

Thanks!

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.

Howdy!

This doesn’t appear to be valid to me, given the “fix” suggested above.

All that code does is to check that the Referrer header is equal to the site itself. However, the referrer header is controlled by the requesting source, in that it comes from the headers of the browser making the request to add a comment. So a spammer sending to the comments form post process directly could, rather trivially, bypass your “fix”.

Given that, this doesn’t appear to be a valid vulnerability in the first place. The point of somebody making a POST request to the wp-comment-post.php file is to, simply, post a comment. Any request to this that is valid should make the comment, while spam should be handled by anti-spam systems such as Akismet. Requiring a referrer check doesn’t mitigate this except in the “club” sense. Adding such a referrer check to core, for example, would simply mean that every spam-bot out there would just be modified to start including the referrer header in their POSTs.

That said, there was a separate issue in 3.3.1 involving the redirect after comments. The suggested patch above would not fix it, but that’s okay because the issue in question was fixed in WordPress 3.4 as well as backported for WordPress 3.3.2.

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.

Hello 6Scan,

I have manually edited the files but even then the scan still shows the issues. Once I had made a one time payment after which the issue was not longer showed, but doing manually is not helping.

I’m in the same boat with you Harish. After manual fix, 6scan is still warning that the issue needs attention (doesn’t recognize the fix).

@bluesbrush, they have now added the dismiss button. so atleast we can get rid of the warning message.

I have WordPress 3.4.2, and I’m STILL getting this error, so obviously it has not been fixed. @harish, dismissing the error also means that you won’t be notified again about that file, even though there still may be a vulnerability on your system. Am I correct about this, 6Scan?

Good day Bradley,

You are correct – we have reported this issue to WordPress team and hopefully it will be resolved in the future

Thank you

@bradley, 6scan is a great tool. They firewall is excellent. However to be able to monetize I understand the need to have few warning that will convert some users to customers.
Even if you manually fix the the issues the warnings still show up so I guess its up to us to remember this and update the files manually every time WordPress updates.

Good day Harish,

Thank you for the kind words,
However there is a way to mark your manual fix as applied – click on the ” I have manually fixed this vulnerability” link.
But indeed, you have to keep this matter in mind when updating to a new WordPress version.

Please refer to those screenshots:
Applying the fix
The result

@6scan yes currently I do the same. But even after that, the warning message is still shown and on the 6Scan menu the warning count is shown as well.

Good day Harish,

You are right.
We have just changed our vulnerability reporting functionality.
Manually fixed vulnerabilities will no longer be counted as active.

The counter value will be updated on the next scheduled scan (You should see it within a day)

Thank you for this feedback – don’t hesitate contacting us with new ideas/comments!