WP Plugin Security: Multiple Leaks in WP-PhotoContest

What IS WP PhotoContest? The readme states:

This plugin permits you to create a ‘voting for photos-contest’ from the WordPress admin panel Subscribed users can uploads photos and everyone else can vote for the uploaded photos (sic).

The author could rephrase that as follows:

This plugin permits everyone to inject SQL commands into the database and to do a cross site scripting attack.

You most certainly do not want to install this plugin even if you are in the mood for a photo contest.

I did not review the whole plugin, just login.php where I have found the XSS leak and view.php as well as viewimg.php where the SQL injection leaks are located. Most propably there are even more leaks as this plugin seems to be from an inexperienced PHP programmer.

The author has been notified at UTC 1022. Information applies to version 1.0 and 1.0.1.

Details

The XSS leak is all too common:

$frompost_id = $_REQUEST['prid'];
...
<a href="<?php echo bloginfo('wpurl'); ?>/wp-content/plugins/wp-photocontest/login.php?post_id=<?php echo $frompost_id; ?>"><?php _e('Log In', 'wp-photocontest') ?></a>

There it is. A classic.

SQL injection in view.php and viewimg.php:

$post_id = $_REQUEST['prid'];
...
$q1 = "SELECT contest_id, start_date, end_date, contest_path, contest_name, intro_text, num_photo FROM ".$wpdb->prefix."photocontest_admin where post_id=$post_id";
$out = $wpdb->get_row($q1);

This is also a classic and a beginners mistake as well. There is no security whatsoever. Don’t consider this plugin to be safe when the mentioned leaks have been fixed!

What to do for plugin users

Deactivate and remove WP-PhotoContest immediately and wait for a revised plugin.

This issue has been resolved

WP Plugin Security: When the genius is out for lunch

I am in the mood for some more ranting… Why am I doing this? The low security level in the WordPress community aggravates me. And I care about the security of WordPress users out there. So here goes the next issue.

It’s a rather insignificant XSS security vulnerability but since the WP theme’s author runs the Website GeniusHackers.com and his Swift theme for WordPress is getting more than 2000 downloads per week you might be interested in this.

There is a simple XSS hole in search.php of the Swift theme. GET parameter ‘s’ does not get sanitized or even touched. Go to GeniusHackers.com, paste this into the search box and press enter for a live demo.

<style>*{visibility:hidden}html,body{visibility:visible}</style><div style=visibility:visible;line-height:150px;font-size:200px;color:green;position:absolute;top:0;left:0;padding:0;margin:0;background-color:red;width:10000px;height:10000px;margin-left:-200px;margin-top:-300px;padding-top:100px>XSS XSS XSS XSS XSS<script>alert(String.fromCharCode(88)+String.fromCharCode(83)+ String.fromCharCode(83))</script></div>

If a red page appears containing ‘XSS’ and a JS alert box containing ‘XSS’, the genius hacker has not yet fixed it.

You may want to check your own blog the same way. If it is vulnerable, search for something like this in your theme’s PHP files:

Search results for "<?php echo $_GET['s']; ?>"

and replace with

Search results for "<?php the_search_query(); ?>"

Search result page might still look ugly after a XSS attempt but at least nothing gets injected and rendered or even executed.

Update: Theme has been updated. Download the updated version with WordPress.org. See SwiftThemes.com for more information.

WP Plugin Security: WP Shopping Cart/WP eCommerce Security Holes

Another week, another security hole. This time I have found several holes in ajax-and-init.php from WP-eCommerce v3.7.4 aka WP Shopping Cart. It is the latest stable version. Let’s go.

The first issue is an unrestricted file deletion security breach. Remote attackers can trick a logged in WP user to click prepared links that can make the above mentioned script to delete files in webserver context. WP users must be logged in, a simple subscriber account would be sufficient.

The second issue is a SQL injection security breach. It is possible for remote attackers to trick a logged in WP user to click prepared links and have “Products List” items deleted and table “Products Files” truncated. As above, WP users must be logged in, a simple subscriber account would be sufficient.

There is at least another hole that enables remote attackers to change the plugin’s configuration under similar conditions.

What to do

Upgrade immediately to version 3.7.5 RC1.

Conclusion

The author of the plugin has been notified. I wonder though why these security leaks have not been mentioned in the 3.7.5 RC1 announcement… Judge for yourself.

UPDATE Oct 19, 2009: Leaks are still unfixed in the current stable version.

WP Plugin Security: WP-Ajax-Edit-Comments

Those who are WordPress admins should already know it: WordPress plugin quality often is quite worrisome. The latest smoking gun is WP Ajax Edit Comments. Normally I do not disclose security issues but this one is so obvious it freaks me out. Just to make clear: You do not have to be a seasoned programmer or admin to find bugs like this one. I did not check the whole potential of this vulnerability, maybe it also lets one inject SQL commands — I don’t know.

Let’s have a look. In file “comment-editor.php” (and in “move-comment.php” and “request-deletion.php” BTW) there’s this line:

“`php
$commentAction = $_GET[‘action’];
“`

Yellow alert. But let’s look further before drawing a conclusion yet. $commentAction does not get touched anymore until this line occurs:

“`php
<input type=”hidden” id=”action” value=”<?php echo $commentAction;?>” />
“`

RED ALERT. This is a beginners mistake. The leak ist existing at least since version 2.2.6.0 while the current version (as of this writing) is 2.4.0.1 which also is vulnerable. It has been around for at least one year without someone noticing or fixing it despite being so obvious. According to WordPress plugin database it has been downloaded over 140,000 times so there may be tens of thousands of vulnerable WordPress installations.

Attackers could inject arbitrary HTML, like “THIS SHOULD NOT BE POSSIBLE”. Of course, criminals could create malicious pages this way and host them on remote WordPress sites.

wpajaxedit

How to fix it quick!

Replace this line

“`php
$commentAction = $_GET[‘action’];
“`

with these lines:

“`php
$commentAction = $_GET[‘action’];
$commentAction = addslashes(preg_replace(“/[^a-z0-9]/i”, ”, strip_tags($commentAction)));
“`

It’s a quick and dirty fix. But it gets the job done. An even better approach would be to reject “action” parameter values with other characters than a-z.

The author of WP Ajax Edit Comments has been notified.

UPDATE: There is a new version that seems to be fixed.

File Disclosure

Wenn man eine Sicherheitslücke dieses Kalibers entdeckt, staunt man Bauklötze… Auf dem Webserver eines Kunden habe ich folgendes Szenario vorgefunden:

Dort waren zwei virtuelle Hosts eingerichtet, beispielsweise

  • /var/www/www1.example.com/
  • /var/www/www2.example.com/

Anfragen an www1.example.com und www2.example.com wurden an die entsprechenden vHosts weitergeleitet. In den o.g. Verzeichnissen lagen dann das wwwroot, Datenbank-Backups, SSH-Schlüssel etc. herum.

Vielleicht ist das nicht grad die reine Lehre, aber mal ehrlich, bei wem siehts anders aus… :) Das beschriebene Szenario ist noch kein echtes Problem, solange sicherheitsrelevante Dateien außerhalb der wwwroots liegen und das taten sie ja — scheinbar.

Leider hat der ursprüngliche Admin, der den Webserver seinerzeit eingerichtet hatte und den ich übrigens nicht kenne, eines übersehen: In der Konfiguration des httpd war weiterhin /var/www als Standard-Rootverzeichnis eingerichtet. Und über die IP-Adresse der Maschine konnte man alles innerhalb von /var/www per http abrufen, also Datenbank-Dumps, SSH-Keys… alles. Man musste nur Pfade erraten. Das wäre im Prinzip kein Problem gewesen, weil man leicht hätte herausfinden können, welche Software dort läuft. Eine IMHO klassische File Disclosure-Sicherheitslücke.

Welche Schlüsse kann man nun daraus ziehen?

  1. Sensible Dateien dürfen nicht dort gespeichert sein, wo der httpd hinkommt.
  2. Zusätzliche Einstellungen dürfen nicht einfach auf die vorhandenen “aufgeflanscht” werden, sondern sie müssen im Rahmen des vorhandenen Sicherheitskonzepts gemacht werden.

Punkt 1 ist so eine Sache. Da halte ich mich selbst nicht immer dran, beispielsweise wenn eine Software es so voraussetzt und es zu aufwändig oder gar unmöglich ist, das zu ändern. Aber ein Ideal sollte dieser Punkt zumindest sein. Ob und wie weit man sich dem nähert ist eine andere Frage.

Punkt 2 halte ich daher für wichtiger. Als dritten Punkt könnte man vielleicht noch den nehmen: Wenn man schon Datenbank-Dumps auf dem Webserver speichern muss, sollte man sie zumindest verschlüsselt speichern.

Dass die Sicherheitslücke von mir behoben wurde ist klar denke ich :)

Wollen Sie auch Ihren Webserver von mir administrieren oder untersuchen lassen? Ich bin für Sie da, rufen Sie mich an.