Filed Under (Plugin Reviews, WordPress) by DK on 8 October 2007

While going through the current security plugins for WordPress, I came across an interesting project called, "Inspector WordPress" which is not quite there, but may offer some extra protection in the future.

wordpress inspector logo

What it does

This plugin monitors each request to your wordpress blog and based on conditions you can define in the options pane it interrupts the attacker’s action and logs it.

How it works

The plugin has a list of security conditions (stored in conditions.txt). These rules define what requests are considered bad. I took interest in the plugin to see if we could use it in the WP hardening project.

Pros

  • The Inspector WordPress menu system is quite nice. It provides a logging page on the desktop as well as a configuration page under the options menu.
  • Can be an early warning system to alert you that you are under attack


WordPress Inspector pics


WordPress Inspector pics

Cons

  • There is no CSRF protection, so an attacker may be able to change/delete your rules remotely
  • There is also a persistent XSS vulnerability which may be used to compromise your entire blog.
Affected code:
250 $newConditions = $_POST["conditions"];
251 file_put_contents(dirname(__FILE__).”/conditions.txt”, $newConditions);

Summary

The Inspector WordPress features will be included in the upcoming WP hardening project, however, if you do want to use this plugin, I’d wait until the author has addressed the security issues we found in "cons".

In short, I think its a great first step to something bigger and better. As an additional side note, this plugin will wreck havoc with your application-level firewalls (i.e. ModSecurity) if you try to update the ruleset. This will be the challenge any plugin of this nature will face if it allows rule updates over HTTP.

Read and Contribute to BlogSec News!

Comments

The Doctor What on 8 October, 2007 at 5:31 pm #

Can you explain how that code example is a problem?


DK on 8 October, 2007 at 9:08 pm #

There is no sanitisation of $_POST["conditions”];".


The Doctor What on 9 October, 2007 at 3:04 am #

Yes. I see that. But why is it a problem? It goes straight into a file. Is file_put_contents() susceptable to an attack through it’s data?

Ciao!


DK on 9 October, 2007 at 8:23 am #

Doc, read this: http://blogsecurity.net/wordpress/articles/article-280507/

Because the rules are fetched from the text file and displayed to the user, it is possible to inject malicious HTML (due to CSRF vulnerability) that will then be executed everytime the admin opens that page.

If conditions.txt was conditions.php, it would even be possible to execute malicious queries on the web server.

Doc, if you still don’t follow drop me an email via the BlogSecurity contact form and I’ll explain it further.


The Doctor What on 9 October, 2007 at 4:51 pm #

DK:

But surely the problem is that it’s displaying an untrusted file? Displaying any kind of log file is displaying untrusted content.

FYI: I’d read the code, but the site seems gone or something.

Ciao!


DK on 9 October, 2007 at 8:43 pm #

Doc, using htmlspecialchars() to sanitise the data before putting it into the log file would prevent this problem.


The Doctor What on 9 October, 2007 at 9:27 pm #

I understand the vector now.

But the problem isn’t putting unchecked content into the file, per se. There is nothing you can put into conditions.txt that would break a text-editor or text-viewer.

However, if conditions.txt is shown again at a latter point via a web page, then it should be escaped prior to showing.

Of course, there are other attacks, such as a disk-space DoS (large conditions will fill the disk up). Etc.

As I said, I haven’t been able to get to the site.

Ciao!


Comment
Name:
Email:
Website:
Message: