Cross-Site Request Forgery Vulnerability (CSRF) in WP to Twitter
Recently we wrote a post, Don’t Expect That Someone Else Has Checked The Security of the WordPress Plugins You Use, about the fact that you can’t expect that others have checked the security of the plugins you use. That obviously applies to us as well as everyone else, so we are taking a closer look at the plugin we use and spotted one minor security issue so far. That issue was a cross-site request forgery vulnerability (CSRF) vulnerability that was in Wp to Twitter’s function for saving it’s options.
The vulnerability would have allowed an attacker who could get a logged in Administrator level user to visit a page they control to change the plugin’s settings. This type of vulnerability isn’t something we see attempts to exploit in general and when it can’t be combined with something more serious like a cross-site scripting (XSS) it would be little more than a nuisance if exploited. In this case the plugin’s settings seemed to be hardened against cross-site scripting.
It is worth bringing up though because the cause of this vulnerability is something we see frequently causing CSRF vulnerabilities and in other cases the CSRF could have more serious consequences than this one.
In the file /wp-to-twitter-manager.php the nonce included with request to change the options, which is used to prevent the CSRF, is checked this way in version 3.2.9:
9 10 11 12 13 14 | if ( ! empty( $_POST['_wpnonce'] ) ) { $nonce = $_REQUEST['_wpnonce']; if ( ! wp_verify_nonce( $nonce, 'wp-to-twitter-nonce' ) ) { die( "Security check failed" ); } } |
The problem with that code is that if a value for the nonce, $_POST[‘_wpnonce’], is not included then the function this is in will continue running past this code even though the security check did in fact fail since there was not a valid nonce. As we mentioned in one of our security tips for developers, you don’t need to check if a nonce exists before verifying it since WordPress will do that check for you.
Within a few hours of us notifying the developer, the vulnerability was fixed with the release of version 3.2.10.
Proof of Concept
The following proof of concept with change the value of “
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin.php?page=wp-tweets-pro&tab=basic" method="POST"> <input type="hidden" name="submit-type" value="options" /> <input type="hidden" name="wpt_post_types[post][post-published-text]" value="CSRF" /> <input type="submit" value="Submit" /> </form> </body> </html>
Timeline
- 6/13/2016 – Developer notified.
- 6/13/2016 – Vulnerability fixed with release of version 3.2.10.