Security Advisory – WP-Slimstat 3.9.5 and Lower

  • February 24, 2015

Security Risk: Very High

Exploitation Level: Remote

DREAD Score: 8/10

Vulnerability: Weak cryptographic keys leading to SQL injections

Patched Version: 3.9.6

WP-Slimstat users should update as soon as possible! During a routine audit for our WAF, we discovered a security bug that an attacker could, by breaking the plugin’s weak “secret” key, use to perform a SQL Injection attack against the target website.

What Are the Risks

This bug can be used by any visitor browsing the vulnerable website. If your website uses a vulnerable version of the plugin, you’re at risk. Successful exploitation of this bug could lead to blind SQL injection attacks, which means an attacker could grab sensitive information from your database, including username, (hashed) passwords and, in certain configurations, WordPress secret keys (which could result in a total site takeover).

Technical Details

WP-Slimstat used a “secret” key to sign data sent to/from the client. By looking at how it was generated, we found it would be possible for an attacker to guess its original value:

The weak 'secret' token

The “secret” was a hashed version of the plugin’s installation timestamp. An attacker could use sites like Internet Archive to approximately guess what year the site was put online (which would leave us with approximately 30 million values to test, something doable within 10 minutes with most modern CPUs).

The only missing piece in order to brute force the site’s timestamp is the valid, signed, information coming from the plugin to compare our generated signatures with. It’s used in multiple places within the host site, including its home page, making the process much easier to find:

Example of a signed payload

It might look a little complicated at first, but looking at how this data structure is used throughout the plugin revealed a straightforward way of signing data, hashing a concatenated string containing our payload and the “secret” token:

How data is signed/validated

Using this information, one could brute force timestamps until they get the same signature noted from the site’s home page. The leads to the second part of the issue; using this bug to perform a SQL injection attack.

While investigating what processes we could play with using our new attack vector, we discovered we could insert arbitrary data into an unserialize() call (which could have led to an object injection vulnerability, depending on what other plugins are installed on the target site), which would later be passed to the maybe_insert_row() method using the $content_info variable:

Calling the maybe_insert_row() method

A quick look at this method’s way of handling associative arrays led us to a possible blind SQL injection attack vector:

The SQLi Attack Vector

Given that we control $_data, we can make it contain an associative array whose indexes are SQL statements (ie. array(“1=sleep(100)–“=>”1”) ). This capacity to execute arbitrary queries would allow an attacker to get anything they want from the database.

Update As Soon As Possible

This is a dangerous vulnerability, you should update all of your websites using this plugin as soon as possible. If for any reason you cannot, we highly recommend you to have a look at our Website Firewall (WAF) product. It’s designed to help you stay ahead of vulnerabilities like the one described here, and many more.

Marc-Alexandre Montpas is Sucuri’s Senior Security Analyst who joined the company in 2014. Marc’s main responsibilities include reversing security patches and scavenging vulnerabilities, old and new. His professional experience covers eight years of finding bugs in open-source software. When Marc isn’t breaking things, you might find him participating in a hacking CTF competition. Connect with him on Twitter.

Related Tags
14 comments

  3. To MD5 hash 10 million strings might take 10 minutes on a fast pc, but you also need to test them on the to be attacked server, which will take much longer (depended on the internet connection of the attacker, the target and the target server cpu). Or am I missing something?

    2. Even if it did take much longer than 10 minutes, the compromised version of the plugin was updated 5 days ago and since then only around 10,000 sites have updated acording to the stats on the plugin’s WP page. So that’s 5 days a test could be running for, and countless months more whilst sites eventually update (or not at all).

  4. The installation of plugin is not combined with the installation of wordpress. If you find when blog has been opened you don’t have the correct information to when the plugin has been installed. You have to check the source code of each snapshot of website. For this you needed of a kind of tools that check it for you. There’s much more work to do. Wrong?

  5. regarding this vulnerability, what would a typical attack look like? would it be code that loads an iframe that links to an exploit kit? the reason i ask is because i am wondering what the real risks are to my own computer when visiting a website..

  6. Hi @robertpaprocki:disqus

    What we analyze and respond to depends on what we find to be interesting, coupled with their existing or potential impacts to the greater web. We often like to reserve our releases to things we find and disclose internally, or more importantly can add significant value to. That doesn’t mean we won’t write about something that’s already been released, but in those cases we’d have to have something of value to contribute to it (i.e., maybe a cool way to exploit it).

    Hope this helps. As you might imagine, there are many many vulnerabilities released daily, trying to write about each would be too taxing and would do away with the value form high severity / high impact ones like the ones we write about here.

    All the best

    Tony

  7. As soon as we received Marc’s email, we got to work to patch the vulnerability. We apologize for any inconvenience this may have caused, and we thank Sucuri for the thorough analysis they performed on our code.

  9. @Tony Perez, are you currently mitigating this vulnerability in your WAF? I couldn’t understand that from the last paragraph. from what I understand attackers need to base64-encode their payloads in order to initiate a successful attack, do you support base64 encoded SQL Injection vectors?

  10. Great find. I wonder which other plugins will fall prey to trusting very bad authentication controls?

    Even with a stronger key PRNG, what about chosen-prefix collision attacks, timing attacks, and the non-strict comparison operator?

  12. i have problem with

    Warning: set_time_limit() has been disabled for security reasons in /web/htdocs3/freshnewonesk/home/www/wp-content/plugins/super-social-content-locker-lite/super_social_content_locker.php on line 18

    Can you help me?

Comments are closed.

Related Categories
You May Also Like