Archives

by Charlie Eriksen

WordPress Online Store arbitrary file disclosure

Advisory

Secunia Advisory SA50836

Analysis of vulnerability

The plugin hooks two functions as a part of its core functionality in core.php by adding an action for init and admin_init.

The first line calls into osc_session_init_fend whenever a WordPress page is loaded, in order to set up a session.

The interesting thing is that on line 136 is checks the “force” request variable to see if it matches to “downloadnow”. If it is set, it will change the content type of the response to be a download, and then read the file set by the request variables “turl” and “file” and write that to the response. These variables are however not sanitized, which leads to an arbitrary file disclosure. We can exploit this by making a request to any page with following querystring, which will force the browser to download a page containing the contents of the wp-config.php file at the top of the file:

 

by Charlie Eriksen

WordPress Zingiri Forums arbitrary file disclosure

Advisory

Secunia Advisory SA50833

Analysis of vulnerability

The Zingiri Web Forums for WordPress writes our a header for the forum in forum.php through adding an action to wp_head.

So on each load of the WordPress blog it will call into zing_forum_header. The first call it makes it into zing_forum_output, which is rather long. I’ve highlighted two areas:

We can affect the value of $zing_forum_to_include through the zforum GET variable. This is then used in a big else if statement. Here is the block of code that is executed if we set that to css:

If we don’t set anything expect the “url” get variable, we can cause it to be fed into the file_get_contents call on line 554. We can abuse this to disclose the contents of the wp-config.php file like this:

 

by Charlie Eriksen

WordPress Google Document Embedder arbitrary file disclosure

Advisory

Secunia Advisory SA50832

Analysis of vulnerability

Google Document Embedder offers a proxy for forcing a PDF to download rather than use the default browser handler. It implements this through /libs/pdf.php:

First it will check if allow_url_fopen is enabled. Then it checks the two variables we need to provide, the “fn”(Filename) and “file” GET parameters. If both are provided it will verify that the filename ends in .pdf. From there, it goes onto deicing how to fetch the file, and eventually call into file_get_contents by passing the file GET parameter straight into the call. Note that the filename is only used to determine the filename returned on line 45. Because it will use file_get_contents if at all possible, we can provide a local path to include. We can for instance fetch the wp-config.php file like this:

 

by Charlie Eriksen

WordPress Duplicator plugin arbitrary file disclosure

Analysis of vulnerability

In version 0.3.0 of WordPress duplicator the file /files/installer.rescue.php and /files/installer.template.php which were added for security reasons. The file was made to download an installer file. They both start with this snippet of code::

If the “get” querystring parameter is set, it will read the file specified by the “file” querystring parameter and read that into the response as installer.php. But because this file is deployed by default to all installations and it does not sanitize the “file” variable, we can use it to read any arbitrary file by making a request like this:

 

by Charlie Eriksen

WordPress Cimy User Manager arbitrary file disclosure

Advisory

Secunia Advisory SA 50834

Analysis of vulnerability

The Cimy User Manager is made to be able to export data from WordPress. The file cimy_user_manager.php has an init action which decides whether or not to download some content from the site:

First it checks if the cimy_um_filename POST variable is set. Then it goes to check if the referer is from the admin page, which is a flawed way of authentication. But if it thinks you come from the admin page, it will attempt to protect against path traversal. It is pretty obvious that we can fake the referer header. But we can quite easily bypass the path traversal. Lets have a look at an example.

Take this string: …/…//
Now lets see where we match ../:  .../...//
Which leaves us with: ../

This tells us that the path traversal “protection” on line 78 can be bypassed trivially.

Additionally, in the case where you’d want to obtain a wp-config.php file, which contains credentials and other very critical information about the blog, we do not need to bypass this, because when init is called, the working directory is the wordpress base folder, which contains the wp-config.php file. Here’s an example request showing how to pull the wp-config.php file: