Security Advisory: Object Injection Vulnerability in WooCommerce

Security Risk: Dangerous

Exploitation Level: Easy/Remote

DREAD Score: 8/10

Vulnerability: Object Injection

Patched Version: 2.3.11

During a routine audit for our WAF, we discovered a dangerous Object Injection vulnerability in WooCommerce which could, in certain contexts, be used by an attacker to download any file on the vulnerable server.

Are You At Risk?

The vulnerability is only present when WooCommerce’s “PayPal Identity Token” option is set. If it is, your site is vulnerable to an Object Injection type of vulnerability, which essentially means that depending on the context the site is running in, it may be used to do a variety of things. We managed to use a combination of WordPress and WooCommerce components with a known PHP bug (CVE-2013-1643) to download critical files, files like wp-config.php; for those unfamiliar, this file contains the database credentials and WordPress secret keys. As seen in the past, giving an attacker access to these files usually results in full site compromise.

It is worth noting that even if your site doesn’t run on top of an old version of PHP a lot of different attack vectors an attacker could be used depending on what extensions you have available. There’s also a couple other bugs related to PHP itself that we could have investigated, but we decided to stick with CVE-2013-1643 because it’s widely documented and relatively simple to recreate.

Technical Details

Everything begins in the get_paypal_order method of the WC_Gateway_Paypal_Response class.

The get_paypal_order method
The get_paypal_order method

 

The $custom function parameter is directly passed to WordPress function maybe_unserialize(), which can be used in Object Injection attacks when ran with direct user input.

The check_response method
The check_response method

 

As you can see from the above snippet, the get_paypal_order method is used with a variables tainted by $_REQUEST[‘cm’] – anyone accessing the page where this code gets executed (when someone visits the plugin’s order-received page with some very specific parameters set) can use this vector to spawn arbitrary class instances and potentially modify the application’s execution flow (depending on what classes are available in the current context).

Because this type of vulnerability requires very specific conditions to be exploited, we decided to give it a try and create a Proof of Concept to demonstrate how a malicious individual could use this vulnerability, along with CVE-2013-1643, to leak WordPress configuration file wp-config.php.

Leaking files

Some of you might already have noticed, the CVE mentioned earlier refers to some SOAP/XML issues, nothing related to unserialize() or Object Injection as a whole. The trick lays in the fact that this particular bug affects a few PHP mechanisms, including the SoapClient class. What makes this particular class interesting is the fact it contains a __call magic method that makes it possible to submit a SOAP request to any server and parse the resulting XML making it possible to conduct XXE attacks and download files from the server.

In order to trigger the __call method, we needed to find a place in the code where we could force our unserialized object to call a method that doesn’t exist in the original class definition, thus forcing the magic method to trigger. We found what we were searching for in WordPress PHPMailer class, specifically in the smtpClose() method.

PHPMailer’s smtpClose method
PHPMailer’s smtpClose method

 

In this scenario, we would unserialize a PHPMailer class whose smtp variable would contain a carefully crafted SoapClient instance to trigger the XXE part of the exploit. That’s good in theory, but we needed to find a way to call this method.

PHPMailer’s __destruct method
PHPMailer’s __destruct method

.. we got lucky!

The PHPMailer class also contained a destructor that calls the smtpClose() method! This means that all we’d need to do to get the __call magic method to execute is to initiate a PHPMailer class that has the Mailer variable set to “smtp”; PHP would call the necessary methods when the current script’s execution ends.

Last but not least, we’d need  the PHPMailer class to be present in the application context when our serialized payload hits the maybe_unserialize() call, which isn’t the case by default. Generally speaking, this class is included when WordPress uses the wp_mail() function, so we had to find a place where we could force WooCommerce to send an email before our serialized payload gets unserialized.

Hooking the process_lost_password function
Hooking the process_lost_password function

 

The process_lost_password functio
The process_lost_password functio

WooCommerce allows users to reset their account’s lost password, a process that requires sending an email, exactly what the hackers want! Plus, this function is hooked very early in the WordPress boot sequence, which is perfect because it makes the PHPMailer class available for unserialization.

Update as Soon as Possible

If you’re using a vulnerable version of this plugin, update as soon as possible! In the event where you can not do this, we strongly recommend leveraging our Website Firewall or equivalent technology to get it patched virtually.

24 comments
    1. We could trace back the vulnerable snippet of code to version 2.0.20, so anything between this and the latest version should be considered as risky.

  1. As much as I appreciate your ongoing enthusiasm in making WordPress a more secure place I really think the time to disclosure is far to short. We already had this discussion last year after the MailPoet security issue and I will not start it again. However disclosing a severe security issue the same day a patch is released is to early. Even those systems to perform automatic updates for a couple of sites need a few hours (usually 1 day synchronization cycle) until updates are applied. You do a great job. No doubt. But sometimes less is more – so just wait at least 1 day with the disclosure.

    1. Even disclosing stuff within a week… People don’t always update within a few days.

      All those “security” folks making things less secure (in a sense) by letting the world know about these kinds of things is just against logic. If fewer people know about it, the risk is also lower. So disclosing security issues is just irresponsible.

      1. That is laughably incorrect. Once a fix is released, hackers can identify the issue and how to exploit it by looking at what has changed. Writing a blog post just lets the wider user base know that there is a serious security vulnerability that needs to be updated immediately.

        1. @TimothyBJacobs:disqus : There is a saying. You can make the deaf listen. But you can’t make them Listen who are ignorant.
          this goes to guys who cry about Ndays. @mensmaximus:disqus@Arnan:disqus:- smart players do download the old and new codes and write exploit. Sucuri exploits are scanned by noobs who even dnt know what to do with it.(After access). And those who know they dnt need to read the blog. Sucuri writes about their work.

    2. Hi Michael,

      Thanks for your feedback. However, you are missing an important point on your argument:

      -The hackers (bad guys) already know.

      They do not need our disclosure to know that there is an issue. They constantly monitor changelogs and releases for security issues.

      What we are doing is helping the community as a whole to be aware and take the proper action to protect themselves. If we do not disclose and urge users to patch, they will be a step behind the bad guys that will try to exploit it.

      thanks!

      1. Daniel if you just want to make people aware about a security issue just tell them they should update. Users do not need to know every dirty detail in the first place to understand how important an update is.

        And maybe you underestimate your work at Sucuri. Each time you disclose a severe bug it takes about 12 hours until my perimeter firewalls and honeypots get a high workload. You definitely feed bad guys with information en mass. And there is a big difference between one or two professional hackers or a myriad of average hacks and script kiddies.

        As I already said you do a great job but you should wait with disclosing the details.

        1. Some users DO want to know, and need to know. Users who are in the hosting business for example. So many of our customers run wordpress, I sure as heck need to know if I need to launch a search across 1000+ servers, each with sometimes hundreds of websites, to see if anyone is vulnerable.

          These blogposts are vital to my work keeping our network and customers somewhat safer.

        2. Hi @mensmaximus:disqus

          Thanks for sharing your concerns and insights. I echo Daniel’s sentiments; there are obviously various sides to this debate, and it’s not one we plan to have at the moment. We’ll take your concerns into consideration when we discuss our approach to vulnerability disclosures in the future.

          Thanks so much for stopping by,

          Tony

        3. Hey Michael. You do have a point. Especially for new users like me. Seeing a notice of this type may cause panic, when in fact, it’s just a word of pre-caution. I was a bit shocked when i saw the post and was wondering, where do i go wrong? What’s going to happen now?

          I am assuming that a post of this nature is basically telling hackers what we are doing to prevent them, therefore, they will find ways to do what they want to get done.
          Tell me if i am mis-understanding the conversation.

        4. Yes, I know this is a year old post. I don’t care. I am going to make a prediction, and I wonder how accurate it is. My prediction is this: “You, mensmaximus, are likely a flaming Liberal Democrat.” Well, am I correct? Are you, in fact, a Democrat? I am very interested to know if I am correct in my assumption or not. Please, do tell.

      2. I am not alone in appreciating the early disclosures. I’m already subscribed to bugtraq mailing list (as anyone concerned about network security should be) but dear lord, there are so many every day. Without people like Daniel putting the CVEs in context it would just be lost under a pile of more CVE releases. So carry on, Daniel and team. The web needs people like you and your team!

  2. So I know it’s in your best interest to sell your Website Firewall, but you guys really should release ModSecurity rules with disclosures like this if possible. I feel like it would make the internet safer as a whole. Hell, I could probably convince some people to pay for rules if you guys made them.

    1. No, that’s the patched version — meaning the vulnerability was patched in that version. 2.3.10 is the last vulnerable version for this exploit.

  3. hello

    Apply for a quick and convenient loan to pay off bills and to start a new financing your projects at a cheapest interest rate of 3%. Do contact us today via: elijahloanfirm@outlook.com with loan amount needed as our minimum loan offer is 1,000.00 to any choice of loan amount.I am certified ,registered and legit lender.You can contact me today if you are interested in getting this loan, contact me for more information about the loan process, process like the loan terms and conditions and how the loan will be transferred to you. I.. need your urgent response if you are interested.

    Thank you

  4. After wasting 2500 USD to fake hackers am at the very point of giving up on upgrading my school grade before one my mate told me about Hacking Genius. They hacked into my school websites, they upgraded my score for me,and i graduated with a very excellent grade. so am advising you to stop wasting your money to scammers and contact hackingenius8@gmail.com for a satisfactory work.

Comments are closed.

You May Also Like