WordPress.org

Ready to get started?Download WordPress

Forums

6Scan is warning about a comment posting forgery ? (17 posts)

  1. DavePorter
    Member
    Posted 2 years ago #

    Hi There,

    I had a security issues a few weeks ago, and now have BulletProof Security on my sites, and on a few I also installed 6Scan.

    Last night the sites that had 6Scan all received an email warning of an issue...

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Wordpress 3.3.1 comment posting forgery
    CSRF vulnerability in WordPress versions under 3.3.1 allows malicious users to make fake posts
    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

    Is this something I should be concerned about ?
    They won't provide any further details until you upgrade to their paid version :(

    Is this a real vulnerability ? And if so is it fixed in 3.4 ?

    TIA, Dave

  2. 6Scan
    Member
    Posted 2 years ago #

    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.

  3. DavePorter
    Member
    Posted 2 years ago #

    Cheers, thanks for the quick update!
    Dave

  4. AANC
    Member
    Posted 2 years ago #

    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!

  5. 6Scan
    Member
    Posted 2 years ago #

    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.

  6. Samuel Wood (Otto)
    Tech Ninja
    Posted 2 years ago #

    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.

  7. 6Scan
    Member
    Posted 2 years ago #

    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.

  8. Harish Chouhan
    Member
    Posted 1 year ago #

    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.

  9. bluesbrush
    Member
    Posted 1 year ago #

    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).

  10. Harish Chouhan
    Member
    Posted 1 year ago #

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

  11. Bradley A.
    Member
    Posted 1 year ago #

    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?

  12. 6Scan
    Member
    Posted 1 year ago #

    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

  13. Harish Chouhan
    Member
    Posted 1 year ago #

    @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.

  14. 6Scan
    Member
    Posted 1 year ago #

    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

  15. Harish Chouhan
    Member
    Posted 1 year ago #

    @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.

  16. 6Scan
    Member
    Posted 1 year ago #

    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!

  17. Bradley A.
    Member
    Posted 1 year ago #

    I love the 6Scan plugin, so that's great to hear!

Topic Closed

This topic has been closed to new replies.

About this Topic