This monthly report is provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core No notable WordPress core security releases. Plugin/Theme Vulnerabilities of Note Security & Malware scan by CleanTalk https://wpvulndb.com/vulnerabilities/10292 This vulnerability within CleanTalk allows an authenticated user, such as an editor or subscriber, to make unauthorized Ajax calls which could lead to file deletion or downloads and also potentially function calls. Adning Advertising https://wpvulndb.com/vulnerabilities/10293 The Adning Advertising plugin has a vulnerability in versions lower than 1.5.6 which allows unauthenticated requests to upload or delete files, leading to an RCE attack, which can then lead to full site takeover. Wise Chat https://wpvulndb.com/vulnerabilities/10299 Wise Chat versions lower than 2.8.4 are susceptible to a CSV injection via a command sent in chat messages by an unauthenticated user that is included in an exported CSV file, which then could potentially lead to an RCE attack. Email Verification for WooCommerce https://wpvulndb.com/vulnerabilities/10318 The Email Verification for Woocommerce plugin prior to version 1.8.2 is affected by a loose comparison issue. This could potentially lead to any user (authenticated or non-authenticated), to log into the WordPress site. SRS Simple Hits Counter https://wpvulndb.com/vulnerabilities/10316 The SRS Simple Hits counter plugin is currently vulnerable to an unauthenticated blind SQL injection vulnerability. The responsible reporting parties at Tenable ( https://www.tenable.com/security/research/tra-2020-42 ) are working with the developer to write a more comprehensive patch to address this vulnerability, and will not release more details on the attack until they know a patch has been released. Site owners using SRS Simple Hits Counter plugin on their sites should keep an eye out daily for the patch to be released. Payment Form For Paypal Pro https://wpvulndb.com/vulnerabilities/10287 The Payment Form for Paypal Pro plugin versions before 1.1.65 are vulnerable to an unauthenticated SQL injection attack. The attack is a trivial single request which can expose the contents of your database (which includes user passwords and potentially other secrets) to the attack. This is a high risk vulnerability and site owners should patch immediately. WooCommerce Subscriptions https://wpvulndb.com/vulnerabilities/10330 The WooCommerce Subscription plugin is vulnerable to an unauthenticated stored cross site scripting (XSS) attack in the subscription billing process. Attackers can submit their XSS attack payload to during the billing step in the signup process, and later that payload will be executed on the browser of the administrator/user who reviews the attacker’s account. Site owners should update WooCommerce Subscriptions plugin to version 2.6.3 and not check any new user account information until that update is performed. TC Custom JavaScript https://wpvulndb.com/vulnerabilities/10325 The TC Custom Javascript plugin is vulnerable to an unauthenticated stored cross site scripting attack. Sites running versions before 1.2.2 should update immediately, attackers can add their own javascript or HTML to the footer of all pages loaded by WordPress with a few basic requests. This vulnerability is likely to be targeted by SEO spam bots. KingComposer https://wpvulndb.com/vulnerabilities/10297 The KingComposer plugin is vulnerable to a reflected cross site scripting vulnerability in versions before 2.9.5 This means the attacker’s malicious HTML/javascript will only be available to the browser making this request. This still poses a high risk if an attacker can trick an already logged in user to click on a malicious link/form to the website, potentially exposing secrets viewable by the user giving them to the attacker. JobSearch https://wpvulndb.com/vulnerabilities/10328 The JobSearch plugin versions before 1.5.6 are vulnerable to a reflected cross site scripting vulnerability. Much like the KingComposer vulnerability above it is a high risk if logged in users to be targeted. The proof of concept for this vulnerability will be released on August 6th, 2020, site owners should patch before this date. See previous months’ WordPress security updates from May and June.
These monthly reports are provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core WordPress 5.4.2 Security Release https://wordpress.org/news/2020/06/wordpress-5-4-2-security-and-maintenance-release/ A WordPress Security release (5.4.2) was made available on June 10th. This release addresses the following 6 vulnerabilities: Authenticated XSS in the block editor Authenticated XSS in media files Authenticated XSS in theme uploads Privilege escalation in set-screen-option() Open redirect in wp_validate_redirect() Information leak allowing comments to be read from password-protected posts and pages. Plugin/Theme Vulnerabilities of Note Removed from Repo WordPress website owners who have the following plugins installed are strongly encouraged to remove them from their websites or find a replacement as soon as possible. These plugins were removed from the WP.org plugin repository due to inaction of the developer to patch one or more security flaws: wp-pro-quiz delete-all-comments-easily High Severity Vulnerabilities ACF to REST API https://wpvulndb.com/vulnerabilities/10284 The acf-to-rest-api plugin versions before 3.3.0 are affected by a vulnerability which would disclose the values of the wp_options table to attackers. This vulnerability has varying severity based on what data is contained in a site’s wp_options table. KingComposer https://wpvulndb.com/vulnerabilities/10270 The kingcomposer plugin versions before 2.9.4 lack proper access controls for ajax endpoints, many of these ajax endpoints also include vulnerabilities which users with a valid accounts could target to change WordPress option values, inject content, store XSS code, delete files on the site or execute arbitrary code. wpDiscuz https://wpvulndb.com/vulnerabilities/10273 The wpdiscuz plugin versions before 5.3.6 are affected by an unauthenticated SQL injection vulnerability. This plugin is currently on release 7.0.3, and the plugin author is making 5.3.6 available as a back port for site owners not ready for version 7. Brizy – Page Builder https://wpvulndb.com/vulnerabilities/10261 Brizy Page Builder before version 1.0.126 is susceptible to an access control vulnerability via AJAX calls which allows a user with minimal privileges the ability to access editor functions. JobSearch https://wpvulndb.com/vulnerabilities/10255 The Jobsearch premium plugin before version 1.5.1 is affected by an unauthenticated reflected cross-site scripting vulnerability. The Proof of Concept is provided within the link below and is easily replicated: https://github.com/vladvector/vladvector.github.io/blob/master/exploit/2020-07-03-jobsearch-wp-job-board-wordpress-plugin-v1-5-1.txt See previous months’ WordPress security updates from April and May.
This article covers our public notifications related to major security issues our clients and the WordPress community should know about. We are always focused on prevention and the mitigation of risk to our clients, and keeping you updated here is part of that process. WordPress 5.4.2 Security Release June 11th, 2020 WordPress site users We trust them within reason. And patch, to be sure. The WordPress security team has released WordPress 5.4.2. This security release addresses 6 security vulnerabilities. There are numerous cross site scripting vulnerabilities addressed in this release however each required an authenticated user to execute the attack. There also includes one privilege escalation attack. If there were a theme in this release, it serves as a reminder to be sure you trust who you give accounts to on your WordPress site. The Pagely team has already begun rolling out this patch for all customers. If you have a version hold request on file, we will patch your site while keeping it on the same major branch version. WordPress 5.4.1 Security Release April 29th, 2020 You are safe at home, while we are patching your sites. Stay Safe. Stay Secure. The WordPress security team has released WordPress 5.4.1. This security release addresses 7 security vulnerabilities and includes 17 bug fixes. There are numerous cross site scripting vulnerabilities addressed in this release, so it is recommended site owner update right away (if you’re a Pagely customer we are already working on this for you.) The Pagely team will be rolling out this patch for all customers shortly. If you have a version hold request on file, we will patch your site while keeping it on the same major branch version. WordPress 5.3.1 Security Release December 13th, 2019 A vuln is a vuln, until a patch is released. Now it is secure. The WordPress core team has released WordPress 5.3.1, which addresses 3 security vulnerabilities and includes 1 security hardening measure. The higher risk vulnerabilities include XSS (Cross Site Scripting) in some unlikely situations, as well a vulnerability which could allow someone to mark a post “sticky” on the site, without the need for authentication. Pagely has tested this version and has the patch available for all customers running any WordPress version. Due to the weekend being upon us, we will begin upgrading sites on Monday December 16th. Any customers who would like the upgrade to be performed over the weekend can reach out to our support staff and they will be glad to help. PHP-FPM+Nginx Remote Code Execution (CVE-2019-11043) October 29th, 2019 Hasty vuln released. We checked immediately; Our servers are safe. On October 22nd, 2019 a security researcher released their findings related to a remote code execution in PHP-FPM, which was present on hosts with specific nginx configurations using fastcgi_split_path_info. Pagely’s stack does use the fastcgi_split_path_info directive within our nginx configurations, and our staff investigated the vulnerability on the 22nd the day of the relase. We identified we were already properly using the recommended remediation of try_files to ensure the file being requested actually exists on the website. Pagely’s default nginx configuration is not vulnerable. On October 24th the PHP dev team released the official patch version to address this vulnerability. Our staff have already started applying this patch to all customer servers. WordPress 5.2.4 Security Release October 15th, 2019 Secure WordPress Fast Six Vulnerabilities Secured by this Patch. The WordPress.org core team has released WordPress 5.2.4, a security release addressing six vulnerabilities from XSS to viewing unauthorized posts. Pagely staff have already begun applying patches to our customer’s WordPress websites. Customers with version holds will only receive the patch for the branch they are currently running. WordPress 5.1.1 Security Release Addresses XSS March 15th, 2019 Comment filter for Cross Site Scripting prevention; Helps secure WordPress. The WordPress.org core team has released WordPress 5.1.1 which is a security release to address two vulnerabilities related to improper filtering of comments on WordPress sites. Pagely staff have already begun applying the patch for each of our customer’s WordPress version, and will keep customers on their current branch version if they have requested a version hold. WordPress 5.0.1 (and 4.9.9) Security Release December 13th, 2018 WordPress new release Patches seven vulns in all. Handled by our team. The WordPress.org core team has released WordPress 5.0.1 which is a security release to address a number of vulnerabilities found in WordPress versions 5.0, 4.9.8 and older. The core team has also provided security releases for WordPress versions 4.9.x, 4.8.x, etc.. which addresses the same vulnerabilities for that WordPress branch release. Pagely staff will apply the appropriate patch for each of our customer’s WordPress version, and will keep customers on their current branch version. This means, if you’re running 5.0, we will apply the 5.0.1 patch, if you’re running 4.9 then we will apply the 4.9.9 patch, and so on with 4.8 and etc… This patching will be completed by the end of the week. WordPress 4.9.7 Security Release Addresses Arbitrary File Delete (CVE-2018-12895) July 5th, 2018 We patched this last week. This security release is safe to wait for. The WordPress.org core team has released WordPress 4.9.7 which adds some functionality and includes a security patch for the previously reported “Arbitrary File Delete” vulnerability (CVE-2018-12895) which we addressed last week Pagely implemented a patch to address this vulnerability on all customer websites, as there was no WordPress.org patch available when the vulnerability was publicly disclosed. Pagely customers can request to be upgraded to patched versions of WordPress over the weekend, all customer sites will be upgraded by early next week. WordPress Author Arbitrary File Delete (CVE-2018-12895) We trust our authors, to not delete files, but let’s not allow it. RIPSTech researchers Slavco Mihajloski and Karim El Ouerghemmi reported yesterday of a vulnerability in WordPress core which would allow users on a WordPress site with Author level access or higher the ability to delete and/or re-upload any file writable by the PHP process WordPress runs under. The limitation of this vulnerability hinges on the fact a malicious user must also be someone a site owner trusted with having author level access already (or a compromised author user account could be abused) The consequence of this vulnerability would be that an attacker or malicious user could potentially remove files on the server, which may disable protections (such as .htaccess files, or security plugins), or allow them to re-write a site’s wp-config.php (to point your site at the attacker’s database, or install their own credentials/secret keys.) Our infrastructure configuration does not allow PHP processes to be able to modify any WordPress core files, however the risk of modifications to plugins, .htaccess files or other user uploaded files remains. To address this we have implemented a recommended hotfix which sanitizes the file path in the attachment delete/modification function used by WordPress core. The patch implemented has been tested and verified as safe and will be pushed out to our customer servers this week. If for any reason this hotfix causes issues with your site user’s ability to remove or edit media on your blog, please let our support staff know and we can help sort out the problem. PHPMyAdmin File Inclusion and Remote Code Execution (CVE-2018-12613) (PMASA-2018-4) Admin your DB with php, securely. We did the upgrade Pagely customers who have phpMyAdmin configured on their servers can rest assured we have taken steps to upgrade all of our customer’s phpMyAdmin installations to address multiple vulnerabilities recently reported. TLS 1.0 Retirement It’s been a long time coming, so break out the gold watch and cake. TLS 1.0 is finally being retired across the web thanks to the push by PCI-DSS. Pagely is updating our customer websites this week to address this and will be supporting TLS 1.1 or higher by default on our servers this week. By default, customer websites will only communicate over HTTP using the more secure TLS 1.1 and 1.2 protocol versions, and TLS 1.0 will no longer be an option. The reason for the change has been a long time coming. There are multiple browser based vulnerabilities in TLS 1.0, and the protocol version has been depreciated for years. However, the big deadline is that PCI-DSS counsel has set a hard deadline for June 30th, 2018 as the final day that sites will no longer be able to pass PCI scans if they have TLS 1.0 enabled in any manner. The impact of requiring TLS 1.1 or higher, is almost certainly going to be negligible. Every major browser supports TLS 1.1 and 1.2, rough estimates put less than 4% of the global internet traffic as using a browser that only support TLS 1.0, this is mostly composed of old mobile devices. So, sorry everyone on a dated iPad or Android tablet/phone, it’s not safe for you to transmit data over HTTPS and hasn’t been for a long time! Luckily, this number continues to drop every year, as these old devices eventually get replaced or taken out of service. Pagely Login Page Updates Pagely customers will notice something new when accessing their Pagely administration panel https://atomic.pagely.com on May 31st 2018. Our new login portal! Don’t worry, this change is expected as we are rolling out some improvements to our administration panel and preparing for it’s replacement. When you visit https://atomic.pagely.com your browser will automatically be redirected to our new version of Atomic. You may see the words “BETA” here and there, and some customers (those already upgraded to ARES) will have new features available as well. There is nothing you need to do on your end at this time, your login will function as normal and the new atomic panel has all the same basic features as the old one — If you’re feeling a little nostalgic, you can still switch back to the old Atomic panel by hitting the “Atomic (Legacy)” button found in the panel. In the near future we will be offering a new 2FA feature to give our customers a better experience with their 2FA management, but this first login portal change on 2018-05-31 will not affect your existing login credentials. PHP Security Patch (CVE-2018-10546 CVE-2018-10547 CVE-2018-10548 CVE-2018-10549) You need a null byte; Or you get heap overflows! MakerNote take Note. PHP has released a security patch which addresses four security vulnerabilities, the worst of which is a heap overflow from uploaded images which lack null bytes or corrupted EXIF data in MakerNote files. Further details available in the PHP 7.0 Changelog and PHP 5.6 Changelog. Pagely has begun upgrading customer servers and all PHP versions will be on patched in the next few days, if not already. WordPress 4.9.5 Release Secure hardening in the four nine five release; Other bugs fixed too. WordPress version 4.9.5 has been released and is considered a security and maintenance release. The WP core team addressed 3 security related bugs which are not critical security bugs, but improve the code’s overall security. You can read more about the release here. Pagely will begin updating customer sites to 4.9.5 shortly. POP-ping WordPress Object Injection? DNS must be trusted. Or else, oh no! Hacks! Researcher Nick Bloor (@nickstadb) recently released a report on object inject+DNS vulnerabilities in WordPress which could lead to remote code execution/arbitrary file uploads to sites. Nick explains that if attackers control the name servers the website uses to lookup domains, then it’s possible to “spoof” being the WP update server due to WordPress defaulting to HTTP communications when HTTPS fails during updates. This report outline that if attackers were able to take control of a DNS server, they could pivot that access to then also take over WordPress website via the WordPress auto-updater as well as exposes a PHP Object injection as well. Pagely customers are not affected by this vulnerability, as we are a managed host and do not allow modifications to what name servers our customer’s servers utilize. Secondarily, our server permissions would not allow WordPress auto-updater to function on it’s own (we handle upgrades for customers), this is identified in the “caveats” section of the vulnerability disclosure page as a preventative measure. WordPress load-scripts.php DoS (CVE-2018-6389) Feb. 6, 2018 Loading all the scripts, leads to long web responses. Rate limiting, Win. We are aware of the reported Denial of Service (DoS) affecting WordPress’s /wp-admin/load-scripts.php; Assessing the risk we believe our caching system dramatically reduces any DoS threat targeting a single URL with scripts like this. We are implementing a fix which is currently in testing, it will limit the number of requests people can make to this file before being throttled and subsequently blocked. This fix will be available for all customers, including those on the new ARES platform. WordPress Security and Maintenance Release: 4.9.2 Jan. 16, 2018 Other people’s code How did it get on your site? Sad emoji face. WordPress version 4.9.2 has been released and it contains an update to address an insecurity in the Media Elements library, which is included in WordPress core. The patch addresses a cross site scripting (XSS) vulnerability, which could allow remote attackers to inject their own HTML onto your site. Pagely will be patching customer sites immediately, and should be finished shortly. If you would like to read more about this release please see the WordPress blog announcement here. Spectre and Meltdown Jan. 5, 2018 Reading memory, outside of your privilege. Time to patch kernels. [Update: Feb 2, 2018 CST] Our kernel hotpatch provider has released a working patch for Meltdown as well, and it has been applied to all customer servers. [Update: Jan 18, 2018 09:00 CST] Spectre: Patched without the need for a reboot Meltdown: Patch available if you request a reboot, we are still waiting on the no-reboot patch which is close to being tested as safe to apply. If you are concerned about the risks associated with Meltdown, contact support to request a server reboot. Or wait until our no-reboot patch has been tested and is working safely. Risk associated with Meltdown: There are still no PHP based proof of concepts, therefor we consider it a low-likelyhood that anyone (aside from someone with SSH access to your server) would be able to perform this attack on your site/server. If you disagree with this risk assessment, then please contact support and we will schedule a reboot to apply the patch for Meltdown ASAP. [Update: Jan 11, 2018 11:30 CST] Our kernel patch provider has released a working patch for Spectre, but not Meltdown. We will be applying the Spectre patch to all servers before the end of the week, and will be awaiting their patch for Meltdown when it becomes available. If you would like to hasten the patch time, we can apply the kernel patch from Ubuntu (released yesterday) however this will require a schedule reboot for the change to take affect. If you would like to schedule a reboot of your server, please contact our support staff from your account’s primary contact email address (or via our administration panel) These patches are known to cause a negligible performance hit on servers when applied. It’s likely you will not notice this performance hit on your site unless your code does a large amount of system calls and/or you are already close to needing an upgrade. Our engineers are working on a solution to this issue and we may be able to work with customers impacted to entirely remove this performance hit or actually come out ahead. [Update: Jan 9, 2018 09:00 CST] At this time (Tuesday January 9th) we do not yet have a stable patch to apply to customer’s servers. The patch plan for early this week was not met. This was due to the complicated nature of this patch, and ensuring a stable patch is what is pushed out to servers. It’s been identified by multiple sources that this patch is not the simplest, concerns of stability and CPU overhead come up and this has delayed the patch from either Ubuntu (our operating system) or KernelCare (our kernel patch provider). Risk assessment: The existing proof of concepts for these vulnerabilities are not executable against our customer’s sites due to how our PHP is configuration (we restrict/ban any exec/shell calls) which reduces the risk of this vulnerability. Only customers with compromised SSH accounts would be vulnerable (and if there does exist a PHP PoC in the future, only customers with compromised sites would be exposed.) We are delaying the patching process. This decision is made under the consideration that many people are reporting issues with the patches available, and the lower risk this vulnerability has at exploiting WordPress sites on our network. Tentative timeline: We expect patches from one of the upstream providers (Either KernelCare or Ubuntu) tomorrow, Wednesday Jan 10th, however this may be delayed. When a patch is available, if it is Kernel Care, no reboot will be required. If it is Ubuntu, then we will need to reboot your server for the change to take affect. We will begin applying patches for customers this weekend or next week (a few days after the patches are released so we have time to test the patch sets.) We will contact customers via email to schedule a reboot, if it will be required to apply this patch. [Original post] Pagely is aware of the multiple related vulnerabilities in Intel (and other) CPUs known as “meltdown” or “spectre” and has been working on patching affected servers. This vulnerability is a bit different than most, as it requires patching done on the bare-metal server as well as a second round of patching on our virtual instances for Pagely customers. Our data center provider notified us regarding what servers were affected by a security concern and needed reboots to apply a patch. We have already been working with the affected customers on and scheduled reboots to address this security concern. It’s likely that these CPU architecture vulnerabilities were likely the cause for the scheduled reboots in December. At least check, we have address almost all of these (and the last few are scheduled with the respective customers to happen shortly.) All remaining EC2 instances are on bare-metal servers which likely have been patched without the need for a reboot (however this may change). If you did not receive an email related to scheduling reboots on your site/server, then the patch for this vulnerability did not require a reboot to take affect. If this changes, we will be on contact with any customers who need to schedule a reboot. That only leaves the linux kernel on each of our EC2 instances as a remaining concern. Luckily we now utilize a new technology in the linux kernel which allows for live-patching the kernel without the need for a reboot. This patch will be applied to all of our customers as soon as the kernel patch is officially out and properly tested. The tentative timeline for this should be this weekend or early next week (and require no reboot of the server, it should be applied seamlessly.) PHPMyAdmin CSRF Jan. 5, 2018 Click this link my friend Cross-Site Request Forgery! But not with Pagely. Over the holiday break there was a CSRF vulnerability reported with PHPMyAdmin, this class of vulnerability would allow an attacker to send malicious links to users with browser’s already authenticated in PHPMyAdmin to perform actions as the logged in user. A patch was applied in 4.7.7 to address this issue, and all PHPMyAdmin installations Pagley has have been updated. WordPress Security and Maintenance Release: 4.9.1 Nov. 20, 2017 Holidays are for: Family, eating too much, and security. Don’t worry you can stay distraction free when dining with friends and family this holiday season, knowing that we have handled this WordPress security release update for you and your sites. Instead of worrying if your site has been patched, you can be the one to bring it up at social gatherings and watch as your friends or family with WordPress sites become uncomfortable not knowing if their sites are secure or not. Pagely customers will receive the WordPress 4.9.1 security release update this week. This security and maintenance release includes patches for multiple vulnerabilities including a cross-site scripting (XSS) and XML eXternal Entity (XXE) issues. This will also officially bring all customers up to the 4.9 branch from 4.8.3, unless you’ve previously written in requesting an upgrade to 4.9 in the last few weeks. You can read more about this security release and specific details on what it includes here on the WordPress news blog, as well as more details on how we handle major WordPress releases (like 4.9) on our blog here: WordPress 4.9 Release. WordPress 4.8.3 Oct. 31, 2017 WordPress Halloween. We patch the tricks, 4 8 3 You get the treats. Boo! There is nothing spookier than a WordPress security release, the 4.8.3 patch addresses an SQL injection vulnerability in WordPress core which could be exposed by insecure coding practices found in some plugins. This release hardens the WP Core code to protect the sites who may harbor an insecure SQL query that trusts user input, sanitizing the input before it’s passed along to the database server. More information on this release can be found on the WordPress blog, details on the changes and how it modifies the return value of of esc_sql() have been posted by Gary Pendergast on the Make WordPress Core developers blog. Thanks goes out to the reporter of the vulnerability (Anthony Ferrara) for working with the WordPress security team. And a special acknowledgement to our own Arman Zakaryan for the Haiku this time around. OptionsBleed Sept. 21, 2017 Memory Leaking over OPTIONS requests sent. This patch stops the leak. The vuln-du-jour is called OptionsBleed and affects Apache2 web servers. It was caused by a programming oversight in the Apache2 server project which allowed small amounts of memory to be leaked when an OPTIONS request is sent to the web server. This bug only affects sites that are configured with a LIMIT directive which attempts to filter nonexistent HTTP methods, which is extremely rare but does exist in just under 500 of the Alexa top 1 million websites. A more detailed write up about this can be found here. The Apache2 dev team wasted no time in providing a patch. Which we have already begun applying to customer servers. We are rolling this patch out slower than a normal security patch because it’s so rare for this misconfiguration to exist and initial reviews of customer sites shows no Pagely customers have misconfigured LIMIT directives which would put them at risk. That said, the patch will be applied in a safe manner over the next week as to minimize any risk of downtime on customer sites related to the upgrade. WordPress 4.8.2 Sept. 19, 2017 Within this release, Nine security patches. Sites are now secure This week brings a security update to WordPress core. The security patches include multiple serious vulnerabilities and we are applying patches as soon as possible for customers. The WordPress core and security team have also released version to address any of the patched vulnerabilities for the following versions: 4.8.2, 4.7.6, 4.6.7, 4.5.10, 4.4.11, 4.3.12, 4.2.16, 4.1.19, 4.0.19, 3.9.20, 3.8.22, and 3.7.22. Any customer of Pagely running older branches of WordPress will also be brought up to date with these security patches. Malicious Code in Display Widgets Sept. 13, 2017 We coined a new term: “plugin identity theft”. Let it not catch on. A popular plugin in the WordPress.org repository has been “hijacked” (for lack of a better term) by a developer with suspicious intent. The popular plugin “Display Widgets” is described as “Adds checkboxes to each widget to show or hide on site pages“, yet in the last few releases there have been some unexpected new features added: such as adding posts directly to the site and tracking site visitors. Wordfence, a security plugin, wrote a full explanation on how this might have happened, it’s worth a read here. For our customer’s safety, we have banned the plugin from our customer sites. If your site hosted with Pagely was affected we have already reaching out directly to help you with the concern. More information about the issue at hand with this plugin can be found on WPVULNDB and in the plugin’s support forum . Update: The plugin team at WordPress.org have released a patched version of Display Widgets which reverts it back to the last known safe version, but there appears to be no author to continue maintenance on the plugin. The plugin will remained banned on our network until a time that we see someone has taken responsibility for the plugin and the future of patching it’s code. Which plugins and themes aside from display-widgets should you avoid? See our full list here. WordPress 4.7.5 Release May 17, 2017 Patchy patchy patch I love patches for WordPress Here come the patches Pagely customer sites are being updated to address 6 vulnerabilities. The ExploitBox Unauthenticated Password Reset Vulnerability has still not yet been addressed; Pagely customers are still not affected. Further details on this release can be found here: wordpress.org ExploitBox’s CVE-2017-8295 May 5, 2017 Return to sender sending to the wrong domain read from HOST header. There was a recently released authentication bypass vulnerability that affects WordPress before and including 4.7.4, with specific server configurations. The attack requires a request to a WordPress site via it’s IP address, while the attacker sets the HTTP request header to their own HOST value. Pagely does not allow direct access to WordPress sites via IP address and requires the HOST field sent in the headers to be the actual site being requested, thus a request with a HOST value controlled by an attacker will not be directed to a WordPress installation at Pagely. Bonus Haiku: Pagely hosted sites are not affected by this reported exploit. For more details on the vulnerability and how it works, please read: https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html WordPress 4.7.3 Security Release Mar. 6, 2017 XSS and more bugs get patched in this release. The update is done Customer sites are being updated to address 6 security related issues. Further details on the release can be found here: wordpress.org CloudBleed, Shattered, CVE-2017-6074 Feb. 28, 2017 SHA One Collision CloudFlare Leaking Memory and Kernel Patching Normally these Haiku’s are short and sweet, but it was a busy week for security in the headlines last week so I took a little more time to compile the following information for you: The CloudFlare Bug (A.k.a. “let’s not call it CloudBleed”) A security researcher working for Google’s Project Zero disclosed information on a bug identified in CloudFlare’s services. The bug was in CloudFlare’s services, and in some cases resulted in a trace amount of the contents of the CloudFlare’s servers memory being leaked. This could have had major repercussions as the contents of these servers may contain sensitive information being sent to or from the web server behind CloudFlare’s services (such as passwords, encryption keys, or other sensitive data.) Many news outlets reported this as a catastrophe, however CloudFlare patched it’s server’s before the announcement and there have been no reports of this being attacked in the wild before the report by the Project Zero researcher. Key points include that the data being leaked was not controllable by the attacker (it was always random, including no ability for an attacker to target a specific site’s data). The data was also limited to small chunks. The leaks however, have likely been happening for a while, no one knows how much data has been leaked to people looking for it or if any widespread attacks could have gleaned any usable data from the memory leaks. Ultimately, while it’s possible every password, SSL cert, and secret keys were pulled from CloudFlare server’s using this attack, it’s not likely to be the case. Most probably: the researchers at Google’s Project Zero were the first to be aware of the problem and reported it responsibly to CloudFlare. However, it is still yet to be seen if anyone reports malicious activity caused by these leaks in the weeks and months to come. How could this affect you? If you utilize CloudFlare on your site (or utilized a service that used CloudFlare) and wish to be absolutely sure your private data (such as a password) is safe then you may want to be pro-active and change that password or other secret data. The SHA-1 Collision: (A.k.a. “Shattered”) A collision in the SHA-1 algorithm was reported by a different team at Google. SHA-1 is a cryptographic hashing algorithm, commonly used to validate the integrity of data being sent. The collision released by the team at Google showed that they were able to send two different messages but they both validated with the same SHA-1 value; ultimately meaning that data signed or verified using a SHA-1 algorithm can no longer be trusted. There is some good news however, this attack is fairly expensive to execute (over $100k) and SHA-1 has been on it’s way out for the better part of a decade. SHA-256 has already been established as the replacement and most people have already migrated to the more secure algorithm. How could this affect you? If your site has SSL/HTTPS, then that certificate might be signed using SHA-1 , but it is probably already signed using SHA-256 (as of 2015) if you would like to double check you can always utilize a utility like ssllabs.com to look up your site’s SSL certificate and see what method is used to fingerprint it. If you find you are using SHA-1 only, then the fix is to get a new certificate (most likely whomever you purchased the certificate from will issue you a new one using SHA-256 without much hassle.) Secondarily, if you developed your site’s code explicitly using the sha1 function, then you may wish to swap that sha1 function with the sha256 function. CVE-2017-6074 While CVE-2017-6074 did not have a cool name or website or lots of media coverage; it was a more serious threat. This flaw could allow anyone with access to a Linux server to escalate their privileges from a normal user to root on the server. Linux servers running up to date kernels (such as ours) were affected and we were very concerned about getting this patched for our customers. Luckily we have been updating our infrastructure and these kernel based vulnerabilities no longer require reboots to apply new patches. We applied a patch to address this vulnerability on the same day it was made available and noted no issue with the new kernel code running. WordPress 4.7.2 Security Release Jan. 26, 2017 Sites updating now we handle the patch. So you focus on your site. Customer sites are being updated to address 3 security related issues. Further details on the release can be found here: wordpress.org CVE-2016-5195 “Dirty COW” Oct. 26, 2016 We have sent many email notifications about the reboot. Kernel patches have been applied on our servers, however a restart is required for it to take affect. Scheduled reboot notification emails have been sent out and reboots will take place the week of October 31st. More information on the vulnerability can be found here: dirtycow.ninja WordPress 4.6.1 Security Release Sept. 12, 2016 The update happened faster than I could write this haiku about it. All sites have been updated to address 2 security related issues. Further details on the release can be found here: wordpress.org httPoxy Jul. 20, 2016 A pox on proxy headers; that are misused by some developers. Updates to our server configs are being pushed out that remove any “Proxy:” values attempted to be set by a request header. More details here: httpoxy.org And see also: Pagely’s Reverse Proxy WordPress Hosting WordPress 4.5.3 Security Release Jun. 21, 2016 WordPress 4.5.3 Several security issues are addressed. We are currently testing and rolling out this security update. Further details on the release can be found here: wordpress.org WordPress 4.5.2 Security Release May 9, 2016 4 point 5 point 2; Patch vulnerabilities in cross site scripting Updates on our platform are finishing up today. Further details on the release can be found here: wordpress.org CVE-2016–3714 “ImageTragick” May 9, 2016 Image conversion tragedy; is currently patched by policy. Further details: ImageTragick.com CVE-2016-2107 CVE-2016-2108 May 3, 2016 High Severity Vuln? We patched openssl, so you don’t have to. Security Haiku: CVE-2015-7547 Feb. 19, 2016 Host lookup dangers? No worry, we already patched glibc Which plugins and themes aside from display-widgets should you avoid? See our full list here.
These monthly reports are provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core A WordPress Security release (5.4.1) was made available on Wednesday, Apr 29th. This release addresses the following 7 vulnerabilities: Unauthenticated viewing of some private posts Two XSS (Cross Site Scripting) vulnerabilities fixed in WordPress customizer XSS in wp-object-cache XSS in file upload process XSS in search block Password reset tokens not being invalidated Plugin/Theme Vulnerabilities of Note WordPress website owners who have the following plugins installed are strongly encouraged to remove them or find a replacement as soon as possible. These plugins were removed from the WP.org or CodeCanyon plugin repositories due to inaction of the developer to patch one or more security flaws: art-picture-gallery bsi-hotel-pro car catch-breadcrumb contact-form-7-datepicker poll-wp support-ticket-system-by-phoeniixx widget-settings-importexport wp-advanced-search wp-post-page-clone wp-gdpr-core The following plugins had high severity vulnerabilities addressed in April: Simple File List This plugin has a low install count of 4,000+ but has a high-risk arbitrary file upload vulnerability in versions lower than 4.2.3 which can lead to remote code execution. The vulnerability allows an unauthenticated user to upload an image file with PHP code in it, then make a second request to rename the image file’s extension .php, making it executable via the web. https://wpvulndb.com/vulnerabilities/10192 Media Library Assistant With over 60,000+ installs, the Media Library Assistant plugin had an authenticated remote code execution vulnerability that was fixed in version 2.82. https://wpvulndb.com/vulnerabilities/10182 LearnDash The LearnDASH premium plugin (sfwd-lms) is vulnerable to a remote unauthenticated SQL injection vulnerability. This could allow attackers to manipulate the database on the hosted website. It is strongly recommended site owners ensure their sfwd-lms plugin is updated to version 3.1.6 or higher, this must be done manually as it is a premium plugin and may require re-purchase to receive this patch. https://wpvulndb.com/vulnerabilities/10161 Tickera WordPress Event Ticketing Site owners using the Tickera WordPress Event Ticketing plugin should update immediately to version 3.4.6.9 or higher. There exists a public exploit that shows attackers how they can download a PDF which includes information on all registered attendees for an even. This poses a high risk for site owners who are concerned about protecting private data. https://wpvulndb.com/vulnerabilities/10174 LifterLMS LifterLMS versions before 3.37.15 did not properly check file type or paths when updating files on the webserver, which could lead to an attacker being able to write web executable files to the site. This is considered a high-risk vulnerability and recommended site owners update immediately. https://wpvulndb.com/vulnerabilities/10159 See previous months’ WordPress security updates from March and February.
These monthly reports are provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core No notable WordPress core security releases. Plugin/Theme Vulnerabilities of Note WordPress website owners who have the custom-searchable-data-entry-system or product-lister-walmart plugins installed are strongly encouraged to remove them or find a replacement as soon as possible. Both of these plugins were removed from the WP.org plugin repository due to inaction of the developer to patch one or more security flaws: Moving on, let’s discuss plugins that have patches for reported vulnerabilities in March: All-in-One WP Migration This very popular plugin with over 2 million active installations is, unfortunately, naming backup files based on a timestamp and a random number between 0 and 1000. Attackers may be able to make an educated guess as to what that the timestamp’s value is, then initiate attacks to download backups of websites. This flaw was fixed by making the backup file names less guessable in version 7.15. https://wpvulndb.com/vulnerabilities/10151 WooCommerce Smart Coupons This premium add-on for WooCommerce had a high-risk vulnerability that may cause direct financial loss for WooCommerce sites running the Smart Coupons add-on. Due to a lack of proper authorization checks in the gift card/coupon creation codebase, an attacker could make a request to generate a new gift card or coupon to the site without authenticating themselves first. Allowing them to create gift cards or coupons with arbitrary values, then use them to purchase items off the website. This would only affect sites with this plugin installed and the gift card or coupon functionality enabled. Since this is a premium plugin, auto-update functionality may not work as expected. Due to the high risk, it is strongly encouraged you manually double-check that this plugin has been updated to at least version 4.6.5. https://wpvulndb.com/vulnerabilities/10109 WP Security Audit Log This Security Audit Log plugin has over 100,000 active installations. If any of those installations has not completed the initial setup wizard, they are vulnerable to an attack that allows attackers to run the install wizard themselves without logging in to wp-admin. The WP Security Audit log team patched this vulnerability in version 4.0.2, site owners are encouraged to check if they have this plugin installed and verify the install wizard has been completed (or remove it entirely). https://wpvulndb.com/vulnerabilities/10118 LearnPress LMS Remote classrooms and learning websites running LearnPress LMS need to be aware of an insecurity that allows students (or any authenticated user) to change their role to the instructor role. It is recommended to update this plugin to 3.2.6.7 or higher before any students decide to recreate the cliche of a 90s hacker movie attack and gain instructor access to their classrooms. https://wpvulndb.com/vulnerabilities/10134 Gutenberg & Elementor Templates Importer for Responsive WordPress Theme The plugin named “responsive-add-ons” (Used for importing Gutenberg & Elementor Templates for the Responsive WordPress theme) lacked proper authentication steps on a number of it’s AJAX endpoints. This plugin before release 2.2.6 would allow unauthenticated requests to take many actions on the site, with numerous highly dangerous actions including importing xml/json files, activating plugins, inject javascript or reset the site’s data. https://wpvulndb.com/vulnerabilities/10137 See previous months’ WordPress security updates from February and January.
WordPress Core No notable WordPress core security releases. Plugin/Theme Vulnerabilities of Note Duplicator Plugin The Duplicator and Duplicator-Pro plugins both contained a vulnerability that allowed attackers to make a single request to a website, and be able to download arbitrary files from the WordPress website. It is being reported that attackers are actively using this vulnerability, attempting to download files like wp-config.php; which contains the database credentials and secret encryption salts/keys for a hosted WordPress application. Pagely customers who have not opted out received an update within 24 hours of the patch being available, and Pagely’s security team notified any customer with plugin updates turned off to update their installation immediately. It is valuable to note that our hosting infrastructure design does not allow direct connections to our database servers from remote IP addresses, nor do we store secrets like salts or passwords in the common wp-config.php file. https://wpvulndb.com/vulnerabilities/10078 WooCommerce Flexible Checkout The Flexible Checkout Fields free plugin addon for sites running WooCommerce were being actively targeted with a series of vulnerabilities that under specific circumstances allowed remote attackers to create their own administrator accounts on an affected site. The developers of the plugin quickly released a patch when they became aware of the problem, and the Pagely security team checked all sites for signs of infection, notifying customers if any action needed to take place. https://wpvulndb.com/vulnerabilities/10093 https://www.wpdesk.net/blog/flexible-checkout-fields-vulnerability/ Pricing Table (Supsystic) The pricing table plugin versions before 1.8.2 included an AJAX endpoint which performed privileged actions (such as updating database contents) without proper authentication that the request was being made by a valid user on the site. This vulnerability would allow anyone to modify database contents on the site and posed a high risk as the changes they make in the database could lead to running javascript from within the wp-admin panel. The risk is similar to the Flexible Checkout Fields with the key difference being this was found and reported by security researchers first and was not actively being exploited before the patch was made available before an attack was weaponized. https://wpvulndb.com/vulnerabilities/10090 ThemeREX Addons Lack of authentication in a REST API endpoint that ThemeREX Addons creates can expose a site to a remote code execution vulnerability. Allowing unauthenticated attackers to execute arbitrary code on sites running an insecure version of this plugin. No patch has been made available by the developers and people are reporting this is being actively attacked in the meantime. Pagely’s security team is recommending the removal of the plugin if you have it installed. https://wpvulndb.com/vulnerabilities/10076
WordPress Security and Maintenance Releases: 5.2.4, 5.3.1, and 5.3.2 Pagely customers were spared issues from bugs introduced in the 5.3.0 release as, due to the proximity to the holidays, we didn’t upgrade our customers to 5.3 until early January. All Pagely customers received security patches for vulnerabilities identified in WordPress Core before 5.2.4 for the 5.2 branch and 5.3.1 for the 5.3 branch. 4 vulnerabilities found in WordPress Core: Privilege Escalation (allowing any user to “sticky” a post) XSS (Cross Site Scripting) Stored in well-crafted links XSS in the Block Editor Improved Security/Sanitization on wp_kses_bad_protocol() Plugin/Theme Vulnerabilities of Note InfiniteWP and WP-Time-Capsule Two separate authentication bypass vulnerabilities were found in InfiniteWP and WP-Time-Capsule, both vulnerabilities were reported by WebARX: These vulnerabilities pose a critically high risk to any site owners running insecure versions of either plugin. The vulnerability allows malicious parties the ability to bypass authentication and get a valid administrator login session via making a single request to a site running either plugin. Links for more information: https://wpvulndb.com/vulnerabilities/10010 https://wpvulndb.com/vulnerabilities/10011 https://www.webarxsecurity.com/vulnerability-infinitewp-client-wp-time-capsule/ Elegant Themes Elegant Themes self-detected and corrected insecure code in their popular plugin Divi-Builder, and themes Divi and Extra. The vulnerabilities Elegant Themes addressed would have allowed an authenticated user to potentially execute short bits of arbitrary PHP code on a website. While the ability to execute code makes this a high-risk threat, the requirement that the attack has valid credentials absolutely reduces that threat significantly to a medium or less risk. **A hat tip and props are due for Elegant Theme’s developers for identifying, patching, and their transparency surrounding this report. More information: https://wpvulndb.com/vulnerabilities/10000
Over recent years Pagely’s security team noticed a trend in WordPress related attacks targeting unauthenticated changes to a WordPress website’s options table. The attack is specific to WordPress, but in its boiled down essence, this vulnerability would fall under Broken Access Controls/Elevation of Privilege (OWASP Top 10, 2017 A5). In laypersons terms: the application lacks proper authorization checks before performing a sensitive action. Over the course of the year, reports of unauthenticated site option update vulnerabilities experienced a snowball effect. Initially, only a few reported vulnerabilities related to a WordPress site’s option table values being able to be updated without authentication went public. Some months later, more reports began to appear as more people started looking for and identifying this vulnerability. All the while attackers were targeting and infecting live sites. By summer, a cyber-arms-race was in full swing, the race was between malicious parties exploiting sites vs. defenders and researchers working to identify, patch, and protect websites. You can see this trend as well as example vulnerabilities and their disclosure dates on WPVulnDB here. What is an Unauthenticated Site Options Update vulnerability in WordPress exactly and how was it being targeted? This vulnerability, as per its name occurs when a website’s wp_options value is allowed to be changed or updated by someone who is not logged in. Of course, it is not literally a form or button that is letting people change the site’s wp_option values, but it might as well have been (I will get into this later in the section for plugin developers.) What is the risk associated with updating values in wp_options without authentication? I would say this is a high severity risk. It only takes a single request against a vulnerable site for an attacker to be successful, no authentication is needed and the result is devastating to the site. The wp_options table contains two critical values, home, and siteurl, which are used by WordPress core to ensure the visitor is visiting the right URL. This is done via an HTTP redirect which happens very early in the page load if WordPress detects your browser is not pointed to the right URL. Any site owner who has changed their WordPress website’s domain name at some point likely had to update the values of these two options before their site could complete the migration to a new domain name. Malicious parties have focused their attacks to alter the value of the home and siteurl options and are changing the value to their own domain names. This results in a destructive action, redirecting all of the infected site’s traffic to the attacker’s domain. This results in the infected site potentially getting blacklisted from search engines, exposing the site’s visitors to malware, not to mention the site will effectively get no visitors while infected. What can you do if your site is affected and is redirecting to another domain? For Pagely customers, we have been actively scanning for these attacks and notified any affected customer as well as performed a security clean up which fixes the affected site. This is all part of our security practices included in all services, PressArmor. If you don’t host with Pagely, and your site has been hit by one of these attackers, here is what you can do: You will need to change the siteurl and home option values back to their correct (original) setting. This needs to be done via phpMyAdmin, wp-cli, or a direct connection to the database server. The easiest way to fix a site is via wp-cli: Here are the two commands to run: wp option update siteurl ‘http://yourwebsitehere’ wp option update home ‘http://yourwebsitehere’ That will update your website’s siteurl and home option values to their correct setting (of course, please use your actual domain name and not yourwebsitehere) If you are not comfortable or do not have database or wp-cli access, but you can also address these hacks by editing your site’s wp-config.php file (via sFTP or such), which will work in a pinch. Here are the steps to follow. First edit your site’s wp-config.php file and define the following two WordPress constants ‘WP_HOME’ and ‘WP_SITEURL’ like so: define( 'WP_HOME', 'http://yourwebsitehere' ); define( 'WP_SITEURL', 'http://yourwebsitehere' ); This hard codes these values into the site and you will not be able to easily change them in the future via the dashboard, so it is not a configuration you want to leave active even though your site will begin functioning normally again. Now, you can log in to your wp-admin dashboard and correct the modified values in your General Settings page. (You may need to clear browser and server caches.) Now, remove those define(‘WP_HOME’ … and define(‘WP_SITEURL… lines from your site’s wp-config.php file and test that your site is working as expected. Finally, you must remember to update the plugin with the vulnerability in it which exposed your site to this hack, if you miss this step you will likely get hacked again shortly and have to perform all of the above tasks all over again. What can a plugin developer do to address this? What went wrong? Knowing how this exploit works is key in knowing how to code defensively and prevent your plugins from being vulnerable. Looking over the vulnerable plugins that were affected, the core issue was they used a high-risk function (update_option()) and forgot to include a step to verify the person making the request is authenticated and authorized to perform such an action like updating the site’s option values. The exploits all follow this same trend: The developer wants to update a site’s options, and to make it function smoothly on the site they make it an AJAX call via add_action() (in simpler terms, they designed the site to call the function that updates the site’s options via javascript, instead of via a form that would require full page loads). Within their site option updating function, they read data from the browser via GET/POST values to update the appropriate option setting. The developer incorrectly believes there is nothing wrong with this idea, the code controls the GET/POST variables being sent to the AJAX endpoint and only they are making calls to the AJAX endpoint at properly authenticated places within their code. They assume they have written secure code by putting in some role validation before calling the AJAX request, they may even perform sanitization of the GET/POST values before the AJAX request is called… but they missed the critical flaw: An AJAX endpoint created with add_action, is accessible from anyone on the internet to make a direct request to. To develop a secure AJAX endpoint, you must perform all security checks (sanitization, authentication, etc..) within the function add_action calls itself. How can it be fixed? When you create a new AJAX endpoint and point it to a function, you must remember that it exposes that function directly to the internet. If you take any sensitive actions within that function, then you must have appropriate checks within the function to ensure the user making the request has sufficient privileges to perform the sensitive action. This is especially important for add_actions starting with wp_ajax_nopriv. The AJAX endpoints naming allows you to limit the endpoint to anyone on the web (intended for frontend AJAX requests) or only logged-in users of the site (intended for backend requests). Simply naming the endpoint ‘wp_ajax_[function_name]’ limits it to logged-in users, but you must be extra cautious with endpoints that are named ‘wp_ajax_nopriv_[function_name]’ as they will be available to everyone (no logged-in user required.) Most plugins vulnerable to this attack placed a call to update_option() within an AJAX endpoint named wp_ajax_nopriv. I would recommend developers always perform authorization verification before taking any sensitive actions, but it’s especially true to exist within functions connected to AJAX endpoints. It is true that backend AJAX request (without nopriv) are only available to logged-in users, however this means they are accessible for admin users, as well as authors and subscribers, so you still need to check the user’s role and capabilities before taking any sensitive actions. The function you should be using to check if a user can take an action is current_user_can() This function’s purpose is to check if the user’s role and capabilities allow for them to take any action, and there is a long list of capabilities you can check against. For the sake of this article’s topic, before you call update_option() you can check if the currently logged in user can manage site options via: current_user_can(‘manage_options’); I have a quick gotcha! I need to address here too. In one of the affected plugins, the developer attempted to put in an authorization check but misunderstood the intention of the function is_admin(). Within their AJAX endpoint function, before any code is executed, the developer put a conditional that is_admin() must return true (otherwise exit immediately). The problem is, they were assuming this function returns true if the logged-in user is an admin user, and that would be wrong. is_admin() checks if the request URL appears to be from the wp-admin dashboard (e.g.. does it contain /wp-admin/?) which will return true for all WordPress AJAX requests, because, all AJAX requests are sent to /wp-admin/admin-ajax.php, the URL for AJAX endpoints always has the path to the wp-admin dashboard, is_admin() always returns true for AJAX requests. I hope the information above is helpful for anyone running a site affected by this WordPress specific vulnerability, as well as for plugin developers who may want to double-check how they are doing proper authorization within their AJAX calls or before they call sensitive functions like update_option().
The relationship between WordPress developers and security researchers has been strained for some time now. Recently it is so bad that vulnerability reporters are going rogue which is affecting site owners. In the past months we’ve seen multiple researchers drop 0-day information (vulnerability details with no current patch available) which has resulted in our security staff being in emergency mode to ensure plugins are getting updated quickly, before sites get hacked. In some rare occasions where sites get hacked before we can patch, we’re putting in even more time handling incident response and cleanup for every affected site. This is not a healthy scenario for anyone involved. Developers are being rushed to produce patches, sites are getting hacked due to no fault of the site owners, security teams are putting in more time than normal towards remediation of hacks, and researchers are getting [bad] press over their actions. Here are two articles from this week that in one shows a security researcher with great patience facing months of non-communication from the developers they reported a vulnerability to, and a second where it’s shown a different security researcher has stopped being nice and is now choosing to go full disclosure before attempting to contact plugin authors about vulnerabilities: RCESecurity “About a Sucuri RCE … and How Not to Handle Bug Bounty Reports” June 20, 2019 ZDNet “Disgruntled security firm discloses zero-days in Facebook’s WordPress plugins” June 17, 2019 This scenario the WordPress and Security communities have got themselves in is a net loss for everyone involved (except the hackers), and it’s really quite saddening. Pagely’s Security Team has a strong background of doing the right thing in these cases, be it with reporting of vulnerabilities (including those in WordPress core and plugins) as well as received and triage vulnerability reports on behalf of others. We know that the process of reporting vulnerabilities can be a net-positive and does not have to go down the road that leads to sites being compromised. Here we have four recommendations for Developers, plus an offer for Security Researchers and Developers alike. These are our four recommendations: 1. Have a point of contact. It would be surprising that one of the biggest hurdles for the security researchers may be simply finding out who to contact. The WP.org plugin repository understandably (for anti-spam and privacy reasons) does not include your email address or a contact form on plugin pages. Nor is it acceptable to publish details of a security finding in the plugin forums (this is the same as releasing the vulnerability since it’s a public discussion forum). So take a minute to think. How do you want to receive security reports? Maybe include a security point of contact in the plugin’s readme/source files, or if you have a development website that you’re linking to from the plugin description page on WP.org, be sure to have either a generic contact form or specific page detailing instructions on how people can report security issues found in your code. If you’re a development shop that has some funding, you also may wish to consider signing up for a bug bounty program like hackerone or bugcrowd, and use that as your point of contact. What happens if a security researcher can’t find out how to contact a plugin author? Well, then they will reach out to the WP.org plugin team to act as liaisons to receive, triage, and report the issue to you, the developer. Pro-tip: If the plugin team confirms a vulnerability, they will likely remove your plugin from the WP.org repo until you have a patch available. 2. Be appreciative. Reading a report of a security flaw in your code base can bring up some negative emotions, especially if you’ve got your ego tied up in your code. Try to let any negative emotions slide away if they bubble up. It helps to take a second before you start reading the report to imagine the reporting party as someone who already contributed multiple hours of their own time towards your project, free of charge. Treat them as you would someone who had a great idea or pull request that improved your code, not as a threat. This is the step I see things break down the most. A developer gets, what they perceive as, a nasty email from a researcher. They take personal insult because they believe they’re being told their code is bad. Their reaction to this is to send an email maybe downplaying or demeaning the report which starts a negative downward spiral from where there is no positive outcome. As a developer, imagine spending hours contributing to a project free of charge and when you unveil your improvements, the project lead acts dismissive or negatively towards your contribution. Would you feel comfortable contributing your time towards that project ever again? Probably not. Is it possible you may even have feelings of wanting to get even? Possibly. Now imagine that contribution was a security finding? That security researcher has their means of getting even right there in the report they sent to the project in good faith. By making that same security report public, makes it an 0-day, sites get hacked, the project’s reputation is tarnished, and the developer still has to write and push a patch. 3. Communicate. Don’t leave the reporter out of the loop while you work on a patch or review their report. Share your progress and timeline if you have one, even if it’s a long way off. Ask questions if you have any (some of these vulnerabilities are confusing the first time you read about them, it took me some time to really understand object injection and its risk). If you inform the reporter you’re squeezed for time, or you’re having trouble understanding the issue, or maybe even just ask them their opinion of the proposed patch, sometimes they may offer to help. Keep in mind the person reporting the vulnerability may have an internal timeline they assumed is sufficient (maybe 30, 90 or 180 days , but it’s always an arbitrary timeline until both parties communicate their expectations) and if the researcher doesn’t hear anything from the developer in that time frame, they may just report the vulnerability publicly so they can close the case and move on to finding more vulnerabilities. It doesn’t hurt to keep up communications, ask questions or share timelines and/or knowledge. 4. Transparency. This last bit is for the users of your code. Be sure when you have a security release ready, you include a note in the changelog that the release contains a security related patch. Your users need to know that the version released addresses a security issue, so they know to update ASAP. Hiding or neglecting to include security notes from your code’s changelog, doesn’t mean the security issue never existed. Neglecting to include a note that a version of the software includes a security patch is simply a disservice to a project’s users. If users don’t see there is a security patch in that release, then some will not bother to update their sites. Sites not getting security patches results in sites being compromised. The worst part is, during the incident response phase to clean up the mess the hack causes, it will be pointed out your plugin insecurity as the fault of the hack. When Pagely customer’s experience a compromise we perform a detailed incident response which, is more than just a cleanup because, 99% of the time we will include details on what the initial attack vector was. It’s very common that if the cause of the hack was a plugin whose developer ignored or played down a security issue, the site owner chooses to remove the plugin from the site entirely. Understandably so, as the site owner feels betrayed and loses trust that the project’s developers will be honest with them about security concerns. That’s the basics. I hope developers reading this take to heart some of the considerations. I believe nothing recommended above would harm a project’s reputation and, in fact, I would argue they improve the project’s reputation as being ran by mature developers who have earned their user’s trust. For the few security researchers who may be reading this, especially if you agree with the importance of the above four points, here is our offer: I know some of you have faced some difficulties when reporting vulnerabilities to the WordPress development community in the past. We would like to offer an olive branch in the form of assistance. If you have had a bad experience reporting vulnerabilities to the WordPress development community (core, themes, plugins, whatever), and would like us to help, please reach out (contact us via the Pagely support contact form, and someone will route notification to our security team). We will be glad to help you find the point of contact for a plugin (we have connections in the community) and even act as mediators, reviewing/confirming your report and reaching out to the plugin author on your behalf! This would be a win-win. You can spend more time finding vulnerabilities and less time writing emails, while we help the affected project be more secure. This offer has already been put into play, we helped Slavco Mihajloski just last week with reporting a vulnerability he found in NextGen Gallery. We would look forward to helping anyone else (both developers and researchers alike) who want to work towards a solution where vulnerabilities are patched, credit is properly attributed, and sites don’t get hacked. We hope that this dilemma can be addressed, hopefully our offer to help act as mediators will get both security researchers and WordPress developers away from the road that leads to 0-days being released and sites being hacked, and onto a road of collaboration and mutual understanding (and where hackers have to do their own damned work to find vulnerabilities in the WordPress ecosystem).
We spend every April 1st playing jokes on each other that rely on comical hoaxes and abuse our trust, but make us giggle during this annual tradition. We know these fantastical stories are most likely false and intended to entertain. Stories like T Mobile’s Phone BoothE, Nissin’s Cup o Noodles headphones, or Auntie Anne’s Hot Yoga Classes, all strike a nice chord of absurdist humor and harmless prank. There was another story in headlines about abusing trust which appears was not a hoax and far from harmless. In the days prior to April Fools day this year it was reported by multiple parties that the p3 plugin (a premium plugin by pipdig) included multiple sections of code which for all purposes appeared to be high risk or intentionally malicious. The details of the reportedly malicious code found in the plugin have been covered by two reporting parties here and here. The TL;DR for what the plugin was doing based on the above reports was: 1) The plugin allowed whoever controls “pipdigz.co.uk” to change your WordPress user account passwords to the string “p3_safe_styles”, as long as they knew the email address associated with the account. 2) The function name for the code that changed passwords was hidden in a function named “p3_check_social_links()”, even though the only thing the “p3_check_social_links()” function did was call “wp_set_password()”. Which appears to be an attempt to obfuscate the intention of their code. 3) The code would delete all database tables associated with the site IF your website’s domain name was found on a page hosted on “pipdigz.co.uk”. 4) The sites utilizing the plugin could be used as part of a Distributed Denial of Service network, targeting URL(s) found on a page hosted on “pipdigz.co.uk”. The author of the p3 plugin, pipdig, has issued a rebuttal citing that the code had a valid purpose and was not being used how the reporting parties have claimed. It isn’t certain they ever abused this level of access, but the code cannot lie and we confirmed the code was allowing whoever controlled pipdigz.co.uk to take the above actions and we believe that is a higher level of trust than was implied when people installed this plugin. Pagely staff have already reached out to our customers running the p3 plugin and confirmed the reportedly malicious code did, in fact, exist on their sites. Pagely’s security team discussed with our customers running the P3 plugin what risks this plugin added to their site, and we confirmed the reported malicious code worked as explained in the above reports by independently verifying the code existed and could be used in this manner. With the independent confirmation that these high-security risk bits of code existed in the plugin and our staff’s help clarifying points, our customers agreed they did not wish to continue running this plugin on their sites. Trust is a commitment and must be earned. Due to the high-risk code that was introduced in the p3 plugin, Pagely’s staff has decided to add this plugin to the Pagely banned plugin list. Plugins on the banned plugin list are not allowed on our network and are auto-disabled if detected. Most of the banned plugins on this list are there due to conflicts with existing services (cache or backups), and many are there due to risk to the site if they are installed. The P3 plugins by pipdig is not the first plugin the Pagely team has banned for high-risk code, but it’s the first we believe was related to distrust by the author who is still actively developing for the plugin. We hope it will be the first to be unbanned once the author is able to redeem themselves. We would hope that in the future the author of the p3 plugin show everyone they can be trusted to provide code safe to run on websites. We are aware pipdig has already removed much of the reported malicious code in their most recent release. Removing the high-risk code is a great first step, on the road to regaining their trust. I look forward to watching pipdig continue their momentum to show that they are committed to their users and are worthy to be trusted to install code on your sites. In the meantime, our duty is to protect our customers and our servers and this plugin will remain banned until trust has been restored. This whole debacle is a reminder of how much trust site owners put into the developers of plugin and designers of themes you have installed on your WordPress site. Many themes and plugins are freely available from WP.org, but they still require your attention and care, plugins have been abused in the past and we have reported about such abuses like when an author hands off their plugin to a malicious developer (without knowing that the new developer had nefarious intentions). The incident with P3 Plugin is another problem along the same lines, the loss of trust with the plugin developer. If you’re a site owner and your site’s plugins have always been safe and secure, maybe it’s time to send out some thank you emails, for all the developers who have given you not only a useful tool on your site but also not abused your trust. It’s always best knowing you’ve put your trust in the right hands, and it makes April fools day a lot more enjoyable. Did you see Elon Musk released an auto-tuned rap single RIP Harambe? That wasn’t an April fools joke … sometimes hoaxes are best left as hoaxes, we trusted you Elon!