Advisory for: WP-Slimstat
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’s 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 “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 approx. 30 million values to test, something doable within 10 minutes with most modern CPUs).

The only piece missing to be able to bruteforce the site’s timestamp is 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 bruteforce 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.

Via Sucuri.net