WordPress Symposium plugin multiple stored XSS vulnerabilities

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

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

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

Secunia Advisory SA 49506

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:

WordPress A Page Flip Book plugin local file inclusion vulnerability

Secunia Advisory SA 49505

A page flip book for WordPress allows for different languages to be used. This is toggled by posting “pageflipbook_language” to the blog, which will update an option and then include the appropiate language. This is done in the main file, pageflipbook.php, which is always included.

We can see that it checks if “pageflipbook_language” is included in a POST parameter on line 30, it will update the option on the blog, otherwise it will pull the language value from the option and put that into the variable. This value is supposed to be the name of a php file. After that, it will include the chosen language file on line 47.

But because there is no validation that the file is a valid language file and there is no directory transversal, we can do a local file inclusion attack on this:

WordPress Symposium plugin multiple SQL injection vulnerabilities

Secunia Advisory SA 49534

Analysis of group_menu_settings vulnerability
The group_menu_settings function in /ajax/symposium_group_functions.php allows an user to show settings for a group. The function takes a POST parameter called “uid1″, which is used for a sql query.

However due to an incorrect use of wpdb->prepare, the groupID is never sanitized. Also the function does not check user credentials until line 616, and as such allows for a SQL injection through a simple POST request like this:

Analysis of loadComposeForm vulnerability
The loadComposeForm function in /ajax/symposium_mail_functions.php is used to fetch the display name of an userID through a simple SQL query like this:

It first checks if the user is logged in, and then takes to mail_to POST parameter and append it to the query. But because there is no validation that the mail_to variable is in fact an integer, we can make a POST request if we have an authentication cookie, and exploit this SQL injection vulnerability:

Analysis of getReply vulnerability
The getReply function in /ajax/symposium_mail_functions.php is used to fetch the display name of a recipient and message information about a particular mail.

It first checks if the user is logged in, and then takes to mail_id and recipient_id POST parameter and stitches those into 2 SQL queries using simple concatenation. However due to a lack of validation of the parameters being integers, we can exploit this:

Analysis of symposium_openchat vulnerability
The symposium_openchat function in /ajax/symposium_bar_functions.php allows for opening a chat with another user on the site. It does so by getting the chat_to POST parameter, which si expected to be an integer, and then checks if that chat already exists:

If you’re logged in and the chat does not exist, on line 572 it will then insert a new chat and select the display name from the user table, and incorrectly use the wpdb_prepare function. By rather concatenating the ID in instead of passing it as a parameter, we can now select data out of the database like this:

Analysis of getEditDetails vulnerability
The getEditDetails function in /ajax/symposium_forum_functions.php gets the contents of a post for the edit page.

It checks if you’re logged in, and then takes the tid POST parameter and concatenates it into a SQL query without casting it to an integer or otherwise sanitizes it. This means we can exploit it by making a request like this:

Multiple blind injection spots in /ajax/symposium_mail_functions.php
On line 94, 101, 208, 210, 274, 276 in /ajax/symposium_mail_functions.php there is also a lack of validation of integer inputs, which allows for arbitrary query execution.

WordPress Quotes Collection plugin cross-site request forgery vulnerability

Secunia Advisory SA 49653

A type of vulnerability that seems to be fairly common is CSRF. You can obviously speculate as to why, but I found this interesting one. I normally won’t publish CSRF vulnerabilities, but there are cases where they can abuse the inherent trust that is put in an admin to not attempt to exploit the blog readers.

In this case, because the admin pages did not make use of nonces, we are able to craft a page which will make the user make a GET request with a XSS payload, which will at no point be sanitized besides being escaped for inserting into the database.

If we either make this request directly, simulating a CSRF attack, or actually create a malicious page and convince an admin on a WordPress blog with this plugin to click on your link, we can cause a persistent XSS due to the lack of a nonce and sanitizing of html input.

WordPress Zingiri Shop plugin “abspath” remote file inclusion vulnerability

Secunia Advisory SA 49676

I had been looking at this particular piece of code for a while. At a glance, while the handling of the looks somewhat safe due to the validation that the input path is in fact a directory, so at best you could sort of chain an exploit with this. The question is, how could you take this to a RFI? Lets look at /fws/download.php:

As you see, this may very well look safe at a glance. For us to be able to exploit the fact that the ‘abspath’ variable is user controlled, we need to get a true back from is_dir. I checked with google how to pull this off when providing a remote host. This isn’t possible with HTTP, and nobody suggested an alternative. For this to work, the protocol wrapper needs to support the “stat()” family of functions. HTTP isn’t one of these. But as it turns out, FTP is. Bingo! We now have a piece of code that through a very specific detail in the PHP implementation, that we can exploit.

By putting up a FTP server with some specified credentials, and a file called wp-blog-header.php with some malicious PHP, we can include an URL in the abspath GET parameter, which will exploit this vulnerability:

WordPress Mac Photo Gallery plugin “albid” arbitrary file disclosure vulnerability

Secunia Advisory SA 49650

This vulnerability relies on a lack of validation of the “albid” in macdownload.php, which is passed straight into the path that is read at line 37 into the response. This cases an arbitrary file disclosure vulnerability.

If we make a request like this, it will cause the code to read out the wp-config.php file, which will contain database credentials in.

WordPress Nmedia MailChimp widget “abs_path” remote file inclusion vulnerability

Secunia Advisory SA 49538

This vulnerability is nothing but a textbook arbitrary file inclusion vulnerability. The file is used to interacting with the mailchimp API. But the very first 2 lines of executable code in /api_mailchimp/postToMailChimp.php, it goes ahead and accepts a path for loading a file.

By making following request, where the url has a file called ‘wp-load.php’ or otherwise will return php code, or using the proof of concept code, we can exploit this

Proof of concept code