ceriksen.com

Advisory

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.