Automattic’s “Internal Audit” of Plugin Misses Vulnerabilities Impacting Plugins With 1.2 Million Installs
On Friday, Automattic, through their Jetpack service’s blog released details of a vulnerability in a WordPress plugin based on what they described as an “internal audit”:
During an internal audit of the Smash Balloon Social Post Feed plugin (also known as Custom Facebook Feed), we discovered several sensitive AJAX endpoints were accessible to any users with an account on the vulnerable site, like subscribers.
We are not sure what an internal audit is supposed to mean there or why they were really doing it. At the end of the post they wrote this:
At Jetpack, we work hard to make sure your websites are protected from these types of vulnerabilities. We recommend that you have a security plan for your site that includes malicious file scanning and backups. Jetpack Security is one great WordPress security option to ensure your site and visitors are safe.
That service, though, doesn’t provide protection against exploitation of this sort of vulnerability and doing an audit like this seems largely irrelevant to what they actually provide.
What seems like the explanation is to look at the previous employer of the author of the post, Sucuri, that disclosed vulnerabilities in WordPress plugins, explaining the reason for finding the vulnerabilities based on a “routine audit for our Website Firewall product” in situations where the type of vulnerability wouldn’t call for doing “audits”.
What seems to be the explanation in both situations is that the companies are looking to market their service by doing something unrelated to it and not being honest about it.
A problem with what looks to be going on at both companies is that gives people the belief that WordPress plugins are going through security reviews that they are not. That probably makes it more likely that real security reviews don’t happen to the plugins. Why would someone hire a company to do such a review if it appears that they already happen?
In this situation we found that the plugin brought up, Smash Balloon Custom Facebook Feed, which has 200,000+ installs, still contains vulnerabilities related to what Automattic had found, which isn’t surprising when what went on there wasn’t really an audit, but looking for a vulnerability to get themselves coverage.
Furthermore, another plugin from the same developer, Smash Balloon Social Photo Feed, which has 1+ millions installs, also contains vulnerabilities due to the lack of those checks.
The developer has two more plugins, so it is possible that more plugins are insecure.
This is the second time this month that this person has been allowed by Automattic to claim that “internal audit” had been done, where the underlying insecurity still exists. In the other case, we know that they missed part of the issue, as we had already warned about another instance of the insecurity three years ago, which still hadn’t been fixed.
Security Checks Missing in Smash Balloon Custom Facebook Feed
Automattic’s post left out a concerning about the vulnerability being detailed, the vulnerability had only been introduced in the version prior to the one it was fixed in. That is so concerning because you have someone developing very popular plugins that appears to lack a basic understanding of security, as the vulnerable code lack both a capabilities check as well as nonce check, despite those being basic security checks.
The vulnerability Automattic identified involved functionality accessible through WordPress’ AJAX functionality by anyone logged in to WordPress. If you were to do a security review it would be very easy to review all of the functions accessible that way and what you would see is in the version after their review, 4.0.1, there are still plenty of functions that are lacking one or both of those checks.
For example, in the file /admin/admin-functions.php, the function cff_clear_error_log() is made accessible through WordPress’ AJAX functionality and neither of those security checks are made:
2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 | function cff_clear_error_log() { \cff_main()->cff_error_reporter->remove_all_errors(); cff_delete_cache(); echo "1"; die(); } add_action( 'wp_ajax_cff_clear_error_log', 'cff_clear_error_log' ) |
Security Checks Missing in Smash Balloon Social Photo Feed as Well
Checking the plugin Smash Balloon Social Photo Feed, we found the same issue exists there as functions accessible through WordPress’ AJAX functionality are missing capabilities and nonce checks. Looking at that, we can’t even figure out what is going on, as in one file, /inc/admin/actions.php/, there is what appears to be a random mix of missing one or both of the checks.
For example, the function sbi_reset_log() doesn’t include either:
847 848 849 850 851 852 853 854 855 856 | function sbi_reset_log() { global $sb_instagram_posts_manager; $sb_instagram_posts_manager->remove_all_errors(); echo "1"; die(); } add_action( 'wp_ajax_sbi_reset_log', 'sbi_reset_log' ); |
But, the function sbi_clear_backups() does include a nonce check:
803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 | function sbi_clear_backups() { $nonce = isset( $_POST['sbi_nonce'] ) ? sanitize_text_field( $_POST['sbi_nonce'] ) : ''; if ( ! wp_verify_nonce( $nonce, 'sbi_nonce' ) ) { die ( 'You did not do this the right way!' ); } //Delete all transients global $wpdb; $table_name = $wpdb->prefix . "options"; $wpdb->query( " DELETE FROM $table_name WHERE `option_name` LIKE ('%!sbi\_%') " ); $wpdb->query( " DELETE FROM $table_name WHERE `option_name` LIKE ('%\_transient\_&sbi\_%') " ); $wpdb->query( " DELETE FROM $table_name WHERE `option_name` LIKE ('%\_transient\_timeout\_&sbi\_%') " ); die(); } add_action( 'wp_ajax_sbi_clear_backups', 'sbi_clear_backups' ); |
Making the situation with the plugin worse, the value needed to pass the nonce check, which prevents cross-site request forgery (CSRF), is included on all admin pages instead of just the intended ones, so the equivalent of a capabilities check that would normally provide also is limited.
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 for Smash Balloon Custom Facebook Feed
The following proof of concept will empty the error log, when logged in to WordPress.
Replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]]/wp-admin/admin-ajax.php?action=cff_clear_error_log
Proof of Concept for Smash Balloon Social Photo
The following proof of concept will empty the error log, when logged in to WordPress.
Replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]]/wp-admin/admin-ajax.php?action=sbi_reset_log