On 15th July 2021, news was going around regarding an unauthenticated SQL Injection in WooCommerce. WooCommerce released a blog post about the vulnerabilities here: https://woocommerce.com/posts/critical-vulnerability-detected-july-2021/#. The vulnerabilities were detected on the 13th of July and fixed in WooCommerce versions 3.3.6 to 5.5.1 and WooCommerce Blocks versions 2.5.16 to 5.5.1. This blog post is a short analysis of the vulnerabilities, the patch, and then a PoC for the bugs!
Patch analysis
In the WooCommerce security blog post linked above, we can see the vulnerabilities are in WooCommerce and the WooCoomerce Blocks feature plugin. We can see two fixes here: https://plugins.trac.wordpress.org/changeset?old_path=/woocommerce&old=2564657&new_path=/woocommerce&new=2564657&sfp_email=&sfph_mail=#file22 in both ‘class-wc-webhook-data-store.php’ in WooCommerce and ‘ProductFiltering.php’ in WooCommerce Blocks.
Both of these fixes are very interesting. To track this a bit more, I fetched the source for the vulnerable versions and setup a WordPress site for it (this will also of course be useful for the PoC). I know from the source, the vulnerable part is via the API so we can visit ‘woocommerce\packages\woocommerce-blocks\src\StoreApi\RoutesController.php’ to get a nice list of the API routes.
Using this, we can see the route ‘product-collection-data’ which we can navigate to at ‘woocommerce\packages\woocommerce-blocks\src\StoreApi\Routes\ProductCollectionData.php’ which looks promising!
Our path now is /wp-json/wc/store/products/collection-data. From this file, we can craft a full URL quite easily as this details how to use that specific route. Going back to the original patch, following ‘wc_sanitize_taxonomy_name’ leads us to the function as follows:
This is really interesting, and after googling the use of sanitize_title, we get:
By default, converts accent characters to ASCII characters and further limits the output to alphanumeric characters, underscore (_) and dash (-) through the ‘sanitize_title’ filter.
And this code is also using urldecode, so if we URL encode a payload 3 times to get around this, we should have a fully functioning PoC combined with the URL created earlier.
Exploiting the bugs
With the information we have discovered, we can now go ahead and try to exploit these vulnerabilities! From all of the data we’ve acquired, our final URL would be as below. The payload contains a simple sleep SQL-command:
Executing this PoC on a vulnerable version of WooCommerce does indeed work!
Guest blog post by Kane Gamble.
The blog post on WC’s site states that it is patched in 5.5.1, yet this post says it is vulnerable. Which is the correct information?
This post says:
“The vulnerabilities were detected on the 13th of July AND FIXED IN WooCommerce versions 3.3.6 to 5.5.1 and WooCommerce Blocks versions 2.5.16 to 5.5.1”
Doesn’t list that version number any where else in the article.
Can’t see where it says that it is vulnerable in these versions. Maybe WPSec updated the blog since you asked the question.