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).
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 “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:
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:
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:
A quick look at this method’s way of handling associative arrays led us to a possible blind SQL injection 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.
Nice post! How do you guys decide which vulnerabilities to write about? For example, there was a recent vulnerability in WordPress Video Gallery 2.7.0 (https://wordpress.org/plugins/contus-video-gallery/) that allowed for unauthenticated DB dumps, and came with a googledork (http://www.exploit-db.com/exploits/36058/). Any reason slimstat got traction, and contus video gallery didn’t?
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?
No, it’s in the article right below the part about the secret.
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).
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?
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..
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
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.
Nice … 🙂
@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?
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?
My website a little slow and will not update could that be a virus?
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.