WordPress Symposium plugin multiple SQL injection vulnerabilities

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

Leave a Reply