Today, we have a moderately critical SQL Injection Vulnerability that was discovered by HouSSaMix in the “WP-Cal” plugin version 0.x for WordPress. According to the Secunia Advisory:
Input passed to the “id” parameter in functions/editevent.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.
Users with a malicious intent can conduct SQL injection attacks which may result in the retrieval of usernames, password hashes, and email addresses for users and administrators. However, the malicious user must have knowledge of the database table prefix.
So far, version 0.3 has been confirmed as having this vulnerability with other versions possibly being affected. Secunia states that the solution involves editing the source code to ensure that input is properly sanitised.
Click here to read the original advisory which provides an example of the exploit as well as the vulnerable code.
It is strongly advised that if you are using this plugin, to disable it’s functionality until a patch is published.
The other security bulletin deals with the AdServe Plugin.
A person who goes by the handle “enter_the_dragon” has discovered a vulnerability within the Adserve Plugin version 0.2 for WordPress. The vulnerability can allow malicious users to conduct SQL injection attacks that can result in the retrieval of usernames, password hashes, and the like. Just like the other SQL injection vulnerabilities, knowledge of the table prefix is required to perform these attacks. According to the security bulletin:
Input passed to the “id” parameter in adclick.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.
You can check out the original bulletin containing a detailed description of the problem as well as an example of the exploit by clicking here. As with any plugin that experiences a security bulletin, it is strongly encouraged that you disable the plugin in question until a patch is released.
What a good thing that the table prefix is not
wp_on 99% of the WordPress installations out there. 😉See, this is why I love WordPress. The open community who would rather spread the information regarding the problem than exploit it. I remember working with a now defunct CMS that has a slew of holes. Rather than people letting everyone know, they would go around to any site they knew and would use the exploits – ruining all sites they found. Not very helpful.
BUT I’m glad WordPress community is good. Kudos.
@Alex I was checking out the Codex article for hardening WordPress and it is not suggested anywhere within the document to change the default database prefix.
@Tadd Do you enjoy these types of posts? Unfortunately, I see too many security related news posts for plugins but I can continue to write about the bulletins of you guys feel this is necessary.
This is really interesting, and nice information.
Very nice work done guys. By the way, do we have any workarounds around them from our side? any code changes you or anyone can suggest?
I think a work around, resolution should always be posted alongside such a vulnerability disclosure.
Jeffro: Er, that was meant ironic. I wrote that because the sentence “However, the malicious user must have knowledge of the database table prefix.” sounds like guessing the table prefix of a WordPress installation would be a substential blocker for an attacker. Btw, I also wouldn’t suggest changing the prefix, simply because there might be a bug in a plugin where wp_ is hardcoded. Unless you really have the necessity to change the prefix and you are ready to debug plugins, you should leave it.
@Alex Thanks for letting me know regardless. I was thinking of adding the prefix stuff to the codex article about hardening WordPress but because of the point you brought up, It’s better that I didn’t.
Jeff – yeah I do enjoy these posts … not, like enjoy in as in a novel or movie … but I’m grateful that there are people who are helpful and point out problems with plugins that could bring your whole website down.
Any patch yet for WP-Cal? I’ve had it disabled now for a while and would mind switching it back on.