Weblog Tools Collection

Thanks for visiting! If you're new here, you may want to subscribe to our RSS feed. This blog posts regular Wordpress news, updates of themes, plugins, ideas, hacks, quick fixes and everything about blogging, especially about Wordpress. Go ahead, subscribe to our feed! You can also receive updates from this blog via email.

S@BUN is at it again, this time, reporting multiple SQL Injection Vulnerabilities within the Photo Album plugin for WordPress. According to the security bulletin:

Multiple vulnerabilities have been identified in Photo Album (plugin for WordPress), which could be exploited by remote attackers to execute arbitrary SQL queries. These issues are caused by input validation errors in the “wppa.php” script when passing user-supplied parameters (e.g. “photo” or “album”) to certain functions (e.g. “wppa_album_name()” or “wppa_photo_name()”), which could be exploited by malicious people to conduct SQL injection attacks.

Multiple security advisory services places this round of vulnerabilities as a Moderate Risk. For example, FrSIRT describes the Moderate risk as being:

Remotely and locally exploitable flaws, which could lead to denial of Service or privilege escalation.

Versions 1.1 and prior of this plugin are vulnerable. As always, it is recommended that you disable this plugin until a patch for it is released.

[EDIT] Version 1.1 is a fix for this vulnerability. Versions 1.0 and prior might be vulnerable.

I battled this one for a little bit and I hope the information here helps someone.

First and foremost, there are various version of this problem and they might have different causes stemming from the same source. I list them here in no particular order. I found all the topics starting with a search for the dreaded “Method Not Implemented” 501 error code from the admin panel of WordPress.

POST to /test/wp-admin/index-extra.php not supported: This error is also noticed on post.php and theme-editor.php. Now there are various WordPress Forum posts providing somewhat workable solutions to the problem. I tried some of the solutions but either they did not work for me (I had not looked that closely at the error before trying them) or they were too broad and I did not care for the results. There is some finger pointing in both the forums and the various other pages I found but I believe that the answer lies somewhere in the middle.

In my case, posting caused a “PHP Injection Attack. Matched signature” error that I found in my Apache error logs and the error generated on the browser said “Method Not Implemented 501 error code” with the name of the offending file. This error was caused by ModSecurity which is an Apache module that helps secure web applications on the fly. Now the errant bit of text was in ARGS:content that was bring posted to the server and it matched the regex in one of the ModSecurity rules. It could have been generated by WordPress itself or it could have come from one of the various plugins I have on my blog. I am not sure and I have not taken the time to investigate it further. (please provide more information if you have any). This was a false positive from my perspective and I needed to find an elegant and safe solution that would work.

On reading further about false positives, here is the solution that worked the best. Since I wanted to disable the rule that was catching the post, and not disable the whole mod security for either a file inside the admin folder or the whole admin folder, I found a way to do just that through the Apache configuration files for the virtual host. I found the rule number that was being triggered in the Apache error logs and though I will not disclose the rule number here for security reasons, it was relatively easy to spot. Then I added the following code to my httpd.include (or httpd-vhosts.conf depending on your hosts’ version of software) at the end of the file.

<LocationMatch "/wp-admin/post.php">
SecRuleRemoveById XXXXXX
</LocationMatch>

where XXXXXX was the rule number. Now an ever better solution would be to readd a new rule with the offending regex trimmed out or a !ARGS:content to the Secrule section to only apply to post.php inside the admin folder.

Some caveats: This case ONLY applies to a blog I was working on and the content that was being posted. Your case might be different. If you want to use this method to fix the problem and have no access to your server, just direct your administrator to this post. The secret is to find the offending rule in your error logs and use the rule number to isolate it from the file that it breaks by using LocationMatch and SecRuleRemoveById in your Apache vhosts config file.

Any insights or suggestions will be highly appreciated by me and I am sure by other readers.

NBBN has discovered some cross site scripting vulnerabilities for the WP-Footnotes plugin version 2.2 for WordPress.

Input passed to the “pre_footnotes”, “priority”, “post_footnotes”, and “style_rules” array elements in the “wp_footnotes_current_settings[]” array in the admin_panel.php script is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in context of an affected site.

The good news this time around is that, ‘register_globals‘ must be turned on for exploitation to occur. If you are using this plugin on your site, it is advised that you disable the plugin until a security patch has been released. According to the security bulletin, the solution is to edit the plugin source code to ensure that input is properly sanitized.

Again, if you know that your webserver has register_globals turned off, you are in the clear.

S@BUN has reported an “id” based SQL injection vulnerability within the WordsPew plugin version 3.x for WordPress.

Input passed to the parameter “id” in wordspew-rss.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

The solution again is to edit the source code of the plugin to make sure that input is sanitized.

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.

According to an advisory released by Packetstorm, a fellow by the name of g30rg3_x has discovered two bugs within Dean’s Permalinks Migration Plugin version 1.0. The first bug relates to XSRF and can allow an attacker to force a user to perform an unsolicited action that when combined with an XSS bug that has also been discovered, allows the attacker to gain valid credentials.

g30rg3_x actually provides a detailed explanation into the problem:

Since the variable $dean_pm_config['oldstructure'] its not correctly sanitized (when retrieving), this allow any user to store/save “malicious code” inside the database and later be injected this “malicious code” when the data is retrieved. Using the XSRF as a “combo” we can create crafted pages that will force users to conduct this injection and steal some valid credentials to the WordPress based CMS.

g30rg3_x has tried to contact the author of the plugin but has not had any success in doing so. Instead, he has taken on the liberty of releasing his own special sub-version for the plugin which contains the necessary fixes. The plugin is called 1.1-gx and uses some of the WordPress coding standards that are suggested by WordPress developers. You can download a fixed version of this plugin by clicking here.

If you are currently using the latest release of the WP-Forum plugin, listen up. The websec security team has discovered a vulnerability within this plugin that can be exploited by malicious users to conduct SQL injection attacks. According to Secunia:

Input passed to the “user” parameter in the WordPress installation’s index.php script (when “forumaction” is set to “showprofile” and “page_id” to a page with the “<!–WPFORUM–>” tag) is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

This vulnerability when exploited successfully allows the individual to retrieve usernames, password hashes, and email addresses for all users, including administrators. However, the user has to have knowledge of the proper database table prefix. This vulnerability has been confirmed in version 1.7.4 which is currently the most recent version available for download.

Description:

WP-Forum is a WordPress plugin that enables you to have a forum directly attached to your WordPress installation. The plugin is based on Simple Forum.

[EDIT] We wish the plugin author was notified of the vulnerability and given a chance to fix it, but there was no mention of it in the advisory. So until a fix is released, we suggest that the plugin is disabled and removed.

[EDIT] As pointed out in the comments, not the same as Simple Forum WP Plugin.

Daniel Cuthbert has written a paper on ModSecurity and Wordpress. While I praise the work and the effort, I am not sure why they did not find it in themselves to protect the PDF document that they are distributing using some sort of an SHA1 checksum or the like to ensure the integrity of the download. Now I know that these guys know what they are doing but I have a problem with security related papers, help documents, scripts and other items when they cannot be verified with the source and the source itself cannot be verified with the original author of the product.

I have always been a big proponent of mod_security and I think it provides a comprehensive layer of web security without as much overhead. Although I have never thought of WordPress’ security to be as weak as the BlogSecurity folks have claimed it to be. mod_security requires various rules to be put in place for it to filter out malicious activity. This paper goes through some of those generic PHP rules and some specific WordPress based rules for webmasters to add to their mod_security filters.