WP Symposium multiple SQL injection vulnerabilities


Secunia Advisory SA50674

Analysis of groups get_user_list SQL injection vulnerability

This first vulnerability in the /ajax/symposium_groups_functions.php file makes use of the functionality for people to view the users of a group. It accepts a groupID(gid) which it inserts without validation into a query and then spits out the result, even if you are not authenticated.

Because it uses multiple line, we have to do a bit more work than the other ones. We can craft an union select which fits in and uses the rest of the query without a problem like this, and dump a list of usernames and password hashes:

Analysis of get_album_item.php SQL injection vulnerability

This SQL injection vulnerability is practically as simple as it gets. And it even makes it simple for us in get_album_item.php.

It reads in 2 variables from $_REQUEST, which can be either GET or POST parameters. That’s very handy. It then proceeds to stuff the size into the SELECT part of the query using plain concatenation without previous sanitization, and then uses the wordpress prepare method of passing in content to a query safely using a printf syntax, which is safe.

Because we have control over the SELECT part of the query, we can easily select out a single piece of data at a time, which is sufficient to dump the whole database as needed. Here we can pull out a password from the users table, for instance, using a very simple request, no authentication required:

Analysis of symposium_show_profile SQL injection vulnerability

This vulnerability relies on the way which profiles are shown in Symposium. It calls into the symposium_show_profile method in symposium_profile.php file, which finds out what ID to show information for like this, assuming you are authenticated:

Note that the last line takes the $uid variable as determined on the first block of code, and simply puts it straight into the query without any sort of input sanitation. So by creating a page with the “[symposium-profile-menu]” short-tag, we can inject into the page with a simple URL like this:

Analysis of forum updateEditDetail blind SQL injection vulnerability

This vulnerability is actually more like 2. We can see that in this standard ajax call in /ajax/symposium_forum_functions.php file that there is a total of 4 SQL queries executed, 2 updates and 2 selects. Notice that the $_POST parameters aren’t sanitized before use, yet all but the 3rd query uses concatenation to create the SQL query, which creates SQL injection conditions if you are logged in.

We can exploit it like this with an appropriate set of cookies:

 Analysis of profile addFriend blind SQL injection vulnerability

A similar lack of input validation can be seen in the /ajax/symposium_profile_functions.php file in the addFriend action handling code. It takes in an ID for a friend to add and then starts putting together some SQL like this:

Notice that it simply concatenates the $friend_to variable into the query. While this query is not used for output, we can still do a blind SQL injection if we’re logged in.


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 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.