Spectacularly Bad

Another round of notable WordPress plugin vulnerabilities made the rounds today- nothing particular noteworthy, just a smattering of XSS, SQLi, and form uploads. The Rich Counter upload vulnerability caught my eye as the PoC notes the exploit vector is through the user agent header. Given that unsanitized user input is more often exploited in query string and POST argument vectors, I thought this was worth a quick once over.

This plugin is awful- it doesn’t conform to WP’s style guides, it abuses the hell out of globals, and it ignores the wpdb object completely, instead using the old mysql PHP API (which means I couldn’t even get it running at first- WordPress will not provide the connection resource that the bare mysql_connect() call needs when PHP 5.5 is running). The noted exploit vector appears to be in this query:

For context, here are a few of the helper functions:

So, some attempt is made to sanitize user input; vars that are not escaped in this query are generated via additional function calls, such as “browser=’$counter_browser'”; this is built with the following function:

Two issues so far. We can have this function return any arbitrary string, as long as the user agent header doesn’t match any of the definitions in $arr_browsers- getBrowser() will just return a single quote-stripped first word in our string. The other problem is that the raw user agent header is saved in the “agent” column after being run through mysql_escape_string(), which won’t prevent against stored XSS. Not being able to store JS with quotes might make a cookie slurp a bit more tricky, but not impossible.

Another vulnerability arises in setting the “ip” column (this is done with ip=’$g_addr’). $g_addr is built with another helper function:

Sure, let’s just go ahead and blindy trust the X-Forwarded-For header. Keep in mind that SV() doesn’t run addslashes if magic_quotes_gpc is enabled- and magic_quotes_gpc doesn’t escape HTTP headers (get/post/cookie, remember?). Additionally, addslashes is known to be an inadequate defense against SQLi.

The Wordfence advisory indicated the plugin may be abandoned, but the changelog notes an update less than 2 months ago. I’d still call this one “spectacularly bad”, if we hadn’t already seen ten thousand examples of awful practices and wet-noodle attempts at sanitation. I’ll go ahead and wrap up with another “helper” function that summarizes how fascinatingly awful this plugin is:

… yikes.

Leave a Reply

Your email address will not be published. Required fields are marked *